5 ms·

Why is the C++ STL so heavily based on templates?

59 points by hamidr 14y ago

pootch 14y ago
A better answer is C++ is a rudder-less windbag of horribleness of which STL contributed to and convinced sane people to not use C++
pbiggar 14y ago
Stroustrup wrote a couple of books and papers about the history of C++, which discuss how it got the way it did. Its basically by being very pragmatic, focussed on speed, with a requirement to be C source compatible as much as possible. Very worthwhile: http://www.stroustrup.com/dne.html http://www.stroustrup.com/dne.html and http://lambda-the-ultimate.org/node/2283 http://lambda-the-ultimate.org/node/2283 Unfortunately, C++ is a language that fills a niche no-other does - the ability to write genericized systems programming code. For large systems (gcc-sized) it offers a lot of advantages over C (obviously, simplicity is not one of them). I say unfortunately because nobody can argue that C++ is beautiful, but until that niche goes away, C++ will always have a place.
- Negitivefrags 14y ago
  C++ is a beautiful language on the inside. People just don't like it's ugly skin. Those of us who like C++ see it as the language it wants to be, not the language that it is dragged in to being by it's C heritage.
  - qznc 14y ago
    Funny that D claims to be the language "what C++ wanted to be". It drops source compatibility to C and only provides ABI compatibility. Source: http://www.prowiki.org/wiki4d/wiki.cgi http://www.prowiki.org/wiki4d/wiki.cgi
    - tspiteri 14y ago
      Funnily, D demonstrates why C compatibility is so important: without C compatibility the adoption would be very low.
      - betterunix 14y ago
        Which is basically the only thing C has going for it: we have lots of systems written in C, and so C compatibility becomes important for new systems. C itself is not doing anything to make any system better (and C's focus on dangerous low-level operations has created a software ecosystem that is constantly teetering on the edge of oblivion), but nobody is willing to put in the effort needed to get rid of C and move the programming world forward.
        klodolph 14y ago
        You're disparaging C for focusing on "dangerous low-level operations", but you should be singing its praises for delivering us from what came before it: truly low-level languages like assembler, dinosaurs like FORTRAN, and tentacled sea-monsters like ALGOL 68. > nobody is willing to put in the effort needed to get rid of C This statement is wrong on multiple levels. 1. People are willing to put in the effort to move beyond C, and it's been happening for four decades. C++, Java, Python, C#, Haskell, Ruby... 2. Getting rid of C for new projects universally is not really desirable. It's still the only thing I would choose for writing the majority of an OS kernel, where dangerous low-level operations are necessary. For the same reason, we will never ditch assembly. 3. Rewriting old C projects in newer languages is often ill-advised. Source code contains the knowledge of those who worked on it, it is used to describe solved problems. Rewriting code means solving those problems over again, relearning the encoded knowledge, and making bugs that were fixed long ago.
        jejones3141 14y ago
        Algol 68 is really not that complicated. It goes to a lot of trouble about a few things that didn't turn out to be too important (e.g. the "book model" of I/O), but it is a model of simplicity and elegance in comparison with C++.
  - mikevm 14y ago
    Gah, I'm tired of these Language Wars. Every week (day?) we see posts on the front page on why language X is the "bestest programming language eva!". There are now a gazillion programming languages, and new ones popping up every once in a while -- like anal warts. I'm tired of these fucking evangelists. Seeing these posts on the front page is like getting daily visits from Jahova's Witnesses. Just use whatever makes you productive and your product do whatever it's supposed to do, and most importantly, shut the fuck up. </rant>
    - klibertp 14y ago
      Languages, editors and IDEs, comments in the code, static and dynamic typing and a few others - these are the topics that attract lots of people with strong opinions. That was the case thirty, twenty and ten years ago and probably will be in the future. In my experience just when one generation of developers grows up and abandons those topics in favor of actually making things the next generation is more than ready to carry on the holy wars. The best we can do is to ignore them altogether. I know it's sometimes hard, but it's definitely more productive that way :)
    - PommeDeTerre 14y ago
      There's no "war". It's pretty clear that C and C++ are the most important and dominant programming languages around, regardless of what some people may think and say. Almost every truly important software system is either implemented directly in one or both of them, or heavily depends on other software implemented in one or both of them. In practice, you don't get implementations of languages like Java, Ruby, Python, Perl and Go without C and C++. Even if you're using something like JRuby, you'll still likely end up depending on a JVM written in C and/or C++. And all of this isn't even considering that your software, regardless of the language it's written in, will likely be dealing with an OS written in C and/or C++, and possibly communicating with a database or some other server software written in C and/or C++. These days, C and C++ are nearly inescapable when implementing real-world software.
      - betterunix 14y ago
        "In practice, you don't get implementations of languages like...Python,...without C and C++." Unless someone takes the time to free Python from C, by doing something like this: https://en.wikipedia.org/wiki/PyPy https://en.wikipedia.org/wiki/PyPy Really, the reason you see interpreters being written in C/C++ has less to do with any technical quality of C or C++ and more to do with something else you mentioned: "your software, regardless of the language it's written in, will likely be dealing with an OS written in C and/or C++," Bingo. Sometimes software needs to do low-level things, even if the software itself is high-level, and that means the software is probably going to be making system calls. An interpreter for Python is going to have to make some system calls, and it is much easier to do that if the interpreter is written in the same language as the OS's API; most OSes have C APIs, and thus writing a Python interpreter in C makes sense. "These days, C and C++ are nearly inescapable when implementing real-world software." I doubt it, considering how much real-world software is being written in Java, C#, Ruby, Javascript, etc. Not all software needs to do things that involve directly deal with the OS. The fact that these systems are often implemented in C does not make C inescapable; it just means that nobody has bothered to free themselves from C yet. There is no technical feature of C that makes it inescapable as a language, it is just what we have to deal with until we put in the effort needed to rid ourselves of it.
  - bad_user 14y ago
    Personally, I think we have enough languages that are beautiful on the inside. And what does that mean anyway? What does it mean for a language to have "a skin"? And C++ doesn't want anything by itself, as C++ is not a person, but an ugly spec with a bunch of ugly compilers written according to that spec and the funny thing about languages beautiful on the inside, is that such languages will never get rid of their heritage, nor will that heritage become less important. And IMHO there never was and never will be a mainstream language more ugly than C++, being successful only because people wanted C with extensions and they got it. Sometimes I wish normal people knew what C++ was, because sometimes I have a hard time explaining what absolute ugliness is and the first thing that pops into my head is C++.
    - hamidr 14y ago
      The reason of not deprecating ugly features of c++ in new c++11 standard was the production codes in industry which still want to live.
