To view parent comment, click here.
To read all comments associated with this story, please click here.
I think it is kind of missing the point. Template meta-programming does not bring much: it gives you speed and memory savings, at the cost of totally unreadable and uncomprehensible code. The problem of meta-programming is that it is a really bad tool at what it is used for (parsing mathematical operations). I agree that dealing with complex linear algebra kind of things wo using a lot of memory is still an unsolved problem, but I think using a much higher level to parse mathematical expressions is a much better way to solve the problem (e.g. you would have pseudo-code mathematics parsed by something like lisp).
For example, fftw, the reference open source fft library, although implemented in C, is actually generated by a specialized ocaml generator (the meat of fftw is in the ocaml code). This is certainly a more elegant, more powerful approach than C++ meta programming, which is really just an hack with an awful syntax.
At most, your arguments against C++ template metaprogramming are arguments from the implementer's point of view.
From the user's point of view, I don't think there exists any significant drawback! There used to be the too long compile times but that changed a lot in recent years as C++ compilers improved.
Coming back to the implementor's point of view... If you want to see how template metaprogramming allowed 2 devs to write only 11 KLOC and surpass 500+ KLOC libraries, see my blog here, http://bjacob.livejournal.com/6723.html
At the end of the day, this "the code is too obscure" argument is old and tired. It may be relatively complicated, but since it allows unmatched results, it's just worth it.
By the way here are some of our main source files. Do you really find them _that_ obscure? And mind you, C++0x is designed exactly to allow even easier metaprogramming (among other things).
http://websvn.kde.org/trunk/kdesupport/eigen2/Eigen/src/Core/Matrix...
http://websvn.kde.org/trunk/kdesupport/eigen2/Eigen/src/Core/Assign...
Your argument, that external code generators are preferable, made a lot of sense in the times where C++ compilers were not powerful enough for metaprogramming, but nowadays this problem is pretty much solved, although it still takes some care to write meta-code that's easy on the compiler.
Edited 2008-08-21 03:12 UTC
I think you hit the nail on the head, without highly experienced (and hence expensive) developers, C++ code can be very difficult to maintain and develop, whereas C code is much easier simply because more people can cope with C syntax and semantics.
I've been wondering however how many successful open source libraries and applications are actually written in C++. I know that apps like Python, Ruby and R are written in C. GTK is written in C. I think most of the successful numerical libraries are written in C, eg GSL and the bulk of netlib (with a lot of FORTRAN). There is of course Boost, but who uses that other than hardcore developers and in any case I presume Boost can only be used with other C++ apps?
I've tended to stay away from C++ because in the open soruce community there are very few good C++ programmers, which means less usage by the community and more maintenance headaches for the author.
Finally, if you write a C++ library what can you link to, other C++ programs? At least with a C API you can link to anything.
Easy enough...limit what you do with templates and use the primarily to make more readable code.
Yes it's true for hard core mathematical stuff c++ is pretty much where it's at. It combines the ability to be expressive (which 'c' lacks) with the ability to tune memory and performance (which other OO languages lack).
There is a reason why most of the floating point component tests are still written in Fortran.
http://www.spec.org/cpu/CFP2000/
I'm not knocking C--I like C and anyone who says it's obsolete is either under 30 or just delusional.
I'm looking forward to OpenCL and using it's C implementaiton.







Member since:
2006-01-02
Precision is not a language feature, it's a library feature. Don't know if by precision you mean number of significant digits or numerical stability of algorithms, but in both cases this should go into libraries. The language itself should only provide the bare minimum i.e. the IEEE754 floating-point types supported by CPUs.
Fortran indeed used to have by far the best math libraries, but, mark my words! We're a new generation of C++ math software coming to challenge that situation, and template metaprogramming will be a huge strength here.