
C++ Core Guidelines - hamid914
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md
======
_xzxj
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 returned by the C api, or throws for any other
error.. Like guys shit happens on networks all the time, just give me an
error. Instead I have to try to track down all the damn exceptions and figure
out what throws and what doesn't..

I actually really liked the way Apple did it for Objective-C. Don't use
exceptions unless something is really going sideways, instead use NSError. I'm
not saying this is the correct pattern for C++, but I don't personally think
exceptions are the correct pattern either.

~~~
snarfy
Exceptions are a mistake, plain and simple. They should have never been added
to the language. They break the notion of programming as a sequence of events.
With exceptions, now you have two sequences, the happy path and the 'wherever
the hell the exception is caught' path. No matter how you slice it, exceptions
are still a goto under the covers. If they are truly exceptional, you might as
well call exit() too.

Go got this right. If there is an error, return it to the caller. The error
can be a function, and the caller can call it when they want. This returns
programming to a single sequence of events.

~~~
quotemstr
> They break the notion of programming as a sequence of events.

It's never been that way. What's a page fault?

> No matter how you slice it, exceptions are still a goto under the covers.

"break" is also a goto. What's your point?

> If they are truly exceptional, you might as well call exit() too.

That's completely unacceptable for robust software. Programs can recover from
almost all errors and make forward progress, usually via staging some kind of
rollback. Tearing down a whole process in response to error is a ridiculous
extreme that works only in a few narrow domains.

> Exceptions are a mistake, plain and simple.

Is that why almost every language ends up adopting them in some way? Even
languages that start out vehemently anti-exception, like Go and Rust, end up
with the full try-and-catch exception toolkit. That's because, despite
protestations, exceptions are extremely useful.

~~~
steveklabnik
> 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 an abort, it's
not something you can rely on when writing a library, and so I'm not aware of
any significant libraries that do so. You couldn't even catch panics for a
long time, and the possibility was mostly added to prevent UB with regards to
extern functions.

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

~~~
RustGirl
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++.

~~~
frankzinger
> because it really doesn't bring anything new to the table.

What about the built-in memory and concurrency safety?

------
DrBazza
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 templates, and leave a stinking pile for everyone else to
debug. I'm sure I'm included in that group of programmers, but I hope, not as
much.

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

~~~
jnordwick
You've obviously never tried to debug template heavy code. They are like ugly
black boxes - you get an answer (maybe correct maybe not) or you get pages of
incomprehensible often useless error messages.

If c++ wanted a meta language, they really should have created one long ago
instead of continuing this template madness.

------
duneroadrunner
I'm going to dissent on this. While the Core Guidelines "raise the floor" for
code safety, I think the may be lowering/hardening the ceiling[1] as well. One
problem is that, they impose an (inflexible) standard for function interfaces
that is still intrinsically unsafe. For example, they direct you to
standardize on std::shared_ptr for objects shared between threads. But this
prevents you from using (even) safer smart pointers that, for example, do
automatic mutex locking[2].

Presumably the alternatives to a standardized, intrinsically unsafe interface
are either a standardized, safe interface, which would require introducing
safe alternatives for unsafe elements like std::shared_ptr and raw pointers.
Or a more felixible interface standard. For example, making your public
functions function templates when necessary.

[1] shameless plug:
[https://github.com/duneroadrunner/SaferCPlusPlus#safercplusp...](https://github.com/duneroadrunner/SaferCPlusPlus#safercplusplus-
versus-the-core-guidelines-checkers)

[2] [https://github.com/duneroadrunner/SaferCPlusPlus#the-
problem...](https://github.com/duneroadrunner/SaferCPlusPlus#the-problem-with-
stdshared_ptr)

------
112233
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 evaluated at compile time, declare it
> constexpr

Ok. You can't put static_assert in constexpr function. You can't put runtime
assert in constexpr function. You can't put debug print in constexpr function.
How do you even debug that?

~~~
IshKebab
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. What utter tosh.

And as for locking you down to a vendor, even niche compilers that you've
probably never heard of support it.

[https://en.wikipedia.org/wiki/Pragma_once#Portability](https://en.wikipedia.org/wiki/Pragma_once#Portability)

I'd take anything from there with a boulder of salt.

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

------
dang
Discussed in 2015:
[https://news.ycombinator.com/item?id=10239962](https://news.ycombinator.com/item?id=10239962)

~~~
rootlocus
Ignored 4 months ago:
[https://news.ycombinator.com/item?id=15540452](https://news.ycombinator.com/item?id=15540452)

~~~
dang
Yup. The convention here is only to link to the posts that received
discussion, since users get ornery when they click on a link and nothing's
there.

------
Matheus28
Small annoyance (I haven't read the entire thing, but I have strong feelings
about this): gsl::index is disgustingly verbose. If you use stl, just use
size_t. If you're using something else, follow the conventions they use (be it
size_t, int, or whatever). Their examples [1] conveniently omit size_t to push
their alternative.

[1]
[https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Res-
subscripts)

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

~~~
AstralStorm
Ssize_t then. Or ptrdiff_t.

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

------
boltzmannbrain
I recommend the tl;dr version from Kate Gregory at CppCon 2017, “10 Core
Guidelines You Need to Start Using Now”:
[https://www.youtube.com/watch?v=XkDEzfpdcSg](https://www.youtube.com/watch?v=XkDEzfpdcSg)

~~~
luk32
Haha. I have it opened in my browser waiting for some prolonged work
interruption.

I guess I have to dedicate and report 1h for learning and self-improvment
during next week.

------
usefulcat
Anyone know what these guidelines are talking about when they refer to a
'final_action' object, or the function/keyword 'finally'? I'm referring to
E.19. I could not get the example below to compile even using the newest gcc
with -std=c++1y at godbolt.org. It seems potentially useful, if it actually
exists.

[https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Re-
finally)

~~~
nuxi
It's supposed to be part of "Guideline support library", see this section:
[https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#S-gsl)

The only implementation so far seems to be from Microsoft:
[https://github.com/Microsoft/GSL/blob/master/include/gsl/gsl...](https://github.com/Microsoft/GSL/blob/master/include/gsl/gsl_util)

------
1024core
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?

~~~
147
[https://news.ycombinator.com/item?id=16535886](https://news.ycombinator.com/item?id=16535886)

~~~
1024core
Oh wow! How did I miss that? Thanks!

