Why should I have written ZeroMQ in C, not C++ (2012) • Hacker News Board

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

#111

Post by vitaut » Thu, May 21, 2015, 1:38 PM UTC

nulltype wrote: post #95

vitaut wrote: post #78

Earlier quoted context omitted.

Could you give an example?

I've seen some pretty impossible to comprehend or debug uses of templates. Perhaps my favorite, which represents most of the pitfalls you can create with C++ is the Boost library. And of that, the shining star is this page: http://www.boost.org/doc/libs/1_57_0/libs/geometry/doc/html/...

I wouldn't call it a pitfall. Boost is written by C++ experts who like to push the boundaries of what can be done with the language. This doesn't mean that you have to debug their code or overuse templates yourself and there is nothing in the language that encourage this. For common cases such as in the standard library, templates are pretty easy to use and trivial to debug with modern compilers.

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

#112

Post by cesarb » Thu, May 21, 2015, 1:49 PM UTC

dschatz wrote: post #12

cesarb wrote: post #8

Earlier quoted context omitted.

If you read part II (the link to it is near the end of the post), you see that one of the things he wanted was intrusive linked lists. From what I have read so far, implementing intrusive lists is not easy in Rust. (If you know of a working intrusive doubly linked list implementation in Rust 1.0 that does not invoke undefined behavior, please tell me; I'd like to know how it should be done.)

I have one here: https://github.com/dschatzberg/intrusive It can be used in a freestanding (nostd) environment such as a kernel. It uses unsafe code but provides a safe interface. The primary technique is to embed the type that is iterated over in a larger struct which contains the links. This way I can give out references to the inner type without fear of invalidating the iterator.

> The primary technique is to embed the type that is iterated over in a larger struct which contains the links. This way I can give out references to the inner type without fear of invalidating the iterator.

I see. I was too fixated in embedding a small struct with the links within the larger struct (in the style of the Linux kernel "struct list_head"), and didn't think of doing the opposite.

It probably makes being in several intrusive structs at the same time much more complicated, but I think it's possible to do without breaking anything.

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

#113

Post by pjmlp » Thu, May 21, 2015, 1:58 PM UTC

yason wrote: post #89

The reason why the charm of C++ wore off on me early on and why C is like my wife who I love more and more each year is that there's a lot of hidden "knowledge" in C++. The language is always playing a game of its own and a lot of your level of expertise depends on how well you've bothered to learn the rules of that game. For example, exceptions, as decribed in the article. Exceptions themselves make sense in some sc…

> "what I see is what I have"

I guess you have not yet seen too much UB or compiler specific semantics then.

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

#114

Post by pjmlp » Thu, May 21, 2015, 1:59 PM UTC

kabdib wrote: post #108

helmut_hed wrote: post #81

Earlier quoted context omitted.

The Google guidelines are... somewhat out of sync... with the intended use of language features as described in the Standard and the recommendations of people associated with it. They seem to take as a starting assumption that the language is misdesigned and major parts of it should simply be avoided or used in unintended ways. If you agree, it's a perfectly fine guide. Otherwise, I'd recommend reading any of Scott M…

I've read those books. I have a lot of respect for the authors, and they have a lot of good advice. But Exceptional C++ made me not want to deal with C++ exceptions, ever. If getting C++ code correct in the face of exceptions is that bloody hard, then the language is broken. I'm convinced that cobbling up an "int" equivalent type that is exception safe is a pyrrhic endeavor that will be a continual source of fragilit…

> If getting C++ code correct in the face of exceptions is that bloody hard, then the language is broken.

Blame C, as they are that way to keep C++ exception behaviors compatible with C semantics.

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

#115

Post by pjmlp » Thu, May 21, 2015, 2:01 PM UTC

zvrba wrote: post #91

I'm a professional, C++ dev and my greatest quibble with C++ is its deranged system of numerical types, implicit conversions between them, and that signed arithmetic can produce UB just about anytime: http://www.boost.org/doc/libs/1_55_0/libs/numeric/conversion...

Mostly inherited from C, actually.

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

#116

Post by shepardrtc » Thu, May 21, 2015, 2:06 PM UTC

I used to think the same way. In fact, I would reference this article to reinforce my beliefs. But then I actually took the time to relearn C++14 the right way using Stroustrup's Programming Principles book. A project that was horrific in C became ridiculously easy in C++. And I didn't use a single malloc.

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

#117

Post by GFK_of_xmaspast » Thu, May 21, 2015, 2:26 PM UTC

nulltype wrote: post #95

vitaut wrote: post #78

Earlier quoted context omitted.

Could you give an example?

I've seen some pretty impossible to comprehend or debug uses of templates. Perhaps my favorite, which represents most of the pitfalls you can create with C++ is the Boost library. And of that, the shining star is this page: http://www.boost.org/doc/libs/1_57_0/libs/geometry/doc/html/...

Given the design constraints:

""" A generic library should be able to calculate the distance: for any point class or struct, not on just this mypoint type in more than two dimensions for other coordinate systems, e.g. over the earth or on a sphere between a point and a line or between other geometry combinations in higher precision than double avoiding the square root: often we don't want to do that because it is a relatively expensive function, and for comparing distances it is not necessary """

I suspect a little bit of complexity is necessary. (And can you even build something like this in a more fashionable language?)

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

#118

Post by voidlogic » Thu, May 21, 2015, 2:30 PM UTC

nickpsecurity wrote: post #28

voidlogic wrote: post #9

Earlier quoted context omitted.

>I actually see an opportunity for a C-compatible or C-competitive systems language here to beat C++ at its own game. Go or Rust? They might not quite match your dream outlined above, but I think in practice they are pretty much used with the purpose of achieving something similar. They both can be "unsafe" as needed and integrate well with C and ASM.

Currently, Go makes some decisions that hurt it for high performance systems, bare metal, and so on. Rust barely survived some beginner OS projects without its bloat and performance problems showing up. Once comparison I read showed Rust's compiler caught many bugs that slipped through Go's due to Rust design choices. I'm pulling for Rust in particular because its team made clever, design choices for their safety-vs-…

>Currently, Go makes some decisions that hurt it for high performance systems, bare metal, and so on.

Can you expand on this? I have had no issue getting to C levels of performance by using "unsafe" or ASM a few small critical sections as needed (tight bodies of inner loops, etc or mmap based allocation).

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

#119

Post by vitaut » Thu, May 21, 2015, 2:56 PM UTC

jlarocco wrote: post #90

vitaut wrote: post #36

Earlier quoted context omitted.

Actually avoiding C++ pitfalls is not that difficult as most of them come from C: manual memory management, macros, varargs, unsafe casts. In fact C++ provides safe alternatives to many of the unsafe C constructs, so if you stick to them you are fine.

> Actually avoiding C++ pitfalls is not that difficult as most of them come from C If you really believe that, then you're probably writing dangerous code and not even realizing it. Most C++ pitfalls come from subtle interactions between features that don't even exist in C, like exceptions, move semantics, templates, threading, constructors/destructors, references, operator overloading, etc. Those are the things peop…

I don't always write dangerous code, but when I do I fully realize it =). And it has nothing to do with any of the features that you listed.

In fact "threading" in C++ is safer because of the availability of high-quality libraries providing task-based parallelism such as TBB, move semantics is used all the time in C albeit manually with pointer manipulation. It is true that not all of the features play well together, but it's nothing compared to the C pitfalls that I mentioned.

If you want to avoid dangerous interactions, don't overengineer your code, stick to the features you understand. This is true not only for C++, but for any language.

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

#120

Post by zvrba » Thu, May 21, 2015, 3:43 PM UTC

pjmlp wrote: post #115

zvrba wrote: post #91

I'm a professional, C++ dev and my greatest quibble with C++ is its deranged system of numerical types, implicit conversions between them, and that signed arithmetic can produce UB just about anytime: http://www.boost.org/doc/libs/1_55_0/libs/numeric/conversion...

Mostly inherited from C, actually.

Well, "defect by design" is still a defect and I have to work around it on almost daily basis. Besides, being able to do (bool+int) could not come from C since C didn't have bool at the time.

EDIT: actually, there are two defects here. One are the implicit numeric conversions. The other one, which causes me most grievance in this context, is that size() on containers returns an unsigned type.