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

C++ Core Guidelines

github.com

Post reply on HN
Print view View original

81–90 of 115 posts

Re: C++ Core Guidelines

#81

Post by izacus »

IshKebab wrote: post #35
112233 wrote: post #25

Ugh, so much wrong with this. There is C++, as implemented by every compiler, and then there is fantasy C++, as seen by the committee... See, e.g. this trainwreck: https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/rt2ivJnc4hg%5B1-25%5D Also, e.g. > P.6: What cannot be checked at compile time should be checkable at run time Great! I want to do it! later... > F.4: If a function may have to be evaluate…

I agree, e.g. they recommend not using `#pragma once` because: > It injects the hosting machine's filesystem semantics into your program, in addition to locking you down to a vendor. Our recommendation is to write in ISO C++ Erm. What. Compiling anything other than a one-file program "injects the filesystem semantics into your program". I mean... your program is stored in a filesystem. #include uses a filesystem. Wha…

Hrmf, what I think they tried to say is that #pragma once causes your code to compile differently depending on which file it's stored inside. This can cause problem with some tooling (e.g. precompiled header generators, some distributed compiler tools, etc.) which concatenate header and source files to generate an amalgam.

So it's not "tosh", it probably just doesn't correspond to your way of writing C++ code.

Re: C++ Core Guidelines

#82

Post by pknopf »

_xzxj wrote: 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…

People gripe at Go's error checking, claiming it's verbose, etc.

But, I like it. Fully and clearly expressed intent for the handling of errors.

Re: C++ Core Guidelines

#83

Post by to3m »

quotemstr wrote: post #68
mehrdadn wrote: post #54

Earlier quoted context omitted.

> It's only through exceptions that you can have meaningful copy-constructable resource-holding value types. Could you give an example of this specifically? Are you thinking of e.g. a File class whose constructor opens the file? Because every such example I can think of is one where it ultimately seems inappropriate to me to use exceptions to signal the error. Both from a conceptual standpoint (it might be something…

That file class might hold a file descriptor and dup the file descriptor in the copy constructor. If that dup operation fails because you've hit the FD descriptor limit and that copy constructor has no way of indicating that it failed to do its job, you're screwed. Sure, you can give up on copy constructors altogether and manually manage resource copies, but doing so impoverishes the language, wrecks one of its best…

Sure, you can do this, but don't. Approximately the last thing you want is a copy constructor that can fail.

If you have to do an OS call to duplicate the underlying resource, assume the class isn't copyable in this way. It's almost certainly possible to make it moveable, and this will get you the bulk of the benefit: you can return it from functions, and you have a std::vector of it.

