Is STL important?

[ltcmelo]

That would be completely wrong. Static and dynamic polymorphism has nothing to do with what we're talking about here.

Not at all. In C++, parametric polymorphism is achieved through templates. That's why it's usually called static polymorphism (because it happens in compile-time). Inclusion polymorphism is achieved in C++ through inheritance and virtual mechanisms. That's why it's referred as dynamic polymorphism.

If you happen to be close to books like C++ Templates you might wanna take a look. But if you're not, I found a few links that might be usefull:

- http://en.wikipedia.org/wiki/Polymor...c_Polymorphism
- http://en.wikipedia.org/wiki/C%2B%2B
- http://homepages.feis.herts.ac.uk/~m...fl-node59.html

[Lindley]

Some might consider function overloading to be another type of static polymorphism. That doesn't exclude templates from falling under that category, of course.

[salehhamadeh]

As long as you know the standard C++ library then it's ok. Check the free ebook: Thinking C++ 2nd Edition Volume one". It can tell you the pros and cons.

[nuzzle]

In C++, parametric polymorphism is achieved through templates. That's why it's usually called static polymorphism (because it happens in compile-time). Inclusion polymorphism is achieved in C++ through inheritance and virtual mechanisms. That's why it's referred as dynamic polymorphism.

Static and dynamic polymorphism are misleading terms and shouldn't be used. At least not in a wider discussion.

Polymorphisms are features of the type system. When symbols are bound, at compiletime or runtime, early or late, really is irrelevant. These are implementation considerations. And note that in the Wikipedia main article about polymorphism you supplied, static and dynamic polymorphism aren't even mentioned.

Anyway, I still think that there's a third benefit of learning STL (which you challanged). STL is beneficial in its own right (as you mentioned), but Templates is also beneficial as an enhancement of object orientation. To me this is maybe the most important impact of Templates. That's why I mentioned Stephanov, the implementor and driving force behind STL and Templates. I dislike his view that Templates (or generics in general) is superior to OO and should totally replace it.

[nuzzle]

Perhaps, the biggest difference between the two paradigms is not language constructs or techniques. Instead it is a method of thinking. With OO you define classes/interfaces and then build algorithms on top of them. With GP, it's the other way around: You define algorithms and then you build concepts and data structures that can be submitted to them. While in OO the focus of the abstraction process is in creating entities, in GP the focus of the abstraction process is creating algorithms. With this in mind it's easier to understand how GP could replace OO and vice-versa.

I think your view is too one-dimensional. You place OO and GP at opposite ends of a line. I like to imagine a triangle with OO and GP in opposite corners very much like you do. But there's yet another dimension, namely the third corner where you have OO+GP. This is where GP is used to enhance OO.

Note for example the profound difference between the base class List and the generic base class List<T>. The former expresses the general concept of a list, whereas the latter expresses the general concept of a list of things. That's very different. From List you derive classes like ArrayList and LinkedList, that is lists with specific properties. From List<T> you derive classes like FruitList and VehicleList, that is lists holding specific things.

This shows how GP can be used to enhance OO designs. GP in C++ (Templates) is by no means limited to be used like it's used in the standard STL library, that is without any trace of OO at all. To confine Templates to this usage is to belittle it I think.

[JohnW@Wessex]

This shows how GP can be used to enhance OO designs.

Absolutely. I find I'm mixing OO & GP almost all of the time. The two techniques are entirely complementary.

[ltcmelo]

Static and dynamic polymorphism are misleading terms and shouldn't be used. At least not in a wider discussion.

Well, we're in a C++ discussion . Those are the terms I generally see in the C++ world.

Polymorphisms are features of the type system. When symbols are bound, at compiletime or runtime, early or late, really is irrelevant. These are implementation considerations. And note that in the Wikipedia main article about polymorphism you supplied, static and dynamic polymorphism aren't even mentioned.

I think you didn't notice, but the that article talks about parametric polymorphism and how templates are used in C++ to acheive it.

Anyway, I still think that there's a third benefit of learning STL (which you challanged)...

I woudn't say I "challenged it". Perhaps you're getting the wrong idea of misinterpreting it? I just mentioned that I considered that to be a general ability. Whether this could be a major benefit or not would depend on how you define OO.

