Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We have C++14

isocpp.org

Post reply on HN
Print view View original

161–170 of 353 posts

Re: We have C++14

#161

Post by EpicEng »

PopsiclePete wrote: post #98
daenz wrote: 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…

So "Modern C++" is a mirage, but Rust and Go are the surefire winners? Do you have any substance to add to your post?

I don't know, I've been writing C++ for about a decade and the code I write is "modern" as far as I can tell. I just started a new project. It is C++, it is "modern", and Rust and Go simply aren't options.

Rust is an infant and not yet ready for prime time, and Go simply wouldn't be considered by management. Not because they're ignorant, out of date curmudgeons, but because they want a larger pool of talent to draw upon and a language that is well known, well understood, and has decades of work invested around tooling. I can't say that I blame them.

Re: We have C++14

#162

Post by wfunction »

shmerl wrote: post #136
adrusi wrote: post #96

Earlier quoted context omitted.

Linux is on all parts of the spectrum here. Ubuntu LTS and Slackware are going to remain outdated by design. Arch Linux almost always have the most recent stable releases of GCC and clang, and you can even build development snapshots from AUR

You don't need to use the compiler from the distro to release for that distro. There is such thing as cross compilation after all. Most do it out of habit and because distros don't offer such services out of the box. But if you build the cross compiler, you can use the newest one even if the distro ships the older. For example I had a building machine running RHEL 5 which was building for both RHEL 5 and RHEL 6 while…

You say "if you build the cross-compiler" as though it's as simple as "if you cross the street". Have you ever tried building GCC? I've wasted days on it and in the end still failed to make it work.

Re: We have C++14

#163

Post by wfunction »

zak_mc_kracken wrote: post #103
wfunction wrote: post #44

Earlier quoted context omitted.

Performance is only one side of it. The bigger reason is http://stackoverflow.com/a/814939

Over 20+ years of development, I've found this objection to be vastly theoretical and with no practical consequences. In practice, most classes are designed without inheritance in mind and yet, being able to extend and override them has proven infinitely more valuable than the occasional case where such an overriding breaks the parent class. The practical reality is that even if a class is not designed for inheritanc…

Seemingly off-topic, but I'm curious -- what language has the majority of your 20+ years of development been in?

Re: We have C++14

#164

Post by sillysaurus3 »

eropple wrote: post #151
sillysaurus3 wrote: post #118

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. And of course, if you admit that exceptions aren't worth worrying about, then you'll start to question the entire "C++ way," which usually ends in disillusionment. Alternatively, instead of disillusionment, you may still kind of enjoy C++. Bu…

> 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 memory leak than to make your class exception safe on the first try. That's my point. That's why C++ is overly cumbersome unless you ignore most of its capabilities, like exceptions. And that's why you can simply ignore C++ and not miss out on much. If performance is your only reason for rigorously sticking to a mental model, it's likely that your mental model is a premature optimization.

Re: We have C++14

#165

Post by DSingularity »

PopsiclePete wrote: post #98
daenz wrote: 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…

And what exactly does that mean? So what if the libraries are all written differently? I hardly see how thats a negative thing. The language is flexible. I was very impressed with c++11 features and I am looking forward to c++14.

Re: We have C++14

#166

Post by octopus »

mariodiana wrote: post #126
PopsiclePete wrote: post #98

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…

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.

Re: We have C++14

#167

Post by Chronic29 »

shmerl wrote: post #135
PopsiclePete wrote: post #98

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 should have written your project in Go or Rust. That's the whole point.

Re: We have C++14

#168

Post by [deleted] »

wfunction wrote: post #162
shmerl wrote: post #136

Earlier quoted context omitted.

You don't need to use the compiler from the distro to release for that distro. There is such thing as cross compilation after all. Most do it out of habit and because distros don't offer such services out of the box. But if you build the cross compiler, you can use the newest one even if the distro ships the older. For example I had a building machine running RHEL 5 which was building for both RHEL 5 and RHEL 6 while…

You say "if you build the cross-compiler" as though it's as simple as "if you cross the street". Have you ever tried building GCC? I've wasted days on it and in the end still failed to make it work.

[deleted]

Re: We have C++14

#169

Post by nanidin »

millstone wrote: post #146
bodyfour wrote: post #144

Earlier quoted context omitted.

Depends on if you need to gracefully handle malloc failures or not. Otherwise any write operation on an STL type (like appending to a string) will potentially throw an exception that you need to care about. In the C world this is extremely arduous since need to bubble the allocation-failure down through every level of code, adding cleanup to just about every function call. If you're using C++ and RAII you can just ca…

Do you work on systems that handle this? I'd like to know if any still exist. In modern systems I'm familiar with, malloc only reports failure on bogus inputs like -1, or address space exhaustion. Your process is likely to be killed before exhausting your address space (think iOS OOM handling, or Linux overcommit), especially on 64 bit. So checking for allocation success just isn't that useful any more.

I worked on an embedded system that aggressively cached images in memory dedicated to the GPU. It wasn't uncommon for gl texture allocation errors to occur - and in addition to that, we needed to decompress images packed in various formats into whatever format the GPU supported (typically from png to rgba32). In low memory situations, it also wasn't uncommon to not have enough contiguous memory to perform that decompression - in which case malloc would fail.

Gotta love putting forth every effort in software to keep the BOM down :)

Re: We have C++14

#170

Post by [deleted] »

colin_mccabe wrote: post #129
mariodiana wrote: post #126

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

I would use the Google Coding standard. The best book to read is Effective C++ (get the latest edition, since they have changed a lot.)

[deleted]
Post reply on HN