- twoodfin 14y ago
  An enthusiastic second on Design and Evolution. Must reading for any C++ developer who wants to learn the whys and wherefores of the language. I hope he'll update it. The debates over concepts deserve a chapter at least.
  - pbiggar 14y ago
    The book was originally made from the contents of his paper at the 2nd History of Programming Languages conference. He wrote another paper at HOPL3 (2007) which I linked above aswell.
- betterunix 14y ago
  "Unfortunately, C++ is a language that fills a niche no-other does" There are an awful lot of languages out there; I would be careful with statements like this. I am not sure there is any feature or combination of features in C++ that is not equally good or better in another language.
  - pbiggar 14y ago
    I believe it to be the only language with the following features: - support on basically every platforms - ability to write parametrized, typed, compile-time constructs - speed
    - betterunix 14y ago
      I am not sure that "support on basically every platform" really qualifies as a language feature, but I can grant that it is a strong motivation for choosing C or C++. As for parameterized/typed/compile-time constructs, you can get that in other languages if you want it; in Lisp, you can get static typing as a macro library, and the support for compile-time processing in C++ does not hold a candle to Lisp's macro system. Speed is overrated for C++. Ada and Lisp can compete with C++ on speed in any task except in cases where there is some special hardware that is giving you a speed boost and which only has tools that support C/C++ (and even then, language support tends to expand over time, so this will only really be a short-term gain). C and C++ actually constrain a programmer's ability to optimize code in some cases; CL-PPCRE, for example, is faster than libpcre because rather than set up a pointer structure and interpret a regular expression, CL-PPCRE creates a compiled, callable function that matches the regex. The lack of support for high-level features winds up hurting C++ in some cases, by forcing programmers to come up with their own way to accomplish the task, which is usually slower than what a mature compiler produces. On the other hand, there are compilers for high level languages that do allow programmers to do low-level optimizations; CMUCL and SBCL, for example, support a form of inline assembly, and have mechanisms that allow programmers to access low-level pointers and other constructs. So really, what this boils down to is not that C++ is necessarily faster, nor that it's language features are unique, but that it is just a lingua franca of sorts that has some very limited support for some high-level features.
