- Boost - lists.boost.org

Re: [boost] Formal Review: Indexed Set
by JOAQUIN LOPEZ MU?Z 28 Mar '04

28 Mar '04

Hi Jeff ----- Mensaje original ----- De: Jeff Garland <jeff(a)crystalclearsoftware.com> Fecha: Domingo, Marzo 28, 2004 9:25 pm Asunto: Re: [boost] Formal Review: Indexed Set > On Sun, 28 Mar 2004 20:09:24 +0200, JOAQUIN LOPEZ MU?Z wrote > > > > > 2) bidirectional_map > > 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. Thanx for your patience. I hope in the meantime (some months) you can get by with the bimap from the example. > > > > > > 5) Naming [about boost::container::multi_index namespace] > > 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. > At this point, whatever decision involves a manageable amount of work. So I'll stick with what people like most. Further changes would be much more painful. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [boost] Formal Review: Indexed Set
by JOAQUIN LOPEZ MU?Z 28 Mar '04

28 Mar '04

Hi Jeff ----- Mensaje original ----- De: Jeff Garland <jeff(a)crystalclearsoftware.com> Fecha: Domingo, Marzo 28, 2004 9:25 pm Asunto: Re: [boost] Formal Review: Indexed Set > On Sun, 28 Mar 2004 20:09:24 +0200, JOAQUIN LOPEZ MU?Z wrote > > > > > 2) bidirectional_map > > 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. Thanx for your patience. I guess in the meantime (some months) you can get by with the bimap from examples. > > > > > > 5) Naming [about boost::container::multi_index namespace] > > 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. > At this point, whatever decision involves a manageable amount of work. So I'll stick with what people like most. Further changes would be much more painful. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Indexed Set needs a name?
by Tom Brinkman 28 Mar '04

28 Mar '04

I think that you should call the library "Nautilus". This name is arbitrary and sufficiently different than any other library name on boost or stl. You are expecting too much if you want the name of the library to represent the complete functionality of the library. If you named the library Nautilus, you could then name the indexed set, just a set. Everyone nows what a "set" is. Adding "indexed" to everthing does not help me understand what the library does. boost::nautilus::set boost::nautilus::list boost::nautilus::index boost::nautilus::identity Filenames boost/nautilus/set.hpp boost/nautilus/list.hpp boost/nautilus/tag.hpp boost/nautilus/index.hpp boost/nautilus/identity.hpp boost/nautilus/member.hpp boost/nautilus/mem_fun.hpp Tom Brinkman __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html

1 0

RE: [boost] Re: Standard C Library and C++ / BOOST
by Reece Dunn 28 Mar '04

28 Mar '04

Gennaro Prota wrote: >On Sun, 28 Mar 2004 12:55:10 +0200, "Pavel Vozenilek" ><pavel_vozenilek(a)hotmail.com> wrote: > >"Reece Dunn" <msclrhd(a)hotmail.com> wrote > >> So is it possible to prevent derivation? If not, then at least make it > >> harder to do so (and put a warning in the docs)? > >Yes. > >Legal way: > >http://www.research.att.com/~bs/bs_faq2.html#no-derivation >And where is derivation prevented? ;) That only gives an error when >you try instantiating the derived class. (Not only you may still >derive, but of course you can access and use any static members). There aren't any static members to errorcheck, so this is fine. If you try to do something like: class foobar: public boost::errorcheck<> { // ... }; you will not get any errors until you do something like: foobar foo; which generates an error message like: VC7.1 -- test.cpp(11) : error C2248: 'boost::detail::cannot_derive_errorcheck<Storage,MsgStorage>::__ctor' : cannot access private member declared in class 'boost::detail::cannot_derive_errorcheck<Storage,MsgStorage>' with [ Storage=boost::policy::error_storage<>, MsgStorage=boost::policy::no_errormsg_storage ] and [ Storage=boost::policy::error_storage<>, MsgStorage=boost::policy::no_errormsg_storage ] and [ Storage=boost::policy::error_storage<>, MsgStorage=boost::policy::no_errormsg_storage ] d:\devel\ADL++\include\boost\errorcheck.hpp(102) : see declaration of 'boost::detail::cannot_derive_errorcheck<Storage,MsgStorage>::__ctor' with [ Storage=boost::policy::error_storage<>, MsgStorage=boost::policy::no_errormsg_storage ] and [ Storage=boost::policy::error_storage<>, MsgStorage=boost::policy::no_errormsg_storage ] VC6 -- test.cpp(70) : error C2248: 'cannot_derive_errorcheck<class boost::policy::error_storage<int>,class boost::policy::no_errormsg_storage>::cannot_derive_errorcheck<class boost::policy::error_storage<int>,class boost::policy::no_errormsg_storage>' : cannot access private member declared in class 'boost::detail::cannot_derive_errorcheck<class boost::policy::error_storage<int>,class boost::policy::no_errormsg_storage>' Borland C++5.5 -- Error E2247 test.cpp 11: 'boost::detail::cannot_derive_errorcheck<boost::policy::error_storage<int>,boost::policy::no_errormsg_storage>::cannot_derive_errorcheck()' is not accessible in function foobar::foobar() Therefore, the error message is intuitive: cannot_derive_errorcheck! Regards, Reece _________________________________________________________________ Tired of 56k? Get a FREE BT Broadband connection http://www.msn.co.uk/specials/btbroadband

