Somehow it reads like a love letter to Go, but I bet he wouldn't like the Garbage Collector ;-)
Why should I have written ZeroMQ in C, not C++ (2012)
71–80 of 170 posts
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#72By now he probably realizes that the Java version is what he was looking for all along: https://github.com/zeromq/jeromq Why C/C++ coders don't even write "Hello World" in Java SE before drifting away into rewriting the ball bearing (1907) part of the wheel is beyond me. The Throwable class is exceptional in every way, it wastes almost nothing and gives the programmer the ability to catch all problems that occur in t…
> Why C/C++ coders don't even write "Hello World" in Java SE before drifting away into rewriting the ball bearing (1907) part of the wheel is beyond me.
I write C++ & Java on a daily basis.
I don't know why I would ever willingly choose Java for a personal project. It's not fun & it's inflexible. And the C++ side of me cringes with how inefficient & slow "simple" things are. Especially for anything that doesn't last long enough for the JIT to come along and make it not horrendous.
If I want to pay for a JVM I'd at least go with Kotlin. But I'd take C# over Java if I had a choice.
And I don't know why you think C++ means "rewriting the ball bearing"? There's a pretty decent standard library these days, and no shortage of libraries to add anything else. Depending on what you're doing there's a richer set of available libraries for C/C++ than there are for Java even (such as anything to do with graphics).
> Java [..] has the same performance as machine code
It so incredibly doesn't. Maybe when value types are added then Java can regain some ground on the performance front, but right now you're absolutely paying a price for Java. Often a price well worth paying, but still a price.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#73I think there's a lot of merit to this post, but it really shows its age. Modern C++ typically suffers from only the last point raised - exceptions during destruction, but that goes against the all good C++ practices. Overall, the author's approach to exception use is flawed. It's bad form to use exceptions for code flow purposes, as per their example. If you throw an exception in the same block that catches the exce…
>2-step initialisation is the only way around errors during construction whilst forbidding exceptions.
Static methods returing optional or some more refined either type work fine and don't suffer the from the dreaded zombie state issue.
Having spent the last week fixing bugs after a refactoring of a class hierarchy that would somtimes leave base classes half initialized, I say please, for the sake of maintainability, dont use init methods!
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#74By now he probably realizes that the Java version is what he was looking for all along: https://github.com/zeromq/jeromq Why C/C++ coders don't even write "Hello World" in Java SE before drifting away into rewriting the ball bearing (1907) part of the wheel is beyond me. The Throwable class is exceptional in every way, it wastes almost nothing and gives the programmer the ability to catch all problems that occur in t…
As a Python developer, I would only use a Java library as an absolute last resort, possibly even below implementing it myself or abandoning the softtware.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#75I think there's a lot of merit to this post, but it really shows its age. Modern C++ typically suffers from only the last point raised - exceptions during destruction, but that goes against the all good C++ practices. Overall, the author's approach to exception use is flawed. It's bad form to use exceptions for code flow purposes, as per their example. If you throw an exception in the same block that catches the exce…
A problem is if you use RAII for other resources than memory, for example files. You want to put the close function in the destructor then, but close can throw an exception. http://www.cplusplus.com/reference/fstream/ofstream/close/ (Of course the solution is easy, you wrap close in a try catch block, but as alwaya all the solutions are easy in c++ but this is one of the surprising corners, which might be done more o…
Fstream is hardly a paragon of good design. Then again there is no reason to call close in the destructor as fstream destructor itself will call close.
If you care about reliability and want to make sure your stream is flushed, you probably want an explicit commit interface and reserve the destructor for rollback (which necessarily shouldn't possibly fail).
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#76Author 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.
Furthermore, properly structured C++ applications with RAII use the same path for normal cleanup for exceptional cleanup meaning that you're always covering that code. You don't have an entirely separate error handling path that only gets executed for errors.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#77The only thing I dislike about C++ is that I can't declare private fields privately, I can use private: but it is there in header... in C I can just declare struct Foo; in header then implement it without expose its gusts.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#78Author 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 "general…
Look at all the results. Even before that exceptions are more often a win than a loss.
> The same test on Windows/VC++ will probably run a lot slower ...
By default on 32-bit, with SJLJ exceptions, that's likely. But on 64-bit windows the default exception handling (SEH) uses a similar mechanism than Linux and should have comparable performance.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#79The only thing I dislike about C++ is that I can't declare private fields privately, I can use private: but it is there in header... in C I can just declare struct Foo; in header then implement it without expose its gusts.
What do you mean? You can do exactly the same thing in C++.
You can't instantiate a value of that type [1] as it requires knowing the size, but, via base classes and pointers you can still call functions on it.
[1] but see the letter/envelope idiom.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#80The only thing I dislike about C++ is that I can't declare private fields privately, I can use private: but it is there in header... in C I can just declare struct Foo; in header then implement it without expose its gusts.
Is that a security concern, an obscurity concern, or a readability concern?