Hacker News Reader

Comment by rumcajz | Hacker News Reader

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.

View on HN

If you can use C++11, this becomes a non-issue with move semantics.

Ownership of internal resources can be transferred, and emplace_back even allows constructing your object in place.

As others said, the O(n) really becomes more like pseudo-O(1) due to cache effects unless you have elements the size of your cache lines (in which case prefetching still helps) or you're only fetching one element at a time and then triggering a context switch (as in a scheduler).

I'm not bashing your library, and if you prefer to use C then that's great, but it's kind of unfair to blame it on the language in the first place.

Languages are designed for specific purposes. I am claiming that C++ is not the best language for system development. The fact that most OSes are not written in C++ is a good indication of the fact. Still, C++ is great for rapid development & corporate development.

> The fact that most OSes are not written in C++ is a good indication of the fact.

This is just inertia and only true on UNIX world due to how C is tied to UNIX.

BeOS, Symbian, Genode -> C++

Mac OS X -> drivers are done in C++ (IOKit)

Windows -> C is now official deprecated and C++ is the way to go. (http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and... && Herb's remarks at BUILD 2012)

That's all good, but to they use STL in the internals?

Maybe not, but C++ is much more than just plain STL.

That is one of the problems with C++. In "C" land you also might be put to restrictions - for example don't use malloc()/realloc()/free() but some other functions, or don't use the provided assert() but something else, or no Xxxprintf() functions, etc - e.g. most of them are around function calls, that could be caught at preprocessor, compiling, or even runtime level.

Now C++ comes with new/delete, dynamic_cast<>, throw/catch/etc, RAII, always export "C" interface (to avoid mangling) - While all of these are useful, due to the constraint where the language has to be used they can be forbidden. It's no longer functions that you are restricting from being called (as in "C"), you are forbidding to use parts of the language that are considered by many as vital, and it's basically a different language at this point.

I'd like to know what restrictions cause you not to be able to use RAII.

Even if that's the only C++ feature that a project were to use, I'd still consider it a net gain. Anything that makes your program less susceptible to manual resource management bugs in "goto cleanup"-style C is worth using. This doesn't just include memory leaks, but more insidious problems like unclear ownership of various system resources (sockets, file handles...). Things not even a GC would help you with in a long-running server process.

You can't use longjmp/setjmp - http://en.cppreference.com/w/cpp/utility/program/longjmp

There are several popular "C" libraries that use them - jpeglib comes to mind, but there are others. Also certain language's runtime environment uses it. There is a way to handle it, but you need to take care.

Even in C, setjmp/longjmp leave all non-volatile automatic storage duration variables on the current stack frame in an indeterminate state if they are modified between the two calls.

To get defined behaviour with regards to destructors, you simply have to make sure that the function calling setjmp doesn't internally use RAII. Call a wrapper function to do the setjmp and you're safe.

Of course it's a whole other question whether using setjmp/longjmp to implement "exception handling in C" is a good idea in the first place.

OS X drivers are "a restricted subset of C++"[1] that restricts you from using Exceptions, Multiple inheritance, Templates, and Runtime type information (RTTI). Also, not all drivers use IOKit.

1) https://developer.apple.com/library/mac/documentation/Device...

I am fully aware of it, besides "a restricted subset of C++" is still C++.

Well, not exactly. I/O Kit uses a specification called Embedded C++. It has been heavily criticized by C++ folks and is basically dead at this point.

I know Embedded C++.

Yes, it is true it wasn't well accepted in the community and never really took off.

Still it is a C++ subset, not C, which is what this discussion is all about, regarding the use of C++ in kernel space.

Add the modern L4 microkernels to that list, e.g.: https://github.com/l4ka/pistachio

Well, this is just precious. When the first C++ recommendation turned out to be not applicable, the answer is:

1) He can solve the issue by requiring C++11 (!!)

2) Just rely on cache-effects making it pseudo-O(1), unless (insert various cases where it might blow).

Sure, he can jump through 200 hoops to use C++, special features, rely on CPU cache behavior, finetune to death, etc -- or, you know, he can use C and be done with it...

1) It's 2013, all major compilers (GCC, Clang, MSVC, ICC) have supported rvalue-references for multiple releases.

2) You missed the part where there's nothing preventing anyone from using intrusive lists in C++.

Removal of an element in a vector is definitely O(n), regardless of cache effects.

    template <typename T>
    void remove(std::vector<T>& v, std::size_t i)
    {
        std::swap(v[i], v.back());
        v.resize(v.size() - 1);
    }

That's just a different algorithm that produces different results than .erase() and has nothing to do with cache.

No one is saying it is not O(n), they're just saying that the cache effects can be larger than the complexity hit.

Except the parent did make that claim.

> If you can use C++11, this becomes a non-issue with move semantics.

That wasn't an option for ZeroMQ which was started in 2007.

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.

Ever tried removing element from a middle of vector?

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.

So, what you say is: I don't care to implement an efficient solution, because the CPU cache will fix it anyway. That way of thinking is well known as "The Java way of problem solving" (TM)

That's not what he said, and his solution is not "inefficient." CPUs have no emotions; if it runs faster due to cache, it's simply the better solution.

For the use case required by ZeroMQ, it's faster in all cases, because swap-with-last and shrink is O(1). Sure, if CPUs didn't have caches, a list might be faster.

Do you see where this is going? The C way of solving problems consists of adding one more level of indirection (ever heard of 3-star C programmers?), because it becomes more efficient asymptotically that way. Nevermind the hidden factor of 100-1000 due to pipeline stalls and cache misses.

Fortunately not all C programmers think that way.

My solution is more efficient in the normal case, ignoring the asymptotic case that never happens.

Never traversing the list. Removal every time a peer disconnects.

Removal with intrusive containers: flip two pointers.

Removal with std::vector<>: copy all the subsequent items in the vector one position backwards.

Since you never traverse the list, the order of elements obviously doesn't matter. In that case, you can just swap the element to remove with the last element.

A vector will still give you better cache-locality and also amortize the number of allocations.

Yes, that's exaclty what ZeroMQ is doing. Then check how the code looks like. It's a mess. Intrusive containers deliver same performance characteristics and the code actually looks clean.

And what stops you using an intrusive datastructure in C++?

Nothing. But if he is going to write C in C++, then what is the point of writing C++? Especially sticking to C gives substantially increased flexibility in terms of language bindings, embedded usage etc.

I've probably spent more years writing C++ code than C code, but I'm all with him on this - if what you need to do for whatever reason don't need/benefit all that much from C++ when accounting for all constraints, then choosing C as being the lowest common denominator between other languages is a very good choice for a library.

Reply on news.ycombinator.com