Earlier quoted context omitted.
> The downside, of course, is just how much code exists that is written in pre-C++11 dialects, and how many programmers are trained to write that sort of code. I do the same thing. Not because I can't write C++11, but because I still encounter systems with older compilers that I want to run programs on. What, is this surprising? Let's face reality: it's a little unreasonable to expect every system you work on to have…
> Let's face reality: it's a little unreasonable to expect every system you work on to have a compiler less than 3 years old. If you are running Linux, this is one thing that Windows gets right. (Although as you say VC++ has some catching up to do still).
We have C++14
211–220 of 353 posts
Re: We have C++14
#212Earlier quoted context omitted.
RAII is hardly a trait of modern C++.
Eh? How do you mean that?
RAII has been with C++ almost from the beginning.
Re: We have C++14
#213When I started writing C++ around 5 years ago, I had a perception that it was a language that is "on its way out". As I learned more and more of it, I've been super impressed at how modern it is becoming, and how it is adapting to overcome its perceived flaws. It is becoming a killer language to me: blazing fast, modern, ubiquitous, stable, and expressive.
I _completely_ agree. I think people need to start talking about how, when combined with the right tools and compilers, you can achieve nearly anything you can with another "modern" language more expressively and faster, all while being compatible with decades of massive c, c++, and objective-c libraries. Perhaps we should start with dispelling the old notion that one "shouldn't use" the STL.
Re: We have C++14
#214Can anyone recommend a book on modern C++?
Re: We have C++14
#215Earlier quoted context omitted.
> In languages like C++ "verbose" means "specific and obvious" Whoa, no it doesn't. C++ is far more verbose than necessary for things like creating algebraic datatypes or really creating any types.
Or looping through for loops. I remember the jaw-hitting-floor moment when my C++ book tried to pass off std::vector ::iterator it; for (it=arr.begin(); it!=arr.end(); it++) { ... } as an improvement over for (int i=0; i Not entirely unrelated: I'm currently busy verbosifying a large chunk of C++11 code into C++90 code because Reasons (or so the maintainers assure me).
Times have changed now of course.
Re: We have C++14
#216I see a lot of discussion around C++ becoming modern. I would like to know which features are actually modern? Is it lambdas? been around for literally decades. Is it type deduction? again been around for quite some time, far better type inference has been available in the likes of Haskell for quite some time. Is it addition of a particular threading model to the standard? this has always been available via some form…
C++ is 35 years old and predates Haskell and many other "modern" languages like Java, C#, Python, ... So yes, compared to what C++ was originally, it has become modern.
Comparing a later version of language to an earlier one to measure modernism seems rather pointless.
Re: We have C++14
#217Earlier quoted context omitted.
Too bad it's a mirage. No, really. "Modern C++" doesn't exist outside of blog posts, books, and tutorials. Real-world C++ is an array of sometimes mututally-exclusive dialects, patterns, rules, sub-dialects. Reading MFC is nothing like reading Qt which is nothing like WxWidgets which is nothing like Boost which is something (but not quite like) the STL which is way different from Apache C++ libs which is way differen…
Rust is really the only language that's actually targeting the same niche as C++ primarily occupies, system level programming where reasoning about memory management and performance is part of the actual work being done. Go, let alone others, simply do not allow you to do this. It shows a distinct lack of understanding of why people still use C or C++ to raise languages/environments like Go as viable alternatives.
Re: We have C++14
#218Earlier quoted context omitted.
Uh, no, "virtual" should absolutely NOT be the default. I don't know where you got that idea from (Java?) but it's absolutely horrible.
It was the right default twenty years ago for performance reasons. These days, the economy of a vtable pointer is not really a good reason, and all languages that have the opposite default (such as Java, as you point out) are doing quite fine. Because of this default, I can't count the number of times where I've seen "#define private public" and other horrors that developers used to be able to extend classes that the…
Not being able to inline a method like (from vector)
T& operator[](size_t pos)
{ return data[pos]; }
Would kill performance.In languages which do run-time optimisation you can inline such methods later, but in C++ that's not possible and proving when you can de-virtualise a method (which most compilers do) is very hard and often fails.
Re: We have C++14
#219Earlier quoted context omitted.
Too bad it's a mirage. No, really. "Modern C++" doesn't exist outside of blog posts, books, and tutorials. Real-world C++ is an array of sometimes mututally-exclusive dialects, patterns, rules, sub-dialects. Reading MFC is nothing like reading Qt which is nothing like WxWidgets which is nothing like Boost which is something (but not quite like) the STL which is way different from Apache C++ libs which is way differen…
As a counterpoint, I write "Modern C++" for my job. I know several others who do, too. I'm overjoyed at how much the C++11 features have improved my code (and I'm still learning how to deploy them effectively), as well as how good the compiler support is. MFC was the vilest, most horrible abuse of C++ from the day it was released. Anything that involves MFC should just be rewritten with C# or turned into a webapp. I…
MFC's greatest benefit was that it made returning to plain win32 C programming without MFC a pleasurable experience.
Re: We have C++14
#220I see a lot of discussion around C++ becoming modern. I would like to know which features are actually modern? Is it lambdas? been around for literally decades. Is it type deduction? again been around for quite some time, far better type inference has been available in the likes of Haskell for quite some time. Is it addition of a particular threading model to the standard? this has always been available via some form…
> What is modern about any of features that have been added? Nothing. On the other hand, which features of a “modern” language are missing in C++ by now? Type deduction is still a bit less powerful than in Haskell, yes, but apart from that I can’t really think of anything that may or may not be missing. This in turn implies that C++ allows essentially any style of coding you may wish for at the moment while at the sa…
The real wins in performance for real world applications are in terms of algorithmic complexity. A poorly implemented solution in C++ will still be slow, the language does not make it fast.
Any micro optimization you can make with C++ will be an order magnitude less significant than O(log n) vs O(n).
The likes of Janestreet will likely need high performance software yet have great success with Ocaml for example, which incidentally can be very fast.
Just saying C++ is fast does not make programs written in C++ actually fast.