1 0

Re: [boost] Re: Re: Formal Review: Indexed Set
by JOAQUIN LOPEZ MU?Z 28 Mar '04

28 Mar '04

----- Mensaje original ----- De: Arkadiy Vertleyb <vertleyb(a)hotmail.com> Fecha: Domingo, Marzo 28, 2004 5:47 pm Asunto: [boost] Re: Re: Formal Review: Indexed Set > >"JOAQUIN LOPEZ MU?Z" <joaquin(a)tid.es> wrote: > > >IMHO nth_iterator_type and familiy are user-level > >facilities (similar vg to Boost.Tuple get<>) and accepting > >mpl integral constants instead of raw constants does > >not make much sense here. Please somebody correct me > >if I'm wrong. > > One positive thing that could result from this would be the > possibility of > specializing the class to determine the type of the index, such as > insteadof > > nth_index_type<1>::type > > to use > > index_type<mpl::int_<1> >::type //rather clumzy, but doesn't > clash with > index_type<tag>::type > > If you then create some typedefs (possibly with the preprocessor), > somethinglike: > > typedef mpl::int_<1> _1; > ... > typedef mpl::int_<10> _10; > > This might look like: > > index_type<_1>::type; > I more or less get your approach, but still don't see what would gain us wrt the current scheme. And those typedefs will probably we disliked by many here at the mailing list. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[timer] throwing constructor?
by Gennaro Prota 28 Mar '04

28 Mar '04

The documentation for boost::timer says: "The constructors may throw std::bad_alloc." I don't see how they could. There are two of them; one is the compiler generated copy constructor and the other one is: timer() { _start_time = std::clock(); } Maybe the intent was to write it as: start_time = std::clock(); if (_start_time == (std::clock_t)(-1)) throw ...; ? But why the exception would be bad_alloc? PS: I haven't checked whether progress_timer and progress display have the same problem. PS2: I know that it is (the intent for it to be) allowed in class scope but shouldn't we refrain from using identifiers with a leading underscore? Genny.

1 0

Re: [boost] Formal Review: Indexed Set
by JOAQUIN LOPEZ MU?Z 28 Mar '04

28 Mar '04

