Re: [boost] Formal Review: any

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-11-07 16:48:26

In message <D3E6C22AF7F13B4FB2490F89879B408F0660A0_at_SEA-DOG>, Gary Powell
<Gary.Powell_at_[hidden]> writes
>> >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.

This is definitely true. However, it still doesn't mean that we should
parameterise everything in sight with a broken interface that won't
really do the job :->

I suspect that in sneaking an extra parameter into this simple class we
are in danger of creating another basic_string, or another valarray wrt
a particular community of users. Minimalism tends to be a more robust
strategy.

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

Err, anyone that used or was taught any kind of template would have seen
something like this within the first few pages. Which roughly equates to
not "almost no one". I do not believe that the humble any is the place
to start educating a whole generation on a new point of syntax just to
cater for a very rarely used generalisation.

>IMO the usage of any looks odd.
>
>  boost::any a;
>
>  a = 1.0f;
>  a = string("foo");
>  a = true;
>
>  boost::any b(goo() );
>
>  a = b;

Why does this look odd? I'm not sure, given that we are of course
talking about C++:

        const void * p;
        p = 0;
        p = "foo";
        p = p;
        p = &p;
        p = cout;

>That said,
>the change is in the definition of any, which is the least written/read/used
>place of the type.

I doubt this very much: argument lists, function return types, local
variables, data members, containees, etc. And std::vector<boost::any>
becomes std::vector<boost::any<> >, etc.

>  boost::any<> a;
>  ...
>  ..
>The question should be, can users figure it out? IMO Easily with the typedef
>solution.

Which is why I think that this may be a way of accommodating the future
without messing up the present. Start with something we know works and
is called boost::any. In future if we find a reasonable
parameterisation, we do it through another type name and typedef
boost::any in terms of it. However, I don't think that any is the place
to start that mission.

Briefly stated, if there is a need for customising any wrt allocation,
its requirements are based on single object allocation and single object
deallocation of variable sized objects. The current allocator is neither
simple nor cohesive wrt these allocation/deallocation requirements, nor
is it well suited for variable allocation sizes... unless we always
rebind to an allocator of char and allocate arrays, by which point I
suspect we may have lost many of the hoped-for benefits :-}

Kevlin
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  Curbralan Limited               mobile: [phone]
  mailto:kevlin_at_[hidden]     fax:    [phone]
  http://www.curbralan.com
____________________________________________________________