If you've been away from C++ for a while I'd recommend revisiting it. Some C++14 features greatly improve the syntax when working with templates: auto return type deduction is a huge simplifier for example. Alias templates are very helpful too and generic lambdas come in handy.
Variadic templates add new syntax but they make some previously very tedious things relatively trivial once you understand the syntax.
C++17 will bring some further improvements when writing templates. Concepts lite will be a huge deal but there are a number of other niceties too, some already available in clang.
I see it as a language in itself. Once done with the steep learning curve you start to observe repeated patterns and get it more easily. I do agree that the syntax is a huge drawback from now.
Yup, it's definitely its own language! It made me so happy when I saw a Haskell-to-C++-template compiler [1] because of all the similarities in pure-FP style (pattern matching, iteration via recursion, etc).
Haskell and C++ look like the "elite" combo these days, especially when it comes to meta-programming and FP as you said! It's funny how these two different communities are mixing. It feels like JavaScript and Ruby having a child.
> gcc seems to use a fixed size "pool" of mutexes attributed to a shared_ptr according to a hash of its pointee address, when dealing with atomic operations. In other words, no rocket-science for atomic shared pointers until now.
A side effect of the shared pool is that you might have two totally unrelated pointers share the same mutex, leading to surprising locking behaviors. Something to keep in mind.
As I explained in a commentary:
As far as I understand gcc implementation. In a pseudo-code it would be:
Mutex mutexes[SIZE_OF_POOL];
int hash(void* p)
{
...
}
std::shared_ptr<t> atomic_load( const std::shared_ptr<t>* p )
{
int r = hash(p);
lock(mutextes[r % SIZE_OF_POOL]);
return *p; // Safe copy of p.
}
All the other atomic operations (store, etc) use the same lock pool, so it should be fine for the copy!
If you want to take a look at gcc's implementation:
Yes, that's my understanding of the implementation as well. I was commenting on the fact that you might have two totally unrelated p1 and p2, where (hash(p1) % SIZE_OF_POOL) == (hash(p2) % SIZE_OF_POOL), that will end up sharing the same mutex.
Yes definitely tricky. It might give a heart attack to some high frequency system designers! I will investigate this topic in future: maybe someone can come up with a spin-lock or lock free solution.
In a somewhat misspent youth, I was a grad student of Jaakko Järvi when he and the rest of the Indiana folk were pitching variadic templates and concepts. I was browbeat into attempting to add concept constrained variadic templates to GCC. So... it turns out, for this problem, for precise constraints, the number of constraints is strongly exponential (factorial of factorials). I think we ended up going with the intersection of all the concepts, instead; which totally sucked & made constrained variadic templates pretty useless.
I suppose it doesn't matter since the concepts proposal was torpedoed. (But that's another story.)
I yet didn't check the proposal for C++17 concepts, it seems to constantly change since C++11. Does it includes anything related to variadic templates? Anyway, you must have had a lot of fun with Jaakko Järvi as a teacher!
This is vaguely reminiscent of a SO comment I ran across recently: http://stackoverflow.com/a/27962571, which really opened my eyes to the powerful combination of variadic templates and tuples. OP's guide is very informative in breaking things down, kudos; but I also suggest checking out that SO comment as it's a more barebones exposition of variadic templates + tuples (no threading, no watching, etc).
The syntax is, well, horrible, but the things you can do really help eliminate what would otherwise be redundant code.
Just make sure you comment the hell out of things like this or the people that have to read and maintain your code later will hate you.