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