Yes, you've managed to find workarounds to all of these issues. There are of course ways to work around them. People do use C++ to get real work done; I have used it successfully many times in the past.

The point is that you have to *know* about all of these issues in order to use just this one feature effectively, without introducing subtle bugs, performance issues, or design problems.

Your solutions will mostly work of course but they are not terribly compelling. We might as well keep going:

• Calling arbitrary functions in constructors might work, but you can't return multiple values to use as different constructor arguments, so there are more hacks to be done there.
• Taking a bool& is pointless; you still need a dead-state for the destructor, so you may as well make a separate method to test for the dead-state after the constructor is run. (Good style also generally dictates you should never use non-const reference parameters; use pointers for out parameters to highlight that they will be written to.)
• Making its destructor protected prevents the class from being destroyed at all unless it is subclassed; the example GGP gave would longer work. I'm not sure what you meant be this. I do agree that documentation should suffice, but tools like -Weffc++ will still warn about it (and rightfully so.)
• I am not sure what you mean by resource classes. All I'm saying is that if MyClass contains a pointer and you forget to create a copy constructor, the compiler will do so implicitly, and your class will break horribly somewhere down the line.

Again, these are not insurmountable issues. They are just many things you need to be aware of in order to use constructors effectively. No other language has such land mines in such a simple feature as object constructors.

There are many problems with your example.

• You can't do non-trivial initialization in the constructor because initializer syntax is not turing complete. Most C++ style guides (such as Google's) suggest using a separate init() function, so it isn't really less lines of code.
• A constructor can't fail without throwing an exception. Assuming you don't allow exceptions, your class now needs an internal dead state. This is the case even if you use a separate init(), because the destructor needs to know whether init() was successful (unless of course you use a separate destroy(), making this pointless.)
• A destructor can't fail at all. There is no way to indicate failure; you can't throw an exception because the destructor might be called during stack unwinding from another exception. What if the destructor fails to flush a buffer? The C version can simply return a boolean to indicate this.
• There is no way to indicate that MyClass should not be inherited, so to allow deletion through a base class pointer (a requirement to satisfy the Liskov substitution principle), your destructor should be virtual. This adds overhead to the class itself, and adds a lot of overhead at the call site if the runtime type cannot be statically inferred.
• You now need implement (or at least declare private) copy constructors and operator=. Developers expect C++ objects to be copyable, and standard containers require it.

Don't you see what is going on here? Even the most trivial feature of C++, constructors, are horribly ridden with complications. C++ is a language of never-ending surprises, gotchas, land mines. It's a trap.

Unless you're coding in Java, I definitely don't agree with the Java-style getRisk(), because the 'get' is redundant. Accessor methods usually take no arguments and return a value, so the fact that they 'get' something is obvious. Google's C++ style advocates risk(), as does Apple with Objective-C (the default accessors for properties even work this way).

I would call it calcRisk() if it is not const, i.e. it modifies the Investment object somehow (and calc is common short form for calculate). If however it's a const method that just returns the risk, then putting calculate in front is unnecessary. In fact I'd argue that advertising the fact that it is calculated on the fly is a violation of encapsulation. What if you find out that calculating the risk is slow, so you'd like to pre-calculate it, and just return the stored value? calculateRisk() is now mis-named (and you get your grubby hands all over everyone's code and logs if you rename it.)

What universe do you live in? You've obviously never been a mobile developer if you think this even remotely resembles reality. Having been a mobile developer for over 2 years, I can tell you that Java has done absolutely nothing to solve device fragmentation. The language doesn't matter; it's the libraries, of course.

Every carrier has a hundred devices, and every single device has a different bug in its implementation of MIDP. With the strict size requirements for J2ME, for all but the simplest applications you can't even attempt combined builds. You are forced to make a different build for each device. Just wait until you try something *really* broken, like say, playing audio...

And smartphones of course use different APIs. MIDP, Android and BlackBerry have entirely different windowing toolkits. How do you expect an app to be magically portable between them? Even BlackBerries, where RIM has tight control over the devices and API, exhibits lots of fragmentation between devices and OS versions. Java is quite hostile to incompatible libraries, giving classloader errors for the slightest inconsistencies. When you buy a BlackBerry app from a third party site, especially for games, you almost always need to specify the exact model of your phone.

What is needed to reduce fragmentation is a rigorous certification process to strictly enforce the requirements of the platform. Sun had their chance; they could have required extensive testing to put that J2ME/MIDP logo on a phone. Unfortunately Sun failed, and Android seems to be deliberately going down the same path. I don't see the landscape getting better any time soon.

>> D did another thing right: it did not remove destructors, like Java did. Instead, when there are zero references to an object, the GC calls the destructor *immediately*, but deallocates the memory previously occupied by that object whenever it wishes (or it reuses that memory). This way RAII is possible in D, which is very useful for things like scoped thread locks.

First of all, Java does have destructors. It's called finalize().

Second of all, calling destructors on a modern GC are extremely costly. Sure, your example implementation of destructors seems simple, but it is only possible in a reference counted garbage collector, which is so primitive as to be nearly useless.

Modern Java GCs are generational copying collectors. They have a young heap, where objects are allocated, and an old heap, where objects are moved when they survive an allocation. Object retention is done by tree search from a root node.

This means you can do fun things like allocate a linked list, then drop the reference node. When a collection happens, anything living is rescued from the young heap, and then it's simply wiped clean. No computation is performed regardless of how large it is or how many links it has, because there's no such thing as deallocation on the young heap. When you drop that first link, it's like the VM doesn't even know it's there anymore; the whole list just gets overwritten on the next pass over the heap.

If, however, you write a destructor for your links (or in Java, finalize()), the destructor then needs to independantly keep track of all of your destructable objects. It needs to remember that they're there so it can call their destructor when they do not survive an allocation. Furthurmore, if you impose your hard requirement of calling the destructor immediately, then the implementation of such a collector is impossible for your language. Even a primitive mark sweep collector, or anything not reference counted is impossible.

This example is discussed in detail here:

http://www.ibm.com/developerworks/java/library/j-jtp01274.html

You should familiarize yourself with modern garbage collectors. I don't know much about D, but if D really is tied down to a reference-counting collector due to its destructor requirements, that makes it extremely unnatractive as a language. Here is more information on various collector implementations:

http://www.ibm.com/developerworks/java/library/j-jtp10283/

The first sentence in TFA is:

Imagine every time you closed your curtains, you were capturing enough solar energy to power your laptop.

I don't think they realize how little power a laptop uses. Can we get in "number of laptops" the power usage of a refrigerator or water heater?