Boost logo

Boost :

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2003-03-12 13:14:39

The multiply indexed set seems a most interesting container, and
as a matter of fact I'm working on something like that, but progress
is slow.

There's an issue I guess I should comment here before advancing
with this. The code is non-conformant in (at least) two points, neither
of which I've found a conformant replacement for:

* It is assumed that for these two classes (in simplified form here):

template<typename A,typename B>
struct direct_pair
  A first;
  B second;

template<typename C,typename D>
struct inv_pair
  D second;
  C first;

it is asummed, I was saying, than a direct_pair<A,B> can be reinterpret_cast'ed
to a inv_pair<C,D> (and vice versa) whenever A=D and B=C. I cannot imagine
how on earth this couldn't be so for any conceivable compiler, but I'm afraid a
strict interpretation of the standard does not guarantee this.

* offsetof() is used for non-POD types. The types on which it is used are
arguably simple enough to be treated as POD (no virtual methods or anything), but
then again the standard bans it. G++ complains at this, an ugly workaround has
been applied for this case.

I'd like to know whether these two points could prevent bimap from entering
Boost, or, in the contrary, they can be tolerated. Standard workarounds are most
welcome, of course.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

Daniel Frey ha escrito:

> David Abrahams wrote:
> >
> > It's similar for me. It's one of those things that you don't need
> > every day, but when you need it, you really need it. That may be why
> > there's not more vociferous interest. Anyhow, while bidirectional
> > maps are the most common case, they're not the most general:
> > N-directional maps, which I've sometimes needed.
> I'd also be interested in a 'set' of 'tuples' with a user-defined set of
> 'views', where a view has its own sort-criterion and its own iterators,
> find-functions, etc. At least this is what I imagine but I haven't
> worked on it, so I don't know whether it's a realistic approach.
> Regards, Daniel
> PS: And yes, *if* you need them, you really *need* them.
> --
> Daniel Frey
> aixigo AG - financial training, research and technology
> Schloß-Rahe-Straße 15, 52072 Aachen, Germany
> fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
> eMail: daniel.frey_at_[hidden], web:
> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at