- Boost - lists.boost.org

[Boost-bugs] [ boost-Bugs-925163 ] Compiling Boost with Python without Unicode
by SourceForge.net 29 Mar '04

29 Mar '04

Bugs item #925163, was opened at 2004-03-29 17:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=925163&group_i… Category: Python Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Gray (codeazure) Assigned to: David Abrahams (david_abrahams) Summary: Compiling Boost with Python without Unicode Initial Comment: If compiling Boost 1.31.0 against Python 2.2.3 where Python has been compiled to not include Unicode support, Boost fails to compile. The problem is caused by a function within libs/python/source/converter/builtin_converters.cpp The function encode_string_unaryfunc() needs to be preceded by #ifndef BOOST_NO_STD_WSTRING, which is currently below the function. It is also necessary to add #define BOOST_NO_STD_WSTRING to libs/config/user.hpp to compile Boost without Unicode support. I am using Python on an embedded system where Unicode is not required and support for these libraries requires considerable memory. To build Python without Unicode support, do this: ./configure --disable-unicode ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=925163&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[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