RS>  Ah Shucks!!! does this mean I don't get the car???   Seriously, I know
 RS>  that C++ is an OO language.  I think you misunderstood what I was
 RS>  writing.  I mean that I think I can benefit from trying to apply what
 RS>  I know about procedural languages, ie; C, COBOL, BASIC, etc... to
 RS>  C++ and find out what all the differences are...  I have gained
Ah - and the point I was making is that OO is drastically different enough 
from procedural that, well, there's few similarities.  :-)  The "paradigm" of 
OO vs procedural is always a bigger difference than mere syntax differences.  
Going from C to COBOL is easier than C to C++.  (Now, for a REALLY easy 
switch: C++ to Java! )
 RS>  understanding by making false assertions here.  I don't care about
That's exactly what assert()'s are for - when they fire, you know.  ;-)
 RS>  my ego or if everyone here thinks I am a complete idiot.  As long as
 RS>  I am learning the language I am getting what I came for.
Don't worry about anyone thinking you're a complete idiot - we've all had to 
start somewhere.  :-)
 RS>  It seems to be very different than C to me.  I am slowly gaining an
That was my point.  Yes, it IS very different.  It's a different mode of 
thinking.  Feel free to ask questions, but be sure to remain open to this new 
mode of thinking.
 RS>  understanding of OOP.  I have been following a online class and the
 RS>  instructor has us doing things like describing the process of making
 RS>  a cup of coffee.  Pre and Post conditions must be described.  I guess
I've never gotten that formal, but, yes, that's an idea.  Personally, I still 
use objects (C++/Java) as a really nice ADT that is extensible via 
inheritence.  I think that has simplified learning OO for me, as well as 
cleaned up my C code.
 RS>  that is a key part of Abstract Data Types... that each method will
 RS>  have pre and post conditions for the data that it acts upon.
Right.  If it helps you to think this way, do it - I don't know of any 
reasons not to.  After a while, you'll find other features of objects over 
ADTs, but at least you may have a basis for understanding them.
 RS>  What I don't understand, (and I probably will need to read a great
 RS>  deal more before I do) is just what this pure OOP is.  It seems to me
 RS>  that OOP is making it's mark all over the programming world... the
 RS>  explosion in JavaScript for instance.
Pure OOP, so I've heard, is merely the case where there is only one built-in 
type.  For example, in Java, it is supposedly "Object."  Everything is 
derived from this base class.  C++ not only does not mandate this, but, 
worse, it allows functions that ARE NOT A MEMBER OF *ANY* class.  This is a 
total no-no in pure OOP.  Pure OOP allows for a function to be a static 
member of some class (which makes it basically global), but never EVER 
anything that is global in both scope and namespace.
 RS>  Getting back to the language at hand.  What is the difference between
 RS>  a constructor and a copy constructor?
"A constructor" is a superset of "a copy constructor."  A copy constructor is 
a special case of constructor.  First of all, I'm not sure if you understand 
constructor - if you do, ignore this part.  :-)
A constructor, literally, constructs the object.  It may have no arguments 
(default constructor), a const reference to its own type as an argument (copy 
constructor), or any other number of parameters, preferably () that make 
sense for the object.  Due to the ability to overload functions, we can have 
more than one constructor, so long as no two can be decoded to the same 
constructor.  For example, for a given class foo, the following constructors 
are legal:
foo(); // default constructor
foo(const foo&); // copy constructor
foo(int, char* = NULL); // constructor taking int, and optionally a char*
foo(const string&, const bar&); // constructor taking constant references to
                                // string and bar
However, the following pairs are NOT legal:
foo();
foo(int = 1); // optional int could be used for default case with no params
foo(int, char* = NULL); // optional char*
foo(int, int = 1);      // optional int
// both could be called with a single int parameter
(But this is the same for any overloaded function.)  The constructor will 
take these parameters to create itself.  For example, a string taking a char* 
for a constructor argument would presumably make a copy of the C-style string 
and store it in its own memory.  A string taking another string argument 
would presumably both have the same string stored in them.  Or, at least, the 
effects would be the same.  (To save time/space, they could both point to the 
same string, so long as the string stayed around as long as EITHER of the 
string objects were around, and so long as when you changed one, you did NOT 
change the other, implying that there is a copy made when you write to the 
string.)
The special cases.
1. Default constructor
This is the constructor called when no arguments are specified.  This is 
special because of the ways it can be called... without parenthesis at all.
foo f;
foo* pf = new foo;
foo* paf = new foo[12]; // calls the default constructor for each of the 12
                        // foo objects in the array
2. Copy constructor
This is the constructor called when a reference to another of the same object 
is specified.  This also has a special way of being called (optional, but the 
usual method).
foo firstone;
foo f2(firstone); // "normal" but rarely used
foo f3 = f2;      // also uses the copy constructor
foo f4 = foo(arg1, arg2); // basically the same as foo f4(arg1, arg2),
                          // but not as fast
foo f5;
f5 = f2; // ***NOT*** the copy constructor
The last one actually calls foo::operator=(const foo&) instead.
Also note that if you don't supply any constructors at all, the compiler will 
generate a default and a copy constructor for you:
1. default constructor does nothing
2. copy constructor does a member-by-member copy.  This can be dangerous when 
you have pointers that you will need to delete/free since both the original 
and the copy will want to delete that memory when they are destroyed.  If you 
have only 'objects' (and built-ins), the default copy constructor is 
generally sufficient.
Any questions?  :-)
Hope this helps!
---
---------------