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

Why should I have written ZeroMQ in C, not C++ (2012)

250bpm.com

Post reply on HN
Print view View original

31–40 of 170 posts

Re: Why should I have written ZeroMQ in C, not C++ (2012)

#31

Post by rumanator »

sxyuan wrote: post #6

It seems like the author's main complaints are avoided if one follows the Google C++ style guide, which says: - Don't use C++ exceptions - Don't do work in constructors (prefer "Init" or factory functions instead) https://google.github.io/styleguide/cppguide.html There may be other reasons to prefer C over C++, but if you don't like exceptions, you don't have to use them.

> Don't use C++ exceptions

That's not what Google's C++ style guide says at all. They only argue that Google's old C++ code base is not exception-tolerant, thus as they don't want to waste time and they don't want risk adding bugs by refactoring their legacy code then they just decided to not use exceptions.

That's it.

Re: Why should I have written ZeroMQ in C, not C++ (2012)

#32

Post by Koshkin »

commandlinefan wrote: post #3

I've always felt that object-oriented programming as a concept (that is, define structures and then define functions to operate on them together) is useful: object-oriented programming as a language design is not. Once you understand what encapsulation, inheritance and polymorphism are , you're much better off using them as guidance to structure your program in an otherwise procedural language like C than wrestling w…

C++ is a multi-paradigm language, and programming in it does not force you into the object orientation. Sure, there is a lot of encapsulation going on in the standard library, but it does not mean that you have to follow the same approach in code you write (although I find that it is the ability to specify destructors that separates C++ from the plain old C, and you cannot do that if you do not write classes).

Re: Why should I have written ZeroMQ in C, not C++ (2012)

#33

Post by dxhdr »

gumby wrote: post #12

This article is simultaneously both obsolete and completely current. Obsolete in that the C++ committee has addressed almost all of the issues raised (e.g. constructor semantics, xception semantics et al) though the discussion of site-of-error/handling-of-error continues unabated. Later versions of C++ (17and 20) are powerful and expressive systems programming languages that aren’t like the object-oriented messes of…

I'm not very familiar with the C++17 and 20 changes, how do they address the errors-during-constructor/destructor issues that the article mentions?

Re: Why should I have written ZeroMQ in C, not C++ (2012)

#34

Post by Koshkin »

stickfigure wrote: post #27
fluffything wrote: post #26

Earlier quoted context omitted.

Not sure what a "factory method" is, but struct Foo { private: int a = 0, b = 0; Foo() = default; Foo(int a, int b): a(a), b(b) {} public: static Foo init_zeroed() { return Foo{}; } static Foo init_ones() { return Foo{1, 1}; } }; will do. You can add as many static methods acting as "named constructors" as you want.

...and now you know what a "factory method" is.

Almost. One of the biggest advantages of a class factory is that it can return a pointer to an interface rather than a concrete class.

Re: Why should I have written ZeroMQ in C, not C++ (2012)

#35

Post by jcelerier »

rectang wrote: post #30
jcelerier wrote: post #18

Author asserts that "The decoupling between raising of the exception and handling it, that makes avoiding failures so easy in C++, makes it virtually impossible to guarantee that the program never runs info undefined behaviour." (and all the woes he encounters afterwards stems from trying to avoid exceptions due to that assertion). But that is not my experience at all. Exceptions are much more reliable than error cod…

> there will always be a case where you forget to propagate an error you got Not if the ecosystem supports Result types a la Rust (and others). You don't get to access the return value unless you deal with handling the error first.

> You don't get to access the return value unless you deal with handling the error first.

Well, that's exactly what I was referring to. 80% of the time you don't / can't know what to do with the error at a given call site, so from what I could see, either people end up doing nothing and "abandoning" the error (bad) or panicking (worse). It's better to just let the error go transparently so that if someone actually can do something meaningful upper in the call stack, it's possible.

source : https://github.com/search?l=Rust&q=panic&type=Code

Re: Why should I have written ZeroMQ in C, not C++ (2012)

#36

Post by htfy96 »

gumby wrote: post #12

