7 ms·

The author - and creator of zeroMQ - has written a very good series of posts explaining problems they encountered with C++: http://250bpm.com/blog:4 http://250b

The author - and creator of zeroMQ - has written a very good series of posts explaining problems they encountered with C++: http://250bpm.com/blog:4 http://250bpm.com/blog:4 ; these have been on HN before and generated a lot of good discussion: https://news.ycombinator.com/item?id=3953434 https://news.ycombinator.com/item?id=3953434

mihai_ionic 13y ago
It has also been pointed out that these problems are not intrinsic to C++, but rather due to the way he was using it: http://www.codeofhonor.com/blog/avoiding-game-crashes-related-to-linked-lists http://www.codeofhonor.com/blog/avoiding-game-crashes-relate...
- rumcajz 13y ago
  The above is a great post BTW. I recommend reading it.
- willvarfar 13y ago
  Aha, you mean that he should have written idiomatic C code and compiled it with a C++ compiler?
  - _pmf_ 13y ago
    > Aha, you mean that he should have written idiomatic C code and compiled it with a C++ compiler? Henceforth, I'll be using this quip whenever debating C++ fan boys; thanks!
  - mhd 13y ago
    Even the code in the article makes heavy use of C++ features (templates, resource management) and that's not even talking about the Boost intrusive library that gets mentioned, which is knee-deep in template effluvial... Never mind that I've seen plenty of C code with wrapping structs for data structures, too. Intrusive vs. non-intrusive is a design choice in both languages.
  - mihai_ionic 13y ago
    No, the ZeroMQ author should be writing idiomatic code in whatever language he is using. In his blog post, he complains that std::list<widget* > causes 2 allocations per insertion. Fine, because that's not idiomatic C++. The C++ way would be to use std::list<widget>, since there's no need for the extra indirection. Note that this would only be a good choice if you for some reason really need a list, std::vector is mostly preferred due to its better cache behaviour and requires even fewer allocations. Secondly, if he needs to remove list items by their address, there's no reason he couldn't use an intrusive list in C++. The article I linked shows an implementation of one, and there's always boost::intrusive::list if you don't want to roll your own (and you shouldn't).
    - rumcajz 13y ago
      Extra indirection is needed when the objects are non-assignable, e.g. if there's a thread running inside the object, if it owns a fd or similar. std::vector has O(n) complexity for a lot of operations, so it's not an option.
      - alexchamberlain 13y ago
        Unfortunately, the complexity argument is generally bullshit and you really need to profile. It turns out multiple very respected authors have found under a typical work load, `vector` performs very well on a lot of machines.
        rumcajz 13y ago
        Ever tried removing element from a middle of vector?
        alexchamberlain 13y ago
        Yes, the world does not end. For small objects and `vector`s, it's probably quicker, because 1) you found it quicker due to cache locality and 2) there were no system calls to release memory.
- alexchamberlain 13y ago
  The post is interesting, but is there anything stopping you using the following... template<typename T> struct Link { T obj; Link *link; } That looks pretty much like the intrusive version in memory, right?
  - mihai_ionic 13y ago
    The point of intrusive lists is to allow access to the link when you provide only the contained object. The way you're thinking of would theoretically work, but you'd have to make sure the compiler isn't adding fancy padding that would break your pointer manipulation and type casting. boost::intrusive::list on the other hand, works in a type-safe manner by having your class either inherit a list hook, or provide it as member and then pass the list implementation a member pointer as template parameter so that it can be accessed.
pjmlp 13y ago
As mentioned multiple around on those HN discussions, it has more to do with his ability to use C++ than C++ vs C.
- beagle3 13y ago
  That's one way to look at it, but certainly not the only one. Back in 2007, when he started ZeroMQ, you couldn't build on C++11 features. Furthermore, if you're targeting slightly less common platforms, then C++ runtime support and recent C++ features is always a hit-or-miss issue. For a library that is at such a basic level of infrastructure (which, if it's stable enough and popular enough deserves to be kernel-level) C++ is probably more trouble than it's worth. The higher you go app the stack, the more reasonable it becomes to go farther from C (high enough, and even ruby makes sense - though it wouldn't for 0mq/nanomsg)

