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

21–30 of 115 posts

Re: C++ Core Guidelines

#21

Post by ilammy »

_sdegutis wrote: post #8
_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…

The 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.

To 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).

Re: C++ Core Guidelines

#22

Post by jcelerier »

112233 wrote: post #19
_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…

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…

most containers have a "reserve" method which does this. for maps you can use boost's flat_map (ordered) or ska::flat_hash_map (hashed) which both use linear storage that you can reserve. and if for some reason you can't you can still pass your own allocator with preallocated memory, or use boost::pool_allocator

Re: C++ Core Guidelines

#23

Post by Leszek »

Matheus28 wrote: post #6

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

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

Re: C++ Core Guidelines

#24

Post by 112233 »

jcelerier wrote: post #22
112233 wrote: post #19

Earlier quoted context omitted.

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…

most containers have a "reserve" method which does this. for maps you can use boost's flat_map (ordered) or ska::flat_hash_map (hashed) which both use linear storage that you can reserve. and if for some reason you can't you can still pass your own allocator with preallocated memory, or use boost::pool_allocator

Right. My point was that there is no mechanism to do top level resource allocation, like exceptions do for top level error catching. Allocators are fine, but they are not enough for this, really:

    // big task will create map with 1000 elements
    MyAllocator a;
    a.reserveMemory(????); //

Re: C++ Core Guidelines

#25

Post by 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?

Re: C++ Core Guidelines

#26

Post by pjmlp »

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 debug print in constexpr function. How do you even debug that?

Use an IDE.

Re: C++ Core Guidelines

#27

Post by humanrebar »

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…

> How do you even debug that?

You provide a set of static assertions for the use cases you aren't sure of. constexpr functions should be thoroughly unit testable at compile time.

If you're worried about production compile times, put the static assertions in your test code.

Re: C++ Core Guidelines

#28

Post by 112233 »

pjmlp wrote: post #26
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 debug print in constexpr function. How do you even debug that? Use an IDE.

> Use an IDE.

Explain.

Re: C++ Core Guidelines

#29

Post by jcelerier »

112233 wrote: post #24
jcelerier wrote: post #22

Earlier quoted context omitted.

most containers have a "reserve" method which does this. for maps you can use boost's flat_map (ordered) or ska::flat_hash_map (hashed) which both use linear storage that you can reserve. and if for some reason you can't you can still pass your own allocator with preallocated memory, or use boost::pool_allocator

Right. My point was that there is no mechanism to do top level resource allocation, like exceptions do for top level error catching. Allocators are fine, but they are not enough for this, really: // big task will create map with 1000 elements MyAllocator a; a.reserveMemory(????); //

> My point was that there is no mechanism to do top level resource allocation

How could it make sense if bigtask(a) is a separate function, maybe in another DLL / shared object ? Maybe bigtask is not even written in C++ but in C, Rust, D, whatever. Maybe it's not even using malloc but directly OS primitives.

Re: C++ Core Guidelines

#30

Post by pjmlp »

112233 wrote: post #28
pjmlp wrote: post #26

Earlier quoted context omitted.

> You can't put debug print in constexpr function. How do you even debug that? Use an IDE.

> Use an IDE. Explain.

IDEs 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.

Post reply on HN