3 ms·

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 signifi

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

by muyuu 14y ago

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.