To STL or not to STL, that is the question...

**AvDav** · November 21st, 2003, 04:43 PM

Well, I don't know what standard says about such situation when you have the first part of hierarchy with non-virtual dtor and the other part with virtual dtor, and trying to delete via some class pointer which has virtual dtor. The point is that it is dangerious to derive a class from some class which has non-virtual dtor.
Imagine a situation where others can use that class:

Code:

typedef vector<POINT> Shape;
vector<Shape*> all_shapes;

struct Shape1 : Shape
{
 virtual ~Shape1() {}
};
struct Shape2 : Shape
{
 virtual ~Shape2() {} 
};

void erase_all_shapes()
{
 //assume several instances are created  by new and are inserted into all_shapes.

 for(Shape::iterator it = all_shapes.begin()....)
   delete *it; //fault at least in MSVC.
}

Of course it's a very common case though.

**Paul McKenzie** · November 21st, 2003, 05:00 PM

Well now that I think about it:

I know that it is safe to directly delete an object that is derived from a class that does not have a virtual destructor. Therefore, make me amend what I've been saying:

Since my example derived from string_vector, and if string_vector has a virtual destructor, and you delete directly a "string_vector" object or pointer, you are fine. This is not disputed, but I wasn't thinking this at the time. Sorry for the wrong information.

Now, the rub is how far up the coder will declare their pointer in the hierarchy: if the coder were to go up one more above the hierarchy and declared a pointer to vector<string> and used it polymorphically, then they would be in trouble.

Code:

int main()
{
   std::vector<std::string> *pMyVect;
   if ( do_some_customizations )
      pMyVect = new MyCustomizedStringVector;
   else
     pMyVect = new AnotherCustomizedStringVector;
//...
   delete pMyVect;  // trouble
}

So you still need to post a warning as to how far up the hierarchy someone can use your class polymorphically -- right now, they can stop at string_vector, but go no further up the branch when a pointer is declared.

AvDav's most recent post shows the dangers of deriving from a class that does not have a virtual destructor, and how easily it can be erroneously used in a program without any great programming effort.

Regards,

Paul McKenzie

**galathaea** · November 21st, 2003, 05:26 PM

As I've mentioned earlier in this thread, a simple and robust way for extending the functionality of a standard library container is to write your own algorithms. I mean, that's what is being desired if I'm correct. You don't want to access any internals into the container, like whatever implementation-defined types contained or private methods, right? So there's absolutely no need to derive in these cases. I know its fun to derive, but that's not an end in and of itself. And not everything in c++ has to be put inside a class...

**oktronic** · November 21st, 2003, 05:37 PM

lol, you guys are all adorable...

For Paul:
For those of you who like to keep quoting standards I should point this out:
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.
The statement "conforms to the standard" means "is compatible with the ideas of the standard" or "Is similar to the standard". Don't believe me, buy a dictionary.

1. STL was an extension of a compiler written by a small group of people who thought it would be a cool idea, and it was WAY off the standard at the time.

2. MFC came out long before STL, however, STL is almost as old from conception. Not like that has any bearing on anything, but I thought I'd throw it in there.

3. Most degreed people wrote a compiler in college. The point of ANSI is to say, "please try to include these things in your compiler". I does not say, "You MUST have a compiler just like this". So just because the "standard" says to do something, doesn't mean its right or actual or even implemented. And even if you write code right down to the very specifics of the ANSI standard, it still wont work on every compiler that claims to be ANSI compliant...again, write a compiler, then talk to me about how you think I'm wrong. I've written 2 compilers(ASM and C\C++) and 1 de-compiler (C++) and extended countless others, so yes, I do indeed know what I'm talking about before anybody decides to tell me I'm "BS"ing again.

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.

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.

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...

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.

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. 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. 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.
But whatever floats your boat. You will learn with experience.

**galathaea** · November 21st, 2003, 05:46 PM

Oktronic, do you really have such a bad self-image that you have to demean others to make yourself feel better? All this "big-boys" talk make you sound like an insecure 13 year-old trying to hang with punks on the corner.

But ok, can you point to one bug you've found? Just one would be helpful for context of your comments (to illustrate you are a big boy and not someone who just doen't know how to use things)...

**oktronic** · November 21st, 2003, 05:54 PM

galathaea,
Please when making an accusation, quote what you feel was wrong so I can understand.
I wasn't my intent to demean, but to educate, while I am indeed annoyed by the arrogance I have seen in this thread, it's not my intent to hurt your feelings.
So please tell me what you felt hurt by and I will correct it.

**souldog** · November 21st, 2003, 06:11 PM

Its tough being obsolete

**galathaea** · November 21st, 2003, 06:23 PM

First I didn't know people were still using STL in production code.

...

Which makes STL great for the one time slap a 'int' container together program. Otherwise known as a homework assignment....

...

Most of us senior programmers are, Paul. This might comes as a shock, but C came before C++. There were a whole bunch of languages before C++ surprisingly....

...

c) you mean thousands of buggy college programs?

...

The STL classes are written by some of the best C++ programmers in the world

I'd love to tell you all about this, but instead I'm just going to laugh real hard...

They are not fly-by-night programmers who made up these classes

Guess you never opened one of the header files....

...

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.

...

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.

You seem to want to alpha-male your position to the forefront instead of actually giving arguments about the topic. This thread could be very beneficial to many reading it, but I see instead in places this desire to bad mouth absent argument, like subverted superiority issues coming to the surface or something. If you actually know of a true bug somewhere, or can show a concrete example of bad design, that would be great. It gives an objective focus without diversionary name-calling and "nanny nanny" type schoolground tactics. I notice that you didn't respond with an example to my query. Should I take that as conceding something, or is there substance behind these claims, because it is very very important to all professional coders to have accurate information on the stability of the code they use.

