Printable View
I'm just starting programming and I've made it until the Standart Template Library. But the chapter seems incredibly boring, daunting and complicated, it looks so awful that I haven't yet read it so I can't really say is it complicated or not. So is it a very important thing or can I just skip it and live happily? I'm just kinda lazy to read the 30 pages dedicated to STL.
You can make do without it, but it'll make your life much easier in the long run.
Hi all.
Only 30 pages????
It's a little introduction to the topic!!!!!
Well, I've developed in C++ for long time, and I used STL very rarely. But I think that it's a very important argument, and we can see STL as a part of C++ programming. If you know STL you can use a powerful programming tool to build your application (without re-invent the wheel, as we say).
Moreover one good reason to study accurately STL is that it's a standard, and you'll find it on every serious programming environment you are going to use, Visual C++ for Microsoft as well as aCC for Unix.
Without STL, write a program that creates an array of "n" integers. The "n" is inputted by the user. Once you do that, write a function to insert and remove items from this array. After that, write a program that sorts the integers in descending order. Make sure that all memory allocation and deallocation is done properly.Quote:
Originally Posted by norsul
After you code this, you will see why STL is a powerful library. The code you will need to accomplish the above without STL is by far, much harder to write and maintain than with STL.
Regards,
Paul McKenzie
The STL for C++ programmes is as important as a car, ship or airplane. You can get everywhere without these vehicles, but it will take you days, months or probably years.
I would recommend reading the introduction so you are familiar with what can be achieved with the STL. Then begin to learn specific parts as you come across problems that can be solved using components of the STL.Quote:
Originally Posted by norsul
It's an essential part of C++. For one thing because a large part of the C++ standard library uses it but also because it represents a special programming paradigm called generics which is as important as object oriented programming, if not more so.Quote:
Originally Posted by norsul
Ok thanks guys, I'll read the chapter :)
Don't read it. Understand it :)Quote:
Originally Posted by norsul
In my opinion there are two major benefits you can get from a good understanding of the STL.
1 - The most obvious one is that you improve your C++ abilities. You can do pretty amazing things combining all STL capabilities like containers, algorithms, iterators and function objects. Most fundamental algorithms and data structures are there.
2 - You can learn from its design. In particular, you get a feel on the power of generic programming, which is the development paradigm of the STL. (If you don't know yet, the STL is not constructed on a traditional object oriented paradigm.) You'll have a great example of how to build reusable and extensible software libraries.
There's also a point 3. This is when generics is used together with object orientation.Quote:
Originally Posted by ltcmelo
In principle generics is just another a form of polymorphism. For this see this defining paper,
http://lucacardelli.name/Papers/OnUnderstanding.A4.pdf
Here generics is called "parametric" polymorphism and the OO form of polymorphism is called "inclusion" polymorphism.
Fortunately in C++ we have both sorts, both parametric and inclusion polymorphism.
More unfortunate is that the implementor of generics in C++, Mr. Stephanov, is convinced generics is all that's needed. He bluntly rejects OO as total crap.
I don't agree with Mr. Stepanov. You sure can use generics and OO separately or in happy conjunction. It's not one or the other, it's both separately or together.
I've tried to understand Mr. Stepanovs position. I've even bought his book (there's just one) called Elements of Programming. And although his approach has its merits there's nothing in this book that explains how generics could replace OO. I've recently revieved his book at Amazon (as uj and I guess it will appear shortly).
I don't see that as point 3 the way you do. Basically, I consider this to be just a general ability. Still, keep reading...Quote:
Originally Posted by nuzzle
I have not read this paper yet. But I've seen different names for both kinds of polymorphism. So I get your point. Since we're in a C++ world, I think more appropriate names would be static polymorphism (GP) and dynamic polymorphism (OO). Those are the terms I've seen in books and references in general.Quote:
Originally Posted by nuzzle
I haven't gotten his new book yet (but I sure will very soon). Anyways, without taking sides or claiming that this is Stepanov's argument, there is a subtleness on this issue that motivate different perspectives. Starting with...Quote:
Originally Posted by nuzzle
What really is OO? What actually characterizes it? People have developed systems years before OO was widely accepted as a programming paradigm. Were they doing OO?
First, classes and objects. Maybe not with the same terms, but in the old C-style you had structs (you could even simulate member functions through function pointers). You can think of them being designed following a methodology concerned of identifying entities and their behaviour - the OO way. On the other hand, you can think of them being designed simply for the sake of satisfying the requirements of an algorithm or a family of algorithms - the GP way.
Next, encapsulation and abstraction. Are those really OO specific? I think people already wrote code with them in mind before OO. (I'm not even 30, but well... we're just exchaning thoughts, rigth?) Perhaps encapsulation and abstraction could be considered general guidelines of programming in many paradigms.
Inheritance and dynamic polymorphism are well known marks of OO. I think we can't argue on this one. However, in this case generic programming provides a nice alternative which is template style type binding and static polymorphism. More formally, concepts and models. (Which unfortunatelly are out of C++0x :( ) The point here is that both alternatives can be applied in most cases.
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.
That would be completely wrong. Static and dynamic polymorphism has nothing to do with what we're talking about here.Quote:
Originally Posted by ltcmelo
Here we're talking about polymorphisms of the type system of programming languages. Essentially there are 4 kinds - overloading, coercion, parametric and inclusion.
They were first defined in the paper I was referring to.
The gospel according to JohnW@Wessex
1.0 Once upon a time there was a lowly programmer that wrote C++ in the C style of his forefathers.
1.1 One day, his employer said unto him, "Go forth to this advanced C++ course and return with knowledge of the mysteries of C++".
1.2 The wise sages at the course revealed many things that were previously unknown to him.
1.3 Upon his return he proclaimed, "The scales have been lifted from my eyes and now I see the wonders of the STL and generic programming".
1.4 His mind, now free from the confines of C Programming Paradigms, combined Object Orientated and Generic techniques to produce code that was simple, reusable and free from bugs.
1.5 And his employer was filled with joy that the productivity of his coder had dramatically improved.
May C++ neophytes learn from this humble C++ coder's journey.
There endeth the lesson.
I actually have written a set of interview questions that ask something like that. The aim is to see whether the interviewee uses the STL to solve the problem in a couple of lines or tries to implement the algorithm/container themselves. One question, that uses data indexed by strings, is virtually impossible to complete in the time provided without using std::map. Using std::map the task takes 11 lines of code, and that's including the curly brackets!Quote:
Originally Posted by Paul McKenzie
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.Quote:
Originally Posted by nuzzle
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
Some might consider function overloading to be another type of static polymorphism. That doesn't exclude templates from falling under that category, of course.
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.
Static and dynamic polymorphism are misleading terms and shouldn't be used. At least not in a wider discussion.Quote:
Originally Posted by ltcmelo
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.
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.Quote:
Originally Posted by ltcmelo
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.
Absolutely. I find I'm mixing OO & GP almost all of the time. The two techniques are entirely complementary.Quote:
Originally Posted by nuzzle
Well, we're in a C++ discussion :). Those are the terms I generally see in the C++ world.Quote:
Originally Posted by nuzzle
I think you didn't notice, but the that article talks about parametric polymorphism and how templates are used in C++ to acheive it.Quote:
Originally Posted by nuzzle
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.Quote:
Originally Posted by nuzzle
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.Quote:
Originally Posted by nuzzle
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.
Read this as well.Quote:
Originally Posted by norsul
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.
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.Quote:
Originally Posted by ltcmelo
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.
In fact you did. You said,Quote:
I didn't place OO and GP at different corners.
"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?
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.Quote:
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.
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.
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. ;)
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.
That's the sort of thing I'd like to eventually see replaced or supplemented by something akin to boost::functions eventually.
Well, we got to the point where your argumentation broke down, didn't we. Better luck next time. :)Quote:
Originally Posted by ltcmelo
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.
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.Quote:
Originally Posted by nuzzle
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:
So you think no one sees OO in the STL but the STL can be used to learn OO together with GP. Confusing, no?Quote:
Originally Posted by nuzzle
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.
So do I but I also know what buttons to push to engage people, and it worked! :)Quote:
Originally Posted by ltcmelo
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.Quote:
So you think no one sees OO in the STL but the STL can be used to learn OO together with GP. Confusing, no?
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.Quote:
You also say that static and dynamic polymorphism are terms not traditionally used.
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.
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.Quote:
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.
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.
Where do you need to derive from these in order to use the STL? I think they are just a handy way to create the correct typedef's in your function objects that will be used by template functions. You could just as well provide the typedef's yourself and remove the inheritance of std::unary_function or std::binary_function.Quote:
Originally Posted by JohnW@Wessex