5 ms·

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

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).
- baq 14y ago
  the biggest problem with C++ is that you can't really use it correctly without knowing it inside out, because as soon as you make a simple mistake that compiles without a warning you're in undefined behavior territory. to efficiently debug such problems you need to know both the language and the debugging tools, which, cough, aren't simple.
  - hamidr 14y ago
    costs of performance?
- greyman 14y ago
  Yes, and what is interesting, the need for efficiency haven't faded away, despite the computers being more powerful every year. I am a veteran C++ coder, and I still find C++ a viable choice. You are getting native compiled objects, which is also efficient due to C legacy, AND, what is important, you are getting this efficiency also in the very abstract code. This I consider one of the main powers of C++ - you can basically choose which level of abstraction do you want; the language will not limit your choices here. But I agree the learning curve is quite steep, it takes years to really benefit from the language. What I found is a good practice is to define which paradigms/language constructs will be used in a project, and then to stick with those.
  - betterunix 14y ago
    "you can basically choose which level of abstraction do you want; the language will not limit your choices here." The language absolutely limits you in terms of choosing your abstractions. You can only redefine the operators already in the language. Adding a feature like continuations or dependent types would require a rewrite of your compiler. There is no notion of a metaobject protocol. At best, you can get some of the power of these abstractions by using a brittle mess of templates and objects, and you'll be left with code that is almost unreadable as a result. If you want to see a language that actually allows you to choose any abstraction, even those that were unknown when the language was developed, look at Lisp and its macro system.
pmr_ 14y ago
I think there is a different kind of modularity which you are talking about. That a solution that brings different components together requires to know about the other components is obvious. It is about how the components can be designed as free standing modules without any direct dependencies. Of course, a better module system in C++ would be great and things are moving into this direction (clang already has a preliminary implementation of the modules spec). It is not like the addition of templates broke C compatibility. This happened long before templates were talked about. Still, C code mostly (Yes, with tricky corners.) compiles with a C++ compiler which is great and is exactly what I would expect from a sub-set of a language. Funnily, first you complain about missing modularity due to headers and then you advocate being compatible with C, whereas exactly that feature is necessary for C compatibility. As to the efficiency: You can actually know which problem you are trying to solve in generic programming by inspecting the properties of types and optimize according to those properties. See for example the different optimizations in standard libraries when it comes to optimizing copies to memcpy calls when called with appropriate types. There is certainly a lot of generic code that is quite efficient (see std::function which compares to native function calls or hand-written virtual function call operators, very fast vector implementations (llvm, facebook), std::thread). There is, of course, bad generic code as there is bad code in every paradigm.
blablabla123 14y ago
"I think Go got generics much better. Pass an interface{LessOrEqual} to a Sort and you're golden." That's not generics but interfaces. C++ has them too... Kind of, in C++ they are called abstract classes; eventhough you need to inherit them explicitely. This is why you need to do type assertions when using container/heap, container/list... And this is why math.Min of two integers doesn't work without any extra work. :-) Go is pretty cool, I like it a lot. But there are fields in which interfaces are way less powerful than generics.
- ithkuil 14y ago
  go generics are different from abstract classes. C++ requires you to think in advance about the kind of abstract operation your class provides, and if you are adding "sort" operation later on, and you realize that in order to sort something you have to have the concept of ordering, you have to add it to all classes you want to be sortered. Go allows you to create an interface and then to create implementations of this interface for any type that already exists. Scala solves this problem by introducing implicit conversions, so it's core design is like C++/Java, but the net effect you get from that is like in golang.
  - eropple 14y ago
    Scala solves this problem better with structural typing, which is not that different from what Go does.
  - blablabla123 14y ago
    Yeah I totally agree, the Go interfaces are much more flexible than those of C++ or even Java. But please, don't call them "go generics", they are called "interfaces". ;-) http://golang.org/doc/go_faq.html#generics http://golang.org/doc/go_faq.html#generics
  - joelthelion 14y ago
    Go doesn't have generics. It has cool interfaces, but they solve a different problem, and the lack of generics (or templates, if you prefer) is a real problem in Go.
IheartApplesDix 14y ago
Garbage collection is not something to be proud of. I don't know where you got the idea that C++ as any thing but C with extensions. If you don't have to recompile after changing a template then what is the template even doing? Go is no replacement for C/++
- alexchamberlain 14y ago
  I agree that Garbage Collection; +1. However, C++ is no longer C with extensions. It is now a truly powerful multi-paradigm language in its own right.
  - IheartApplesDix 14y ago
    My point being that it isn't OOP specifically.
abrahamsen 14y ago
Bjarne Stroustrup was never a huge OOP evangelist. He spend all of 1½ page in the first edition of "The C++ Programming Language" explaining why this technique would be useful in specific situations, back when it was not widely known. Alexander Stepanov who designed STL is very critical of OOP. Stroustrup likes quoting him, mostly to annoy the evangelists. The C++ "party line" on the Usenet groups back when the OOP craze was at its top and C++ was a hot new upcoming language reflected Stroustrup's view. OOP was a useful technique is certain situations.
pandaman 14y ago
"C++ is the OOP" is, unfortunately, a very popular stance, especially among people who put "C/C++/C#" on their resumes. This has nothing to do with the "party line" whatever it might be, the C++ is as much "the OOP" as Scheme i.e. you can use its type system to implement some kind of OOP.

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

