David B. Held wrote:

>  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! :)

Regards,
Dirk Gerrits



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost