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

Subject: Re: [boost] Review of a safer memory management approach for
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2010-06-04 14:13:19

Bartlett, Roscoe A wrote:
>> For instance, it's been so long since I last wrote a virtual
>> function that recently, I made the silly mistake of forgetting that,
>> in a derived class, an overrided function doesn't have to specify
>> the virtual keyword ;) 
> 
> [Bartlett, Roscoe A]
> 
> High warning levels (i.e. with GCC) catch most such mistakes that the
> language proper allows to go through. 
> 
> BTW, are you gravitating to stack-based programming because of the
> memory management problems or because of problems of change
> propagation of shared mutable objects?  These are almost 100%
> unrelated issues in my opinion.   
> 
> Is the C++ boost community really ready to throw away OO programming?
> That just seems crazy to me. 

Since virtual functions and templates are oil and water it shouldn't be surprising that the boost community doesn't use many virtual functions.  Even so there are so many bad things about virtual functions and inheritance (let alone multiple inheritance) and so little benefit in most cases that it is a bizarre accident of academic language development and instruction that OO is such a dominant design style.  From what I can tell most people come up with an OO design by default without making a design decision or thinking about their design options.  Usually an OO design is not the best way to go, inheritance and especially dynamic polymorphism are not needed or helpful and the resulting implementation is overcomplicated code bloat layerd on top of some absurdly simple C style programming and some use of the stl.  There are so many classes written that should be POD structs and so many classes written that should be just a function that people have some how come to a conclusion that this is normal and all to the good.  People are writing classes and virtual functions without knowing why.

If you write an application or library that you want to compile once and release as a binary with header files but no source files and then let people change the behavior of *your* code at link type (especially dynamic linkage) then virtual functions are a way to do that and people use them for that.  That's not the kind of thing most boost libraries need or want, it is something for collaboration of closed source software shops who don't trust each other and large unwieldy applications that have a build system more complicated than the space shuttle.  Boost doesn't resemble either case.

Regards,
Luke