Live data from Hacker News

We have C++14

isocpp.org

291–300 of 353 posts

Re: We have C++14

#291

Earlier quoted context omitted.

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…

What were these corner cases and special considerations you ran into? I wouldn't call Herb Sutter's _Exceptional C++_ a huge tome and it seems to be the standard treatment of exception safety.

It's 240 pages of knowledge that you can completely do without, and it's a book called "47 engineering puzzles." The puzzles, of course, are entirely exception-related.

I'm not saying it's impossible to write exception safe code. I'm saying that you can write code without exceptions without being worse off for it.

Re: We have C++14

#292
post #219

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…

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

[deleted]

Re: We have C++14

#293
post #149

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…

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.

Is this a replacement for RenderMan? Interesting...

Re: We have C++14

#294
post #219

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…

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

Funny thing is that MFC iw like that because of Win16/Win32 C developers.

Microsoft team made a prototype OO framework even more OO that what OWL and others offered. MFC was the result from the feedback over the said framework.

Re: We have C++14

#295
post #219

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…

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

[deleted]

Re: We have C++14

#296

Earlier quoted context omitted.

Don't forget D

D is fine language and a pleasure to program in, but with it's required garbage collector, it's not really in the same niche as C/C++/Rust. I think the hallmark of this niche is the ability to run without a garbage collector penalty and the accompanying lack of determinism.

You mean like Mesa/Cedar at Xerox PARC, Oberon at ETHZ, Modula-3 at Olivetti...

Re: We have C++14

#297

Earlier quoted context omitted.

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

Why do people keep assuming that they need an X programmer, or a Y programmer? Go is a garbage collected imperative and OO language, right? It's not like Java and C++ programmers wouldn't be able to learn the basics in 3 days, and be proficient in a couple weeks. Why does the "pool of talent" even matters ?

Companies don't want to pay for training.

Re: We have C++14

#298
post #47

Earlier quoted context omitted.

Why not just write C style C++? I never understand the arguments to use C anymore - you can write C style C++ and get on with your life, and cherry pick the features you want. In C++ unicode is as simple as: string s = u8"This is always a utf8 string.";

Weeellll, your position is defensible if you're writing an application. If you're writing a library though, let me just let you know that every time I encounter a package with a C++ API, I want to drive stakes into the author's eyes, as compensation for the pain I'm about to experience. Like it or not, C is the lingua franca of the programming world. Pretty much every other language out there provides C bindings, not…

extern "C" {

}

Hey look, C API.

> This is not true for C++,

Depends on the code you write. If you write C in C++, you get the same near machine parity, since its the same source material. If you do not use namespaces you don't even get name mangling.

Re: We have C++14

#299
post #47

Earlier quoted context omitted.

Why not just write C style C++? I never understand the arguments to use C anymore - you can write C style C++ and get on with your life, and cherry pick the features you want. In C++ unicode is as simple as: string s = u8"This is always a utf8 string.";

Unicode is much more complex than that. For example, how would you then convert that string to uppercase, or truncate it? For Unicode strings in C++, you can either limp along with the wchar_t support, or leverage something like ICU. Neither is especially easy.

If you want string manipulation in C++ you need an external library no matter what encoding you use.

Also, std::toupper inherits the system locale (or whatever you set it to), so if it is utf8 it would do proper utf uppercase conversions. You need to parse per character though, and that depends on the locale again.

Re: We have C++14

#300
post #297

Earlier quoted context omitted.

Why do people keep assuming that they need an X programmer, or a Y programmer? Go is a garbage collected imperative and OO language, right? It's not like Java and C++ programmers wouldn't be able to learn the basics in 3 days, and be proficient in a couple weeks. Why does the "pool of talent" even matters ?

Companies don't want to pay for training.

Not even 4 weeks worth of semi-productive self-learning? That sounds quite pathetic.

There must be something else, like fear of the unknown, risk aversion, "nobody got fired for choosing IBM"…

Post reply on HN