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

91–100 of 170 posts

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

#91

Post by augustk »

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…

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

What you describe here are abstract data types. Unless it involves inheritance and/or dynamic binding I wouldn't call it object-oriented programming.

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

#92

Post by Zitrax »

blt wrote: post #47
billfruit wrote: post #45

Earlier quoted context omitted.

Bjarne Strsoustroup's short book "A Tour of Modern c++" fits the bill, and was written for the same purpose.

Has it been updated for C++20?

"It covers C++17 plus a few likely features of C++20.", from http://www.stroustrup.com/tour2.html

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

#93

Post by andrewflnr »

jstrong wrote: post #62
fluffything wrote: post #52

Earlier quoted context omitted.

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?

Only if someone specifically catches the panic, averting the crash. That's what the catch_unwind stuff was about.

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

#94

Post by jynelson »

steveklabnik wrote: post #68
fluffything wrote: post #52

Earlier quoted context omitted.

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

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.

However I'm not in favor of the proposed solution - if the docs.rs server aborted every time a thread panicked we would have a lot of outages!

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

#95

Post by Gaelan »

@mods can we change the title to "Why I should have" instead of "why should I have"?

The current title reads like a question with the question mark omitted ("Why should I have used C, not C++?") which, at least to me, implies that it's saying C++ was the right decision. The thesis of the post looks like the opposite.

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

#96

Post by Animats »

oefrha wrote: post #29
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 haven’t written anything nontrivial in C++ for many years and so far have only learned and used a couple minor features newer than C++11. Would you be kind enough to point to some resources on why C++17/20 are “powerful and expressive systems programming languages that aren’t like the object-oriented messes of old”?

Yes, please.

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

#97

Post by irishjohnnie »

jcelerier wrote: post #78
irishjohnnie wrote: post #38

Earlier quoted context omitted.

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

> But on 64-bit windows the default exception handling (SEH) uses a similar mechanism than Linux and should have comparable performance.

AFAIK SEH in Windows calls RaiseException() which in turn causes a user/kernel mode transition, probes for exception/termination handlers, and vectored exception handlers depending on the severity. It's been a while but I'm not sure the code GCC generates in Linux is quite like this.

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

#98

Post by steveklabnik »

jynelson wrote: post #94
steveklabnik wrote: post #68

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

> Well, rarely done isn't the same as never done.

Absolutely. But I do think the difference between "idiomatic" and "rarely done" is valuable, here. And as you said yourself, it's not clear that these leaks are caused by this kind of thing.

If someone saw Rust code leaking memory all the time due to catching panics, I'd want to know about it, because it's very contradictory to my own experience, and I think that's interesting.

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

#99

Post by netdur »

LeifCarrotson wrote: post #80
netdur wrote: post #77

The 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?

usability, say I use external library Bar, then I declare

private: Bar bar;

the end use will have install Bar library as well to use my library despise Bar being embedded in my static library, I dislike that.

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

#100

Post by gumby »

dxhdr wrote: post #33
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?

Note: I also wrote a parallel reply with some other commentary.

On the specific issue of constructors, a slight change to the semantics of error signalling in the constructors and the addition of the ":" syntax to constructors made a lot of difference.

Post reply on HN