Re: [boost] Formal Review: Indexed Set

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2004-03-28 13:09:24

----- Mensaje original -----
De: Jeff Garland <jeff_at_[hidden]>
Fecha: Domingo, Marzo 28, 2004 6:05 pm
Asunto: Re: [boost] Formal Review: Indexed Set

> On Sun, 28 Mar 2004 13:56:02 +0200, JOAQUIN LOPEZ MU?Z wrote
> 
[...] 
> > > 2) bidirectional_map
[...] 
> > an example of use which I think will be common enough.
> > IMHO a much more user-friendly bidirectional map could be
> > developed based on indexed_set, 
> 
> 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.
* 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.

> 
> >but we are talking probably of a separate library. 
> 
> I don't see why.  It would be a specifically targeted 
> multi-index container built on the flexible core.  To me,
> your library is now a family of collection types.  Adding 
> targeted easy to use collections in the library makes perfect 
> sense.
> 

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?

[...] 
> > > 4) Should the SGI/HP copyrights be included in the source 
> files 
> > > which are
> > > based off the stl_tree.h implementation?  
[...] 
> In reading the license in the docs, I don't think there is a 
> problem with
> compatibility, but I believe it would be safer to also include 
> this notation
> in the affected source -- even though the licenses sort of implies 
> it isn't
> necessary.  
> <usual disclaimer>
> I am not a lawyer.  The above is not legal advice.
> </usual disclaimer>

Maybe someone else reads this and can shed some more light.

> > > 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? Boost.Multicontainer?
Boost.Container.MultiIndex (in sync with the namespace)?
Suggestions here most welcome.

>  Also, are you suggesting that I'm going to see
> BOOST_ROOT/libs/container/multi_index and
> BOOST_ROOT/boost/container/multi_index?  This is what was just 
> done with the
> string algorithms library (BOOST_ROOT/libs/algorithm/string/).
> 

Yep, that's the idea.

> While this structure makes perfect sense to me, it creates an 
> inconsistencywith existing container libraries like array and 
> multi_array which are not
> under the .../container subtree.  Personally, I'd like to see array,
> multi-array, and dynamic_bitset get moved under a .../container 
> tree -- but it
> is alot of work. 
> 

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.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo