5 ms·

Pretty much everything in C++11 sounds extremely cool and useful. It seems like the committee did their homework; from what I can see all of the new features a

Pretty much everything in C++11 sounds extremely cool and useful. It seems like the committee did their homework; from what I can see all of the new features are well-designed and thought through. Lots of things that were verbose or inefficient before are fixed, and as a result the language will be more expressive. But I just have this nagging worry that C++ is going to collapse under its own weight. C++ was already the most complicated language in common use IMO (except possibly Perl); with C++11 there are more keywords, more constructs, more variations. I just hope this doesn't make C++ seem totally unapproachable to beginners, or too hard to keep up with for people who are already using it.

cageface 15y ago
C++ isn't going away but its domain continues to contract. The C++11 standard will slow the erosion but I'm very doubtful that we'll see the "C++ renaissance" that people like Herb Sutter are predicting. Even now on low-powered devices like phones you can often get away with more wasteful languages like Java or even Javascript. And server-side there are a bunch of much higher-level languages that are close enough in performance and usually with a far richer ecosystem to boot.
- pjmlp 15y ago
  I used to think like that, but now I am back to languages with native code generation for the projects where I can dictate a language choice. Depending on the project requirements, this means C++, D, Go, Haskell or OCaml. Sadly from all options I listed above, C++ is still the best one supported in the industry. But coupled with a good static analyzer, it is quite nice. What we miss is the possibility to have native code generation support for higher level languages to become more widespread.
  - akg 15y ago
    I'd be curious to know why you switched back to languages with native code generation? Is it mostly due to the control you have over code performance? Is so, are such applications fairly specific in scope, e.g., fluid-simulation on the GPU?
    - pjmlp 15y ago
      More control over performance and easiness of distribution. Desktop applications, where a good integration with the operating system is required. System programming and distributed systems as well. I lost a bit faith on VM based systems for deployment, due to too many deployments gone wrong. Now I advocate systems where you can get the best of both worlds. A VM based environment for development, and compile to native code when releasing the product. Something like Eiffel, ML and Lisp language families already offer. Java and .NET also have such options available, but they are not widespread.
    - soup10 15y ago
      Raw pointers, manual memory management, and "what you see is roughly what's executed in assembly" is very helpful for a wide variety of performance sensitive tasks, there is a whole world out there beyond CRUD apps. There are many trivial optimizations you can't do without writing native code. Writing any performance sensitive code in a high level language is like playing the telephone game. What's funny is that high-level languages develop a culture of not caring about performance, which makes what could be a mild problem, much much worse. Java is actually a pretty fast language(for most purposes), you wouldn't know it from 9 out of 10 desktop java applications I've used.
  - cageface 15y ago
    I'm fond of native languages too and would like to believe that they're making a comeback but I really just don't see much evidence for this so far. I've dabbled in OCaml and Haskell but my current favorite is Go. I'm still looking for a good excuse to use it.
pubby 15y ago
The design idea of "don't pay for what you don't use" seems to cause the language features/library to be wide and orthogonal instead of deep; the weight is more or less spread out. Beginners can learn in increments, which is the approach I took for C++11 - first I used new template features, then rvalue references, then threading, and so on.
JoeAltmaier 15y ago
I'd have liked better ptr features. The auto-cleanup is good. Is it flexible enough to do other things like: auto-close (a file ptr); auto-deref (a ref-counted thing); auto-unlock (a critical section) etc?
- mkl 15y ago
  All of these can be done in a class's destructor, which is called when the object is deleted, e.g. when a shared_ptr's ref-count reaches 0 (i.e. there are no references to it left). To express observation (and break cycles) there is weak_ptr, and to express ownership there is unique_ptr. IMO the new pointer stuff is excellent, and relieves the large majority of the memory management burden.
  - reddit_clone 15y ago
    There are some boost macros which will run clean up code at the end of the scope if you prefer. They are not pretty. But they work. (This is a life saver in a long function with multiple exit points)
- njs12345 15y ago
  I haven't read TFA, but all of this stuff is commonly done with RAII in C++: http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization#Typical_uses http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initial... I think the main change C++11 makes in this area is the introduction of std::unique_ptr.

cageface 15y ago

C++ isn't going away but its domain continues to contract. The C++11 standard will slow the erosion but I'm very doubtful that we'll see the "C++ renaissance" that people like Herb Sutter are predicting. Even now on low-powered devices like phones you can often get away with more wasteful languages like Java or even Javascript. And server-side there are a bunch of much higher-level languages that are close enough in performance and usually with a far richer ecosystem to boot.

pjmlp 15y ago
I used to think like that, but now I am back to languages with native code generation for the projects where I can dictate a language choice. Depending on the project requirements, this means C++, D, Go, Haskell or OCaml. Sadly from all options I listed above, C++ is still the best one supported in the industry. But coupled with a good static analyzer, it is quite nice. What we miss is the possibility to have native code generation support for higher level languages to become more widespread.
- akg 15y ago
  I'd be curious to know why you switched back to languages with native code generation? Is it mostly due to the control you have over code performance? Is so, are such applications fairly specific in scope, e.g., fluid-simulation on the GPU?
  - pjmlp 15y ago
    More control over performance and easiness of distribution. Desktop applications, where a good integration with the operating system is required. System programming and distributed systems as well. I lost a bit faith on VM based systems for deployment, due to too many deployments gone wrong. Now I advocate systems where you can get the best of both worlds. A VM based environment for development, and compile to native code when releasing the product. Something like Eiffel, ML and Lisp language families already offer. Java and .NET also have such options available, but they are not widespread.
  - soup10 15y ago
    Raw pointers, manual memory management, and "what you see is roughly what's executed in assembly" is very helpful for a wide variety of performance sensitive tasks, there is a whole world out there beyond CRUD apps. There are many trivial optimizations you can't do without writing native code. Writing any performance sensitive code in a high level language is like playing the telephone game. What's funny is that high-level languages develop a culture of not caring about performance, which makes what could be a mild problem, much much worse. Java is actually a pretty fast language(for most purposes), you wouldn't know it from 9 out of 10 desktop java applications I've used.
- cageface 15y ago
  I'm fond of native languages too and would like to believe that they're making a comeback but I really just don't see much evidence for this so far. I've dabbled in OCaml and Haskell but my current favorite is Go. I'm still looking for a good excuse to use it.

pubby 15y ago

The design idea of "don't pay for what you don't use" seems to cause the language features/library to be wide and orthogonal instead of deep; the weight is more or less spread out. Beginners can learn in increments, which is the approach I took for C++11 - first I used new template features, then rvalue references, then threading, and so on.

JoeAltmaier 15y ago

I'd have liked better ptr features. The auto-cleanup is good. Is it flexible enough to do other things like: auto-close (a file ptr); auto-deref (a ref-counted thing); auto-unlock (a critical section) etc?

mkl 15y ago
All of these can be done in a class's destructor, which is called when the object is deleted, e.g. when a shared_ptr's ref-count reaches 0 (i.e. there are no references to it left). To express observation (and break cycles) there is weak_ptr, and to express ownership there is unique_ptr. IMO the new pointer stuff is excellent, and relieves the large majority of the memory management burden.
- reddit_clone 15y ago
  There are some boost macros which will run clean up code at the end of the scope if you prefer. They are not pretty. But they work. (This is a life saver in a long function with multiple exit points)
njs12345 15y ago
I haven't read TFA, but all of this stuff is commonly done with RAII in C++: http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization#Typical_uses http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initial... I think the main change C++11 makes in this area is the introduction of std::unique_ptr.