**mclark** · November 21st, 2003, 06:25 PM

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.

**mclark** · November 21st, 2003, 06:42 PM

Originally posted by galathaea
But ok, can you point to one bug you've found? Just one would be helpful for context of your comments (to illustrate you are a big boy and not someone who just doen't know how to use things)...

I can provide an anecdotal STL bug just to lighten the mood.

In the early HP versions of STL you could not create containers of built-in types because built-ins didn't have destructors (which were directly called by STL at the time).

Sorry that this bug hasn't been relevant in ~10 years.

**gstercken** · November 21st, 2003, 06:45 PM

Originally posted by Toxick
And now, I'm trying to figure out what's the point of using an OO library or language if you can't (or shouldn't) use OO techniques. (like inheritance).

Which, I suppose, puts me in the position of the original poster, and I don't think we need to hash that out again.

IMHO, this quote reflects quite well the basic misunderstanding floating all about this thread, probably the same which led to its initial creation by darwen. In one of the earlier post to this thread, Zeeshan already made some valid statement to this subject, I'll try to put them in simpler words:

Yes, C++ started up as an "object-oriented" superset of the "procedural" C language, introducing elements like classes, inheritance, polymorphism via virtual member functions, etc... Hence, C++ is very commonly perceived as an "OO language". So when templates were added to the language, many didn't notice at first that this wasn't yet another addition to make the language even "more OO", but the introduction of a new concept: that of generic programming. But generic programming is not part of the OO paradigm, nor does the reverse apply. To some extent, those two concepts are even orthogonal to each other, and C++ allows you to use of both of them.

I remember that when I first heard about the idea to bring templates into C++, I saw them as an ugly and superfluous addition to the language, some kind of sophisticated macro preprocessor which just spoiled the nice OO concepts. It took some time to understand that a container library like the STC part of STL is not an OO library, but a completely different animal: Instead of implementing containers as classes which polymorphically keep pointers to instances of a base class from which you derive your own concrete classes (like the original MFC containers do), they use template metaprogramming to achieve a similar goal, which is by no means OOP, but generic programming.

Each time the "STL vs. MFC" or the "STL vs. not STL" discussion arises, I see statements from people how seem to be stuck with the idea that the STL is an OO class library implemented with templates. However, the STL is not OO. Likewise, C++ is not an OO language. C++ is a real allrounder, having all of a low-level language which can be used for systems programming tasks at nearly machine level, yet being procedural and block-structured (the idea C started with), and it features strong OO elements as well as generic programming.

So while I understand the point of view of darwen and Toxick, I also suspect that they just failed to notice until now that templates (in general) and the STL (more specifically) have nothing to do with the OO concepts of C++ - they just move along another dimension of the C++ space.

**mclark** · November 21st, 2003, 06:55 PM

Originally posted by gstercken
But generic programming is not part of the OO paradigm, nor does the reverse apply. To some extent, those two concepts are even orthogonal to each other, and C++ allows you to use of both of them.

I beg to differ. Templates are very much part of the OO methodology. Both templates and inheritance enable polymorphism (the hallmark of OO). They simply enable two different types (i)subtype polymorhism; (ii)parameter polymorphism. It is important to see both as forms of polymorhism to understand OO within C++. One of the challenges of OO design in C++ is to determine when and where to use each so that overall costs are minimized (static/dynamic memory footprint, run-performance, compilation performance, sloc).

**gstercken** · November 21st, 2003, 07:02 PM

Originally posted by mclark
They simply enable two different types (i)subtype polymorhism; (ii)parameter polymorphism. It is important to see both as forms of polymorhism to understand OO within C++.

Yes, both are ways to implement polymorphism. But as to my point of view, subtype polymorphism is the OO way of doing it, and parameter polymorphism is the GP way. The fact that polymorphism is an important element of OO doesn't allow for the reverse implication that any approach supporting polymorphism is automatically OO.

**Paul McKenzie** · November 21st, 2003, 07:10 PM

Originally posted by oktronic
lol, you guys are all adorable...

<snipping a lot of junk>

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.

SDK short for Software Development Kit. Is this the answer you're looking for? You never answered the question -- is the C-library an SDK? If not, why not? Are fopen(), fclose(), malloc(), free(), etc. SDK functions?

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.

And you have knowledge that I and others don't write "real programs"?

STL on the other hand, is badly written, buggy as ****

As galathea pointed out to you, tell us where the bugs are instead of demeaning others by saying "we don't write real programs" and "when you step out with the big boys". If you make a claim, make your claims like an adult instead of sounding like someone from the World Wrestling Federation.

There is no need to come on board here (I see you're new) and act condescending to the others that have spent much more time here helping others. You will only wear out your welcome that much sooner.

Regards,

Paul McKenzie

**mclark** · November 21st, 2003, 07:15 PM

Originally posted by gstercken
Yes, both are ways to implement polymorphism. But as to my point of view, subtype polymorphism is the OO way of doing it, and parameter polymorphism is the GP way. The fact that polymorphism is an important element of OO doesn't allow for the reverse implication that any approach supporting polymorphism is automatically OO.

OO (at least as preached by OMG and UML) contains both harmoniously. Parameter Polymorhism and Subtype polymorphism are both equal sibling refinments of the relationship between classes. OO embraces both. In C++ different language mechanics, styles and support communities have made these two less related than they should be. But from a design perspective they are unified.

Thread: To STL or not to STL, that is the question...

Thread Tools

Display

Posting Permissions