lolcraft 14y ago
So, if I get this, the "party line" was that C++ is great because it's OOP -- never mind if it actually does not provide encapsulation or modularity. Or garbage collection. Or reflection. But now it is that C++ is great because it's not OOP, it's generic. It still does not provide encapsulation or modularity. And all of this is derived from the design choice of making it not-even-compatible with C. To me, that's ideology. That the compiler doesn't load a bunch of .o files does not mean there's no dependency graph. There is, it's just on header files, which makes things worse. You just moved the "modularity" from the linker/loader stage to the compilation stage. Which is the opposite of modularity. You can't modify a template with LD_PRELOAD. You can't have pluggable templates. If you modify a template, you have to recompile everything that uses it. The STL never had to be efficient. It just had to be convenient. Anyway, you won't get efficiency from generic code, because real efficiency requires knowing what's the problem you're trying to solve. I think Go got generics much better. Pass an interface{LessOrEqual} to a Sort and you're golden.
- flyinRyan 14y ago
  The party line was always that C++ is multiparadym. Stroustroup said that over and over in his book.
  - deleted 14y ago
    [deleted]
- Negitivefrags 14y ago
  Does the lack of being able to link against pre-compiled modules really make the language not modular? You have to recompile javascript every time you run it, does that mean that that language is incapable of being modular? I think you are confusing two different types of modules here.
