> Joaquín Mª López Muñoz wrote:
>
> > and seems to me a fair amount of work has to be done in order to
> > integrate the features of bimap into boost::map.
>
> Yes. Very true. But the idea is to put that hard work to good use by
> generalizing the concept of a map even further than I have, so that all
> of the maps in question (std::set, map, and bimap) become special cases.
> As an analogy, consider the progression from std::pair<> ->
> boost::tuple<>. It may involve a complete redesign of both maps, but
> then it could result in something much more useful and powerful, as well.

I'm all for it. :)

[snip]

> This can be accomodated somewhat already
> in my map design, since the node type is a policy. For a single-key
> map, you simply provide single-threaded nodes.

How exactly did multi-threading come into play? Or did you refer to some
other meaning of 'threaded'? :)

> For a multi-key map, you provide nodes that have as many tree pointers
> as necessary. I had to make the node type a policy to support
> efficient indexing (you don't pay for indexing if you don't use it).

Great.

> > * bimap uses an artifact I call memberspaces in order to allow for
> > duplicate operator[]s for the from and to part. To the best of my
> > knowledge, this trick hasn't used before, but it is not fundamentally
> > complex. With memberspaces, one can write things like:
> >
> > bimap bm;
> > bm.from[1]=2;
> > bm.to[10]=8;
> > bm[7]=6; //no memberspace specified, from assumed.
>
> Yes, I saw this discussion in your Annex. However, I obviously didn't
> study it closely enough to notice that this is how you support the
> subscripting operator over both keys. I like it. Clearly, it can be
> generalized to more than 2 keys, as well. Possibly a syntax like this
> could be possible:
>
> nmap map;
> map.key<1>["joe"] = employee_record;
> map.key<2>["123-45-6789"] = employee2;
> employee_id = map[35]; // defaults to .key<0>

Yes very nice indeed. However, is that syntax supported on all compilers
that Boost is generally compatible with? I thought MSVC6 had problems
with explicitly specifying template arguments to function templates.

In any case, the library suggestions in this thread seem promising. I
would definately welcome a general map and/or an efficient
bidirectional-map. (If the latter can be done with the former as you
suggest, all the better! :)