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

Subject: [boost] FW: Boost Digest, Vol 2933, Issue 1
From: Bartlett, Roscoe A (rabartl_at_[hidden])
Date: 2010-06-05 13:01:22

Joel,

>   13. Re: Review of a safer memory management approach for C++?
>       (joel falcou)

 
> ------------------------------
> 
> Message: 13
> Date: Sat, 05 Jun 2010 16:40:01 +0200
> From: joel falcou <joel.falcou_at_[hidden]>
> To: boost_at_[hidden]
> Subject: Re: [boost] Review of a safer memory management approach for
> 	C++?
> Message-ID: <4C0A61C1.3020804_at_[hidden]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Bartlett, Roscoe A wrote:
> > 1) Well written OO C++ software builds and (more importantly)
> rebuilds *much* faster than heavily templated code.  This massively
> speeds up the development cycle.  The difference can be orders of
> magnitude of time savings in recompile/relink times.  I have seen cases
> where carefully using runtime OO can result in recompile/relink cycles
> take less than 20 seconds where using all template code would take 20
> minutes.  I am *not* exaggerating here at all.
> >
> You have the right to write proper, fast to compile template code.
> Technics and tools exists for this. And if your tempalte takes 20mn to
> compile, your template design is wrong ...

[Bartlett, Roscoe A] 

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?  

> In our own HPC template base
> code, everything compiles under 20s and only some exhaustive unti test
> that instanciate all and every type/functiosn took up to 5mn.
> > 2) Current compilers may not even be able to compile large amounts of
> template code at all.  There are compilers that we have to support
> (e.g. Sun and IBM) that will segfault or return "internal compiler
> error" when you give them too much template code.  These same compilers
> have no problem with virtual functions with standard OO.  This is
> reality.
> >
> Sun and IBM are all but references on the point of tempalte handling
> ...
> gcc, MSVC, ICC and even clang don't choke on most templated code ...
> What about stopping working with compilers from before the industrial
> revolution ?

[Bartlett, Roscoe A] 

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

> > 3) Templated programs can result in massive object-code bloat over
> equivalent runtime OO programs.  If you are really sloppy with
> templates and use it for everything, you can easily double, triple, or
> more (10x) the size of the object code and executables (see Item 44 in
> "Effective C++, 3ed edition").
> >
> >
> same than 1/ learn to do it right ... And well, since when gigabyte
> started to be costly ?

[Bartlett, Roscoe A] 

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.

> > 5) Well written OO C++ software allows for significant runtime
> flexibility.  If you use dynamic libraries, for instance, you can add
> new implementations of objects without even having to relink customer
> executables.  Also, you can fix many types of bugs in updated shared
> libraries without having to recompile/relink customer executables.  In
> a large-scale software setting, this can be very helpful.
> >
> That's maybe th eonyl poitn where I agree with you.
> >
> ***********************************************************************
> *********************
> > *** You can't portably compile and link large C++ programs that
> template everything!!!!! ***
> >
> ***********************************************************************
> *********************
> >
> Why ?

[Bartlett, Roscoe A] 

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!!!!!!!

> > As long as people keep suggesting that we template all of our codes
> for every little reason, I am going to keep reminding people of the
> realities of template code in C++.  If you can't respond to the above
> points (especially #1 and #2) then there is little point in continuing
> the discussion.  Thinking that we are going to drop runtime
> polymorphism and use exclusively compile-time polymorphism for
> everything is just fantasy land.
> >
> Nobody told you to put template everywhere. Same we don't want to put
> dynamic polymorphism everywhere. What about learnign to sue the proper
> tool for the proper task ?

[Bartlett, Roscoe A] 

Finally we agree.  Runtime polymorphism with OO has its place as does templated code with compile-time polymorphism.  I was never arguing that template methods should never be used (because I use them all the time, much more than most C++ programmers) but other people did seem to be arguing to never use runtime OO with virtual functions (which is just bad advice).  

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.

That is it.

- Ross