6 ms·

> Given C++'s age, I'll assume in the following that the question also puts C++ alongside with C as a target for replacement. Yes, C++ is old, but it has reall

> Given C++'s age, I'll assume in the following that the question also puts C++ alongside with C as a target for replacement. Yes, C++ is old, but it has really stayed with the times in an impressive way. The so-called "Modern C++" that started with C++11 is a significantly different way of writing C++. All the things that made C++ infamously challenging and allowed inexperienced developers to leak memory and cause crashes, are, for the most part, no longer in the normal C++ workflow. And all the rage about functional programming, passing around functions as values, writing closures that capture and encapsulate their surrounding values, using map, filter, reduce algorithms, relying on type inference, forgetting about pointer deletion and manual memory management and avoiding the access out of bounds memory on iterations -- that is all normal C++ now. If anything has or will successfully replace C++, it is going to be C++ itself. The standards committee and community are doing an extraordinary job of keeping the language current while maintaining its great reputation for speed.

seivan 11y ago
Yeah but the problem is that your benefits depend on the libraries you're using. You might not be able to use unique/shared_ptr because of some framework using different conventions internally. But overall, I agree with you. C++11 seems different from when we used it in high school.
- KayEss 11y ago
  That's true to a certain extent. There are a ton of new libraries appearing though, and the benefits of moving to the newer features are so compelling that actively maintained libraries are swiftly moving over. In the past six months I've moved all of mine from C++03 to C++14 and going through the process of stripping out loads of Boost and internal facilities that are now in the language.
