38 ms·
I don't buy the `it's better because it's C rather than C++`. For example, "Number of memory allocations is drastically reduced as intrusive containers are used
by alexchamberlain 13y ago
I don't buy the `it's better because it's C rather than C++`. For example, "Number of memory allocations is drastically reduced as intrusive containers are used instead of C++ STL containers." can be solved in 3 ways:
1. use an intrusive container in C++.
2. Just use a `vector`, faster in most cases, regardless of complexity.
3. Read about and use allocators properly.
- willvarfar 13y agoThe 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 agoIt 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 agoThe above is a great post BTW. I recommend reading it.
- willvarfar 13y agoAha, 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 agoEven 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 agoNo, 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 agoExtra 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 agoUnfortunately, 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 agoEver tried removing element from a middle of vector?
- alexchamberlain 13y agoYes, 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 agoThe 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 agoThe 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 agoAs mentioned multiple around on those HN discussions, it has more to do with his ability to use C++ than C++ vs C.
- beagle3 13y agoThat'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)
- shin_lao 13y agoIn C++ it's even easier than in C to safely use stack-based allocation (thanks to RAII) so this it's better because it's C rather than C++ is a huge warning sign.
- masklinn 13y agoIt's not like the author just made this assertion out of the blue, he previously made 2 posts about the issues he had having used C++ for ZMQ: http://250bpm.com/blog:4 http://250bpm.com/blog:4 http://250bpm.com/blog:8 http://250bpm.com/blog:8
- shin_lao 13y agoThe purpose of C++ is to provide experts with a toolbox to do anything without any compromise. This is why the language is hard to master and very easy to misuse. It's a two edged sword literraly. Although in C++ one could say it's more like a two-edged chainsaw. In this case, I would simply say that the author problem is more about how he relates to C++ than about C++ itself. Saying C++ is abrasive is a valid point, but saying it cannot be as fast as C or it cannot do "something" is stratospherically stupid.
- vidarh 13y agoWho is saying it cannot be as fast as C? The original post only claims that it makes his life easier, and then makes two further claims about the C implementation without stating you can't achieve the same in C++. He then links to a post where he goes into more detail, including _explicitly pointing out_ you can do the same in C++, but that he believes that the language encourages you to think in certain ways that negatively affects these factors. It seems to me that he is stating his reasons for why he believes C is the best choice, and particularly for him, without making any claim that it is objectively better. In other words, unless I've completely missed something, you are setting up strawmen.
- shin_lao 13y agoI was referring to his original rant on C++: http://250bpm.com/blog:4 http://250bpm.com/blog:4 and http://250bpm.com/blog:8 http://250bpm.com/blog:8. They are pretty misinformed. He claims in C++ the erasing solution is O(n) where it is O(1) in C. This doesn't make any sense of course. The comments you are referring to where he moderates his position are resulting from the comments he received from the C++ community regarding his incorrect statements.
- zobzu 13y agoi'm pretty sure the real reason for C is that the author is just more familiar with it (which is a fine point imo) now there's other things i'd criticize, like nanomsg is a trademark of the company.. so if you repackage it i'm suspecting you have to rename all the stuff, for example.
- rumcajz 13y agoThe trademark can be passed to a foundation so that it's not controlled by any particular company. However, even then, if you modify the code you should name it differently to prevent confusion.
- damien 13y agoWhy would you be pretty sure he is more familiar with C when most of his past projects were written in C++? Not to mention that he's written two blog posts explaining his reasoning... I'm not sure the trademark is a big deal, it's probably to prevent misuse like what happened with the Linux trademark (which took a few years to resolve). I doubt he's doing it to make it more annoying to use.
- angersock 13y agoOr, the other valid solution: 1. Write the whole thing in valid C89 2. Prevent users from having to use Boost or the rest of the C++ nonsense 3. Users can now write trivial language bindings and link at runtime easily. 4. Profit. ~ C++ is a cool bro and all, but honestly the solutions you've listed make it annoying to work with this code outside of C++ on a platform with subgood template support. Moving a simple utility library like ZMQ to C makes a great deal of sense.
- easytiger 13y agoWho said anything about boost? afair zmq compiles with no boost dependencies
- angersock 13y agoRead the thread--as per usual, the stock response to criticisms of C++ (here, the difficulty with intrusive lists) is "USE MOAR BOOST!1111one". Now, it's a very useful library, but it's also an amazingly tired refrain.
- X-Istence 13y agoEventhough the backend for ZeroMQ was written in C++, the front-end, and the main language bindings as it were, are in C. That means it was already trivial to write language bindings.
- pjscott 13y agoIt's totally plausible. Rewriting C++ code in C usually makes it better. Similarly, rewriting C code in C++ usually makes it better.