RE: [boost] Formal Review: any

From: Gary Powell (Gary.Powell_at_[hidden])
Date: 2000-11-07 14:27:30

> >As an addition I'd also prefer that "any" take a template parameter
> >allocator instead of calling the global new. (That would make any a
> >template, which would make the above swap addition illegal.) 
> 
> Or, to be accurate, it would require partial function template
> specialization... which is not legal :-(
> 
> >Reasoning, it would make it more flexible for user controlled memory.
> 
> Well, there are some problems with this, not least of which is that I
> personally dislike the standard allocator model :-> It solves a small
> class of problems in an unnecessarily complex and awkward fashion. It is
> often easier to solve such problems a different way.
> 
> Partly as a result of the previous point, custom allocators are rare.
> Very rare. As a corner case it would completely change the syntax of any
> from simple to quirky, ie instead of declaring boost::any users would
> always (that's 99.X% rounded up :->) be declaring boost::any<>. In other
> words, common usage would be compromised.
> 
> Making any templated on an allocator sounds like premature
> generalisation, esp as I am not convinced that it genuinely buys users
> much. In over four years of presenting and playing around with similar
> classes, custom allocation has never been requested until now :-}
> 
> >Alternatively would it be possible for holder to have an operator new,
> which
> >called the ValueType::operator new() ? That would allow it to call the
> user
> >type new. (Caveat I haven't tried this so I'm not even sure that its
> >possible.)
> 
> Problem with that is that ValueType::operator new may not be of much use
> as it would be in all probability be tailored to sizeof(ValueType)
> rather than sizeof(holder<ValueType>).
> 
The issue with memory management is that in games we often have a fixed
limited pool from which to allocate memory. There are times when I can't use
code that prevents the game from having total control of this. With
allocators, its not necessary that the pool is tailored by individual
allocation size, but rather, the whole container and all that data come from
one contiguous block that will be freed as one block. I've been "granted" a
block of memory, and that's it.

The std container's allocators only give me partial control of the memory,
my complaint. I control the data allocation, but not the container itself.
Drives me bonkers, and to using my own homegrown awful containers. ICK! I'm
just trying to prevent this from continuing. So I agree that their model
isn't the one to follow, and since any is relatively simple code, 

I can live with the current implementation, because if I need to change the
allocation method, I can just modify the source. I just hate to do that. And
yes, memory allocation has become less of an issue than it once was. 

As for users having to know that any is a template, So?? All of STL is
templates, the string class is templated, the i/o library is templated, you
can't get away from it.  Would perhaps an additional typedef, where the more
complex name is the template solve your common usage problem?

template < class Allocator = default_allocator>
class any_with_user_controled_memory_mangement;

typedef any_with_user_controled_memory_management<> any;

Anyway consider the above just whining of a person who needs a cup of
java.... It'll be a great addition to boost even without any of my
"improvements" (broth with "improvements" is stew, not the same thing.)

  Yours,
 -gary-

gary.powell_at_[hidden]