I think your view is too one-dimensional. You place OO and GP at opposite ends of a line. I like to imagine a triangle with OO and GP in opposite corners very much like you do. But there's yet another dimension, namely the third corner where you have OO+GP. This is where GP is used to enhance OO.

I didn't place OO and GP at different corners. Sorry, but again I think you're misinterpreting. Since you mentioned Stepanov's argument I tried to raise some aspects where the definition of OO could vary. Where classes, objects, encapsulation, and others are not specifically part of it. And where there was a replacement for inheritance/virtual polymorphism.

If you take OO as its usually accepted today by most people, I perfectly agree that OO and GP fit together and can be used finely in conjunction. However, not everyone see OO this way (based on that different point of view I described in the earlier post). For Stepanov, for example (again, I emphasize that I'm not stating that this is actually his perspective, it's just a hypothesis), there could be basically no (significant) OO part in the STL.

[kempofighter]

Ok thanks guys, I'll read the chapter

Read this as well.
http://cplusplus.com/reference/algorithm/

The best way to learn the STL is by reading AND doing. This website has example programs for all algorithms and containers. You'd be better off reading a variety of sources, not to memorize of course. The STL can be a bit overwhelming because there may be many things you'll never use. Familiarize yourself with the capabilities so that when you are designing something you will remember that there was this container/algorithm that might help. Maintain links to documentation and pick up a copy of an actual dedicated STL reference so that you have resources handy when you need to find a tool for a particular job. Having an understanding of the STL is like having a garage full of useful hand and power tools. You don't use every tool every day but when you need one you want them organized so that you can search for the correct tool for each job. Although it could take years of experience and study to really master C++, there are many STL algorithms and containers that are really very simple.

[nuzzle]

Well, we're in a C++ discussion . Those are the terms I generally see in the C++ world.

Yes but these terms traditionally aren't used in the way you claim. They're used to separate overloaded methods (static polymorphism) from overriden virtual methods (dynamic polymorphism). Polymorphism here stands for "many methods with the same name" and static means it's decided at compiletime which one to call whereas dynamic means this decision is deferred to runtime.

So the traditional C++ usage of these terms is to distinguish between early and late binding of symbols. They're not used to distinguish between parametric and inclusion polymorphisms of the type system, the topic at hand here, and that's why they should be avoided.

I didn't place OO and GP at different corners.

In fact you did. You said,

"Perhaps, the biggest difference between the two paradigms is not language constructs or techniques. Instead it is a method of thinking. With OO you define classes/interfaces and then build algorithms on top of them. With GP, it's the other way around: You define algorithms and then you build concepts and data structures that can be submitted to them. While in OO the focus of the abstraction process is in creating entities, in GP the focus of the abstraction process is creating algorithms. With this in mind it's easier to understand how GP could replace OO and vice-versa. "

Here you separate OO from GP using a classification based on "method of thinking". OO represents one way of thinking and GP represents the other way around. That puts them in different corners, right?

I happen to agree with this classification. It follows the traditional division of development methods into either top-down or bottom-up. And both can be used to reach the same goal.

So exactly in what way did I "misinterpret" what you wrote?

If you take OO as its usually accepted today by most people, I perfectly agree that OO and GP fit together and can be used finely in conjunction. However, not everyone see OO this way (based on that different point of view I described in the earlier post). For Stepanov, for example (again, I emphasize that I'm not stating that this is actually his perspective, it's just a hypothesis), there could be basically no (significant) OO part in the STL.

Well, Stepanov definately doesn't see any OO in STL, and I don't think anybody else does either. Everybody agrees that OO and Templates represent two very different programming paradigms. That's not controversal.

Most programmers think that OO and Templates could and should be used together. Stephanov, on the other hand with a few followers I guess, claims that Templates is superior to OO. According to him OO is crap and shouldn't be used at all in favour of Templates. That's what's controversial.

Now, you indicate that Stepanov may "see" OO from a certain angle or in a particular light unaware of how OO is perceived by everybody else. I don't think so, that would be to underestimate him. I'm sure he's in full command of OO and the principles it rests on, and especially how it works in C++. No, he's most certainly fully informed on every aspect of OO - and he just blundly rejects it.

[ltcmelo]

Nuzzle, I think this discussion is not going anywhere. At least, we all agree that the STL is important. This is one thing the original poster should know.

