We have C++14 • Hacker News Board

Re: We have C++14

#351

Post by prodigal_erik » Thu, Aug 21, 2014, 9:44 AM UTC

sillysaurus3 wrote: post #332

jonstewart wrote: post #328

Earlier quoted context omitted.

We're talking about the same book, _Exceptional C++: 47 Engineering Puzzles, Programming Problems, and Solutions_, by Herb Sutter. The takeaway I had from reading that book (a long time ago) was just to use RAII religiously, which also tends to make other things easier. So I'm curious about why you think RAII makes writing exception-safe code difficult?

Sorry for the confusion. I meant that writing exception-safe code is difficult, not that RAII makes it difficult to write exception-safe code. I should have been clearer about that. The book is excellent. For anyone who wants to use C++ exceptions, it should be required reading. But as someone who has gone through that gauntlet, I feel that I probably would've been better served by spending my time on something other…

Their style guide http://google-styleguide.googlecode.com/svn/trunk/cppguide.x... is sheepish about it. The authors seem to believe using exceptions would have been better, except they found themselves beyond a critical mass of bad code that would fail or leak on a throw, and now they can't fix it all or throw it away.

I can't understand how a correct init method could be easier to write than a ctor, given that the compiler is required to generate code that knows which of your base classes and fields are already initialized at any point they could fail, which you would have to do yourself after moving to an init method, as well as losing the guarantee you can't silently ignore an error by forgetting to check for it.

Re: We have C++14

#352

Post by maxlybbert » Thu, Aug 21, 2014, 6:00 PM UTC

nly wrote: post #343

maxlybbert wrote: post #313

Earlier quoted context omitted.

Nobody's ever accidentally tried to uppercase a UTF-32 string by passing each code point to C's toupper() function; but that constantly shows up in projects using UTF-8 for in-memory strings. And it's not always caught by unit tests. People never accidentally pass a UTF-32 string to a legacy API that expects char*'s in Latin1 encoding. I when I say "never" I don't mean "almost never happens"; I mean literally "anybod…

> Nobody's ever accidentally tried to uppercase a UTF-32 string by passing each code point to C's toupper() function Note to put aside, since this was all about C++, the toupper() in is a template type that takes an arbitrary character type and a locale. There are also functions for locale sensitive collation and comparison. So, modulo bad implementation, you should be able to do basic unicode string handling in ISO…

> So, modulo bad implementation, you should be able to do basic unicode string handling in ISO C++.

The locale stuff has been intentionally left vague. So:

(1) assuming that your implementation supports passing a char16_t or char32_t to the functions in , you're guaranteed it will do the right thing as far as Unicode and the C++ standard (although, there are some well-known problems with what the C++ standard defines the "right thing" top be for lowercasing epsilon -- since in Greek, there are two lowercase forms of epsilon, and the C++ standard doesn't provide the function enough information to decide between those two forms -- and for uppercasing ẞ (LATIN CAPITAL LETTER SHARP S) -- because in German the uppercase form takes two letters, and the C++ standard assumes doesn't allow for that).

The fun part is that plain char's can be encoded in several different ways, and not all have anything to do with Unicode. So you need to have a Unicode-aware locale for the functions in to do anything sensible with Unicode. Of course, that's something of a tautology, but I'm not sure what the standard requires for locales. So, yes, if your implementation is Unicode aware, you can call a standard C++ function to get what you want, but be sure to call the right one. There's another, with the same name, that isn't guaranteed to do what you want.

Re: We have C++14

#353

Post by ixtli » Sat, Aug 23, 2014, 12:02 AM UTC

72deluxe wrote: post #213

ixtli wrote: post #26

Earlier quoted context omitted.

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!

(Sorry for the late reply.) But yes, I find that people who've made careers out of programming in non c++ languages never revisit it when planning a project because they have this weird notion that it "slow" or "poorly implemented." I really don't know where this is comes from but I've heard it from many people i've worked with over the years.