March 2004 - Boost - lists.preview.boost.org

[program_options] nasty bug!
by Neal D. Becker 29 Mar '04

29 Mar '04

There is a bug in program_options. Now I remember, this is why I stopped using it before. It can't accept negative numbers as command line arguments! #include <boost/program_options.hpp> #include <iostream> #include <cxxabi.h> // demangle using namespace std; namespace po = boost::program_options; int main (int argc, char** argv) { double angle; std::set_terminate(__gnu_cxx::__verbose_terminate_handler); po::options_description desc("Allowed options"); desc.add_options() ("help", "produce help message") ("angle,a", po::value (&angle)) ; po::variables_map vm; po::store(po::parse_command_line(argc, argv, desc), vm); po::notify(vm); if (vm.count("help")) { cout << desc << "\n"; return 1; } cout << "angle: " << angle << '\n'; } ./Test1 -a -0.2 terminate called after throwing a `boost::program_options::invalid_command_line_syntax' what(): required parameter is missing in '-a' Aborted

2 1

Re: [boost] Indexed Set needs a name?
by JOAQUIN LOPEZ MU?Z 29 Mar '04

29 Mar '04

Hi Tom ----- Mensaje original ----- De: Tom Brinkman <reportbase(a)yahoo.com> Fecha: Domingo, Marzo 28, 2004 11:11 pm Asunto: [boost] Indexed Set needs a name? > 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. > Well, I hope we don't have to resort to an arbitrary name. IMHO those should be reserved for larger libraries, indexed_set after all is nothing but a container full-o-gadgets. Anyway, you're right that trying to find the perfect descriptive name is probably impossible, but at least some indication on what the library is about is useful (if "index" and "container" somehow appear around, you'll know the library is not about genetic algorithms, for instance.) The review will finish in a couple of days. By the last day I'll try to propose something reasonable which, if not loved by everybody, is at least a sufficiently good compromise. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

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

29 Mar '04

----- Mensaje original ----- De: Jeff Garland <jeff(a)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

3 2

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