Re: [boost] Re: Formal Review: Indexed Set
----- Mensaje original ----- De: Arkadiy Vertleyb <vertleyb@hotmail.com> Fecha: Domingo, Marzo 28, 2004 3:28 pm Asunto: [boost] Re: Formal Review: Indexed Set
Hi Joaquin,
Sorry for joining this discussion so late, but here are my comments:
Hello Arkadiy, thanks for joining in. I was certainly waiting for you to show up.
- What is your evaluation of the design? - What is your evaluation of the implementation?
The code looks clean. One minor question: the index class template's equal_range method forwards to lower/upper_bound. Is it really the best you can achieve here or is it just a temporary shortcut?
Well, there's some room for improvement. Pavel touched on this issue some time ago, too. I didn't optimize the code at the time cause (1) this is how other STL implementations do it anyway and (2) the gain is not that much. But consider this QoI detail in my todo list. [...]
- Do you think the library should be accepted as a Boost library?
Yes, definitely.
Definitely thank you :) I'm glad you like the library. Maybe you have still some spare time to take a look at the review notes and state your opinions on best namings and header organization for indexed_set. Once fixed, there's no way back and we'll have to live with whatever cool/ugly names we have settled on. Two more questions: * Have you looked at mpl_index_list? This facility was designed with RTL in mind so as to ease the internal creation of indexed_set instantiations. Useful for your particular needs? * (off-topic) How's the RTL stuff going on? Planning on open some public discussion on its design aspects? I'd certainly love to contibute in that. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Hi Joaquin,
Maybe you have still some spare time to take a look at the review notes and state your opinions on best namings and header organization for indexed_set.
I like "multi_index" for the container name. As far as namespace, I like shorter names, so what about mdx -- if it's still available :)? By the way, thanks for your concern not to clash with RTL "table". We just went through the (emotionally painful) process of replacing our "tuple" with "row". Somehow it didn't occur to me before that boost::tuple::tuple is lifted into the boost namespace :(
* Have you looked at mpl_index_list? This facility was designed with RTL in mind so as to ease the internal creation of indexed_set instantiations. Useful for your particular needs?
I am printing it out and will take a look on my way to work tomorrow...
* (off-topic) How's the RTL stuff going on? Planning on open some public discussion on its design aspects? I'd certainly love to contibute in that.
We had some discussions with Pavel, and went on to implement some of his suggestions. I think we'll be able to soon come up with a new version that would include a few changes, such as fully re-implemented join, an additional (based on your yet-unnamed-container) table implementation, lambda support in selection, etc. As far as design discussions -- public or private -- they are always welcome... I am not sure how to "open" them without asking for the formal review... And we are not yet ready to it. Arkadiy
Hi Joaquin,
* Have you looked at mpl_index_list? This facility was designed with RTL in mind so as to ease the internal creation of indexed_set instantiations. Useful for your particular needs?
I am glad that you have this capability. It will definitely be very useful for RTL. However (and I know that many people on this list will disagree with me), I don't see much benefit in wrapping MPL sequence in the first place. Basically you just hide the MPL functionality, which you then restore with the mpl_index_list, at the expence of two intermediate templates (one to hide, and another to restore). And the more templates you have -- the slower compilation is, and the closer are your users (especially ones using VC6) to various compiler limitations, such as ISO, etc. If you don't want you users to see MPL, I would just derive your index_list from an MPL container, thus retaining all MPL container features, and allowing other users to use MPL sequences directly.
I'd appreciate if you take a look at the [naming scheme] proposal and either accept it or provide strong argument against it (or against parts of it)
While voting for your library with my both hands, with no regards which naming scheme would be chosen, I still think that the name "composite_container" is rather boring :(... I actually liked the IndexedSet better. But since it is probably not a very "strong argument", you can disregard it :) Arkadiy
participants (2)
-
Arkadiy Vertleyb -
JOAQUIN LOPEZ MU?Z