Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk