Probably one of the handiest features of C++ is the ability to create an object on the stack, and have it destroyed once the class has gone out of scope. This is because of the design of the language.
When you create an object using the syntax ‘ObjectT foo’ the object is instantly initialized, and you refer to each of the items in the object as foo.<whatever>. When the function returns the ObjectT’s destructor is called to clean up the object. This happens for every class.
Borland have seen it fit to make their compiler barf when you use one of the Visual Class Library(VCL) classes to create an object. Personally, I find the fact that you have to then wrap the code in a __try__ __finally__ block to be a waste of my time. After all there is no rational reason for preventing me from using the variable on the stack, as stack memory is just as good as heap memory (I’m old skool me!).
All you’re going to have on the stack is a pointer to a VTBL and the data concerned with the object; nothing more. If you have to cast it to a lesser object, then cast it to a lesser object. If you are using this object in another object (for example adding it to a collection), then use the proper syntax (in this case the ObjectT *foo = new ObjectT()). As a programmer you should know these things.
I would argue that the compiler should not protect us from such annoyances, but the reality is that to make better code we need more assertive nannies. All my C code is compiled with -Wall -Werror, which catches a lot of stupid mistakes, but doesn’t catch a lot of normal problems. Sometimes I think I would be better in a garbage collected, reference managed, array overrun protected world… but where would be the fun in that? I like my assembly language, I’m more careful as I know every instruction counts. That and the fact that a review of assembly code takes significantly longer than the same review of C code makes me pray that the developers are paying more attention.
If it wasn't for carbon-14, I wouldn't date at all