23 ms·
C++ Core Guidelines
- dang 9y agoDiscussed in 2015: https://news.ycombinator.com/item?id=10239962 https://news.ycombinator.com/item?id=10239962
- wskinner 9y agoIt's a permalink. The document itself seems to have been updated quite a bit since 2015.
- grzm 9y agoI think 'dang provided the link so people could read the previous discussion (which has over 100 comments), not to imply it was a dupe. If the latter, I suspect he'd've marked it as such.
- rootlocus 9y agoIgnored 4 months ago: https://news.ycombinator.com/item?id=15540452 https://news.ycombinator.com/item?id=15540452
- dang 9y agoYup. 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.
- duneroadrunner 9y agoI'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#safercplusplus-versus-the-core-guidelines-checkers https://github.com/duneroadrunner/SaferCPlusPlus#safercplusp... [2] https://github.com/duneroadrunner/SaferCPlusPlus#the-problem-with-stdshared_ptr https://github.com/duneroadrunner/SaferCPlusPlus#the-problem...
- Matheus28 9y agoSmall 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/CppCoreGuidelines.md#Res-subscripts https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...
- Leszek 9y agoI think you're missing the point that gsl::index, unlike size_t, is signed.
- AstralStorm 9y agoSsize_t then. Or ptrdiff_t.
- smitherfield 9y ago`ssize_t` isn't standard C++ (it is required by POSIX); `ptrdiff_t` is only one character fewer than `gsl::index`.
- _xzxj 9y agoI 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.
- _sdegutis 9y agoThe way ObjC did it is to use exceptions to signal programmer error, and error objects for program errors. I think it’s the best style, at least until the day programmer errors just won’t compile , but that needs something like Idris to take over.
- deleted 9y ago[deleted]
- ilammy 9y agoTo be fair, it's not always true. Many APIs actually don't have NSError argument and throw Obj-C exceptions on actionable errors. For example, reading from an NSFileHandle may throw NSFileHandleOperationException. I suppose, in most cases it has been done for brevity. Though, you can also argue that only opening a file could fail (due to invalid path or insufficient permissions).
- mehrdadn 9y ago> 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?
- 1024core 9y agoNot 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?
- boltzmannbrain 9y agoI 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 9y agoHaha. 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.
- 112233 9y agoUgh, 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?
- pjmlp 9y ago> You can't put debug print in constexpr function. How do you even debug that? Use an IDE.
- 112233 9y ago> Use an IDE. Explain.
- pjmlp 9y agoIDEs provide graphical debuggers and colorization to show which code actually gets compiled. For example on Visual Studio, paths not taken on conditional code get grayed out.
- oblio 9y agoYou disappoint me pjmlp, you're not a true graybeard unless you use Vim or Emacs :o) The slightly more serious question: is there anything like this in Vim or Emacs-land? I somehow doubt it... I, for one, have never seen something like it outside of the big IDEs (Visual Studio, IntelliJ, etc.)
- pjmlp 9y agoI am an ex-XEmacs user, and used vi on Xenix, DG/UX if that makes you happy. :) Always been an IDE fan since Turbo Pascal 6.0 with its Turbo Vision based IDE.
- deleted 9y ago[deleted]
- DrBazza 9y agoThis 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.
- lucozade 9y ago> how will you ever debug it? > leave a stinking pile for everyone else to debug I think you answered your own question. The trick is to leave the debugging to someone twice as clever as you. Job done.
- otabdeveloper2 9y agoYou'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.
- syrrim 9y agoIs it? At runtime, I can cover my code with couts, and run a debugger. At compile time this is much harder.
- jnordwick 9y agoYou'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.
- usefulcat 9y agoAnyone 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/CppCoreGuidelines.md#Re-finally https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...
- nuxi 9y agoIt's supposed to be part of "Guideline support library", see this section: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#S-gsl https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC... The only implementation so far seems to be from Microsoft: https://github.com/Microsoft/GSL/blob/master/include/gsl/gsl_util https://github.com/Microsoft/GSL/blob/master/include/gsl/gsl...
- jhasse 9y agoYou can write finally yourself like this: https://github.com/jhasse/jngl/blob/master/src/jngl/Finally.cpp https://github.com/jhasse/jngl/blob/master/src/jngl/Finally....