This article is simultaneously both obsolete and completely current. Obsolete in that the C++ committee has addressed almost all of the issues raised (e.g. constructor semantics, xception semantics et al) though the discussion of site-of-error/handling-of-error continues unabated. Later versions of C++ (17and 20) are powerful and expressive systems programming languages that aren’t like the object-oriented messes of…

Feel like the adoption of new versions of C++ is largely determined by sectors and behaves like a bimodal distribution. Most BigTech / Internet companies I stayed already transited to at least C++11 (and a significant amount has transited to C++17), but for others it's really dreadful because they are stuck in random binary blobs / legacy compiler toolchain / relying on UB or hacks, and if no unicorn appears the case just continues.

Re: Why should I have written ZeroMQ in C, not C++ (2012)

#37

Post by usefulcat »

jcelerier wrote: post #18

Author asserts that "The decoupling between raising of the exception and handling it, that makes avoiding failures so easy in C++, makes it virtually impossible to guarantee that the program never runs info undefined behaviour." (and all the woes he encounters afterwards stems from trying to avoid exceptions due to that assertion). But that is not my experience at all. Exceptions are much more reliable than error cod…

> you cannot "forget" to propagate an exception

Not only that, but you don't have to write a ton of boilerplate to manually propagate errors back up the stack since the compiler will do that for you. And it will do it in a consistent, well-defined manner.

Re: Why should I have written ZeroMQ in C, not C++ (2012)

#38

Post by irishjohnnie »

jcelerier wrote: post #18

Author asserts that "The decoupling between raising of the exception and handling it, that makes avoiding failures so easy in C++, makes it virtually impossible to guarantee that the program never runs info undefined behaviour." (and all the woes he encounters afterwards stems from trying to avoid exceptions due to that assertion). But that is not my experience at all. Exceptions are much more reliable than error cod…

> benchmarks have shown that exceptions are generally faster

The blog post you linked to says "Immediately we see that once the stack depth grows above a certain size (here 200/3 = 66), exceptions are always faster. This is not very interesting, because call stacks are usually not this deep (enterprise Java notwithstanding). For lower depths there is a lot of noise, especially for GCC ..." So ... not exactly "generally faster".

Also, the test is only for Linux. The same test on Windows/VC++ will probably run a lot slower ... again not "generally faster"

Re: Why should I have written ZeroMQ in C, not C++ (2012)

#39

Post by cmckn »

leni536 wrote: post #22

1. That "C equivalent" for error handling is not an equivalent at all. If one could handle the error in the same function then there is no reason to throw. The "C equivalent" is returning an error code, which has other problems. 2. One can handle errors in initialization without exceptions and half-initialized objects: Make your constructor private and expose a static member function that returns an optional (where T…

> If one could handle the error in the same function then there is no reason to throw.

Thank you, this made absolutely no sense to me. I use exceptions for "panic" situations -- when you can't recover from an error. If you can recover...why throw an exception?

Re: Why should I have written ZeroMQ in C, not C++ (2012)

#40

Post by steveklabnik »

fluffything wrote: post #28
leni536 wrote: post #22

1. That "C equivalent" for error handling is not an equivalent at all. If one could handle the error in the same function then there is no reason to throw. The "C equivalent" is returning an error code, which has other problems. 2. One can handle errors in initialization without exceptions and half-initialized objects: Make your constructor private and expose a static member function that returns an optional (where T…

> 3. Throwing in destructors is not a C++ problem, it's a general semantic problem around resources that aren't guaranteed to be freed up successfully. They are a pain in any language and you can only do best-effort approaches for not leaking them. C++ is quite good here, arguably quite better than Rust, since in C++ you can add a `noexcept(true)` clause to your destructor, and if it throws, your program terminates.…

I am not sure what you mean here. "throwing in a destructor", aka "panic during Drop" in Rust terms, runs the risk of seeing "thread panicked while panicking. aborting." In general, Rust treats panics as being something that terminates execution, not something for error handling. Where are you seeing these memory leaks in Rust code?
Post reply on HN