[JohnW@Wessex]

Although there may be no OOP in the STL, it certainly expects you to use it.

e.g.
You often need to drive from std::unary_function and std::binary_function to create adaptable function objects for use in STL algorithms.

[Lindley]

That's the sort of thing I'd like to eventually see replaced or supplemented by something akin to boost::functions eventually.

[nuzzle]

Nuzzle, I think this discussion is not going anywhere. At least, we all agree that the STL is important. This is one thing the original poster should know.

Well, we got to the point where your argumentation broke down, didn't we. Better luck next time.

Sure, STL is important but Templates are not as important as Mr. Stepanov claims. Or is it? I still have this nagging feeling he may have a point. Maybe the OO emperor has no clothes after all. But it's hard to know. Stepanovs book Elements of Programming didn't exactly strengthen his case. I had hoped for a strong case against OO but there was none of the kind.

[ltcmelo]

Well, we got to the point where your argumentation broke down, didn't we. Better luck next time.

Not really. I don't see this as a competition forum where one is trying to break the other's argument. I see codeguru as a great place to learn and exchange ideas and experiences.

When I said the discussion was going nowhere it was because I had already expressed my opinions on the subject and I considered the conclusions you were making not consistent. Below are statements you made regarding the STL in two different posts:

There's also a point 3. This is when you use "generics lite" TOGETHER with object orientation.
...
Stepanov definately doesn't see any OO in STL, and I don't think anybody else does either.

So you think no one sees OO in the STL but the STL can be used to learn OO together with GP. Confusing, no?

You also say that static and dynamic polymorphism are terms not traditionally used. I think the opposite: inclusion and parametric polymorphism are the ones not used frequently. Books like C++ Templates, C++ Coding Standards, and others, prefer to use the terms static and dynamic polymorphism. Also, just for curiosity, I ran two google searches. The one with static dynamic polymorphism c++ returned many more results than the one with inclusion parametric polymorphism c++.

Also, the fact that I see a different method of thinking betwen GP and OO doesn't put them at different corners from a development point of view.

[nuzzle]

I don't see this as a competition forum where one is trying to break the other's argument. I see codeguru as a great place to learn and exchange ideas and experiences.

So do I but I also know what buttons to push to engage people, and it worked!

So you think no one sees OO in the STL but the STL can be used to learn OO together with GP. Confusing, no?

It may sound like a contradiction but it isn't. STL definately is no step-by-step instruction showing how to combine OO and GP but it's a very good example of what pure GP looks like in practice. And knowing what GP is all about is an important first step in combining it with OO.

You also say that static and dynamic polymorphism are terms not traditionally used.

These terms are, contrary to what you think, traditionally not used as alternatives for GP and OO respectively. They're not used to distinguish between parametric and inclusion polymorphism. That's why they're misleading in this discussion.

Static versus dynamic polymorphism is used to denote when methods are bound. Polymorphism here stands for "many methods with the same name". Static means it can be decided at compiletime which one of the many methods to call. Dynamic means this decision has to be deferred to runtime. So these terms are traditionally used to separate overloaded methods from overridden virtual methods, and that's not the topic of this thread.

Also, the fact that I see a different method of thinking betwen GP and OO doesn't put them at different corners from a development point of view.

The whole point of a classification is to separate things. If you think of a separation as being along a line or as putting things in different corners or buckets or whatever isn't that important really.

If one were to classify GP and OO as design methods using the traditional top-down/bottom-up pair, I'd say OO would be top-down and GP would be bottom-up. I though this was what you meant when you said this,

"Perhaps, the biggest difference between the two paradigms is not language constructs or techniques. Instead it is a method of thinking. With OO you define classes/interfaces and then build algorithms on top of them. With GP, it's the other way around: You define algorithms and then you build concepts and data structures that can be submitted to them. While in OO the focus of the abstraction process is in creating entities, in GP the focus of the abstraction process is creating algorithms. With this in mind it's easier to understand how GP could replace OO and vice-versa."

Also Stepanov has referred to the GP design process as "lifting" which I interpret as meaning bottom-up.

I don't understand what's your beef with this really. What are you in opposition of?

-----

Anyway I think I've said what I wanted in this discussion now. Thank you.