(Also worth noting that close (2), which presumably you'd call from the destructor, can fail with EIO or EINTR. I don't consider looping on EINTR ever safe, but that's up to you. EIO, on the other hand - what are you going to do about that? And if you don't call close from the destructor, what the hell use is this class anyway?? Overall, I don't think value objects make very good wrappers for a POSIX-style file descriptor.)

Re: C++ Core Guidelines

#84

Post by smitherfield »

112233 wrote: post #25

Ugh, so much wrong with this. There is C++, as implemented by every compiler, and then there is fantasy C++, as seen by the committee... See, e.g. this trainwreck: https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/rt2ivJnc4hg%5B1-25%5D Also, e.g. > P.6: What cannot be checked at compile time should be checkable at run time Great! I want to do it! later... > F.4: If a function may have to be evaluate…

>You can't put runtime assert in constexpr function.

As of C++17 you can: http://en.cppreference.com/w/cpp/error/assert

You can also throw exceptions in constexpr functions since C++14.

Re: C++ Core Guidelines

#85

Post by smitherfield »

AstralStorm wrote: post #69
Leszek wrote: post #23

Earlier quoted context omitted.

I think you're missing the point that gsl::index, unlike size_t, is signed.

Ssize_t then. Or ptrdiff_t.

`ssize_t` isn't standard C++ (it is required by POSIX); `ptrdiff_t` is only one character fewer than `gsl::index`.

Re: C++ Core Guidelines

#86

Post by RustGirl »

quotemstr wrote: post #66
steveklabnik wrote: post #57

Earlier quoted context omitted.

> Even languages that start out vehemently anti-exception, like Go and Rust, end up with the full try-and-catch exception toolkit. Rust (and as far as I know, Go) have pretty much remained the exact same with regards to their implementations here. Go uses panic/recover a bit more liberally than Rust uses panic/catch_panic; using panic for control flow is not idiomatic, and so is not done. Since you can turn them into…

I find it amusing and sad that the Rust ecosystem, via this "panics as abort" feature, replicated one of the worst parts of the C++ ecosystem: -fno-exceptions, which, in C++, turns throws into aborts. In both language environments, the availability of a compiler option that breaks a language feature doesn't erase the existence of that language feature.

I started out as a rust True Believer and still am active in the Rust community. But I don't use it anymore for new projects because it really doesn't bring anything new to the table. At my current job, I'm knee-deep in C++.

Re: C++ Core Guidelines

#87

Post by otabdeveloper2 »

DrBazza wrote: post #62

This quote from Kernighan should be at the top of any C++ guideline: "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" Writing supposedly smart code seems to be a weird culture thing in C++. I've lost count of the number of C++ devs I've worked with that get the "Mmmm, donuts!" reaction to templ…

You've obviously never written any C++. The point of templates is precisely the fact that they make debugging easier, by replacing runtime assertions and bugs with cryptic compile-time error messages.

Figuring out a compiler error is significantly easier than having to debug a malfunctioning test.

Re: C++ Core Guidelines

#88

Post by syrrim »

otabdeveloper2 wrote: post #87
DrBazza wrote: post #62

This quote from Kernighan should be at the top of any C++ guideline: "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" Writing supposedly smart code seems to be a weird culture thing in C++. I've lost count of the number of C++ devs I've worked with that get the "Mmmm, donuts!" reaction to templ…

You've obviously never written any C++. The point of templates is precisely the fact that they make debugging easier, by replacing runtime assertions and bugs with cryptic compile-time error messages. Figuring out a compiler error is significantly easier than having to debug a malfunctioning test.

Is it? At runtime, I can cover my code with couts, and run a debugger. At compile time this is much harder.

Re: C++ Core Guidelines

#89

Post by blub »

AstralStorm wrote: post #73
jgh wrote: post #15

Earlier quoted context omitted.

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

Like std::future right? You can use that one today.

Nope, a result like expected-lite on github.

Re: C++ Core Guidelines

#90

Post by jandrewrogers »

quotemstr wrote: post #68
mehrdadn wrote: post #54

Earlier quoted context omitted.

> It's only through exceptions that you can have meaningful copy-constructable resource-holding value types. Could you give an example of this specifically? Are you thinking of e.g. a File class whose constructor opens the file? Because every such example I can think of is one where it ultimately seems inappropriate to me to use exceptions to signal the error. Both from a conceptual standpoint (it might be something…

That file class might hold a file descriptor and dup the file descriptor in the copy constructor. If that dup operation fails because you've hit the FD descriptor limit and that copy constructor has no way of indicating that it failed to do its job, you're screwed. Sure, you can give up on copy constructors altogether and manually manage resource copies, but doing so impoverishes the language, wrecks one of its best…

A common pattern for dealing with failures on construction, such as the example above, without using exceptions is for the object to be constructed in a null state (often useful in any case) and implementing a 'explicit operator bool()' overload that evaluates to false if construction failed or is intentionally null. Of course, that means you have to actually check that construction was successful, similar to returning an error code. It doesn't require you to give up copy constructors etc if they are sensible (and these are usually, but not always, best served by move constructors).
Post reply on HN