mihai_ionic 13y ago

It has also been pointed out that these problems are not intrinsic to C++, but rather due to the way he was using it: http://www.codeofhonor.com/blog/avoiding-game-crashes-related-to-linked-lists http://www.codeofhonor.com/blog/avoiding-game-crashes-relate...

rumcajz 13y ago
The above is a great post BTW. I recommend reading it.
willvarfar 13y ago
Aha, you mean that he should have written idiomatic C code and compiled it with a C++ compiler?
- _pmf_ 13y ago
  > Aha, you mean that he should have written idiomatic C code and compiled it with a C++ compiler? Henceforth, I'll be using this quip whenever debating C++ fan boys; thanks!
- mhd 13y ago
  Even the code in the article makes heavy use of C++ features (templates, resource management) and that's not even talking about the Boost intrusive library that gets mentioned, which is knee-deep in template effluvial... Never mind that I've seen plenty of C code with wrapping structs for data structures, too. Intrusive vs. non-intrusive is a design choice in both languages.
- mihai_ionic 13y ago
  No, the ZeroMQ author should be writing idiomatic code in whatever language he is using. In his blog post, he complains that std::list<widget* > causes 2 allocations per insertion. Fine, because that's not idiomatic C++. The C++ way would be to use std::list<widget>, since there's no need for the extra indirection. Note that this would only be a good choice if you for some reason really need a list, std::vector is mostly preferred due to its better cache behaviour and requires even fewer allocations. Secondly, if he needs to remove list items by their address, there's no reason he couldn't use an intrusive list in C++. The article I linked shows an implementation of one, and there's always boost::intrusive::list if you don't want to roll your own (and you shouldn't).
  - rumcajz 13y ago
    Extra indirection is needed when the objects are non-assignable, e.g. if there's a thread running inside the object, if it owns a fd or similar. std::vector has O(n) complexity for a lot of operations, so it's not an option.
    - alexchamberlain 13y ago
      Unfortunately, the complexity argument is generally bullshit and you really need to profile. It turns out multiple very respected authors have found under a typical work load, `vector` performs very well on a lot of machines.
      - rumcajz 13y ago
        Ever tried removing element from a middle of vector?
        alexchamberlain 13y ago
        Yes, the world does not end. For small objects and `vector`s, it's probably quicker, because 1) you found it quicker due to cache locality and 2) there were no system calls to release memory.
alexchamberlain 13y ago
The post is interesting, but is there anything stopping you using the following... template<typename T> struct Link { T obj; Link *link; } That looks pretty much like the intrusive version in memory, right?
- mihai_ionic 13y ago
  The point of intrusive lists is to allow access to the link when you provide only the contained object. The way you're thinking of would theoretically work, but you'd have to make sure the compiler isn't adding fancy padding that would break your pointer manipulation and type casting. boost::intrusive::list on the other hand, works in a type-safe manner by having your class either inherit a list hook, or provide it as member and then pass the list implementation a member pointer as template parameter so that it can be accessed.

pjmlp 13y ago

As mentioned multiple around on those HN discussions, it has more to do with his ability to use C++ than C++ vs C.

beagle3 13y ago
That's one way to look at it, but certainly not the only one. Back in 2007, when he started ZeroMQ, you couldn't build on C++11 features. Furthermore, if you're targeting slightly less common platforms, then C++ runtime support and recent C++ features is always a hit-or-miss issue. For a library that is at such a basic level of infrastructure (which, if it's stable enough and popular enough deserves to be kernel-level) C++ is probably more trouble than it's worth. The higher you go app the stack, the more reasonable it becomes to go farther from C (high enough, and even ruby makes sense - though it wouldn't for 0mq/nanomsg)