Hello Jeff, thanks for reviewing the indexed_set! ----- Mensaje original ----- De: Jeff Garland <jeff(a)crystalclearsoftware.com> Fecha: Domingo, Marzo 28, 2004 5:21 am Asunto: [boost] Formal Review: Indexed Set > Let me start by saying thanks to Joaquín for the contribution of > this library. You are welcome. The experience has been a lot of fun to me. [...] > > * Do you think the library should be accepted as a Boost library? > Yes. great :) thanx! > > ********* > Now for some questions / comments: > > 1) Dead code in index_node.hpp? > > I don't think the ':' is legal below -- I assume this is dead code? > > template<typename Super> struct > index_node_trampoline:index_node_impl{}; > template<typename Super> > struct index_node:Super,index_node_trampoline<Super> > ... > This is not dead code. index_node_treampoline:index_node_impl is short for index_node_treampoline:public index_node_impl. My coding style is admiteddly a little too compact. > 2) bidirectional_map > > My first interest in this library started when it was just a bi- > directionalmap. Now it has become something much broader and more > powerful. Curiously, > the bi-directional map part seems to have taken a back seat -- > being pushed > into the examples as an 'exercise for the reader'. > > I think that this is unfortunate. I like to see bidirectional_map > as an > official part of the library. A few reasons for this: > > a) bidirectional_map will be documented up front as a part of > the library. > b) For me it is my current primary use of this library -- even > though it is > now so flexible I'll have to rethink how I use containers in designs. > c) Complex code is pushed on the user. For example, the code > below is from > examples/bimap.cpp > > template<typename FromType,typename ToType> > struct bidirectional_map > { > typedef std::pair<FromType,ToType> value_type; > > #if defined(BOOST_NO_POINTER_TO_MEMBER_TEMPLATE_PARAMETERS) ||\ > defined(BOOST_MSVC)&&(BOOST_MSVC<1300) ||\ > > defined(BOOST_INTEL_CXX_VERSION)&&defined(_MSC_VER)&&(BOOST_INTEL_CXX_VERSION<=700) > > .... > > It is obvious from this that there are some portability issues. > Putting this > sort of detail on library users is too mcch to expect from users > in my opinion. > > But it is only a suggestion since it took me all of 5 minutes to > pull out the > core of the example to a header file. I don't think the bidirectional map I provide in the examples section is good enough for officialization (for one, it lacks operator[]). I only wrote it as 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, but we are talking probably of a separate library. Also, when I first introduced bimap to Boost a year ago, people expressed interest in an extensible approach, which bimap's rigid interface certainly did not provide. As for the macro stuff, you probably shouldn't be concerned if the compiler you work with is reasonably conformant. > > 3) Serialization support > In future directions you say "Once Robert Ramey's serialization > library gets > accepted into Boost..." > > I'd love to see Joaquín at least attempt this soon -- it would > serve as an > excellent review of serialization which is upcoming shortly :-) Good idea, if time permits I'll engage into the review and try to sketch some serialization support for indexed_set. > > 4) Should the SGI/HP copyrights be included in the source files > which are > based off the stl_tree.h implementation? I don't know. The original pieces of code (with lots of changes) are scattered across some five headers or so. Basically it is the rb-tree algorithms that I have retained. Maybe some of the licensing wizards here at the list can offer advice on this issue. > > 5) Naming > > For the namespace/library name I suggest > boost::multiindex_containers. > > Rationale: > -- The library provides several stl-like container types (set, > list, map) -- > hence the plural 'containers'. > -- The containers all have multiple indexes -- hence multiindex. > Maybe boost::container::multi_index would please more people: it is as descriptive as your proposal, but (1) it is into boost::container and (2) avoids the abhorred "ii". Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] Re: Formal Review: Indexed Set
by JOAQUIN LOPEZ MU?Z 28 Mar '04

28 Mar '04

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Domingo, Marzo 28, 2004 7:41 am Asunto: [boost] Re: Formal Review: Indexed Set > JOAQUIN LOPEZ MU?Z <joaquin(a)tid.es> writes: > > > Hi Jeff > > > > ----- Mensaje original ----- > > De: Jeff Garland <jeff(a)crystalclearsoftware.com> > > Fecha: Sábado, Marzo 27, 2004 4:55 pm > > Asunto: Re: [boost] Formal Review: Indexed Set > > > > > >> // why doesn't this work? > >> //typedef nth_iterator_type<date_to_string_bimap,2>::type > to_map_itr;> > > It is > > > > typedef nth_iterator_type<date_to_string_bimap,1>::type to_map_itr; > > > > Index numbering is 0-based. I think this is the > > only problem in the program. If you have further > > problems please tell me so. > > Not having looked at the proposal at all, I still think I should raise > the usual concerns about "metafunctions" not accepting type > parameters, which don't play nice with MPL and lambda expressions. > IMHO nth_iterator_type and familiy are user-level facilities (similar vg to Boost.Tuple get<>) and accepting mpl integral constants instead of raw constants does not make much sense here. Please somebody correct me if I'm wrong. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

RE: [boost] Re: Standard C Library and C++ / BOOST
by Reece Dunn 28 Mar '04

28 Mar '04

David Abrahams wrote: >"Klaus Nowikow" <nowikow(a)decomsys.com> writes: >You're wrong. *this is copied before it is thrown. Still, the idiom >above seems a bit suspicious, unless you somehow prevent derivation >from errorcheck. So is it possible to prevent derivation? If not, then at least make it harder to do so (and put a warning in the docs)? Also, would a non-derivable class be a good addition to C++0x? Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

3 3

RE: [boost] Re: Re: Standard C Library and C++ / BOOST
by Reece Dunn 28 Mar '04

28 Mar '04

Pavel Vozenilek wrote: >"Reece Dunn" <msclrhd(a)hotmail.com> wrote > > So is it possible to prevent derivation? If not, then at least make it > > harder to do so (and put a warning in the docs)? >Yes. >Legal way: >http://www.research.att.com/~bs/bs_faq2.html#no-derivation Cool! I have adapted the example to the errorcheck class, so it will report a clean error message. The code has been tested on borland 5.5 and vc-6, vc-7 and vc-7.1 and should work on other compilers. If there is interest, where in the boost-sandbox would be best to put it? My gut feeling is boost/errorcheck.hpp, but if anyone has any better suggestions... Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

1 0