From: Jeff Garland (jeff_at_[hidden])
Date: 2004-03-28 14:25:20
On Sun, 28 Mar 2004 20:09:24 +0200, JOAQUIN LOPEZ MU?Z wrote
> > > > 2) bidirectional_map
> [...]
> > Agreed -- what more would you add to the example?
>
> * the original bimap had a feature we could call
> "smart interface". Suppose the from and to types
> are different, then for instance
>
> bimap.find(from_key)
> bimap.find(to_key)
>
> are different and can be called without using
> get<>() to first select the appropriate index.
> If is_same<from_type,to_type>, this facility is not
> provided (ambiguities would arise) and the good
> old get<>() is the only alternative.
Ok, sure. I guess I have mixed feelings about
whether the cleaner interface should be offered
if it can't be done in all cases. That said, the
get<from>() type interface is ugly so it would be
nice to explore options to make this easier.
> * the example is strictly 1-1. 1-N, N-1 and N-N
> can be useful too, the instantiation syntax
> should make it ease to get all the variants.
Interesting. I ran into this in the example program
that I wrote because I initially forgot that second key
was also unique. So it took me a little while to see why
my insert wasn't working -- second key wasn't unique. And
one of the advantages of the current implementation is that
by simply changing unique to non-unique I was able to change
the semantics.
> > >but we are talking probably of a separate library.
>...
> Ummm... Sort of prefab ready-to-eat instantiations of
> the main container? Well, the idea looks interesting.
> If only you have patience for the next cycle of
> development. I'd like to gain some feedback from real
> users of the library, to see what they demand. By the
> end of the cycle maybe some common uses can be
> crystallized in specific-purpose containers to be add to
> the prefab gallery. Comments?
I have no problem with waiting. There's no question that on
my current project there are 5 or 6 places I could have used
bi-map. So at the moment it is the one I'd like to see.
> > > > 5) Naming
> > > >
> [...]
> > boost::container::multi_index works for the namespace. But to be
> > clear, I'm
> > expecting you are going to rename the entire library to Multi-Indexed
> > Containers, right?
>
> I didn't think of a general alternative name for the library.
> Boost.MultiIndex?
Can't tell that it relates to containers...
> Boost.Multicontainer?
Yeah, but why doesn't it include multi_array? I don't think this one can
work.
> Boost.Container.MultiIndex (in sync with the namespace)?
Would be my choice except I think Boost Multi-Index Containers reads better
and would be fine even if the namespace boost::container::multi_index.
> > Also, are you suggesting that I'm going to see
> > BOOST_ROOT/libs/container/multi_index and
> > BOOST_ROOT/boost/container/multi_index?
>...
> Yep, that's the idea.
>...
> Seems to me the general perception is that sooner or
> later libs will be have to be migrate to the appropriate
> umbrella namespace; newcomers should do it right away.
Well, I'm actually not very concerned about the namespace -- it's the
directory structure that is a major hassle to fix: CVS, doc pointers, etc.
Its possible the other authors of containers won't want to refactor the
directory structure. So I think we want to make sure they are willing to do
this at some point before we send you down this path.
Jeff