ZeroMQ is a behemoth; for something that just handles communication, it compiles to like 660KB of i386 machine code. Is there an OS kernel with networking, virtual memory, USB and a file system hiding in there?
Why should I have written ZeroMQ in C, not C++ (2012)
121–130 of 170 posts
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#122Earlier quoted context omitted.
> 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 is the given class). This comment criticizes an article written in 2012 about a project developed starting in 2007 for not using a technique that debuted in the 2017 edition of ISO C++. For projects that could force all consum…
It's not hard to write an optional in C++ 2003, and likely can be done in C++ 98. If you don't like that, return a T*, null if not created correctly.
I didn't mean to suggest the language spec would have made it hard so much as that I'd have really not wanted to approach it in a way that was going to work with VC6/2002/2005/gcc 2.95/sunpro/ibm/hp compilers of the era. (I think it was 2009 before I got to push VC6 off the raft.) ISO support in C++ compilers was really bad for a long time.
Our typical pattern was to return T*. But that fits well with the "I should have just written it in C" argument IMO.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#123Earlier quoted context omitted.
> In Rust, this destructor is perfectly fine: Sort of; it's very rare. You don't really write free_memory, unless you're doing some very specific unsafe things. > When that happens, `self.free_memory` will never be called, and memory will be leaked if `panic=unwind`, which is the default behavior. It will be leaked if panic=unwind and if you use catch_panic. catch_panic is not used very much. Partially because panic=…
Well, rarely done isn't the same as never done. docs.rs has exactly the tradeoffs the parent comment is talking about: we have a long-running daemon thread that uses `catch_unwind` and builder threads that occasionally panic. We've had [issues with memory leaks]( https://github.com/rust-lang/docs.rs/issues/656 ) in the past - they weren't related to unwinding that I know of, but it's still possible that they were. Ho…
The solution for docs.rs is handling errors correctly and not panicing.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#124Earlier quoted context omitted.
Are you familiar with the PIMPL idiom?
very nice, I do that but never header of PIMPL
I wouldn’t use PIMPL unless you get something out of it (and “not letting anybody see the private stuff” counts as getting something). It’s a hassle, but it’s also the standard answer to the problem.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#125This has become one of those “classic” articles. Worth a read if you haven’t. The bits about exceptions reminded me of an article on Nim‘s “goto” exceptions implementation [1]. The implementation appears to be a combo of error codes and goto’s to automatically propagate the exception. It performs well and works on embedded devices, although I’ve only done a smaller project in Nim on an Arduino based board. It’s odd having a serial port print stack traces. Careful a slow serial line can lead to a slow printout though!
Nim with the new ARC GC and move semantics seems to make a nice language for embedded development or for creating re-useable libraries. Rust seems promising but so much embedded work is still C/C++ only at some level, while Nim compiles to C/C++ nicely.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#126Author 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…
ZeroMQ is a library to be called from other languages. You do not want to ever accidentally throw an exception from C++ to a function that is called from outside C++.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#127Writing in C++ means that the C++ library you are using becomes a dependency. Probably not an issue, if you have the source code to all libraries that you use, but maybe an issue if you are vendor and try to support not only all possible modern compilers, but what they target to (platforms, runtimes, models, etc.) With just "C", not "C" only at the interface part, you can avoid that. Even to the point that your binar…
Not sure why this got downvoted? Anyone to comment? I use C++ daily on my job, and I'm very happy with its developments - especially C++11, C++14, C++17 and what's coming in C++20 - but statically linking problems are real, and pain to solve (long term). We do mostly MSVC, where some teams are still in VS2017, others VS2019 - and while they are compatible - the compatibility works only if your final app is compiled w…
That exact same problem exists in C in the exact same way. It's somewhat less of an issue just because C is essentially frozen in time, but it has the same inherent problems & design issues.
But if you statically link your C++ runtime & only expose C interfaces then you're fine. You can be "just like C" only at the ABI boundary, that's well supported and works great. It's a quite common setup even.
Like for your particular example I don't think the solution to "in some situations I can't throw exceptions across an ABI boundary" is "switch to a language where exceptions don't exist at all and error handling is 'good luck'". It'd be nice if there was a way to flag an exported symbol as being ABI sensitive & letting the compiler patch up differences, that'd be a nice feature. Nuking it entirely seems like the opposite of a solution though? But you're still free to do that in C++ if you want. noexcept all your exported symbols & use error returns, just like C. Or even just compile with exceptions disabled entirely.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#128Earlier quoted context omitted.
My understanding: Pick zmq if you want something safe and battle-tested with good client library support. Pick nng if you want to be at the forefront of new tech or need some of its unique features over zmq ( https://nanomsg.org/documentation-zeromq.html ). Performance-wise nng still seems like it's inferior to zmq because it's not as heavily optimized. There are lots of performance-related unresolved Github issues.…
Would you say either is something you would put in a decently scaled production system?
Using ZMQ (from C) at high volume, we found it dropped data, so we abandoned it.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#129It 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.
The google style guide says “ On their face, the benefits of using exceptions outweigh the costs, especially in new projects. However, for existing code...” and they use a lot of existing code.
> they use a lot of existing code.
Doesn’t everyone? Lots of C++ code is not exception safe, including large libraries such as Qt.
If I’m writing code that uses such a library, would it be better to take Google’s approach and avoid using exceptions myself, or try to “wrap” the non-exception-safe library somehow?
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#130Earlier quoted context omitted.
Not sure why this got downvoted? Anyone to comment? I use C++ daily on my job, and I'm very happy with its developments - especially C++11, C++14, C++17 and what's coming in C++20 - but statically linking problems are real, and pain to solve (long term). We do mostly MSVC, where some teams are still in VS2017, others VS2019 - and while they are compatible - the compatibility works only if your final app is compiled w…
That exact same problem exists in C in the exact same way. It's somewhat less of an issue just because C is essentially frozen in time, but it has the same inherent problems & design issues. But if you statically link your C++ runtime & only expose C interfaces then you're fine. You can be "just like C" only at the ABI boundary, that's well supported and works great. It's a quite common setup even. Like for your part…
"But if you statically link your C++ runtime" - you need to take careful measures your symbols not to leak as visible. Doable, but takes some time. Also might be easier with gcc/clang - e.g. -fvisibility=hidden, but nothing like this in msvc AFAIK.