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

31–40 of 115 posts

Re: C++ Core Guidelines

#31

Post by snarfy »

_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…

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.

Re: C++ Core Guidelines

#32

Post by jcelerier »

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?

    constexpr int hard_stuff(int x, int y) {
        return x + y;
    }
    
    void hard_stuff_test() {
      static_assert(hard_stuff(2, 3) == 5); 
    }

?

Re: C++ Core Guidelines

#33

Post by 112233 »

humanrebar wrote: post #27
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.

Agree about unit tests. But asserts are used also to catch invalid _use_ of functions.

    void f(size_t x) {
        assert(x); // calling f with 0 is bug
    }

    constexpr f(size_t x) {
        ?????(x != 0); //

Re: C++ Core Guidelines

#34

Post by 112233 »

jcelerier wrote: post #29
112233 wrote: post #24

Earlier quoted context omitted.

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.

Of course. What I meant is that if I am writing bigtask myself, then preallocating resources for any non-table-like data structure (like map) means I cannot use STL as it is now, even with custom allocators. I have to write custom data structures, or deal with any allocation potentially erroring out.

Re: C++ Core Guidelines

#35

Post by IshKebab »

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

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

Re: C++ Core Guidelines

#36

Post by jcelerier »

112233 wrote: post #34
jcelerier wrote: post #29

Earlier quoted context omitted.

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

Of course. What I meant is that if I am writing bigtask myself, then preallocating resources for any non-table-like data structure (like map) means I cannot use STL as it is now, even with custom allocators. I have to write custom data structures, or deal with any allocation potentially erroring out.

> I cannot use STL as it is now, even with custom allocators.

if you are ready to take the runtime hit you could use the polymorphic allocator support and pass your allocator object down the chain.

See http://en.cppreference.com/w/cpp/memory/polymorphic_allocato... ; http://en.cppreference.com/w/cpp/container/vector ; http://en.cppreference.com/w/cpp/container/map .

I don't understand why you are making a distinction between table-like and non-table-like containers: both can take allocators.

But in general, I don't really understand why you would want to do this: how do you expect your code to differentiate between the containers that you want to be affected by the memory changes and the ones that you don't want to ? If you don't want to make this difference and have a blanket coverage of, say, every std::vector called by your function it means that you cannot use any external library in your function, since other libraries may have other allocation requirements that your code would break. This looks like this would completely break encapsulation.

The cleanest thing to do is to do like RapidJSON for instance and just pass allocator objects in your functions : http://rapidjson.org/md_doc_tutorial.html#MoveSemantics

Re: C++ Core Guidelines

#37

Post by 112233 »

jcelerier wrote: post #36
112233 wrote: post #34

Earlier quoted context omitted.

Of course. What I meant is that if I am writing bigtask myself, then preallocating resources for any non-table-like data structure (like map) means I cannot use STL as it is now, even with custom allocators. I have to write custom data structures, or deal with any allocation potentially erroring out.

> I cannot use STL as it is now, even with custom allocators. if you are ready to take the runtime hit you could use the polymorphic allocator support and pass your allocator object down the chain. See http://en.cppreference.com/w/cpp/memory/polymorphic_allocato... ; http://en.cppreference.com/w/cpp/container/vector ; http://en.cppreference.com/w/cpp/container/map . I don't understand why you are making a distinction…

> I don't understand why you are making a distinction between table-like and non-table-like containers: both can take allocators.

Because for map in general I cannot know how much allocations and of what size will it need to store 1000 elements. I might glean it for particular implementation of STL, but not via any api.

Doing anything bearssl-like, "No dynamic allocation whatsoever", just does not work with STL.

> you cannot use any external library in your function, since other libraries may have other allocation requirements that your code would break.

Exactly. Most C++ libraries are not made with the idea of allowing you to police resource allocation. It's malloc all the way.

Re: C++ Core Guidelines

#38

Post by krylon »

snarfy wrote: post #31
_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…

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 go…

Well, strictly speaking, Go has panic() which is very similar to exceptions. But it also has a culture that strongly discourages using it unless things go very wrong.

Re: C++ Core Guidelines

#39

Post by XorNot »

snarfy wrote: post #31
_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…

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 go…

Except Go has panics and they turn up quite a lot looking exception-like.

Go with panics moved to regular error returns doesn't seem like it would lose anything.

Re: C++ Core Guidelines

#40

Post by dullgiulio »

krylon wrote: post #38
snarfy wrote: post #31

Earlier quoted context omitted.

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 go…

Well, strictly speaking, Go has panic() which is very similar to exceptions. But it also has a culture that strongly discourages using it unless things go very wrong.

No, think of panic() as unhandled Segmentation Fault (and other Go specific unrecoverable errors).

You can handle Segmentation Fault, but you need to know what you are doing. In Go it's the same.

Post reply on HN