Re: [boost] Review of a safer memory management approach for C++?

Subject: Re: [boost] Review of a safer memory management approach for C++?
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2010-06-05 12:59:24

05/06/2010 15:02, 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.

One additional factor you have to take when writing template code is 
compile-time efficiency. It is true it adds an additional dimension to 
the difficulty of designing and writing software.

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

It's up to you whether you want to support those compilers or not.
I myself see little compelling reason to support the Sun compiler, 
almost likewise for IBM, at least for new C++ projects.

Balance your support for legacy compilers with your willingness to have 
nice code.

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

They can, but they don't have to.
If your template function is not a good inlining candidate, is likely to 
get instantiated with many different types and and if making it 
runtime-generic has sufficiently low costs, then you should consider 
doing it.

Note, however, that the size costs are usually grossly exaggerated. I've 
seen people use advanced template C++ code on microcontrollers (the kind 
with a few kilobytes of memory) just fine.

> 4) The error messages you get when mistakes are made when using explicit interfaces and virtual functions are far superior to the mess that most compliers put out when you make a mistake with implicit compile-time template interfaces.  This is a huge issue.  Runtime errors, as opposed to cryptic compile-time errors, can be handled by throwing exceptions with very good error messages that programmers can 100% control the quality of.  Yes, of course you prefer compile-time errors to runtime errors all things being equal, and am not arguing to prefer runtime errors over compile-time errors in general.  This is generally not true of template programming (there are some tricks you can use to improve compile-time error messages, but not perfectly).  For example, if you make a mistake with STL it
>   erators/algorithms you can get very cryptic error messages that dumfound most (non-expert and expert) C++ programmers.

Albeit they're long, they're not that cryptic.

Also, there are programming techniques to have nice error messages. I 
would say you can even reach close to the quality of OCaml (for a 
certain definition of close, I suppose).

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

You can use type erasure to achieve dynamic polymorphism while keeping a 
non-intrusive, value-based and template-based generic design.

> As long as people keep suggesting that we template all of our codes for every little reason

No one is suggesting this.
Make your code only as generic as your algorithms intrinsically are, no 
more.

Algorithms are what lay at the center of generic programming, not 
objects. This is quite a different view from OOP.

> Thinking that we are going to drop runtime polymorphism and use exclusively compile-time polymorphism for everything is just fantasy land.

Compile-time polymorphism is better, and you can build runtime 
polymorphism on top of it with type erasure.

So why avoid compile-time polymorphism when you can do it?