DM> Your TTime objects encapsulates a real object (in this case, an
 DM> abstract object that humans believe we understand): time.
 RH> I see what you mean, and regret having to disagree with 
 RH> you. My TTime objects really didn't do anything 
I disagree with your disagreement.  :-)
 RH> remotely resembling encapsulating the real world 
 RH> concept of time, or even my notion of such a concept. 
 RH> What's the substance of time (its data members) and 
 RH> what influences it, that is, which methods should I 
 RH> provide? If I knew, I would have won a Nobel prize. :-)
You provide the methods that you need.  It is still an encapsulation, even if 
it isn't "fully complete" yet.  Ideally, yes, your time class would be a 
complete encapsulation, but, in practicality, it just needs to do what is 
needed - anything else is superfluous.  While programmers are good at 
"superfluous", at some point we need to get on with the program.  :-)
 RH> I hope I'm not over-interpreting your comments, but in my humble opinion 
 RH> object orientation shouldn't be made out to be more 
 RH> than a way of organizing computer code with advantages 
 RH> such as clarity and modularity, and disadvantages such 
The clarity advantage is because we can "relate" with the code.  We know what 
time is - if we need to do something to/with a TTime object, we will know, 
almost intuitively, whether that something should be in the TTime class or 
external.  If we need to increment our time by 1 day, we know that is for the 
TTime class.
 RH> as size and speed of the resulting code. Although it at 
 RH> times might provide for a useful abstraction, I feel 
 RH> that most real world objects, let alone concepts such 
 RH> as time, are far too complex to be encapsulated by, or 
 RH> even described by, a set amount of data and functions 
 RH> to operate on that data.
On the contrary - they are only too complex if you insist on a complete 
abstraction.  We don't need to be complete, only "good enough".  If, at some 
future point, we need more completeness, we have a single place to update, 
and everyone gets the functionality for free.  I like to think of it as 
modularity on speed.  :-)
 DM> A class is merely a description of what an object is and what
 DM> messages can be sent to it.
 RH> I just browsed the chapter on Windows programming using 
 RH> OWL, but I guess here you mean "which methods it has 
 RH> for operating on an object of the class" when you say 
 RH> "what messages can be send to it"? :-)
In OO terminology, you only pass messages to an object.  C++ does this via 
member functions.  (Objective C uses something closer to real messages.)  
This terminology makes it even simpler to see the correspondance between 
message-based GUIs, such as Windows or OS/2, and C++ windowing libraries.
 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.
 RH> Will have to consider this. I don't really like the 
 RH> "this->" method myself, but naming a constructors 
 RH> arguments the same as the class's data members does 
 RH> lend some clarity to the code, as far as I'm concerned. 
 RH> By the way, what does the "m" signify? I'm not sure I 
m_, g_, etc., are extentions to Hungarian notation.  These are for Member 
variables, Global variables, or whatever.  The letter before the underscore 
is typically a scope indicator.  Not that everyone likes Hungarian, though... 
again, a style thing.
 RH> understand your comment about the "multiple" functions. 
Multiple functions - member variables can be acted upon by all member and 
friend functions (assuming they're private - if public, they're the same as 
global...).  Global variables can be acted upon by ... not "multiple" but 
"all" functions.  Locals can obviously only be acted upon by that function.
 RH> Is there any other type? All class data members can be 
 RH> modified by all (non const) member functions, can they 
 RH> not?
Right - I was only making a distinction between local, member, and global 
variables as for one, some, and all, respectively.
 DM> TExample(char* s) : s(strdup(s))
 DM> {}
 RH> I just might like this approach... :-)
Pretty much standard.  And very preferred.
 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.  :-)
 RH> I am somewhat of a minimalist, I really prefer doing 
 RH> things such as that explicitly. Keeps me in touch with 
 RH> what's going on. :-)
I go the other direction - I want the compiler to do my work so I can 
concentrate on NEW things.  :-)
 RH> you aren't even sure yours will? For instance, I was 
 RH> wondering if it were safe to pass a NULL pointer to 
 RH> strdup, which would allow me to write something like
[...]
 RH> without having to check for s being NULL first. Neither 
 RH> Borland's online help nor Tom Swan's function reference 
 RH> said one way or the other, so I had to dig into the RTL 
 RH> source to find out it *wasn't* safe, at least not on my 
 RH> compiler. I'm assuming the standard would have 
 RH> explicitly told me so.
It would have implicitly told you that strdup is non-standard.  ;-)  You're 
on your own automatically now.  :->
---
---------------