Re: [boost] Interest in a "Heterogenous Container" system?

Subject: Re: [boost] Interest in a "Heterogenous Container" system?
From: Christian Schladetsch (christian.schladetsch_at_[hidden])
Date: 2009-06-29 20:32:49

On Tue, Jun 30, 2009 at 10:40 AM, Ross Levine <ross.levine_at_[hidden]> wrote:

> On Mon, Jun 29, 2009 at 6:12 PM, Christian Schladetsch <
> christian.schladetsch_at_[hidden]> wrote:
>
> > The issue of which allocator to use is quite important to some people,
> > especially in embedded and/or high-performance situations. Sliding in a
> > heap
> > allocation somewhere in a container which has an allocator is a big
> no-no.
> > ptr_container does it as well when making temporary arrays and for
> clones.
> >
>
> High-performance/embedded situations are probably not going to need
> heterogeneous storage. Moreover, not only does deriving from common_base
> suddenly make a class polymorphic, which adds a vptr, and thus extra size,
> to every class instance, but your code uses dynamic_cast which requires
> RTTI, which is typically disabled in these environments to reduce overhead.

I agree, although it is more common these days for folks to be using RTTI
than it once was; just as it is more common now for them to be using virtual
methods at all, over a few years ago. A similar argument was made against
moving to C from ASM, and then against C++ over C, then against using STL at
all in C++, and now against using boost with C++.

But eventually, the benefits outweigh the costs. This usually happens when
for example people find that they are making their own implemenation of RTTI
just to avoid using the compiler-generated RTTI. People once eschewed C++
vtbls at all, but then over time found that their C-code closely resembled
"manual C++", by making structures of function pointers, populating them on
construction, and passing them around as the first arguments to their C
functions.

That said, I agree with you entirely. There are still many cases where RTTI
is not welcome. But in these cases, you usually also disable exceptions,
which IIUC means you can't use much of boost anyway.

An alternative that I considered was to introduce a traits-based type
system. I have one of these hanging around. It maps a C++ type to a static
type-number and could be used instead of RTTI, when used with a common_base
that stores that type-number. This seemed to me to be too much to swallow,
so I stuck with RTTI.

This may all render the entire idea useless, and that would be fine as well.
I am not emotionally attached to it; I just saw a way to make it work and
wanted to see what people thought.

Even so, I am sure the high-performance guys would like to have heterogenous
containers that clone correctly using a common allocator. That concept is
generally needed, and either people will roll their own type-systems or hack
around it.

Regards,
Christian.