- T-zex 11y ago
  Smart pointers are about ownership. If "some framework is using different conventions internally" then that framework entirely owns the resource and access to it is not managed by smart pointers. That is a natural, fully idiomatic behaviour of modern C++ and is not related to any specific library.
  - seivan 11y ago
    yeah I am familiar with ownership from Obj-C reference counting. But the problem is when your own code interacts with the framework that uses its own internal way of managing memory (ironically it's a copy of Obj-C reference counting) Right now I've decided just to go with the frameworks way of doing things and inherit from their base object. The problem comes when I want to use this code outside in a different project :-/
pjmlp 11y ago
Yes, I came to the conclusion that when one is allowed to use C++14 and specially with the upcoming GSL and lifetime analyzer, most of the warts are off. For me, it is a good enough for when I step outside JVM/.NET work as I am an old C++ dog. The problem is those that the only tool is the compiler and nothing else. On Herb's talk at CppCon only 1% of the audience confirmed that they use static analyzers. Or those that have to deal with strict code guidelines or codebases that extend before C++98 as even a standard and don't even know what CppCon, HN or Reddit mean. For those cases, I think only way forward are language that throw the unsafe cruft out and provide safe practices from the get go, without external tools that are optional to use.
- lqdc13 11y ago
  I tried using new C++14 features, but the performance was terrible. Even compared to scripting languages. The problem is that you have to now performance profile every single feature and know all the gotchas.
  - danieldk 11y ago
    Could you elaborate which C++14 features were slow?
    - restalis 11y ago
      I don't know his problems with C++14, but from what I encountered with C++ in general, there are some default settings that may affect performance, like the iostream syncronization with stdio, concurrency treatment in stl containers, etc.
    - lqdc13 11y ago
      I would have to find the exact example, but I tried counting words etc. Specifically, using the new built in abstractions is slower than not using the abstractions. For example, unordered_map was pretty slow. I just checked again though and it is much faster for counting words because they fixed a bug: http://www.mail-archive.com/gcc-bugs@gcc.gnu.org/msg368041.html http://www.mail-archive.com/gcc-bugs@gcc.gnu.org/msg368041.h... Edit: I know that example is a C++11 feature, but basically the idea is that you have to try things with different inputs before making conclusions.
jernfrost 11y ago
C++11 in no way solves the fundamental problem of C++. C++ is too big and has too much baggage. There are too many corner cases and oddball stuff to deal with. Being a good C++ developer requires unnecessary amounts of training. C++11 can't remove what is already there and so one just keeps piling on more stuff increasing the complexity. I am actually sad C++11 happened because it keeps alive a language that should have died years ago. I've worked years on projects where so many of the fundamental problems can be traced back to the usage of C++. Huge amount of legacy code which can't safely be refactored because C++ is just too complex a language for a refactoring tool to be able to deal with properly. Insane compile times. Odd hard to track down problems from static initialization and deinitialization. Templates are impossible to use in a sane way because they mix so poorly with regular OOP in C++ and increase compile times too much to be practical. Move a project like that gradually away from C++ is a huge undertaking and nobody is going to support it as long as C++ keeps updating self to not be completely behind the times.
- hellofunk 11y ago
  >There are too many corner cases and oddball stuff to deal with. It seems like all the langauges I've used, from objective-c to swift and Clojure require you to keep certain aspects of the language in mind for certain situations that don't on the surface seem obvious. Purity in any language is quite rare. In the case of C++, it is possible to ignore much of that old baggage most or maybe even all of the time if you write new code using new features. I agree that those maintaining much older codebases are going to have a rough time, but is not an uncommon problem in many languages. Also, even in a so-called "better" language you can run into massive refactoring projects with older code once you choose to adopt new libraries and tools. As Bjarne says, C++11 is much better, C++14 will be even better, and C++17 is further going to be better... frankly, this is a good path for any language to be on.
  - gbersac 11y ago
    There is much more weird stuff in c++ than in any other language. Especially rust. Add to that that you also have to deal with the Makefile/Cmake garbage. Another solved by rust (rust is shipped with cargo which release you of the makefile hell).

seivan 11y ago

Yeah but the problem is that your benefits depend on the libraries you're using. You might not be able to use unique/shared_ptr because of some framework using different conventions internally. But overall, I agree with you. C++11 seems different from when we used it in high school.

KayEss 11y ago
That's true to a certain extent. There are a ton of new libraries appearing though, and the benefits of moving to the newer features are so compelling that actively maintained libraries are swiftly moving over. In the past six months I've moved all of mine from C++03 to C++14 and going through the process of stripping out loads of Boost and internal facilities that are now in the language.
T-zex 11y ago
Smart pointers are about ownership. If "some framework is using different conventions internally" then that framework entirely owns the resource and access to it is not managed by smart pointers. That is a natural, fully idiomatic behaviour of modern C++ and is not related to any specific library.
- seivan 11y ago
  yeah I am familiar with ownership from Obj-C reference counting. But the problem is when your own code interacts with the framework that uses its own internal way of managing memory (ironically it's a copy of Obj-C reference counting) Right now I've decided just to go with the frameworks way of doing things and inherit from their base object. The problem comes when I want to use this code outside in a different project :-/

pjmlp 11y ago

Yes, I came to the conclusion that when one is allowed to use C++14 and specially with the upcoming GSL and lifetime analyzer, most of the warts are off. For me, it is a good enough for when I step outside JVM/.NET work as I am an old C++ dog. The problem is those that the only tool is the compiler and nothing else. On Herb's talk at CppCon only 1% of the audience confirmed that they use static analyzers. Or those that have to deal with strict code guidelines or codebases that extend before C++98 as even a standard and don't even know what CppCon, HN or Reddit mean. For those cases, I think only way forward are language that throw the unsafe cruft out and provide safe practices from the get go, without external tools that are optional to use.

lqdc13 11y ago
I tried using new C++14 features, but the performance was terrible. Even compared to scripting languages. The problem is that you have to now performance profile every single feature and know all the gotchas.
- danieldk 11y ago
  Could you elaborate which C++14 features were slow?
  - restalis 11y ago
    I don't know his problems with C++14, but from what I encountered with C++ in general, there are some default settings that may affect performance, like the iostream syncronization with stdio, concurrency treatment in stl containers, etc.
  - lqdc13 11y ago
    I would have to find the exact example, but I tried counting words etc. Specifically, using the new built in abstractions is slower than not using the abstractions. For example, unordered_map was pretty slow. I just checked again though and it is much faster for counting words because they fixed a bug: http://www.mail-archive.com/gcc-bugs@gcc.gnu.org/msg368041.html http://www.mail-archive.com/gcc-bugs@gcc.gnu.org/msg368041.h... Edit: I know that example is a C++11 feature, but basically the idea is that you have to try things with different inputs before making conclusions.

jernfrost 11y ago

C++11 in no way solves the fundamental problem of C++. C++ is too big and has too much baggage. There are too many corner cases and oddball stuff to deal with. Being a good C++ developer requires unnecessary amounts of training. C++11 can't remove what is already there and so one just keeps piling on more stuff increasing the complexity. I am actually sad C++11 happened because it keeps alive a language that should have died years ago. I've worked years on projects where so many of the fundamental problems can be traced back to the usage of C++. Huge amount of legacy code which can't safely be refactored because C++ is just too complex a language for a refactoring tool to be able to deal with properly. Insane compile times. Odd hard to track down problems from static initialization and deinitialization. Templates are impossible to use in a sane way because they mix so poorly with regular OOP in C++ and increase compile times too much to be practical. Move a project like that gradually away from C++ is a huge undertaking and nobody is going to support it as long as C++ keeps updating self to not be completely behind the times.

hellofunk 11y ago
>There are too many corner cases and oddball stuff to deal with. It seems like all the langauges I've used, from objective-c to swift and Clojure require you to keep certain aspects of the language in mind for certain situations that don't on the surface seem obvious. Purity in any language is quite rare. In the case of C++, it is possible to ignore much of that old baggage most or maybe even all of the time if you write new code using new features. I agree that those maintaining much older codebases are going to have a rough time, but is not an uncommon problem in many languages. Also, even in a so-called "better" language you can run into massive refactoring projects with older code once you choose to adopt new libraries and tools. As Bjarne says, C++11 is much better, C++14 will be even better, and C++17 is further going to be better... frankly, this is a good path for any language to be on.
- gbersac 11y ago
  There is much more weird stuff in c++ than in any other language. Especially rust. Add to that that you also have to deal with the Makefile/Cmake garbage. Another solved by rust (rust is shipped with cargo which release you of the makefile hell).