mihai_ionic

Mantle information starts at 02:26:40.

Edit: It's over now. The VOD is available here: http://www.livestream.com/amdlivestream/video?clipId=pla_334.... Mantle information starts at 02:26:40.

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

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.

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.

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.

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

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

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.

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.

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

This should not be an issue with modern C++ compilers. If two template instantiations generate the same or similar code, they will be merged and useless code is removed by dead code elimination.

> The downside I care about is compilation speed. Simple C projects compile/link faster than modern C++ ones, even though the code for the same functionality is far more brittle, unsafe, and opaque

At the same time, a lot of potential for optimization is lost by barricading everything between translation units and/or behind opaque pointers. While yes, LTO is supposed to help there, all those memory accesses make it infinitely harder for the compiler to prove trivial properties about the data flow. See also this recent presentation by someone who has a lot more experience than me with writing compiler backends: http://www.youtube.com/watch?v=eR34r7HOU14

As a bonus, an actual implementation of curry: https://dpaste.de/qGWcq/

You obviously can't pass this to C code, but it's a portable and extremely efficient solution if you are working purely within a C++ code-base.