Live data from Hacker News

We have C++14

isocpp.org

211–220 of 353 posts

Re: We have C++14

#211
post #75

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

Heh! I am stuck on VC++ 2010 at work. I gaze longingly at C++11 features but can't use them. A pity, as the same codebase is also built under XCode and Clang.

Re: We have C++14

#212
post #202

Earlier quoted context omitted.

RAII is hardly a trait of modern C++.

Eh? How do you mean that?

Presumably that it's nothing new. The term RAII dates to the mid to late 80's sometime, and you could hardly find any book about C++ from the 90's onwards that wouldn't be espousing RAII as the One True Way.

RAII has been with C++ almost from the beginning.

Re: We have C++14

#213
post #26
post #12

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

Do people really not use the STL? It's incredibly useful, and portable!

Re: We have C++14

#214
post #25

Can anyone recommend a book on modern C++?

Stroustrup's The C++ Programming Language 4th Edition (the blue one) is good. The beginning of it gives a tour of C++ in light detail but then you have the rest of the book to look at as a reference. It's actually quite an enjoyable read, particularly as it has a different font to the previous version (the white one?).

Re: We have C++14

#215

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

I remember reading Stroustrup's book and not having a clue what an "iterator" was. Even looking in dictionaries didn't help me - I was just after the very definition of the word!

Times have changed now of course.

Re: We have C++14

#216
post #196

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

My point is that none of the features are modern.

Comparing a later version of language to an earlier one to measure modernism seems rather pointless.

Re: We have C++14

#217

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

Don't forget D

Re: We have C++14

#218

Earlier 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…

The real problem with defaulting to virtual isn't the vtable pointer, it's the lack of inling.

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

#219

Earlier 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 was the vilest, most horrible abuse of C++ from the day it was released.

MFC's greatest benefit was that it made returning to plain win32 C programming without MFC a pleasurable experience.

Re: We have C++14

#220
post #196

I 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…

C++ is no faster than any other language, it's the code that is written which is measurable.

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.

Post reply on HN