Yes, sorry, I misunderstood you. You can't use a fold expression to fold a binary function over a parameter pack as far as I know. You can fold application of a unary function using a fold over the comma operator though.
As a former C++ programmer, I appreciate everybody that tries to make programming in this language more logical.
I just think, that C++ and particularly the whole template system is just to complicated.
I have enough work to do, finding solutions for the real world problems that must be implemented -- I don't want to have more work fiddling around with language specifics and even more trickery, just to have my programs running maybe 1% faster.
C++, particularly the template system and the new standard library that is based on the STL, disappointed me long time ago, when a whole group of programmers where trying to find out what the compiler errors where about deep inside the STL. The whole error handling inside the templates where so muddled, that it was nearly impossible to find out what the trouble was, without reading big parts of the STL source.
I trust, that today's compilers generate better error messages for templates, but still I am not sure that the whole thing -- and particularly the STL -- is worthwhile for most real-life problems.
And what do you mean by "most real-life problems"?
HN is rather biased towards web development, so...
C++ is used for real life problems from web browsers, to physics engines, fluid solvers, photorealistic renderers (in fact, pretty much all software used to make most visual effects CG for movies is in C++), autopilot systems, and pretty much everything in between.
And as yet, there's nothing else that comes close to allowing both high-level abstractions/encapsulations and low-level memory alignment/allocation/control as and when needed, which is important for high performance and memory efficient (bit packing, tagged pointers, etc) code.
What I meant was: I want to spent my time with the problems that I must solve, not with by programming language induced problems!
When I really need speed, I always can implement single routines in pure C -- I don't need an STL abstraction for that, that feigns speed to the programmer, but in the end it does not give it to him, because he chose the wrong abstraction. It seems so easy: Just use the STL/std-c++ library and all your speed problems are solved -- but std-libraries do not make a bad programmer a good one -- instead, it creates programmers that invest their time in language specifics instead in data structures and algorithms. So bad programmers will be even worse in the end.
Also note that in systems such as those, that lean heavily on numeric computation, you'll see only a little bit of templated code, used sparingly, to make writing the rest of it easier. In fact you won't even see any deep nested class hierarchies.
I appreciate the work here, and I'll remember this when I need it, but C++ is long past gross.
Enough already, the committee needs to be less prideful and just add complete macros/metaprogramming to the language already in C++14 and let apparently smart programmers who can disentangle variadic type templates to stop wasting brainpower and valuable time doing that and just write the compile-time transformations they want to have happen.
There are not so many language who can directly compile and optimize to machine code though.
I'm not sure if java or C# can easily jit to have something that is close to machine code. Anyway having machine code directly (and no need for VM) is useful if you want to reduce the overhead and fully exploit your hardware.
Surely it's not for students or for casual programmers, but it has a use.
Yeah, not all features of C++ are for students. But writing highly efficient code if one's aware of the copy-move semantics is almost straightforward.
I can't remember when some larger projects rewritten in C++ turned out to be slower. Build tools, developing tools are superior to those 10 years ago, and the compiler(s) is still the best optimizer there is for production code.
Working in C++ today is easy. I sometimes feel a bit strange when I find that I'm oblivious about some hardships C++ developers had in the past, and today I didn't even know you can do it the hard way.
Incidentally, this is exactly what I am working on, grammar and parser are mostly done (the grammar is _regular_ and programs can rewrite themselves starting from their AST, because I really want something like `go fmt` one day), doing the transpiler at the moment, it's... interesting to say the least.
(it will be foss of course but nothing is published yet)
You can actually easily (compared to some time ago) write your own language to do that via the power of LLVM. You'll also be able to produce object files that can be linked in C/C++ programs, if you wish.
Edit: Or, you know, write a different macro preprocessor for C++. There's nothing special about the standard CPP other than coming bundled with the compiler.
http://en.cppreference.com/w/cpp/language/fold