Re: [boost] FW: Boost Digest, Vol 2933, Issue 1

Subject: Re: [boost] FW: Boost Digest, Vol 2933, Issue 1
From: joel falcou (joel.falcou_at_[hidden])
Date: 2010-06-05 13:08:55

> Nonsense.  Apparently myself and no-one else in CSE or any other domain knows the right way to write templated code.  Apparently all the books I have read on C++ and template programming (see http://www.cs.sandia.gov/~rabartl/readingList.html#_B%29_C++_Books) have not taught me the *right* way to write template C++ code.  If it is that hard to write "correct" template C++ code then C++ should die a slow and painful death because no-one will be able to use it correctly.  Oh, would you please teach us?  
>
>   
Well, maybe not me, but I'm sure using tools like Steven Watanabe 
templkate profiler, knowing how a type is resolved and using 
non-template boilerplate base class helps. Our own HPC matrix library 
went from 15 to 2s compiel time using these technics.

And I can tell you that, as a consultant and now as an assistant 
professor involved in variosu HPC project, the quality of code I saw in 
laboratory is usually sub-par.

> We don't get to pick the platforms that we have to support.  If you supply code to ASC customers you will compile on their platforms, including Sun, IBM, and PGI.  In fact, this is one reason why we can't have any mandatory dependencies on boost because there have been portability problems with boost on some of these platforms.  Things have gotten a lot better with C++ compilers that we have to use in the last 9 years since I have been at Sandia but it is just not true that implicit instantiation with template code will compile just as fast as non-template code.  There are fundamental arguments to refute that.  Compilers could be much more crafty with templated code than they currently are but they are not (yet) and never will be with some compilers (i.e. Sun, IBM, PGI, etc.).
>   
Your context is different than mine so this point may not have a lot of 
interest.
> The size of object code does have some impact, especially some HPC machines.  Again, please teach us all how to do this because we apparently don't know what we are doing.
>   
You can also learn to reply without actually barking at people. It helps 
having a sane conversation.
We never exceed 500Kb binary even for large program. Again using 
compiler supprot for symbol stripping, symbol hiding and other proper 
tempalte code technics (again boilerplate, type colalpsing etc) helps a lot.
> The compilers segfault or return internal compiler errors or take hours to compile if they do finish at all in some cases.  See above.  Reality!!!!!!!
>   
Reality of sucky compilers from 2 century ago. It's lkike blaming people 
using new cars with biofuel whiel comapring them to Ford T.
> My argument is that current accepted ways of writing OO code in C++ make it too hard to write correct well designed programs and an affordable cost.  My argument is that the Teuchos MM approach described in:
>
>     http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf
>
> together with static analysis tools to help enforce the idioms (and keep raw pointers encapsulated) can largely eliminate undefined behavior in C++ programs due to the usage of memory and also yield programs that are more self-documenting at the same time.
>
>   
Well, you better be writing JAVA or OCaml ...