Re: [boost] Formal Review: Indexed Set
----- Mensaje original ----- De: Jeff Garland <jeff@crystalclearsoftware.com> 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
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
Jeff Garland <jeff <at> crystalclearsoftware.com> writes:
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.
I vote for the fully-spelled out 'Multi-Indexed Containers'. Multi-Index doesn't have much meaning when separated from the 'container' part of the name, and Multi-Container is misleading. 'namespace boost::container::multi_index' seems fine in code, though.
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.
Somewhat off-topic - has sourceforge made any pronouncements regarding a possible migration to SVN? Aside from easing problems with directories and moving, I would have thought they'd have a lot to gain from it's implementation details.
participants (3)
-
Jeff Garland -
JOAQUIN LOPEZ MU?Z -
Matthew Vogt