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

61–70 of 170 posts

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

#61

Post by fulafel »

kova12 wrote: post #57
beeforpork wrote: post #49

Earlier quoted context omitted.

> C++ gives you strictly more tools, particularly for guaranteeing reliability, and they're all optional. You are right. But it doesn't help. When I used C++, I constantly shot myself in the foot by using its features. It did not feel like overusing, but I just wanted type-safety and to replace macros. It was impossible to restrict to useful features, because they are all useful in their way, only they come at the pr…

this is ridiculous. Every remotely powerful programming language gives you an opportunity to shoot yourself in the foot. c++ is so simple, and with every new standard it becomes even better and easier to use. How can anybody possibly complain is beyond me.

Its simplicity and ease of yse pales only in comparison with its safety and beauty.

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

#62

Post by jstrong »

fluffything wrote: post #52
steveklabnik wrote: post #40

Earlier quoted context omitted.

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?

In Rust, this destructor is perfectly fine: impl Drop for Foo { fn drop(..) { self.cleanup(); self.free_memory(); } } even if `self.cleanup()` panics. When that happens, `self.free_memory` will never be called, and memory will be leaked if `panic=unwind`, which is the default behavior. If there is a `catch_unwind` somewhere, these leaks will grow over time. The same code in C++: ~foo() { this->cleanup(); this->free_m…

if `self.cleanup()` panics, the program crashes, though? How is a memory leak even a relevant concept in that case?

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

#63

Post by laurowyn »

andi999 wrote: post #51
laurowyn wrote: post #21

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

Interesting corner case that I can't say I've ever seen before.

fstream is a bit of a mess. Even the documentation for close is a bit contradictory. Its exception safety states that an exception is caught and rethrown after closing the file if one is thrown by an internal operation. That to me sounds like the actual resource being managed will be closed (assuming the fd is valid), but any data may not be flushed out of the write buffer.

sounds to me like iostream needs some serious attention in future specs, but that's unlikely to happen unfortunately. Creating new toys > fixing old ones.

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

#66

Post by TheOtherHobbes »

kova12 wrote: post #57
beeforpork wrote: post #49

Earlier quoted context omitted.

> C++ gives you strictly more tools, particularly for guaranteeing reliability, and they're all optional. You are right. But it doesn't help. When I used C++, I constantly shot myself in the foot by using its features. It did not feel like overusing, but I just wanted type-safety and to replace macros. It was impossible to restrict to useful features, because they are all useful in their way, only they come at the pr…

this is ridiculous. Every remotely powerful programming language gives you an opportunity to shoot yourself in the foot. c++ is so simple, and with every new standard it becomes even better and easier to use. How can anybody possibly complain is beyond me.

A language with four different pointer metatypes for memory management and (unrelatedly) four different pointer type meta-casts is not "simple".

The subdialect of features that you have settled on may be simple, but the language itself is a nightmare of random feature archaeology and creeping throw-it-against-the-wall-and-see-if-sticks extensions, which somehow still fails to provide clean simple tools for polymorphism.

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

#67

Post by laurowyn »

jschwartzi wrote: post #58
laurowyn wrote: post #21

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

Another way to support RAII without throwing exceptions is to somehow make the error case an explicit configuration of the class with well-defined behavior. For example, in a "File" class with no filedescriptor you could return a defined "error" from any function calls which would require a filedescriptor. Receiving such a return value or return structure would then signal that the File class is not in a working stat…

yes.

> when you cannot handle the error in the current code block and the function interface does not support returning enough information to the caller to detail what went wrong

Exceptions are, fundamentally, an alternate way to return from a function. That's why the general practice is to avoid using them for control flow - there's enough in the language already to support what you want to do, we don't need to instrument the entire stack when I could return a negative value to indicate the error.

The engineering problem to solve is deciding when to turn a void return into a boolean or enum. Just because there is space in the interface for an error code, doesn't mean it's the right choice. But likewise, just because exceptions are available, doesn't mean every error should be thrown.

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

#68

Post by steveklabnik »

fluffything wrote: post #52
steveklabnik wrote: post #40

Earlier quoted context omitted.

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?

In Rust, this destructor is perfectly fine: impl Drop for Foo { fn drop(..) { self.cleanup(); self.free_memory(); } } even if `self.cleanup()` panics. When that happens, `self.free_memory` will never be called, and memory will be leaked if `panic=unwind`, which is the default behavior. If there is a `catch_unwind` somewhere, these leaks will grow over time. The same code in C++: ~foo() { this->cleanup(); this->free_m…

> 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=abort is also a valid semantic, and partially because if this Drop impl is called when panic happens, regardless of panic settings, you'll get an abort if self.cleanup() panics.

> Rust supports fallible destructors,

This isn't really true. Fallability in Rust is spelled "Result", and drop does not return one. You're talking about a non-recoverable error, which, it is true, Rust does not give you tools to prevent, really. That's because it's very, very rarely used, because the whole intention is to end the current thread of execution.

> At least, I couldn't find any examples in the Rust book / reference / rust-by-example that show in which situations unwinding from a destructor is a good thing to do.

There isn't, which is why it isn't done, which is why your point confused me :)

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

#69

Post by gjulianm »

bullen wrote: post #44

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

Main reason: C/C++ is compiled and can be faster than Java, basically because you control the memory, object lifetimes and there's no garbage collection.

If C/C++ speed/low-level management is not required, I'd rather go to Python or, if want static typing, C#, than Java. Python gives easy development and broad library support, and C# has more features than Java (one being way better metaprogramming support).

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

#70

Post by StavrosK »

kova12 wrote: post #57
beeforpork wrote: post #49

Earlier quoted context omitted.

> C++ gives you strictly more tools, particularly for guaranteeing reliability, and they're all optional. You are right. But it doesn't help. When I used C++, I constantly shot myself in the foot by using its features. It did not feel like overusing, but I just wanted type-safety and to replace macros. It was impossible to restrict to useful features, because they are all useful in their way, only they come at the pr…

this is ridiculous. Every remotely powerful programming language gives you an opportunity to shoot yourself in the foot. c++ is so simple, and with every new standard it becomes even better and easier to use. How can anybody possibly complain is beyond me.

There's a difference between "an opportunity" and "every opportunity". Not all languages have the same amount of footguns.
Post reply on HN