baq 14y ago
the biggest problem with C++ is that you can't really use it correctly without knowing it inside out, because as soon as you make a simple mistake that compiles without a warning you're in undefined behavior territory. to efficiently debug such problems you need to know both the language and the debugging tools, which, cough, aren't simple.
- hamidr 14y ago
  costs of performance?
greyman 14y ago
Yes, and what is interesting, the need for efficiency haven't faded away, despite the computers being more powerful every year. I am a veteran C++ coder, and I still find C++ a viable choice. You are getting native compiled objects, which is also efficient due to C legacy, AND, what is important, you are getting this efficiency also in the very abstract code. This I consider one of the main powers of C++ - you can basically choose which level of abstraction do you want; the language will not limit your choices here. But I agree the learning curve is quite steep, it takes years to really benefit from the language. What I found is a good practice is to define which paradigms/language constructs will be used in a project, and then to stick with those.
- betterunix 14y ago
  "you can basically choose which level of abstraction do you want; the language will not limit your choices here." The language absolutely limits you in terms of choosing your abstractions. You can only redefine the operators already in the language. Adding a feature like continuations or dependent types would require a rewrite of your compiler. There is no notion of a metaobject protocol. At best, you can get some of the power of these abstractions by using a brittle mess of templates and objects, and you'll be left with code that is almost unreadable as a result. If you want to see a language that actually allows you to choose any abstraction, even those that were unknown when the language was developed, look at Lisp and its macro system.

pmr_ 14y ago

I think there is a different kind of modularity which you are talking about. That a solution that brings different components together requires to know about the other components is obvious. It is about how the components can be designed as free standing modules without any direct dependencies. Of course, a better module system in C++ would be great and things are moving into this direction (clang already has a preliminary implementation of the modules spec). It is not like the addition of templates broke C compatibility. This happened long before templates were talked about. Still, C code mostly (Yes, with tricky corners.) compiles with a C++ compiler which is great and is exactly what I would expect from a sub-set of a language. Funnily, first you complain about missing modularity due to headers and then you advocate being compatible with C, whereas exactly that feature is necessary for C compatibility. As to the efficiency: You can actually know which problem you are trying to solve in generic programming by inspecting the properties of types and optimize according to those properties. See for example the different optimizations in standard libraries when it comes to optimizing copies to memcpy calls when called with appropriate types. There is certainly a lot of generic code that is quite efficient (see std::function which compares to native function calls or hand-written virtual function call operators, very fast vector implementations (llvm, facebook), std::thread). There is, of course, bad generic code as there is bad code in every paradigm.

blablabla123 14y ago

"I think Go got generics much better. Pass an interface{LessOrEqual} to a Sort and you're golden." That's not generics but interfaces. C++ has them too... Kind of, in C++ they are called abstract classes; eventhough you need to inherit them explicitely. This is why you need to do type assertions when using container/heap, container/list... And this is why math.Min of two integers doesn't work without any extra work. :-) Go is pretty cool, I like it a lot. But there are fields in which interfaces are way less powerful than generics.

ithkuil 14y ago
go generics are different from abstract classes. C++ requires you to think in advance about the kind of abstract operation your class provides, and if you are adding "sort" operation later on, and you realize that in order to sort something you have to have the concept of ordering, you have to add it to all classes you want to be sortered. Go allows you to create an interface and then to create implementations of this interface for any type that already exists. Scala solves this problem by introducing implicit conversions, so it's core design is like C++/Java, but the net effect you get from that is like in golang.
- eropple 14y ago
  Scala solves this problem better with structural typing, which is not that different from what Go does.
- blablabla123 14y ago
  Yeah I totally agree, the Go interfaces are much more flexible than those of C++ or even Java. But please, don't call them "go generics", they are called "interfaces". ;-) http://golang.org/doc/go_faq.html#generics http://golang.org/doc/go_faq.html#generics
- joelthelion 14y ago
  Go doesn't have generics. It has cool interfaces, but they solve a different problem, and the lack of generics (or templates, if you prefer) is a real problem in Go.

IheartApplesDix 14y ago

Garbage collection is not something to be proud of. I don't know where you got the idea that C++ as any thing but C with extensions. If you don't have to recompile after changing a template then what is the template even doing? Go is no replacement for C/++

alexchamberlain 14y ago
I agree that Garbage Collection; +1. However, C++ is no longer C with extensions. It is now a truly powerful multi-paradigm language in its own right.
- IheartApplesDix 14y ago
  My point being that it isn't OOP specifically.

abrahamsen 14y ago

Bjarne Stroustrup was never a huge OOP evangelist. He spend all of 1½ page in the first edition of "The C++ Programming Language" explaining why this technique would be useful in specific situations, back when it was not widely known. Alexander Stepanov who designed STL is very critical of OOP. Stroustrup likes quoting him, mostly to annoy the evangelists. The C++ "party line" on the Usenet groups back when the OOP craze was at its top and C++ was a hot new upcoming language reflected Stroustrup's view. OOP was a useful technique is certain situations.

pandaman 14y ago

"C++ is the OOP" is, unfortunately, a very popular stance, especially among people who put "C/C++/C#" on their resumes. This has nothing to do with the "party line" whatever it might be, the C++ is as much "the OOP" as Scheme i.e. you can use its type system to implement some kind of OOP.