Boost logo

Boost :

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

> 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.


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