Live data from Hacker News

C++ Core Guidelines

github.com

11–20 of 115 posts

Re: C++ Core Guidelines

#11
Not to threadjack, but: I never really learned C++, just C and then started using C++. And I haven't used C++ much in the last decade+, but would like to get back into it and learn how to do things The Right Way.

What are some good online resources for learning "modern C++", for someone who already knows several languages?

Re: C++ Core Guidelines

#12
post #7

I wish they were more specific about when to use and not use exceptions. Truth be told I really hate exceptions and I strongly feel that they should only be used in the most disastrous situations. I'm messing with the 0MQ C++ wrapper now (which I will probably move off of) and they use exceptions for freaking everything. For example the send(msg) method returns true if the message is sent, false if EWOULDBLOCK is ret…

Bjarne's guidance has always been to use exceptions only in truly exceptional circumstances. A function that might occasionally fail on bad user input could instead return a std::optional and be marked noexcept (assuming it really doesn't throw). A function that fails to allocate memory, on the other hand, is truly exceptional, so throw std::bad_alloc.

The STL unfortunately doesn't always follow this approach, and tends to overthrow.

Signaling why something failed without exceptions is still unnecessarily tricky in C++. Not because it can't be done, but because there's no standard guidance on how to do it. There are 3,385 ways to do the job, so in many cases it's better simply not to.

Re: C++ Core Guidelines

#13

Not to threadjack, but: I never really learned C++, just C and then started using C++. And I haven't used C++ much in the last decade+, but would like to get back into it and learn how to do things The Right Way. What are some good online resources for learning "modern C++", for someone who already knows several languages?

https://news.ycombinator.com/item?id=16535886

Re: C++ Core Guidelines

#14
post #9
post #7

I wish they were more specific about when to use and not use exceptions. Truth be told I really hate exceptions and I strongly feel that they should only be used in the most disastrous situations. I'm messing with the 0MQ C++ wrapper now (which I will probably move off of) and they use exceptions for freaking everything. For example the send(msg) method returns true if the message is sent, false if EWOULDBLOCK is ret…

> I wish they were more specific about when to use and not use exceptions. Do you have any examples in mind where it's unclear to you whether an exception would be appropriate?

No because I almost never use exceptions myself (unless consuming them). The only time I would really use it is if for some reason the constructor could fail, but usually in those cases there are better ways of designing the class. Otherwise it's error codes/reasons.

Honestly I'm not sure where to draw the line specifically, but I obviously err more on the side of "don't use them". Exceptions in C++ are costly and imo control flow gets all wonky with them...I find it's easier to reason about a program if the error handling is there with the rest of the logic instead of being a list of things that can happen at some point in the above code block.

Re: C++ Core Guidelines

#15
post #12
post #7

I wish they were more specific about when to use and not use exceptions. Truth be told I really hate exceptions and I strongly feel that they should only be used in the most disastrous situations. I'm messing with the 0MQ C++ wrapper now (which I will probably move off of) and they use exceptions for freaking everything. For example the send(msg) method returns true if the message is sent, false if EWOULDBLOCK is ret…

Bjarne's guidance has always been to use exceptions only in truly exceptional circumstances. A function that might occasionally fail on bad user input could instead return a std::optional and be marked noexcept (assuming it really doesn't throw). A function that fails to allocate memory, on the other hand, is truly exceptional, so throw std::bad_alloc. The STL unfortunately doesn't always follow this approach, and te…

since optional is a thing now and the standards committee isn't afraid of verbosity maybe we can get std::value_or_error ;)

Re: C++ Core Guidelines

#17
post #13

Not to threadjack, but: I never really learned C++, just C and then started using C++. And I haven't used C++ much in the last decade+, but would like to get back into it and learn how to do things The Right Way. What are some good online resources for learning "modern C++", for someone who already knows several languages?

https://news.ycombinator.com/item?id=16535886

Oh wow! How did I miss that? Thanks!

Re: C++ Core Guidelines

#18
post #15
post #12

Earlier quoted context omitted.

Bjarne's guidance has always been to use exceptions only in truly exceptional circumstances. A function that might occasionally fail on bad user input could instead return a std::optional and be marked noexcept (assuming it really doesn't throw). A function that fails to allocate memory, on the other hand, is truly exceptional, so throw std::bad_alloc. The STL unfortunately doesn't always follow this approach, and te…

since optional is a thing now and the standards committee isn't afraid of verbosity maybe we can get std::value_or_error ;)

Like Google StatusOr?

Re: C++ Core Guidelines

#19
post #7

I wish they were more specific about when to use and not use exceptions. Truth be told I really hate exceptions and I strongly feel that they should only be used in the most disastrous situations. I'm messing with the 0MQ C++ wrapper now (which I will probably move off of) and they use exceptions for freaking everything. For example the send(msg) method returns true if the message is sent, false if EWOULDBLOCK is ret…

So nice to see that attitude. Exceptions, as implemented in C++, turn it into a dynamically typed language. If working with code written by others (libraries, big project), it is really hard to reason about control flow if every function call is potential return statement. It is not exactly easy to read top level error handling code either:

    catch (Pig) { // now Grunk need find pig.
The amount of frame unwinding code generated can get really big, etc.

I wish C++ provided means to preallocate memory for handling task (2 buffers for 4k, map for N objects of type T, ..., ok? then run this). Instead, there is a russian roulette powered default allocator, that can out-of-mem at any time...

Post reply on HN