Re: [boost] Formal Review: Indexed Set

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