PM>> Apart from a few minor differences such as function names, there's only

 PM>> one



 PE> Even that's an issue.  E.g. I document Defaults() as guaranteeing

 PE> not to fail, whilst Init() can fail.  You only have the one,

 PE> Create(), which I presume can fail.  My Defaults() corresponds to

 PE> a C++ constructor, which can't really report errors.



A C++ constructor can fail, so in that regard it's more like your init()
than your default(). While it's true that a constructor can't return
anything, there are other ways of reporting errors.



I don't have an equivalent to your Defaults() as I've haven't seen any
benefit in it.



 PE> Although I think the creators have realised that's really botchy and

 PE> are working on/have completed a botchy workaround.



The problem with constructors (and destructors for that matter) is that
they are often called outside of your control so there's no way to get at a
return value. For instance, given the following declaration how would you
report an error?



    String x = "Hello";



The answer the C++ designers have implemented is to introduce exceptions.
Whether or not this is bodgie is a matter of opinion.



 PM>> I feel that making things private

 PM>> is the better approach as it discourages fiddling with the internals of

 PM>> the class.



 PE> When was the last time you saw code that manipulated elements of

 PE> the FILE data type?  There are millions and billions of programs

 PE> that use the FILE data type, which at least last time I looked at

 PE> (Watcom I think) was public, but I've yet to see anyone stupid

 PE> enough to manipulate the internals of the FILE class.  Who are you

 PE> trying to protect?  You've hired the wrong people if they're

 PE> manipulating stuff in a structure such as FILE.  And Cobol would

 PE> be a better language for such people, IMO.



It's not just updating the members of a structure I'm trying to discourage,
it's also reading them and relying on things that may change. One of the
tenets of OO is that the interface should remain the same, but the
implementation can change.



 PM>> My technique has one problem though. Because I typedef the class as a

 PM>> pointer to a void, and the type checking isn't strict enough to pick

 PM>> this up, it means that you can pass the wrong type of variables to my

 PM>> routines.



 PE> If that concerns you, why are you using void anyway?



Because the data structure I'm using isn't defined in the header file and I
needed to have a pointer to it.



 PE> I would still question the value of attempting to hand-hold C

 PE> programmers.  I do agree that that is the "exact" mapping to

 PE> C++, which is what this code is all about in the first place,

 PE> but I chose to just use the OO concept without the hand-holding.

 PE> I presume you're not trying to protect against yourself doing

 PE> the wrong thing?  BFN.  Paul.



I'm not attempting to hand-hold anyone. I'm just taking the OO view of
encapsulation. What I'm saying is that you don't need to know how this is
implemented and you should stop and think before relying on things that may
change.



This is basically the approach that C++ takes. If you really want to, you
can update the C++ header file and change all of the private key words to
public. In my code you can copy the structure definition into the header
file.





Paul



--- GoldED/2 2.42.G0214+