Originally posted by oktronic
There is no such thing as an ANSI compliant compiler
Before you even start to whine at me, and you know who you are, write a compiler, then talk to me about it, otherwise keep it shut.
It is not possible to detect all constructs whose behavior at run-time is undefined by the standard. Both C and C++ and undecidable languages. It is possible accept all WFF required by the language and reject all invalid required by the language and implement the semantics as described by the language. This is what makes a compiler compliant- the language it accepts not necessary what it does with it. Of the fully specified languages I've seen all were based on an interpretive model for a matematical machine.


4. Just because your STL class in junior college was called "Advanced C++" does not mean that STL is advanced C++. Just in junior college, they want you to feel special. I've taught this class and believe me, there's nothing advanced about it.
I freely admit that I've never been a junior college professor.


5. It's been decided by people way smarter then you, that base classes work as so:
BASE* ptr = &derived;
delete ptr;
If a destructor in base class is virtual when destroyed, any derived class' destructors are called first then the base, otherwise ONLY the base destructor is called and not the derived. This has to do with virtual tables that are created at compile time. No virtual entry, no call to the derived class. easy.
This is the way it works, because it was decided by the people writing the compiler that this is the best way to implement it. Don't like it, give them a call. Don't like what ANSi says about it, call them.
The standard says nothing at all about virtual tables. Virtual tables are simply one approach for implementing the functionallity required by the standard. While its the most common, not all compilers generate or use _vtbls.

These, gentlemen, are facts in programming. There are millions of ways to code things, "standards" are just ways to help control the mayhem. But as you can see from this thread, its not doing a very good job...
The C++ Standard is not about how you code things - its about what do the things you code mean.

Oh, I forgot, STL is a SDK, Paul. Just because a compiler can compile template code, does not mean the libraries that use it are not SDKs. If you have trouble with that, please look up what the definition of a SDK is, and get back to me and I'll explain it to you.
By this definition - everything not derived by the developer from the first-principle language constructs including the entire standard library is an SDK (ie. malloc). Intresting, an SDK that your required to be provided.

My final note:
If you like STL then use STL. When you are ready to step out here with the big boys and write real programs, you will find that STL does not have what it takes and you will have to write you own code.
(quietly avoiding the pissing contest)

Since as pointed out, STL classes are not reliably derived, you will have no other choice to either write your own or to write a bunch of functions to do the job for you which would defeat the purpose of OO programming.
I don't know if Stroustrup would agree that the purpose of C++ is simply OO programming. Nor agree that simple functions and data variables violate the principles of OO after all these are members of the namespace object which is itself an object (just not a class).

Template code is indeed a great idea, I supported it a decade a go and I still support it now, I've written lots of classes and functions with it. STL on the other hand, is badly written, buggy as ****, is almost impossible to extend or pass around with any reliability.
It would seem that these limitations are with the implementations you've used and are not iherent to STL as a definition.

Yes, leaving so much of the behavior of STL objects as implementation-specific has made interacting with STL difficult - leaving many to seak portability through rolling-their-own.

And there you have it. Once again engineering digresses into religion.