- muyuu 14y ago
  I disagree, the STL being efficient was essential for the success of C++ since the standard from 1998. In fact, those parts of STL that can be improved significantly are available from other libraries and are widely used in the industry (like some parts of Boost, some hash tables, etc). Nowadays C++ is mostly used in environments where efficiency is crucial, and this have been the case for many years already. If you take this away, C++ is wildly inferior to several languages. C++ in practice has evolved a lot. With modern C++ programming style and techniques, it's actually usable and very practical. If you see code from the 90's though... it's a complete mess. All in all I think it's worth knowing inside out, like C (but they are very different languages and trying to use C++ in a C-ish way will only lead to a 90's style mess).
signa11 14y ago
here is the quote (http://www.stlport.org/resources/StepanovUSA.html http://www.stlport.org/resources/StepanovUSA.html) from one of the original auhors of stl: 'While in the hospital, in the state of delirium, I suddenly realized that the ability to add numbers in parallel depends on the fact that addition is associative. (So, putting it simply, STL is the result of a bacterial infection.) In other words, I realized that a parallel reduction algorithm is associated with a semigroup structure type. That is the fundamental point: algorithms are defined on algebraic structures. It took me another couple of years to realize that you have to extend the notion of structure by adding complexity requirements to regular axioms. And than it took 15 years to make it work. (I am still not sure that I have been successful in getting the point across to anybody outside the small circle of my friends.) I believe that iterator theories are as central to Computer Science as theories of rings or Banach spaces are central to Mathematics. Every time I would look at an algorithm I would try to find a structure on which it is defined. So what I wanted to do was to describe algorithms generically. That's what I like to do. I can spend a month working on a well known algorithm trying to find its generic representation. So far, I have been singularly unsuccessful in explaining to people that this is an important activity. But, somehow, the result of the activity - STL - became quite successful.'
- jerf 14y ago
  If you want to work in an environment where a lot of people are thinking like this routinely, instead of a few lone voices in a vast sea of otherwise uninterested people, the Haskell community is doing a lot of work in this area, and able to move much faster since it's so much easier in Haskell than C++ templates (which isn't really a criticism of C++ templates, a lot of their capabilities are accidental rather than intended). This is why the Haskell community talks so much about monoids and applicatives and semigroups and a variety of other interesting structures in that area (and no, I did not forget to say monad, that structure is actually uninteresting here because it is too powerful). I believe the Fortress language is also doing some work here. A sample of the interesting sort of algorithm work that you can do when you think this way: http://apfelmus.nfshost.com/articles/monoid-fingertree.html http://apfelmus.nfshost.com/articles/monoid-fingertree.html Edit: See also the Typeclassopedia: http://www.haskell.org/haskellwiki/Typeclassopedia http://www.haskell.org/haskellwiki/Typeclassopedia And if you're really interested and want to take it hardcore, Edward Kmett's video on his lens library walks through how you can derive it with this sort of logic: http://youtu.be/cefnmjtAolY?hd=1 http://youtu.be/cefnmjtAolY?hd=1
schemer4 14y ago
"OOP is not the holy grail. It's a cute idea, and it was quite an improvement over procedural languages back in the 70's when it was invented. But it's honestly not all it's cracked up to be. In many cases it is clumsy and verbose and it doesn't really promote reusable code or modularity. That is why the C++ community is today far more interested in generic programming, and why everyone are finally starting to realize that functional programming is quite clever as well. OOP on its own just isn't a pretty sight." Smalltalk has had anonymous functions in the form of block objects since 1972! And they are so fundamental to the language that all control structures and iteration constructs are implemented using them! Look at the following if/else code in smalltalk: (...boolean expression...) ifTrue: [...true block...] ifFalse: [...false block...] That sends an ifTrue:ifFalse: message with two arguments, a true block and a false block (lambdas), and if the receiver, a Boolean expression that should yield either the True or False object, is true, then the first block gets evaluated and the second ignored, and if it's false, than the second is evaluated and the first ignored. Anonymous functions are a core part of OOP, because OOP is supposed to be a streamlined subset of Lisp, preferably with specialized message-passing syntax. The idea that anonymous functions are some recent, novel addition to OOP, or that functional programming constructs are at odds with "pure" OOP, or that by peppering your C++/Java/C# code with lambdas, your "object-oriented" code has suddenly become multi-paradigm, shows just how distorted an understanding of OOP and functional programming the average programmer, and even language designer, has. Stroustrup clearly didn't understand OOP or Smalltalk when he bolted classes on to his wretched mess of a language, and that's why C++ looks the way it does, instead of like Objective-C, a language that was a faithful, somewhat successful attempt to add Smalltalk-style OOP to C.
- protomyth 14y ago
  His ideas for OOP were based off of Simula 67 rather than Smalltalk.
- sbmassey 14y ago
  C++ OOP was based on Simula, rather that Smalltalk, which was OO back in the 60's, and didn't have blocks/anon functions/lambdas. (It did have coroutines though; not sure why that didn't make it to C++). Unlike Java or (I suppose) C#, C++ has been considered multi-paradigm certainly since 1998 with templates and the STL: this is not related to the recent addition of lambdas to the standard. Very little of the popular Boost library can be considered OO, for example, as it generally discourages inheritance hierarchies, as does most modern idiomatic C++.
npsimons 14y ago
Actually, Bruce Eckel goes over this in "Thinking in C++". Stroustrup chose not to use an object-based hierarchy, where everything inherits from one base class (like in Java and Smalltalk). This presents a problem when making generic containers (that is, a container that can hold any type of object). To solve this, generics (in the form of templates) were added to C++.

59 points by hamidr 14y ago

A better answer is C++ is a rudder-less windbag of horribleness of which STL contributed to and convinced sane people to not use C++

pbiggar 14y ago

Stroustrup wrote a couple of books and papers about the history of C++, which discuss how it got the way it did. Its basically by being very pragmatic, focussed on speed, with a requirement to be C source compatible as much as possible. Very worthwhile: http://www.stroustrup.com/dne.html http://www.stroustrup.com/dne.html and http://lambda-the-ultimate.org/node/2283 http://lambda-the-ultimate.org/node/2283 Unfortunately, C++ is a language that fills a niche no-other does - the ability to write genericized systems programming code. For large systems (gcc-sized) it offers a lot of advantages over C (obviously, simplicity is not one of them). I say unfortunately because nobody can argue that C++ is beautiful, but until that niche goes away, C++ will always have a place.

Negitivefrags 14y ago
C++ is a beautiful language on the inside. People just don't like it's ugly skin. Those of us who like C++ see it as the language it wants to be, not the language that it is dragged in to being by it's C heritage.
- qznc 14y ago
  Funny that D claims to be the language "what C++ wanted to be". It drops source compatibility to C and only provides ABI compatibility. Source: http://www.prowiki.org/wiki4d/wiki.cgi http://www.prowiki.org/wiki4d/wiki.cgi
  - tspiteri 14y ago
    Funnily, D demonstrates why C compatibility is so important: without C compatibility the adoption would be very low.
    - betterunix 14y ago
      Which is basically the only thing C has going for it: we have lots of systems written in C, and so C compatibility becomes important for new systems. C itself is not doing anything to make any system better (and C's focus on dangerous low-level operations has created a software ecosystem that is constantly teetering on the edge of oblivion), but nobody is willing to put in the effort needed to get rid of C and move the programming world forward.
      - klodolph 14y ago
        You're disparaging C for focusing on "dangerous low-level operations", but you should be singing its praises for delivering us from what came before it: truly low-level languages like assembler, dinosaurs like FORTRAN, and tentacled sea-monsters like ALGOL 68. > nobody is willing to put in the effort needed to get rid of C This statement is wrong on multiple levels. 1. People are willing to put in the effort to move beyond C, and it's been happening for four decades. C++, Java, Python, C#, Haskell, Ruby... 2. Getting rid of C for new projects universally is not really desirable. It's still the only thing I would choose for writing the majority of an OS kernel, where dangerous low-level operations are necessary. For the same reason, we will never ditch assembly. 3. Rewriting old C projects in newer languages is often ill-advised. Source code contains the knowledge of those who worked on it, it is used to describe solved problems. Rewriting code means solving those problems over again, relearning the encoded knowledge, and making bugs that were fixed long ago.
        jejones3141 14y ago
        Algol 68 is really not that complicated. It goes to a lot of trouble about a few things that didn't turn out to be too important (e.g. the "book model" of I/O), but it is a model of simplicity and elegance in comparison with C++.
- mikevm 14y ago
  Gah, I'm tired of these Language Wars. Every week (day?) we see posts on the front page on why language X is the "bestest programming language eva!". There are now a gazillion programming languages, and new ones popping up every once in a while -- like anal warts. I'm tired of these fucking evangelists. Seeing these posts on the front page is like getting daily visits from Jahova's Witnesses. Just use whatever makes you productive and your product do whatever it's supposed to do, and most importantly, shut the fuck up. </rant>
  - klibertp 14y ago
    Languages, editors and IDEs, comments in the code, static and dynamic typing and a few others - these are the topics that attract lots of people with strong opinions. That was the case thirty, twenty and ten years ago and probably will be in the future. In my experience just when one generation of developers grows up and abandons those topics in favor of actually making things the next generation is more than ready to carry on the holy wars. The best we can do is to ignore them altogether. I know it's sometimes hard, but it's definitely more productive that way :)
  - PommeDeTerre 14y ago
    There's no "war". It's pretty clear that C and C++ are the most important and dominant programming languages around, regardless of what some people may think and say. Almost every truly important software system is either implemented directly in one or both of them, or heavily depends on other software implemented in one or both of them. In practice, you don't get implementations of languages like Java, Ruby, Python, Perl and Go without C and C++. Even if you're using something like JRuby, you'll still likely end up depending on a JVM written in C and/or C++. And all of this isn't even considering that your software, regardless of the language it's written in, will likely be dealing with an OS written in C and/or C++, and possibly communicating with a database or some other server software written in C and/or C++. These days, C and C++ are nearly inescapable when implementing real-world software.
    - betterunix 14y ago
      "In practice, you don't get implementations of languages like...Python,...without C and C++." Unless someone takes the time to free Python from C, by doing something like this: https://en.wikipedia.org/wiki/PyPy https://en.wikipedia.org/wiki/PyPy Really, the reason you see interpreters being written in C/C++ has less to do with any technical quality of C or C++ and more to do with something else you mentioned: "your software, regardless of the language it's written in, will likely be dealing with an OS written in C and/or C++," Bingo. Sometimes software needs to do low-level things, even if the software itself is high-level, and that means the software is probably going to be making system calls. An interpreter for Python is going to have to make some system calls, and it is much easier to do that if the interpreter is written in the same language as the OS's API; most OSes have C APIs, and thus writing a Python interpreter in C makes sense. "These days, C and C++ are nearly inescapable when implementing real-world software." I doubt it, considering how much real-world software is being written in Java, C#, Ruby, Javascript, etc. Not all software needs to do things that involve directly deal with the OS. The fact that these systems are often implemented in C does not make C inescapable; it just means that nobody has bothered to free themselves from C yet. There is no technical feature of C that makes it inescapable as a language, it is just what we have to deal with until we put in the effort needed to rid ourselves of it.
- bad_user 14y ago
  Personally, I think we have enough languages that are beautiful on the inside. And what does that mean anyway? What does it mean for a language to have "a skin"? And C++ doesn't want anything by itself, as C++ is not a person, but an ugly spec with a bunch of ugly compilers written according to that spec and the funny thing about languages beautiful on the inside, is that such languages will never get rid of their heritage, nor will that heritage become less important. And IMHO there never was and never will be a mainstream language more ugly than C++, being successful only because people wanted C with extensions and they got it. Sometimes I wish normal people knew what C++ was, because sometimes I have a hard time explaining what absolute ugliness is and the first thing that pops into my head is C++.
  - hamidr 14y ago
    The reason of not deprecating ugly features of c++ in new c++11 standard was the production codes in industry which still want to live.
twoodfin 14y ago
An enthusiastic second on Design and Evolution. Must reading for any C++ developer who wants to learn the whys and wherefores of the language. I hope he'll update it. The debates over concepts deserve a chapter at least.
- pbiggar 14y ago
  The book was originally made from the contents of his paper at the 2nd History of Programming Languages conference. He wrote another paper at HOPL3 (2007) which I linked above aswell.
betterunix 14y ago
"Unfortunately, C++ is a language that fills a niche no-other does" There are an awful lot of languages out there; I would be careful with statements like this. I am not sure there is any feature or combination of features in C++ that is not equally good or better in another language.
- pbiggar 14y ago
  I believe it to be the only language with the following features: - support on basically every platforms - ability to write parametrized, typed, compile-time constructs - speed
  - betterunix 14y ago
    I am not sure that "support on basically every platform" really qualifies as a language feature, but I can grant that it is a strong motivation for choosing C or C++. As for parameterized/typed/compile-time constructs, you can get that in other languages if you want it; in Lisp, you can get static typing as a macro library, and the support for compile-time processing in C++ does not hold a candle to Lisp's macro system. Speed is overrated for C++. Ada and Lisp can compete with C++ on speed in any task except in cases where there is some special hardware that is giving you a speed boost and which only has tools that support C/C++ (and even then, language support tends to expand over time, so this will only really be a short-term gain). C and C++ actually constrain a programmer's ability to optimize code in some cases; CL-PPCRE, for example, is faster than libpcre because rather than set up a pointer structure and interpret a regular expression, CL-PPCRE creates a compiled, callable function that matches the regex. The lack of support for high-level features winds up hurting C++ in some cases, by forcing programmers to come up with their own way to accomplish the task, which is usually slower than what a mature compiler produces. On the other hand, there are compilers for high level languages that do allow programmers to do low-level optimizations; CMUCL and SBCL, for example, support a form of inline assembly, and have mechanisms that allow programmers to access low-level pointers and other constructs. So really, what this boils down to is not that C++ is necessarily faster, nor that it's language features are unique, but that it is just a lingua franca of sorts that has some very limited support for some high-level features.

lolcraft 14y ago

So, if I get this, the "party line" was that C++ is great because it's OOP -- never mind if it actually does not provide encapsulation or modularity. Or garbage collection. Or reflection. But now it is that C++ is great because it's not OOP, it's generic. It still does not provide encapsulation or modularity. And all of this is derived from the design choice of making it not-even-compatible with C. To me, that's ideology. That the compiler doesn't load a bunch of .o files does not mean there's no dependency graph. There is, it's just on header files, which makes things worse. You just moved the "modularity" from the linker/loader stage to the compilation stage. Which is the opposite of modularity. You can't modify a template with LD_PRELOAD. You can't have pluggable templates. If you modify a template, you have to recompile everything that uses it. The STL never had to be efficient. It just had to be convenient. Anyway, you won't get efficiency from generic code, because real efficiency requires knowing what's the problem you're trying to solve. I think Go got generics much better. Pass an interface{LessOrEqual} to a Sort and you're golden.

flyinRyan 14y ago
The party line was always that C++ is multiparadym. Stroustroup said that over and over in his book.
- deleted 14y ago
  [deleted]
Negitivefrags 14y ago
Does the lack of being able to link against pre-compiled modules really make the language not modular? You have to recompile javascript every time you run it, does that mean that that language is incapable of being modular? I think you are confusing two different types of modules here.
muyuu 14y ago
I disagree, the STL being efficient was essential for the success of C++ since the standard from 1998. In fact, those parts of STL that can be improved significantly are available from other libraries and are widely used in the industry (like some parts of Boost, some hash tables, etc). Nowadays C++ is mostly used in environments where efficiency is crucial, and this have been the case for many years already. If you take this away, C++ is wildly inferior to several languages. C++ in practice has evolved a lot. With modern C++ programming style and techniques, it's actually usable and very practical. If you see code from the 90's though... it's a complete mess. All in all I think it's worth knowing inside out, like C (but they are very different languages and trying to use C++ in a C-ish way will only lead to a 90's style mess).

signa11 14y ago

here is the quote (http://www.stlport.org/resources/StepanovUSA.html http://www.stlport.org/resources/StepanovUSA.html) from one of the original auhors of stl: 'While in the hospital, in the state of delirium, I suddenly realized that the ability to add numbers in parallel depends on the fact that addition is associative. (So, putting it simply, STL is the result of a bacterial infection.) In other words, I realized that a parallel reduction algorithm is associated with a semigroup structure type. That is the fundamental point: algorithms are defined on algebraic structures. It took me another couple of years to realize that you have to extend the notion of structure by adding complexity requirements to regular axioms. And than it took 15 years to make it work. (I am still not sure that I have been successful in getting the point across to anybody outside the small circle of my friends.) I believe that iterator theories are as central to Computer Science as theories of rings or Banach spaces are central to Mathematics. Every time I would look at an algorithm I would try to find a structure on which it is defined. So what I wanted to do was to describe algorithms generically. That's what I like to do. I can spend a month working on a well known algorithm trying to find its generic representation. So far, I have been singularly unsuccessful in explaining to people that this is an important activity. But, somehow, the result of the activity - STL - became quite successful.'

jerf 14y ago
If you want to work in an environment where a lot of people are thinking like this routinely, instead of a few lone voices in a vast sea of otherwise uninterested people, the Haskell community is doing a lot of work in this area, and able to move much faster since it's so much easier in Haskell than C++ templates (which isn't really a criticism of C++ templates, a lot of their capabilities are accidental rather than intended). This is why the Haskell community talks so much about monoids and applicatives and semigroups and a variety of other interesting structures in that area (and no, I did not forget to say monad, that structure is actually uninteresting here because it is too powerful). I believe the Fortress language is also doing some work here. A sample of the interesting sort of algorithm work that you can do when you think this way: http://apfelmus.nfshost.com/articles/monoid-fingertree.html http://apfelmus.nfshost.com/articles/monoid-fingertree.html Edit: See also the Typeclassopedia: http://www.haskell.org/haskellwiki/Typeclassopedia http://www.haskell.org/haskellwiki/Typeclassopedia And if you're really interested and want to take it hardcore, Edward Kmett's video on his lens library walks through how you can derive it with this sort of logic: http://youtu.be/cefnmjtAolY?hd=1 http://youtu.be/cefnmjtAolY?hd=1

schemer4 14y ago

"OOP is not the holy grail. It's a cute idea, and it was quite an improvement over procedural languages back in the 70's when it was invented. But it's honestly not all it's cracked up to be. In many cases it is clumsy and verbose and it doesn't really promote reusable code or modularity. That is why the C++ community is today far more interested in generic programming, and why everyone are finally starting to realize that functional programming is quite clever as well. OOP on its own just isn't a pretty sight." Smalltalk has had anonymous functions in the form of block objects since 1972! And they are so fundamental to the language that all control structures and iteration constructs are implemented using them! Look at the following if/else code in smalltalk: (...boolean expression...) ifTrue: [...true block...] ifFalse: [...false block...] That sends an ifTrue:ifFalse: message with two arguments, a true block and a false block (lambdas), and if the receiver, a Boolean expression that should yield either the True or False object, is true, then the first block gets evaluated and the second ignored, and if it's false, than the second is evaluated and the first ignored. Anonymous functions are a core part of OOP, because OOP is supposed to be a streamlined subset of Lisp, preferably with specialized message-passing syntax. The idea that anonymous functions are some recent, novel addition to OOP, or that functional programming constructs are at odds with "pure" OOP, or that by peppering your C++/Java/C# code with lambdas, your "object-oriented" code has suddenly become multi-paradigm, shows just how distorted an understanding of OOP and functional programming the average programmer, and even language designer, has. Stroustrup clearly didn't understand OOP or Smalltalk when he bolted classes on to his wretched mess of a language, and that's why C++ looks the way it does, instead of like Objective-C, a language that was a faithful, somewhat successful attempt to add Smalltalk-style OOP to C.

protomyth 14y ago
His ideas for OOP were based off of Simula 67 rather than Smalltalk.
sbmassey 14y ago
C++ OOP was based on Simula, rather that Smalltalk, which was OO back in the 60's, and didn't have blocks/anon functions/lambdas. (It did have coroutines though; not sure why that didn't make it to C++). Unlike Java or (I suppose) C#, C++ has been considered multi-paradigm certainly since 1998 with templates and the STL: this is not related to the recent addition of lambdas to the standard. Very little of the popular Boost library can be considered OO, for example, as it generally discourages inheritance hierarchies, as does most modern idiomatic C++.

npsimons 14y ago

Actually, Bruce Eckel goes over this in "Thinking in C++". Stroustrup chose not to use an object-based hierarchy, where everything inherits from one base class (like in Java and Smalltalk). This presents a problem when making generic containers (that is, a container that can hold any type of object). To solve this, generics (in the form of templates) were added to C++.