Re: Formal Review: any

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-11-07 16:10:22

--- In boost_at_[hidden], Gary Powell <Gary.Powell_at_s...> wrote:
> > >The issue with memory management is that in games we often have 
a fixed
> > >limited pool from which to allocate memory. 
> > [...]
> > 
> > I'm familiar with these issues, but my real question is to what 
degree
> > do we want to parameterise every class we ever write and to what 
degree
> > do we want to consider some of these as more specialised cases?
> Smoke, memory is a big issue for those for who it is an issue at 
all.
> 
> > That is not the issue, the issue is that writing T<> has no 
precedent
> > (IIRC) in the standard library. 
> Before the STL, who wrote std::vector<TYPE> v; ? Almost
> no one.
> 
> > Every class template in the library must
> > be provided with at least one parameter. The zero parameter case 
just
> > makes any look odd, drawing unnecessary attention to a rarely used
> > syntax feature and what would be a rarely used parameterisation.
> > 
> IMO the usage of any looks odd.
> 
>   boost::any a;
> 
>   a = 1.0f;
>   a = string("foo");
>   a = true;
> 
>   boost::any b(goo() );
> 
>   a = b;
> 
>   What other C++ type does this? None! Which is why we need any! 
That said,
> the change is in the definition of any, which is the least 
written/read/used
> place of the type.
> 
>   boost::any<> a;
>   ...
>   ..
> The question should be, can users figure it out? IMO Easily with 
the typedef
> solution. Will incorrect usage compile, no. With the drop of void *
> conversion. Does it read well, can a person not familiar with the 
type
> figure out the semantics based on reading the code. Yes.
> 
> The major counter argument that holds sway for me is whether 
certain nearly
> C++ compilers can handle the syntax, any<>. If they can't then its 
usage
> would drop and I'd hate to see that for what otherwise would be 
very useful
> code.
> 
>   Yours,
>  -gary-
> 
> gary.powell_at_s...

Pardon me for jumping in where I shouldn't...

In general I don't like the idea of adding an allocator to types just 
because for some it's a big issue.  However, in the case of any I can 
see why it might be more compelling than normal.

I also agree that the std::allocator interface is poor (broken) and 
not really appropriate in this particular case.  So, you'd be looking 
at creating your own "allocator" interface.  Since it's non-standard 
any way, why should the template define a default for it?

template <typename Allocator>
class basic_any
{
...
};

...

typedef basic_any<standard_any_allocator> any;

The any<> syntax no longer exists.  You don't even have basic_any<>.  
The typedef also leaves usage identical to the current implementation.

The fun part will be in defining a useful allocator.  I don't envy 
anyone attempting to do this.  If I were in charge of any I'd leave 
it out for now, with the knowledge that you can seamlessly introduce 
it later when a good allocator interface has been designed.  It's not 
a crucial part of the interface, nor a part that will break code if 
added in a later revision (or rather, it's unlikely to break code).

Bill Kempf