Hello Darin ...
Friday April 24 1998, you wrote Rene Herman
 DM> Your TTime objects encapsulates a real object (in this case, an
 DM> abstract object that humans believe we understand): time.
I see what you mean, and regret having to disagree with you. My TTime objects 
really didn't do anything remotely resembling encapsulating the real world 
concept of time, or even my notion of such a concept. What's the substance of 
time (its data members) and what influences it, that is, which methods should 
I provide? If I knew, I would have won a Nobel prize. :-)
I hope I'm not over-interpreting your comments, but in my humble opinion 
object orientation shouldn't be made out to be more than a way of organizing 
computer code with advantages such as clarity and modularity, and 
disadvantages such as size and speed of the resulting code. Although it at 
times might provide for a useful abstraction, I feel that most real world 
objects, let alone concepts such as time, are far too complex to be 
encapsulated by, or even described by, a set amount of data and functions to 
operate on that data.
 DM> Abstract objects or abstract classes?  I've never heard the term
 DM> 'abstract object' before.
You were the one introducing the phrase, I just copied it. :-) But I must 
admit I thought you were referring to abstract classes.
 DM> A class is merely a description of what an object is and what
 DM> messages can be sent to it.
I just browsed the chapter on Windows programming using OWL, but I guess here 
you mean "which methods it has for operating on an object of the class" when 
you say "what messages can be send to it"? :-)
 DM> I always put main last with everything implemented either in other
 DM> modules (where I have a header that is #include'd) or above it.  I use
 DM> prototypes only in header files.
Very glad to hear it, I really prefer it that way. Of course, style is a to a 
some degree a matter of personal taste, but I wouldn't want to start of by 
getting into habits that are frowned upon by most other programmers.
 [ void function() / void function(void) ]
 DM> Both work, but the empty parenthesis is the "right" way for
 DM> everything in C++.
Thanks, I switched.
 [ NULL / 0 ]
 DM> I vastly prefer NULL.
Hate to admit it, since I don't, but you do of course have a valid point. 
Will see if I'm able to switch. :-)
 DM> Use the one in comments for both - but, yeah, spreading it out will
 DM> make it more readable.
Glad to hear it's "allowed", really disliked Tom Swan's way one-line way of 
doing things. I'm typing in most listings from the book as I go along, and 
everytime had to struggle with myself to *not* spread them out. :-)
 DM> One exception may be functions that merely redirect calls...
 DM>   int baz(int i)   { return b->baz(i); }
Agreed.
 DM> Any time I see "m_" in front of a variable, I know I can find its
 DM> definition in the class - it is local to the class, but still global
 DM> in that it can be modified by multiple functions.
Will have to consider this. I don't really like the "this->" method myself, 
but naming a constructors arguments the same as the class's data members does 
lend some clarity to the code, as far as I'm concerned. By the way, what does 
the "m" signify? I'm not sure I understand your comment about the "multiple" 
functions. Is there any other type? All class data members can be modified by 
all (non const) member functions, can they not?
 DM> Another possibility in this case is:
 DM> TExample(char* s) : s(strdup(s))
 DM> {}
I just might like this approach... :-)
 DM> I also have a "cchar" class that handles the strdup/delete paradigm
 DM> for you - it puts an array on the heap but it looks like any other
 DM> array on the stack - you don't have to delete it.  :-)
I am somewhat of a minimalist, I really prefer doing things such as that 
explicitly. Keeps me in touch with what's going on. :-)
 [ (draft) ANSI standard obtainable? ]
 DM> Someone else may help you there - I just go by what my compiler
 DM> allows me to do ... if it doesn't allow it (yet), there's no point in
 DM> doing it even if the standard allows it.  :-)
I agree, but what if you compiler *does* allow it, yet you aren't sure if 
others will? Or worse still, what if you aren't even sure yours will? For 
instance, I was wondering if it were safe to pass a NULL pointer to strdup, 
which would allow me to write something like
  TExample::TExample(const char *s)
  {
    this->s = strdup(s);
  }
without having to check for s being NULL first. Neither Borland's online help 
nor Tom Swan's function reference said one way or the other, so I had to dig 
into the RTL source to find out it *wasn't* safe, at least not on my 
compiler. I'm assuming the standard would have explicitly told me so.
 RH>> Hope I didn't ask too many questions at once. Please be
 RH>> aware that if you do reply I will very likely have some
 RH>> more lined up for you by that time... :-)
 DM> And I probably won't be the only one answering... good luck!
Thank you! I'll be addresing the next bunch to all again, hardly seems fair 
to make you into my personal teacher for having been the first one to answer 
that first question. Don't let it keep you from answering though, you're 
helping me lots! :-)
Rene
---
---------------