Live data from Hacker News

We have C++14

isocpp.org

201–210 of 353 posts

Re: We have C++14

#201

Earlier quoted context omitted.

Not that I disagree with your real point about writing maintainable code rather than "clever" code, but if you have a single codebase that is maintained by thousands of engineers then I would argue that you're probably doing something horribly wrong already, and using exceptions is hardly exclusive to so-called rockstars. I don't really understand organisations that still use C++ in 2014 but then knock out such funda…

I agree that using exception is hardly noteworthy these days, but consider that in the context of a codebase that has evolved for more than a decade. I guess, ten years ago, "let's not use exceptions; they aren't worth it" was more justifiable. In any case, the decision was made, and we have millions of LOC where every single API is built with the assumption "No exceptions here." In that context, introducing exceptio…

This is of course a valid reasoning to forbid the use of some features at this particular company. However, it renders advocating the Google C++ style guide as an ubiquitous style guide for all C++ programming rather moot.

Re: We have C++14

#202

Earlier quoted context omitted.

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…

Me too. RAII ftw!

RAII is hardly a trait of modern C++.

Re: We have C++14

#203

Earlier quoted context omitted.

> Good luck making your RAII class exception safe. It's extremely difficult, to the point that writing a simple class becomes an hours-long exercise in reasoning about exceptions. In my experience, this is literally backwards. RAII is the only way to make exception-safe classes that aren't a gigantic mess. > It doesn't seem like C++ solves the right problems, even with the new dialects. Programming languages should b…

Yes, RAII is the only way to make an exception-safe class. Good luck doing it. It's not easy. I know; I've tried. There are all kinds of corner cases and special considerations that you have to take into account. People have written huge tomes about that exact topic detailing exactly why it's a hard problem and why you're probably not going to solve it correctly by accident. You're far more likely to introduce a memo…

"Good luck doing it. It's not easy. I know; I've tried" Completely unsupported assertion (no pun) without evidence. Other people have tried it, and have succeeded. I could start listing all the software written in C++ that you use in your everyday life, perhaps 100's of times a day... but that'll quickly exhaust my word limit for this post.

"That's why C++ is overly cumbersome unless you ignore most of its capabilities, like exceptions."

Complete non sequitur. Exceptions are not "most of C++ capabilities". In fact, you can refuse to catch or throw exceptions for 99% of your (millions of lines) of code and still end up with a very large, stable code base running a large portion of the internet. Ask Google.

Today, there's pretty much no viable alternative to C++ for writing large scale, high performance systems with reliable performance guarantees. You could do it in C if you have a religious anti-C++ agenda but that would be like cutting off your nose to spite your face, and you'll end up in a horrible mish-mash of macros and generated code all over the place for a project with any level of complexity. Rust or D might get there some day if they manage to attract a solid community and big corporate backing. But they are certainly not there yet.

Re: We have C++14

#204
post #135

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…

My recent project uses standard C++11. No dialects, no restrictions. Gcc 4.8.x. It's not a mirage, it's all up to those who want to use it or not.

You are missing the point. No project uses all features of C++ at once, only a subset, and this forms a dialect. It's not that infrequent to see the dialect change when going from one team to another even in the same organization. Some use multiple inheritance and exceptions, some don't. Some swear by STL, some won't touch it with a long pole. That's why internal coding guidelines exist and that's why they are particularly detailed and thick for C++ shops.

Re: We have C++14

#206
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.

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…

I have furniture at home made of wood. Oddly, my table looks nothing like my broom handle, so does this mean that wood is a terrible choice for both items? "The industry would be better off without wood!!"

Surely libraries in other languages have the same problem? They don't look anything like each other.

wxWidgets and Qt look nothing like each other but it isn't a problem at all. The signalling mechanism / event handling between the two just hides function pointers, so it isn't a headache. In fact, MFC looks like wxWidgets to me. Not sure what the problem is?

EDIT: Not sure why the downvote(s)? Do people get downvoted here because someone points something out that is true on a subject/language that they like/dislike? Or was it the tone or supposed tone that the person read the comment in? Please let me know!

Re: We have C++14

#207
post #149

Earlier quoted context omitted.

Too bad it's a mirage I hate to spoil your worldview, but modern C++ is very alive and well in the scientific computing communities. Disney Animation implemented a new renderer using it, and our next movie is currently being rendered using the new renderer, so I highly doubt it's on its way out in the these areas.

I don't see how that refutes the parent's comment. The areas you listed are very small niches. Frankly, very few people care about scientific computing or even animation rendering. Generally speaking, using C++ is like wearing jeans and white sneakers: popular in the 90s, but definitely out of fashion now.

Why do you need to be fashionable to be productive? Do people really ask what your finished software product is written in?

Re: We have C++14

#208

Earlier quoted context omitted.

I think you could say the same thing about any language where there are big frameworks and libraries that handle a lot for you. In the Java world, a Java EE CRUD application is a LOT different than a Swing application that does the same thing. Likewise, a Python Django application is a completely different beast than a console application.

But there is less variation: Java provides only one paradigm (OO) and frameworks use different flavors of that: beans, POJOs, heavy classes, etc. In C++ you can have such variations, plus all the other paradigms, including: * C with classes (people programming in this style often still use C strings, do deletes and frees in destructors). * C++ as the full-blown OOP language, with extensive multiple inheritance hierar…

That's a pity. My code appears to be a mix of the first three.....

any recommended reading?

Re: We have C++14

#209

Earlier quoted context omitted.

Could you name a book that focuses on Modern C++, that isn't one of these 1200 page tomes? I ask because sooner or later at my job I will probably have to code in C++. It will undoubtedly be a greenfield project, so I don't have to worry about anyone else's horror show (only my own).

Try "A Tour of C++" by Bjarne Stroustroup it has less than 200 pages.

Or just get Stroustrup's "The C++ Programming Language" and read the intro bit - it covers the language in fleeting detail but then you still have the rest of the book to look at if you are having a hard time understanding the section at the beginning.

Re: We have C++14

#210
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.
Post reply on HN