Why Is There So Much Emphasis on Copy Constructors in C++?

While reading up on C++ a couple of nights ago as a refresher to help get through a book on OO development, I spent a good while reading about the Copy Constructor, and related topics like default constructors and shallow vs. deep copies. Anyhow, I couldn't help to start wondering just why is there so much emphasis on using copy constructors in C++?

All the other object-oriented and object-based languages I've studied and used (e.g., Java, PHP, ASP, JavaScript, ActionScript, Lingo) hardly seem to mention or use copy constructors; is there a reason for that?

One reason is that you must use them for classes that have dynamically allocated memory. There will be bugs in these classes if you do not define a proper copy constructor, and just use the default copy constructor provided by the language.

The problem arises in this particular case because the default copy constructor makes a copy of all variables within the class, and stores in them the same values as the original class. This means a pointer will be 'copied' by storing the same address into the newly created class. For dynamically allocated memory, this is a BIG problem, as the program will eventually attempt to de-allocate this same allocated memory twice. The first time will not be a problem... the second time will cause a run-time error.

Thanks Jason D., I don't have a problem understanding issues with multiple pointers using the same address, but how do other languages handle dynamically allocated memory for copied objects then? Do they all use 'deep copies' automatically, or something like that?

Java, PHP, ASP, JavaScript, ActionScript, Lingo - they all don´t support pointers and direct memory allocation. So they don´t need special care when copying objects.
(Since when is Lingo a OOP language?)

Another reason for the importance of copy constructors is that (unless the new standard changed everything) the system will be making and destroying copies of your objects without your ever realizing it and it's going to need those copy constructors to do it right.

For example, it's deeply ingrained in me to always use a pointer or a reference to pass a struct or an object as a parameter to a function. However, if you pass an object to a function, then it will create a copy of the object for use within that function. If the copy is not done right, then that function may not function properly. And if the destruction is not done right, then you could have a memory leak on your hands.

There are other instances of automatic creation of object copies that I can't even remember anymore, but I do remember that Scott Myer's "Effective C++: 50 Specific Ways to Improve Your Programs and Design" did a good job of describing the reasons for copy constructors, virtual destructors, and deep vs shallow copies, etc.

Thank you dwise1_aol, and also for the 'Effective C++' reference.
And thank you, M. Hirsch ... had a feeling there might be a simple reason for it, although when I took a quick look in the official PHP online documentation, the other day, I noticed that PHP does support some type of copy constructor. Do you happen to know what it's for? Haven't had time to check it out yet.
In my experience Lingo has a good deal of OO capabilities, although I haven't used them enough recently to remember exactly how extensive they are.

I remember Lingo supported a special keyword for object creation, along with a system of inheritance, static members, and more. Director's GUI also supported reuse of a variety of 'Cast' member types (graphics, quicktime, text, audio, etc., as 'Sprites' (instances of Cast members), along with programmatic access to them. Don't remember any language access modifiers, but as I said, it's been awhile...

Probably those you´ve seen are the only ones. It has no real OOP features, it only supports an OOP-similar style of writing the code. Just to make the code look "better than basic" But Lingo is one, if not the worst computer language I ever met. I have to work with it every other day, hear my words: Don´t spend any more minute on it than you really have to. It´s really not worth it. Everytime you find a "cool feature", it won´t work. Or it won´t work in the Player. Or it won´t work with your version of director. Or it won´t work in conjunction with other functions / features. Or it will segfault randomly And if it actually does work, it will take you months to find the documentation about how to use it correctly (yes, I have both handbooks and also a third-party book, my first search is always on macromedia.com - most problems are bugs known since ages)

... just my 2ct about Lingo. Sounds frustrating? It is!

Well, M.Hirsch, while I can certainly appreciate your desire to rant about Lingo (see below), what's your minimal definition of support to qualify a language as OO?

Actually I just did a search on Google, and it looks like I left out a slew of Lingo's more advanced OOP features, though it doesn't sound like you're interested to hear about them. I have heard it said that inheritance, which Lingo supports aplenty, and in several forms, two of which I mentioned in my post, is the MOST important feature of OO. I also remember picking up at least a couple of books maybe eight to ten years ago that went into great detail about OOP with Lingo, so not everyone shares your view.
I have worked on some projects that sound similar to yours, and I'd agree that they were frustrating. Frankly though, I thought the source of most of the confusion had less to do with Lingo itself than with the way the projects had been passed around from programmer to programmer, company to company; with the minimal documentation; and with lackadaisical attitudes by the project managers to supporting the projects.

Can you imagine starting a project on a cold weekend afternoon in October, only to find out at after nightfall that your workspace had no immediate lighting (all the directional stuff above was unadjustable and pointed the wrong way), no heat (the unit in my area was broken, and not repaired for about two weeks), a system located so far under the desk that I had to reach way under and poke around with a ruler to open and change CDs? (the system unit was also held in place by so much cabling and wires and surrounded by such quantities of boxes and junk on the back side that when I was finally able to take time to reposition it a couple of weeks later, that took a couple of hours). Anyway, that was just a tip on the iceberg, and I did also have to deal with unsupported, legacy Lingo, but ... now you've got me started too -- hope you're happy.