February 2005 - Boost-users - lists.preview.boost.org

RE: [Boost-users] [serialization] problem with Borland C++ Builder 6
by Richard Jennings 28 Feb '05

28 Feb '05

XML serialization is working fine for me with BCB6. With some of my programs I do get error E2015 reported when I do a make. If I do a build (i.e. rebuild all modules from scratch) then it compiles just fine. I haven't looked in to why this is yet. -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Pablo Aguilar Sent: 26 February 2005 04:50 To: boost-users(a)lists.boost.org Subject: [Boost-users] [serialization] problem with Borland C++ Builder 6 Hi, I've just started using the serialization library, and am trying to do so with BC++6. If I'm right, it should work just as long as I remove support for xml archives (because Spirit doesn't work on BC++) I've a class Cliente which has an appropriate serialize member fxn. And a manager class called Clientes which stores a std::vector<boost::shared_ptr<Cliente> > When doing: void Clientes::serialize(Archive& ar, unsigned const version) { ar & m_imp->m_clientes; // where m_imp is a pimpl-style struct // m_clientes is of the type specified above } (this is trimmed down code, I can post the original if required) I get the following error: [C++ Error] serialization.hpp(121): E2015 Ambiguity between 'boost::serialization::void serialize< boost::archive::text_iarchive , boost::shared_ptr<cc::servidor::Cliente> > ( boost::archive::text_iarchive & , _STL::vector<boost::shared_ptr<cc::servidor::Cliente> > & , const unsigned int )' and 'boost::serialization::void serialize< boost::archive::text_iarchive , _STL::vector<boost::shared_ptr<cc::servidor::Cliente> > >( boost::archive::text_iarchive & , _STL::vector<boost::shared_ptr<cc::servidor::Cliente> > & , const unsigned int )' (I removed the allocator parts to make the message clearer) So the question is, how do I remove the ambiguity? Thanks for your help... Pablo Aguilar _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

Handling "actions" with program_options
by Julio M. Merino Vidal 28 Feb '05

28 Feb '05

Hi everybody, I'm working on a program whose its actual syntax is: vcsme [-c conf_file] [-q] action [action_args] (very similar to the CVS one). I'm trying to convert it to use boost::program_options (to get rid of the getopt(3) call, and to have long options), but I don't know how to do it. So far, I've added the code to handle -c and -q options. This was very easy to do, given the examples on the web. The only annoyance is that the options are accepted everywhere, but I'd prefer to only accept them if they come before the action name (because the action itself might allow options). Unfortunately, I'm stuck with the latest part, the one to handle actions. There must always be an action passed to the program, which may optionally accept arguments. Some example invocations: vcsme -q update vcsme update gtk+ glib NetBSD But I can't see any way to do this with program_options. Using getopt, I do: argc -= optind; argv += optind; after processing the options, so that argv[0] becomes the name of the action, and any remaining entries are its arguments. The same can be achieved with getopt_long. So... is it there any way to do what I want with the actual implementation? Can't see anything relevant in the docs... Thanks, -- Julio M. Merino Vidal <jmmv84(a)gmail.com> http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/

3 4

Re: [Boost-users] File-based container library?
by Beman Dawes 28 Feb '05

28 Feb '05

At 11:23 AM 2/23/2005, John.Wismar(a)autozone.com wrote: >Does Boost have a library that defines a file-based container, perhaps >based on a B-tree or equivalent, for very large collections? Or does >anyone know of such a thing, or has there been talk about developing one? > >We have a few file-based collections with millions of entries. We don't >especially want to install a database. The file is too large to load into >memory. The file's format could be changed to make it compatible with the >type of collection I'm thinking of, but for the moment, we're doing binary >searches by reading the file on disc. As you might guess, this can be >quite slow, especially when the file is on a DVD and not the HD. > >Anyway, I'd like to be able to write something like: > >//file.data contains 100,000,000 entries >file_map<int, int> some_data("file.data"); >file_map<int, int>::iterator it = some_data.find(56789012); > >and have the container (for example via a B-tree or whatever) be able to >locate the item with very few disc accesses. > >Any libraries that can do this type of thing? In 1999 I did some work on a B-tree implementation for Boost, but became discouraged. For maximum portability and very high performance, it would have had to have a lot of limitations; memcopy'able POD types only, an interface that differed in several ways from the standard library containers, etc. Even with those limitations, the prototype took twice as long for typical operations as the old C code B-tree I've used for 20 years. Perhaps someone else will give it a try; a B-tree is an incredibly valuable tool and it would be great to have a good one in Boost. --Beman

2 1

Problems with file_iterator and skip parsers
by chrono232＠fastmail.fm 28 Feb '05

28 Feb '05

Can anyone explain to me what is wrong with the following: ---------------- my_grammer g; // a grammar, the actual grammar I'm using is too long for me to post file_iterator first<char>( "somefile.txt") file_iterator last<char> = first.make_end(); rule_t<> skp = space_p | comment_p("//") | comment_p("/*","*/"); parse_info< file_iterator<char> > = parse( first, last, *g, skp ); ---------------- I keep getting these errors (from MinGW 3.4.2): 189 C:\Dev-Cpp\include\boost\spirit\core\non_terminal\impl\rule.ipp no matching function for call to `boost::spirit::impl::abstract_parser<do_main_thing()::scanner_t, boost::spirit::nil_t>::do_parse_virtual(const boost::spirit::scanner<boost::spirit::file_iterator<char, boost::spirit::fileiter_impl::mmap_file_iterator<char> >, boost::spirit::scanner_policies<boost::spirit::no_skipper_iteration_policy<boost::spirit::skip_parser_iteration_policy<boost::spirit::rule<do_main_thing()::scanner_t, boost::spirit::nil_t, boost::spirit::nil_t>, boost::spirit::iteration_policy> >, boost::spirit::match_policy, boost::spirit::action_policy> >&)' 61 C:\Dev-Cpp\include\boost\spirit\core\composite\intersection.hpp no matching function for call to `boost::spirit::skip_parser_iteration_policy<boost::spirit::rule<do_main_thing()::scanner_t, boost::spirit::nil_t, boost::spirit::nil_t>, boost::spirit::iteration_policy>::skip_parser_iteration_policy()' 61 C:\Dev-Cpp\include\boost\spirit\core\composite\intersection.hpp no matching function for call to `boost::spirit::skip_parser_iteration_policy<boost::spirit::rule<do_main_thing()::scanner_t, boost::spirit::nil_t, boost::spirit::nil_t>, boost::spirit::iteration_policy>::skip_parser_iteration_policy()' According to the FAQ, this shouldn't happen with grammars. I am a beginner, so please forgive my ignorance. Thanks for any and all help. Also, I've tried making the skip rule a grammar, again, with errors.

2 1

Mac OS X 10.3.8 / gcc 3.3 build hanging boost 1_32_0
by Jwahar Bammi 27 Feb '05

27 Feb '05

OS X newbie trying to compile boost 1.32.0 bjam -sTOOLS=darwin stage on OS X 10.3.8 with stock gcc (gcc 3.3), the build hangs trying to compile boost/libs/serialization/build/libboost_wserialization.a/darwin/release/xml_wgrammar.o the compiler (gcc1) just sits there (i started the build and went to bed, in the morning it was still there) Any hints much appreciated. -- Jwahar Bammi bammi(a)memento-inc.com

3 2

can't compile boost example
by Hongyu Zhang 26 Feb '05

26 Feb '05

I just downloaded boost package, but seemed not able to compile the example programs. My platform is Redhat Linux 7.3, compiler is gcc version 2.96 I followed the installation guide, downloade the boost package and successfully compiled it. I install it to a directory called /home/hzhang/tools/boost Then when I tried to compile an example program, first.cpp, which comes with boost, I type $ g++ first.cpp -I/home/hzhang/tools/boost/include/boost-1_32/ It gave me this error In file included from /home/hzhang/tools/boost/include/boost-1_32/boost/program_options.hpp:15, from first.cpp:9: /home/hzhang/tools/boost/include/boost-1_32/boost/program_options/parsers.hpp:151: parse error before ` >' Did I miss any environmental variable set up or forget to include any necessary paths in the command? Please highlight me, because I cound't find even the simplest compiling command example from boost web page. Thanks a lot! -- Hongyu Zhang Computational biologist Ceres Inc.

2 1

reading bad archive by boost_1.32/serialization
by junyi.sun＠supportlinux.net 25 Feb '05

25 Feb '05

Hi, I have a class using boost_1.32/serialization to save/restore object data and it's working fine for loading & saving its own archive. I tried to make it load an archive saved by an unrelated class in order to verify exception handling of reading wrong/ corrupt archive. It dumps core at basic_iarchive_impl::load_pointer. Is it a known issue ? Anyone has similar experience ? Thanks. Junyi Sun --------------- here the core trace ---------------- Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libtcl8.4.so...done. Loaded symbols for /usr/lib/libtcl8.4.so Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /usr/lib/libstdc++.so.5...done. Loaded symbols for /usr/lib/libstdc++.so.5 Reading symbols from /lib/tls/libm.so.6...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /lib/libgcc_s.so.1...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/tls/libc.so.6...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /lib/libnss_dns.so.2...done. Loaded symbols for /lib/libnss_dns.so.2 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 #0 0x081c16cb in boost::archive::detail::basic_iarchive_impl::load_pointer () (gdb) bt #0 0x081c16cb in boost::archive::detail::basic_iarchive_impl::load_pointer () #1 0x081c0d23 in boost::archive::detail::basic_iarchive::load_pointer () #2 0x08060344 in boost::archive::detail::load_pointer_type<boost::archive::text_iarchive, MyObjectP*>::invoke (ar=@0xfef3c240, t=@0xfef3bf74) at iserializer.hpp:450 #3 0x08060304 in load<boost::archive::text_iarchive, MyObjectP*> (ar=@0xfef3c240, t=@0xfef3bf74) at iserializer.hpp:529 #4 0x080602ea in load_override<MyObjectP*> (this=0xfef3c240, t=@0xfef3bf74) at basic_text_iarchive.hpp:60 #5 0x080602c6 in load_override<MyObjectP*> (this=0xfef3c240, t=@0xfef3bf74) at text_iarchive.hpp:59 #6 0x08060298 in operator&<MyObjectP*> (this=0xfef3c240, t=@0xfef3bf74) at interface_iarchive.hpp:92 #7 0x08060260 in serialize<boost::archive::text_iarchive> (this=0xfef3bc80, ar=@0xfef3c240) at nvp.hpp:58 #8 0x0806023d in serialize<boost::archive::text_iarchive, boost::serialization::nvp<MyObjectP*> > (ar=@0xfef3c240, t=@0xfef3bc80, file_version=0) at access.hpp:106 #9 0x0806021b in serialize<boost::archive::text_iarchive, boost::serialization::nvp<MyObjectP*> > (ar=@0xfef3c240, t=@0xfef3bc80, file_version=0) at serialization.hpp:78 #10 0x080601f9 in serialize_adl<boost::archive::text_iarchive, boost::serialization::nvp<MyObjectP*> > (ar=@0xfef3c240, t=@0xfef3bc80, file_version=0) at serialization.hpp:121 #11 0x080601d8 in boost::archive::detail::load_non_pointer_type<boost::archive::text_iarchive, boost::serialization::nvp<MyObjectP*> >::load_only::invoke (ar=@0xfef3c240, t=@0xfef3bc80) at iserializer.hpp:318 #12 0x080601b6 in boost::archive::detail::load_non_pointer_type<boost::archive::text_iarchive, boost::serialization::nvp<MyObjectP*> >::invoke (ar=@0xfef3c240, t=@0xfef3bc80) at iserializer.hpp:366 #13 0x0806019c in load<boost::archive::text_iarchive, boost::serialization::nvp<MyObjectP*> > (ar=@0xfef3c240, t=@0xfef3bc80) at iserializer.hpp:529 #14 0x08060182 in load_override<boost::serialization::nvp<MyObjectP*> > (this=0xfef3c240, t=@0xfef3bc80) at basic_text_iarchive.hpp:60 #15 0x0806015e in load_override<boost::serialization::nvp<MyObjectP*> > (this=0xfef3c240, t=@0xfef3bc80) at text_iarchive.hpp:59 #16 0x08060130 in operator>><boost::serialization::nvp<MyObjectP*> > (this=0xfef3c240, t=@0xfef3bc80) at interface_iarchive.hpp:105 #17 0x080600b8 in operator&<boost::serialization::nvp<MyObjectP*> > (this=0xfef3c240, t=@0xfef3bc80) at interface_iarchive.hpp:111 #18 0x0805fe43 in serialize<boost::archive::text_iarchive, std::string, MyObjectP*> (ar=@0xfef3c240, p=@0xfef3bf70) at utility.hpp:47 #19 0x0805f59f in serialize_adl<boost::archive::text_iarchive, std::pair<std::string, MyObjectP*> > (ar=@0xfef3c240, t=@0xfef3bf70, file_version=1) at serialization.hpp:121 #20 0x0805f48f in boost::archive::detail::iserializer<boost::archive::text_iarchive, std::pair<std::string, MyObjectP*> >::load_object_data (this=0x8a3f6c0, ar=@0xfef3c240, x=0xfef3bf70, file_version=1) at iserializer.hpp:155 #21 0x081c143a in boost::archive::detail::basic_iarchive_impl::load_object () #22 0x081c0d00 in boost::archive::detail::basic_iarchive::load_object () #23 0x0805df95 in boost::archive::detail::load_non_pointer_type<boost::archive::text_iarchive, std::pair<std::string, MyObjectP*> >::load::invoke (ar=@0xfef3c240, t=@0xfef3bf70) at iserializer.hpp:328 #24 0x0805df6c in boost::archive::detail::load_non_pointer_type<boost::archive::text_iarchive, std::pair<std::string, MyObjectP*> >::invoke (ar=@0xfef3c240, t=@0xfef3bf70) at iserializer.hpp:366 #25 0x0805df52 in load<boost::archive::text_iarchive, std::pair<std::string, MyObjectP*> > (ar=@0xfef3c240, t=@0xfef3bf70) at iserializer.hpp:529 #26 0x0805df38 in load_override<std::pair<std::string, MyObjectP*> > (this=0xfef3c240, t=@0xfef3bf70) at basic_text_iarchive.hpp:60 #27 0x0805df14 in load_override<std::pair<std::string, MyObjectP*> > (this=0xfef3c240, t=@0xfef3bf70) at text_iarchive.hpp:59 #28 0x0805dee6 in operator&<std::pair<std::string, MyObjectP*> > (this=0xfef3c240, t=@0xfef3bf70) at interface_iarchive.hpp:92 #29 0x0805deae in serialize<boost::archive::text_iarchive> (this=0xfef3bf60, ar=@0xfef3c240) at nvp.hpp:58 #30 0x0805de8b in serialize<boost::archive::text_iarchive, boost::serialization::nvp<std::pair<std::string, MyObjectP*> > > ( ar=@0xfef3c240, t=@0xfef3bf60, file_version=0) at access.hpp:106 #31 0x0805de69 in serialize<boost::archive::text_iarchive, boost::serialization::nvp<std::pair<std::string, MyObjectP*> > > ( ar=@0xfef3c240, t=@0xfef3bf60, file_version=0) at serialization.hpp:78 #32 0x0805de47 in serialize_adl<boost::archive::text_iarchive, boost::serialization::nvp<std::pair<std::string, MyObjectP*> > > ( ar=@0xfef3c240, t=@0xfef3bf60, file_version=0) at serialization.hpp:121 #33 0x0805de26 in boost::archive::detail::load_non_pointer_type<boost::archive::text_iarchive, boost::serialization::nvp<std::pair<std::string, MyObjectP*> > >::load_only::invoke (ar=@0xfef3c240, t=@0xfef3bf60) at iserializer.hpp:318 #34 0x0805de04 in boost::archive::detail::load_non_pointer_type<boost::archive::text_iarchive, boost::serialization::nvp<std::pair<std::string, MyObjectP*> > >::invoke (ar=@0xfef3c240, t=@0xfef3bf60) at iserializer.hpp:366 #35 0x0805ddea in load<boost::archive::text_iarchive, boost::serialization::nvp<std::pair<std::string, MyObjectP*> > > ( ---Type <return> to continue, or q <return> to quit--- ar=@0xfef3c240, t=@0xfef3bf60) at iserializer.hpp:529 #36 0x0805ddd0 in load_override<boost::serialization::nvp<std::pair<std::string, MyObjectP*> > > (this=0xfef3c240, t=@0xfef3bf60) at basic_text_iarchive.hpp:60 #37 0x0805ddac in load_override<boost::serialization::nvp<std::pair<std::string, MyObjectP*> > > (this=0xfef3c240, t=@0xfef3bf60) at text_iarchive.hpp:59 #38 0x0805dd7e in operator>><boost::serialization::nvp<std::pair<std::string, MyObjectP*> > > (this=0xfef3c240, t=@0xfef3bf60) at interface_iarchive.hpp:105 #39 0x0805d2d2 in boost::serialization::stl::archive_input_map<boost::archive::text_iarchive, std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<std::string const, MyObjectP*> > > >::operator() (this=0xfef3bfae, ar=@0xfef3c240, s=@0xe3693e4) at collections_load_imp.hpp:110 #40 0x0805d192 in load_collection<boost::archive::text_iarchive, std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<const std::string, MyObjectP*> > >, boost::serialization::stl::archive_input_map<boost::archive::text_iarchive, std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<const std::string, MyObjectP*> > > >, boost::serialization::stl::no_reserve_imp<std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<const std::string, MyObjectP*> > > > > (ar=@0xfef3c240, s=@0xe3693e4) at collections_load_imp.hpp:158 #41 0x0805d110 in load<boost::archive::text_iarchive, MyObjectP*, std::string, std::less<std::string>, std::allocator<std::pair<const std::string, MyObjectP*> > > (ar=@0xfef3c240, t=@0xe3693e4) at map.hpp:61 #42 0x0805d0f5 in boost::serialization::free_loader<boost::archive::text_iarchive, std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<std::string const, MyObjectP*> > > >::invoke (ar=@0xfef3c240, t=@0xe3693e4, file_version=0) at split_free.hpp:55 #43 0x0805d0d3 in split_free<boost::archive::text_iarchive, std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<const std::string, MyObjectP*> > > > (ar=@0xfef3c240, t=@0xe3693e4, file_version=0) at split_free.hpp:66 #44 0x0805d0b1 in serialize<boost::archive::text_iarchive, MyObjectP*, std::string, std::less<std::string>, std::allocator<std::pair<const std::string, MyObjectP*> > > (ar=@0xfef3c240, t=@0xe3693e4, file_version=0) at map.hpp:81 #45 0x0805b339 in serialize_adl<boost::archive::text_iarchive, std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<const std::string, MyObjectP*> > > > (ar=@0xfef3c240, t=@0xe3693e4, file_version=0) at serialization.hpp:121 #46 0x0805b03b in boost::archive::detail::iserializer<boost::archive::text_iarchive, std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<std::string const, MyObjectP*> > > >::load_object_data (this=0x8a3f5b0, ar=@0xfef3c240, x=0xe3693e4, file_version=0) at iserializer.hpp:155 #47 0x081c143a in boost::archive::detail::basic_iarchive_impl::load_object () #48 0x081c0d00 in boost::archive::detail::basic_iarchive::load_object () #49 0x08058aa3 in boost::archive::detail::load_non_pointer_type<boost::archive::text_iarchive, std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<std::string const, MyObjectP*> > > >::load::invoke (ar=@0xfef3c240, t=@0xe3693e4) at iserializer.hpp:328 #50 0x08058a7a in boost::archive::detail::load_non_pointer_type<boost::archive::text_iarchive, std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<std::string const, MyObjectP*> > > >::invoke (ar=@0xfef3c240, t=@0xe3693e4) at iserializer.hpp:366 #51 0x08058a60 in load<boost::archive::text_iarchive, std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<const std::string, MyObjectP*> > > > (ar=@0xfef3c240, t=@0xe3693e4) at iserializer.hpp:529 #52 0x08058a46 in boost::archive::basic_text_iarchive<boost::archive::text_iarchive>::load_override<std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<std::string const, MyObjectP*> > > > (this=0xfef3c240, t=@0xe3693e4) at basic_text_iarchive.hpp:60 #53 0x08058a22 in boost::archive::text_iarchive_impl<boost::archive::text_iarchive>::load_override<std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<std::string const, MyObjectP*> > > > (this=0xfef3c240, t=@0xe3693e4) at text_iarchive.hpp:59 #54 0x080579b8 in operator>><std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<const std::string, MyObjectP*> > > > (this=0xfef3c240, t=@0xe3693e4) at interface_iarchive.hpp:83 #55 0x08056615 in encode_function (domain_id=208, bat=0xe728070, info=0xea2c339 "22 serialization::archive 3 0 0 4 1 1 3\n0 0 0 0 1\n1 0 1\n2 0 1\n3 0", info_len=65) at encode.cc:102

1 0

long compilation time using variant and spirit
by Matt P. 24 Feb '05

24 Feb '05

Hello, I have been developing a piece of code using various boost libraries, but I have to pause because the compilation has become unwieldy. It's a 50kloc prgm, which takes about 30min to compile on a pentium 3.5GHz HT and 1GB of memory (gcc 3.4 on linux). The binary, using the static linking with 2 boost libraries (program-options, filesystem) yield a 380M binary. Furthermore, it doesn't compile on msvc 7.1 (c1063, compiler stack overflow), and I had to stop mingw after one hour.... The prgm handles the parsing, storage, and serialization of a big raw string. This string is organized into fragments, about 30 each fragment could be occuring 0 or more times. each fragment contain on average 30 fields. each fragment has little in common with other fragments. my solution was to store the string as a vector of a type Fragment described by typedef variant<fragment1, fragmen2, ..., fragment30> Fragment. typedef vector<Fragment> string_storage. the parsing is handled using a grammar for each fragment, and the grammars are split between the definition and instantiation (manual explicit), as suggested in the FAQ. Most fields have a unique functor which is used as a semantic action to store the data found in the fragment. So this all scheme looked darn good when I had only a couple fragments, and it was working very well too! But now, my computer threatens to go strike whenever I type bjam on the command line. I don't have a clear question, besides the simple 'how well does variant scale'?, or 'does that seem like a not so clever design?'. The variant page mentions an optimization opportunity with 'has_nothrow_copy', but I can't find a good example. Could that help? Thanks, Matt

2 1

special_functions_test
by Gennadiy Rozental 24 Feb '05

24 Feb '05

Hi, Hubert For some reason I couldn't locate message to respond, but here is reply to your last post: > Well, actually, I am held up at the moment by what seems to be > internal Boost.Test problems. > I checked in a few days ago some modifications to the special > functions tests, which take into account the modifications to the > BOOST_CHECK_PREDICATE macro, but compilations still fails (Xcode 1.5): 1. You are using unit_test_ex.hpp. I forgot to remove this header. We don't need it anymore. Boost .Test now works with boost::function out of the box without any extra support. Just use unit_test.hpp 2. I noticed that your test could benefit from BOOST_TEST_TEMPLATE facility. I spend some time and look on attached version that do the trick. Fell free to use it if you want. 3. Usually It's not good idea to do ant thing from within init_test_suite function. This code is not guarded and should only be used for test tree creation. Gennadiy begin 666 special_functions.rar M4F%R(1H'`,^0<P``#0````````#;Q70@D#,`)@,``#4(```"^,CM3-U@6#(= M,PX`( ```&%C;W-H7W1E<W0N:'!P`+#Q:F 1W0S,S/T8$7NO"CCO$JR1)NVS MC(Y,R116R99\<K5O58FD6V<J:2J^$C<N3W>Y7)*VBD@4DVTU4YQG4\"O@-&@ MG1I/C@&@D$ :`#G[_F;F#P(<TTQ1.%A%"2#.8"MD$PR[!B2Q//:,Z_&^*,8' MB,E8;T<R682NN04#((C7(@@!*(:B(E'7LKY<.*..>*^1\/#K97!?"W;^*4XY MS%-0P+\7D:"K-$H.^5V2XR[SN"'O8?T;I*R22 FZ+\1_`%"*XE;2D?O$).32 MN2NXWF',LC.&C5O3T**]=Y5>XN8\.20D-;,AHDR89Y24Z%[@T#O_PE?/24H_ MPIUI9%#T>Z1!EN*505W3N[-AQU/[&&.34KW'5$SFB<;S#)TI!?-R>I1["0=/ M4SKNO_:!RR#'R798@( B;9N2DE)KI^KL.63F6K&:RT:K37"HMZN1]^:C.]TJ M41BZ"..LDTO[0.$B@.F0QP<$CC6<8OP<-E #ZQ6<$]!Y8^+(!R*5-\K*[9<< MTU-$KB)]T9XZB!H?6?->4?1W(),V%T. R[Z1'C?;!B_$+9HMW!&IE\<@](0: M-0BL*MC*$_/3X\B/#9A?#-,3@9?6*03QUL'HH747$?\#\-X^?FVIV^0+9+W; M$\J%WWGG#KYZA"!EALC6HDV35.E#E37!@0Q/N#JRX'7B@AR]G9>6765#)3DO M*AZ]7;T\F=7^?WZU%NCLZQTM0=P=T-$:6GJ)CJS+W)]%1VE@C'NS.+$5R?FW M)J'1NT'#HKD_29:U,^7;H7;?"47.\5<[P75@MZN-$\.TE:JKN>3Y0S/AD:#= MMOA#Q=S]RV?UW-Q&<=HT^U);D%Q4M$/Q!"!Z;^]OVT4ZW\WT:SPZ]N*<ZJGU M7[?LKS="@(L.E[;<U<"Y/U%,X>?H[J JF!V?(4+E#K5CY1D*FI\3V*0[G2M: M^8P=.@44S<1&?R/:+]G$^R2J?A^T_&3!63:>+8I^I@54RT[%?#N4HQD:K%-$ M6Q*M,&J1!W>'4:9&_.V%F/BJ0J#;&B[$;U+VZ57U]@"0]X[F^C_U;%2\;:7C M@V\K[0Y:S>[:.IP=2-5FV"M4=&W\0-P"=""0,P`?`P``*0@```)Y,YW V&!8 M,ATS#@`@````87-I;FA?=&5S="YH<' `\".12!'=#,S,_1@1>Z\*..\2K)&F M[;.,CDS)%';)EGQRM6]5B:1;9RII*KX2)RY/=[E<DK:):!23;353G&=3P330 MT: =&D^.;H! (^)!S]_X;@\"'-1043A810D@S& K9!,0%<Q6<3SV?.OR/BD& M!XC)6&\_,EF$KKD$X]!$:Y$D@(B&JF)5U[(^7#BDCGBOD?#\=;.2+X6K7QLS M#G,4U# OQ>1H*JT2<\Y770*[SN"'O8?S[I*R0\!-T7XD^ *6*W9M63OWB$F) M6&67<;S#F0[.&>[>GH5N]=ZZO;7,>&,Y(7JR%DF3#-(T'0O<&<=_^+-]%)LR M?A4J2J:7H]QT&6XM"@KFG<TN''2^L@8SZE>XZ8F8PI(\HRE"2+Y>4U*/62B$ M]40NZ_]G'*X*CPNR<H@")=FSTDH,Z?]<AR'YT58S66D5:6X4^/5R/ORT9GNT M)1&+G(Y*CEE_:2 (LMA1Z<' =QK,,7X.&N@(**^"SH@\LC5<$<BT)OE97;+C MEFHH*HB;=&:0H L?73=?B3I+.)*V&5' 9-Z1'C';!B_$+9H;F"13+XSCT #3 MI%:PJFL@3]%/CC3X:\'PRS$P3)ZQ2"?G6P>I.N1<2/@/PWML?7R!C<O=L#]( MA[T*UM[6@98;(UJF]DL4HWU2NTP(8GW!TY<#KQ22Y>SLO++K70\*\EZZ'KU= MO3R9E?Y_?K56Z.SK'0TA#(a)[H61I9^GF.K*O<GTNCL+!&1D_,,$5R;FH?4.BQ MH.&"N3=(MC4RJY<#*CX2%T.^KH=Q<6#'Q<::(=BS8IK8B;\H9GPG:#=MKA#\ MN9NW:1Z[FXG,&GM[J2V,7%0S='#B$#TW][?M)J5/IOIU'AU[?*\]U7ZK]OVN M\W0J"*CH>HW+7 N3]12N(GZ>ZD*EH=?Q^QIICJ5CY)^:>M>*,$I=SI6M?+@. MF8* S,1&?R/:+\F$^R2F;A9I_D>"HFDT6M3>B!33IIV*^'<-/J-JH4SQ:TJT MP:96#N\.HQ&WYMA8HU3(TAZMH-B-ZF;-*K:^O<D/>.WOI_]7!4/#M,TX-O)] MH<M9?=O6XK4C51M@K$_1G^**;W0@D#,`= 0``-P2```"UE[C`]5@6#(=,PX` M( ```&%T86YH7W1E<W0N:'!P`/ W!C\,&8T,S0_-@1N[_%8'0'4JXVG-VSC& MY )KUV[!9LD%;MZH)I8V\&II/5\)&MNS_O15+NMI)HXL23242FQN2Z+PS@DT ML)]/PSTG,3_,'T_3"<)'A\ P$\#R()SD@@)M8C0FALZC(148DFDELUO-HT:\ MNP\^9X6=`TR)*Z^^E-HBZS)D^RV_<=:L``1U\\5]?0XP3+F>CW-XQL!V75(L M+U7+GKMQ(OM(_1\&-OO%`:B@S#GL77 +PKY&NU)C7N@B8X(!\ OY>]D&6+AM MW+<#^$8X(a)1)--?/HV0.0,Y3/;T<]_!TX<"/"B^=K3 2#Z)@Y00/$I;#FM''K M';]2WC*RK;WY4*"H?6^A^$"":K>Q05Z2)H<.69[7@SP:DT<LU*B$D'GA&0CE M&B[*$LQZ13++U L]T?\,BTR(7HBFDR,$F'96!,<8B3RO-.0<[*L[]L3RXH;A M&T]1&PQ#1J>S8DV\&LG/5IAE_JL5";9++L,<?' XIJ$L;-VFR"A-/DI[(._Q M<4R&LWL38(FBJ3/#-&PJ*3%%.J+,(''VLW;T>YYH!(6PU36 DWT!Z'_*@1;D M%/85[(\KZN6 :-"./F![$*AAP%XK-.TGW:=!\G82B0W/&"@EXNJ!T&GD+D+Z M#OE:JAA@8:;$[)R=, D#BS? Z_Y1]ZD(9325&I*#3Q=".0LQ^7P--L+'35<! M]W ?GV=75AQ(XL =+_-AP!^??U]'-J4?T_CIOXN?JZ3HRIE,7P`Y7I!2-D>7 M[D4<T2>]TP\WZX#J^((**OXDL1%HK1# PMP4"N8BT5OFO*[-Z\!B& 4D2TV( MEIOWL0%O(G'ERZ]NN?=HLN_[L%_]D>O]\'MY[X3,.DC*#EE$?Q;@J `_[@E8 MAQ2<1.<7(,?<M?+1?*X>&-J>H'ZQ33[&1_^QSO6>AQ0]6A!I[1RO5_['O6C/ M79=WRDC*K$6:$0*@7+H=KVKX;A?S9LF4&HJEK!I!)H.*2UQ7-D5#V<1]V>L^ M"UE*Y'>DR1.>E\YTFG+5`<X831<O(+QHML6*@,LNX9P>V^.V3>_Z][7<IMO8 M+GU'77\SSYDP^ZL;J6X3V+D4V[H0;]\&:_;,-/X'>8MY[O;:I;6(G4K^9+]% MN/2>&G)0,3%FTIC(\B:9)1=O&'%X-C2I0"C9M*'I,F:%@2++*):5?]/!JU- M3$_2L*=G36-3R%<=34JY*F'7'4R(H[4XI*SQ6'NNR>H.36E$4%=M9MD.7#L2 M8(D`57$'+86#7NGC5QV(V!5VY5W%]JPU2&!+Q09DF48#,GUGD<%8L>26S0?W MQ<F2.H -PL=247I*761M=IW#Q!9\J,!O=5%C7)XRKY\>4=[5?#;AWHU8$ZB8 M=22?;?XR6J2PL6_Y>JGB^SSHC_G\_%:5EW_6J6U9N31&J[Y$GW-IVJJYC<FQ M-6M\B[T]N>!>G^F>?2DW9NL/E%#=8S_BS(T:QG2<$\R?P%H8#[X%_B1+S[9, M=T[QG4S^1:_EJ\;]:VW2RUOUK_Z4R)UL:?.>3C;5/$OBKF^MO^TWS'0@D#(` MM@(``$8(```"5XF2;]!@6#(=,PT`( ```'-I;F-?=&5S="YH<' `L& ]60V9 M4,S,_101=Z\*(=TI"-I)VB:7'8 XHK8Q9TBMV[4$TBVR*FDJNB= HGN]%CLK M;71A**=:C5 C@>BZ#H2)PYT<SG,2\<X<Z3G,PYA'VO_3_X(HH*-TD0HAPZ#& M1P8H2.M)Y7W]->@U-E!@^-HC+FGR(:B(\[#0_H8Y+#00"0$BLD)9Y_O@)DRZ MHYH\0X ]/.2DB]JJON3,[<I)*2 Q1YS851L=$_<CSP2O`]CB[68-.YR-#E@' M9%]=7PA2Q6TU4Y7\`QFDK+33V9]EWOE9R4"SGOK+].!=BVQ(>+NE) :M``R) MB- F.B?N:1V_P3Q%H4]7Y%/-"I(>3V!>SD<R@KM-SSX<>PUU!FEU(_LLB@,P M'=^VS&&HRDBYVE#EPQXRE)IK80IJ*%0+'ZH=ZYU+X8:9A&#R`!+2,\TY.KJP M86,*X>%KV!<-O1U\][0L?#Z=*V&_U=*)E:8?(:B61813\_A 0:C#HR%V7+F< MWH&<4/%G]V/,. DH;A,TU.VZF%'D+?MRX>GI"&=Z`YT>+!>^*Z-C" .%B#NP MB.FP,@&&-UL#K(Z;'VP@(^KMT1</9)3>=[\_;K,Q%W#QRRL(I%Z["=A*I0K< MRZWR8Z_FORWU@(9$]@<EWA8']XY9@C)-6=<_HA>J)P87JD;.(1HITQ%Y*I)6 MO,RM^)+^QM4DF#0W\YQYU$[P`?^&Y).?&'KTL#EEXD/1*3Z10[@I1QY_QJ8= M_G"IE19%;.C-.K0MMX*8B-8O/J5Z0['B-EY4K /RH ZE7RC:^R-8KFX(,?MU MEP4[0TCJ:(1!>\2O$'J[H[:I=O!P4![17FW+=>(!Q=L]W#5*C944YW,<]<T= M7XU.R):X54E$!;IJLD0EW_0.[H+6WH\3@ZHOTL]X#%,JWP/@8EY!5HXJ=&\! MW4E\M@2H_+7A78[BL'S3^4#V'70@D#,`N@(``)T(```"8[W"]-)@6#(=,PX` M( ```'-I;FAC7W1E<W0N:'!P`/"$CRD-W5$(S/T8%7O/"M3O2"C@#M4Z7'8D MX0MC5GQ5;M[1##6WJHP*?"?!53W>JR6UL-9FZ ZPA$JXGT3HWH W,YO,YN<Q MOQS/KS<S<Q?DO_1_\)44%&Z2(40X=!D(X,4)'<S2>9]_3GH)'S!!?&T1ES3Y M4M1$>=AG'X8Y;C00`C$BLD)9Y_N@)ES21RQXQP!Z><*4+VJJ^Y,X;D)+24&. M/Q-A56QSGG&\\!7A>R1=C,&G<Q&AE@';%]9/A"EBN)JIE?PC&<E9::>SOLN] MQ6<LZMYL"R_1A78N,2GB[2D@M6@0)4Q'X6HZ)^[I'9_1/&:@3D_*I6XJ2'\> MPJ#3D>I05ZGL\V'%L19 SEU(_LPC(&H#M_;8AGHJDJIF5*+;L>&IKNBPXAKI MJ&8#'ZG#604WAAIF$8"@KQ:1T&?'T].'$QB7#PM?PKA\\_5S7]"Q\/IT+8L' M3T(SN^8?(>BVQ8A3<_A 0:C"3E-\7;LD-Z!G'#P^,;5D#=CSC@(4QPF?5G0, MKBCK?1&L?NW::WL#Q_$ZXY_!AO_%=&UB!(,14C1$=/A1`,,@FP88CI\F;6M. MWKPC8LRSF5[GQL.LZF+V+B+@PBD:7:3M)<->FK<JZWR8ZOFOR8%@M(C1U9PO MD+ _O&6H".7UO7140LDC2E#2Y73*$:,Q,1MRJ26_6A7/`E_N=5M:=/#?*@X\ MZC0(!3=Z&UN/1D%_^Y^O(#=ZL>BCJGJAX4<*A-'>RV('<%OH"K:\H\!4C88, M^BP1UO$;-NUOZ'])`OBL9AM?9&P?OT+,@(,'J7*,PP:1DJ(1!>\2O"'J]H[B MIOG>WIU//7?*::\:QQ=DWG!.,KZ,Z*;ZY)NM6-7\QT0B;_ JDH@+;-6!`"GS MD5MJN;>CQN#JK*F'N!9TE[=*T#%S**Q7-21N!>5"XW0Z,6>_SL@A6CYVGG(? ME-#J=""0/P`2`P``!0D```)?#DDJR&!8,ATS&@`@````<W!E8VEA;%]F=6YC M=&EO;G-?=&5S="YC<' `L&QW%@P!#0S,_101>Z^*T.<4F'6H[1>+:K <<4M8 M#CD%3D HMH032UI:(FD@O"N007_>@1NQM;K9U)J-R52!V"=%P7AI)PYI.'5\ MV3I\,T[I)P9@S@1G#..'.B:8HQQ1BQD='H'X110#9(P[I<CS,9'WHJZ"`.XD M;J0KK\'9"1MPKOI)B'"'A]TCPO?P\/PKYUQD,44&*0R30B_:*(SCAEN)]\)* ML_CCRL0Z=?(R/.!UA=,OQ?TBL5^&N9]88Y@9AEE_) P]V&9;G+-^]=5P+*KV M%RGCZS$@:&0)14QS0FHZ."SI&7O*^(\JKR^VGY(9+6)P&/9=DU)B4-GD,\2" MWNZ<T4F;=U/6B <<@I6QZ5)ZUR1KQCH=_3=EW7V_*%U(@]? %J>-@Y3L==6K M%S/"(G=)G4?F9#2(a)VDQ(U(^R`;S&0H\.I<+:2,QB#P%8KG8KG96@.AA,<IE) MQJ\E[ JOA^W/H,%SE51+8'@20OQM%;8O, *'?\N]H,"G(R)EQ@]O'LPJB712 MSF$<<D+PN []M"_?>FY_V:XW7R^-E:I&33\F)T=.S+5YO<=$)K7+-G;9W'"! MFROP]4J3?<4DLCJH$.Z;7B;51E2.M.<U?O^4D.U 0=;X*SXS_(7%S<RV'5"J M'9;HO:-&ILQBOW=,$U#FPXD]3H6!1(!6W0'5*I-16M/M_6W-PMS2]-82*@&# M0]UMAII'=F;MQ94/7EY[]P" 6U,M;<!0O0E:_X!XB=V'P5C-YFQF@)[ $N>R M`,R/QOG1]?LQ9],"' 7C>.CP0M@6MSJW;UR^OR=&"[AO<V!:<=Z5?K+YH9^> MKO+-GRK9LV?'QO(AA\.0Z<X^ZU*(_T-U&FB0>U\FDQ,-G*^Q2D@'+<\NE&UH M'I"BA)K0=)D+BA7$YTY=3RUSYAA <!: NFHE3-J H"C*C8^.OU107C&)\-+9 M1; ZBD@+9THIO$;LQ<]=!W<KFX#T^S:@O#<//0&C+8/V7('"(RX-GJWE(*,J M?40)LFLU%"_/513GF1Y#@&\T29;].KO2W154YZK;/S\//IAP_,?X@,0]>P! "!P`` ` end

1 1

Assignment library and G++
by Josue Gomes 24 Feb '05

24 Feb '05

Hi, Take this code: #include <boost/assign/std.hpp> #include <boost/assign/list_of.hpp> #include <boost/assign/list_inserter.hpp> #include <map> #include <iostream> #include <string> using namespace std; using namespace boost::assign; const unsigned long USER = 0x0001; const unsigned long ADMINISTRATOR = 0x0004; const unsigned long ALL = USER + ADMINISTRATOR; typedef map<string, long> item_permissions_t; typedef map<string, item_permissions_t> module_permissions_t; int main() { map<string, module_permissions_t> permission_table = map_list_of ("Module1", map_list_of ("Item1", map_list_of ("Feature1", ALL) ("Feature2", ADMINISTRATOR) ) ("Item2", map_list_of ("Feature1", ALL) ("Feature2", ALL) ("Feature3", ADMINISTRATOR) ("Feature4", ADMINISTRATOR) ) ); cout << "modules: " << permission_table.size() << "\n"; cout << "items of module 'Module1': " << permission_table["Module1"].size() << "\n"; cout << "features of item 'Item2' of module 'Module1': " << permission_table["Module1"]["Item2"].size() << "\n"; cout << "permissions of feature 'Feature4' of item 'Item2' of " "module 'Module1': " << permission_table["Module1"]["Item2"]["Feature4"] << "\n"; } It compiles fine with VC 7.1. However g++ 3.3 and 3.4 (both on Linux) refuse to compile it. See the error message (excerpt): sample.cpp:36: instantiated from here /usr/include/c++/3.4/bits/stl_pair.h:90: error: call of overloaded `map(const boost::assign_detail::generic_list<std::pair<const char*, boost::assign_detail::generic_list<std::pair<const char*, long unsigned int> > > >&)' is ambiguous /usr/include/c++/3.4/bits/stl_map.h:166: note: candidates are: std::map<_Key, _Tp, _Compare, _Alloc>::map(const std::map<_Key, _Tp, _Compare, _Alloc>&) [with _Key = std::string, _Tp = item_permissions_t, _Compare = std::less<std::string>, _Alloc = std::allocator<std::pair<const std::string, item_permissions_t> >] /usr/include/c++/3.4/bits/stl_map.h:156: note: std::map<_Key, _Tp, _Compare, _Alloc>::map(const _Compare&, const typename std::_Rb_tree<_Key, std::pair<const _Key, _Tp>, std::_Select1st<std::pair<const _Key, _Tp> >, _Compare, _Alloc>::allocator_type&) [with _Key = std::string, _Tp = item_permissions_t, _Compare = std::less<std::string>, _Alloc = std::allocator<std::pair<const std::string, item_permissions_t> >] the command line is: g++-3.4 -I ../boost_1_32_0/ sample.cpp -o sample Any ideas of what is going on here? Regards, Josue Gomes

2 1

[serialization] editor archive
by Martin Slater 24 Feb '05

24 Feb '05

Hi, I've been using serialization for a while and am extremely happy with it, now I would like to utilise it to automatically populate an editor with object data. Basically I intend to write a new archive type that will serialise to / from an editor interface using the type info of each serialised item to attach suitable editor components. Has anyone done anything like this or have any ideas of problems I may run up against? cheers martin

3 4

object with external linkage in boost/tuple/detail/tuple_basic.hpp
by Michael Benfield 24 Feb '05

24 Feb '05

When I #include<boost/tuple/tuple.hpp> in multiple files and compile them with the Digital Mars compiler, its linker complains about multiple definitions of an object called ignore. The problem is in the file boost/tuple/detail/tuple_basic.hpp, which has this line: detail::swallow_assign const ignore = detail::swallow_assign(); This works when I compile with gcc or the Microsoft compiler, but it shouldn't be there, should it? I thought the only things with external linkage that should go in headers are special cases like inline functions. If I'm wrong and this is a bug in the Digital Mars compiler or linker let me know and I will go report it. Thanks, Mike Benfield

1 0

enable_if for function templates
by Agoston Bejo 23 Feb '05

23 Feb '05

Hi all, I am trying to enable only two version of a function. The caller may choose one of the two versions by specifying a template parameter. I've got two versions for the problem, both of them failing the same way. -------------------------- Version A): integral template parameter -------------------------- #include <iostream> #include <boost/utility/enable_if.hpp> #include <boost/type_traits.hpp> using namespace std; using namespace boost; template<unsigned int N, typename T> enable_if_c<N==1> f(T t) { cout << 1 << endl; } template<unsigned int N, typename T> enable_if_c<N==2> f(T t) { cout << 2 << endl; } int _tmain(int argc, _TCHAR* argv[]) { f<1>(10); // ERROR f<2>(5.5); // ERROR f<3>(7); // ERROR return 0; --- The error message on all 3 lines is: error C2668: 'f' : ambiguous call to overloaded function The compiler's "explanation" for the first one: (for the other two it is much the same except the type) could be 'boost::enable_if_c<B,T> f<1,int>(int)' with [ B=false, T=void ] or 'boost::enable_if_c<B,T> f<1,int>(int)' with [ B=true, T=void ] while trying to match the argument list '(int)' -------------------------- Version B) : type template parameter -------------------------- #include <iostream> #include <boost/utility/enable_if.hpp> #include <boost/type_traits.hpp> using namespace std; using namespace boost; struct A1 {}; struct A2 {}; template<typename U, typename T> enable_if< is_same<U, A1> > g(T t) { cout << 1 << endl; } template<typename U, typename T> enable_if< is_same<U, A2> > g(T t) { cout << 2 << endl; } int _tmain(int argc, _TCHAR* argv[]) { g<A1>(10); // ERROR g<A2>(5.5); // ERROR g<int>(7); // ERROR return 0; } ---- Error messages: error C2668: 'g' : ambiguous call to overloaded function (for all three of them) "Explanation" sample: could be 'boost::enable_if<Cond,T> g<A1,int>(int)' with [ Cond=boost::is_same<A1,A2>, T=void ] or 'boost::enable_if<Cond,T> g<A1,int>(int)' with [ Cond=boost::is_same<A1,A1>, T=void ] while trying to match the argument list '(int)' ----------------- enable_if should actually prevent the compiler from trying to compile the 'false' version, shouldn't it? Thx, Agoston

3 2

[optional] comments about none_t
by Yuval Ronen 23 Feb '05

23 Feb '05

Hi. I checked out the optional library and found it to be of great value. I have, however, a few small suggested improvements (and no, I'm not talking about the pointer/container/discriminated-union semantics debate; I read this discussion in the mail archives and I also saw the resulted library and I'm very happy with what came of it). I'm talking about the detail::none_t part. Should it really be in the detail namespace? Isn't that a little weird? The detail namespace should be "forbidden area" for the users, yet here they are offered to write code like my_optional = boost::detail::none_t(); One might argue that there's the 'none' global variable which will make the code look like my_optional = boost::none; which looks much better. I agree that it looks much better, but it still doesn't make the previous way of thinking (crating a temporary none_t instance) illegal or unsupported. It is unsupported now. And while we're at the global none variable, I have to say that the reason I first tried the temporary-none_t-instance way, is that I didn't know of 'none'. The documentation is very poor on this subject. It's only mentioned in one place in a short, unexplained sentence, and it's in the "Detailed Semantics" section which no one ever bothers to read anyway. In addition to improving the docs, I'd say that it's even better to include the boost/none.hpp header with optional.hpp so it could be easily found and reached. As I understood, the reason why this is not done now, is because some compilers (such as Borland's) have troubles with initialized data and pre-compiled headers. If this is truely the case, then I think it's easily solved. Include as follows: #ifndef BOOST_OPTIONAL_DISCLUDE_NONE #include <boost/none.hpp> #endif while the BOOST_OPTIONAL_DISCLUDE_NONE flag can be set either by the user, or automatically if a troublesome compiler is detected. If Boost.Config could automatically detect and set a BOOST_NO_INITIALIZED_DATA flag, then the optional library is left with fairly simple code. To summarize, I suggest: 1. Lift none_t from detail to boost. 2. Improve docs wrt 'none' global instance. 3. Include none.hpp with optional unless the user/compiler dislikes it. Makes any sense? Yuval

3 5

using boost::format with STLPort
by Alexey Bakhvalov 23 Feb '05

23 Feb '05

Hello, I have a problem when I try to include "boost/format.hpp" from Boost 1.32 in a project that uses STLPort library. I am using MSVC 7.1 and the compiler prints the following error: \boost\format\format_implementation.hpp(216) : error C2244: 'boost::basic_format<Ch,Tr,Alloc>::size' : unable to match function definition to an existing declaration \boost\format\format_class.hpp(58) : see declaration of 'boost::basic_format<Ch,Tr,Alloc>::size' definition 'basic_format<Ch,Tr,Alloc>::size_type boost::basic_format<Ch,Tr,Alloc>::size(void) const' existing declarations 'boost::basic_format<Ch,Tr,Alloc>::size_type boost::basic_format<Ch,Tr,Alloc>::size(void) const' If I switch back to Boost 1.31 or don't use STLPort then the problem goes away. I just wonder what can be the cause of such strange error because I can't see any difference between function's definition and declaration. Also I use many other Boost libraries and don't have this problem with either of them.

3 2

lapack bindings compiled fail with Visual C++ 7.1
by HHSU 23 Feb '05

23 Feb '05

Hi, I used VC7.1 and Boost_1.32_0 to compiled the SVD test file ( ublas_gesvd.cc) which download from http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/libs/nume… I get the following error and warring messages: d:\upload\test\ublas_gesvd.cpp(61) : warning C4267: 'argument' : conversion from 'size_t' to 'unsigned int', possible loss of data c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\boost\numeric\ublas\traits.hpp(941) : warning C4267: 'argument' : conversion from 'size_t' to 'const unsigned int', possible loss of data c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\boost\numeric\ublas\matrix_expression.hpp(4462) : see reference to class template instantiation 'boost::numeric::ublas::promote_traits<X,Y>' being compiled with [ X=boost::numeric::ublas::matrix<real_t,boost::numeric::ublas::column_major>::size_type, Y=boost::numeric::ublas::matrix<real_t,boost::numeric::ublas::column_major>::size_type ] d:\upload\test\ublas_gesvd.cpp(84) : see reference to class template instantiation 'boost::numeric::ublas::matrix_matrix_binary<E1,E2,F>' being compiled with [ E1=boost::numeric::ublas::matrix<real_t,boost::numeric::ublas::column_major>, E2=boost::numeric::ublas::matrix<real_t,boost::numeric::ublas::column_major>, F=boost::numeric::ublas::matrix_matrix_prod<real_t,real_t,boost::numeric::ublas::matrix_matrix_binary_traits<real_t,boost::numeric::ublas::matrix<real_t,boost::numeric::ublas::column_major>,real_t,boost::numeric::ublas::matrix<real_t,boost::numeric::ublas::column_major>>::promote_type> ] c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\boost\numeric\bindings\lapack\gesvd.hpp(281) : error C3861: 'assert': identifier not found, even with argument-dependent lookup d:\upload\test\ublas_gesvd.cpp(69) : see reference to function template instantiation 'int boost::numeric::bindings::lapack::gesvd<m_t,v_t,m_t,m_t,std::vector<_Ty>>(const char,const char,MatrA &,VecS &,MatrU &,MatrV &,VecW &)' being compiled with [ _Ty=real_t, MatrA=m_t, VecS=v_t, MatrU=m_t, MatrV=m_t, VecW=std::vector<real_t> ] What I am missing or doing wrong ? Bert.

1 1

boost::format bug?
by Orhun Birsoy 23 Feb '05

23 Feb '05

Hi, I am getting boost::io::too_many_args exceptions for the following line. cout << format(" %1% %3% \n") % 1 % 2 % 3 % 4 % 5; but not for this one cout << format(" %1% %5% \n") % 1 % 2 % 3 % 4 % 5; If the last argument is used in the format, I do not get the exception. Is this a bug? Thanks. Orhun Birsoy -- _____________________________________________________________ Web-based SMS services available at http://www.operamail.com. >From your mailbox to local or overseas cell phones. Powered by Outblaze

2 1

[lexical_cast]: Converting a formatted string
by maha.ramanan＠philips.com 23 Feb '05

23 Feb '05

Hi, I am quite new to the iostreams and lexical cast and hence bear with me of any lack of knowledge. I am using the lexical cast in the following manner: unsigned int data_value = boost::lexical_cast<unsigned int>("0xFF"); The above comes out with a runtime bad_lexical_cast error. I understood, by default, the streams (stringstream used by lexical cast) should be able to automatically identify the radix of the input and convert it automatically. Is my above undestanding correct? Is lexical_cast meant to be used in this situation? Thanks for your help? Ram ======================================================================================= Mahadevan Ramanan Design Technology Centre DTG - Philips Semiconductors Milbrook Industrial Estate Tel: +44 (0) 23 8031 2540 Southampton, Hants SO15 0DJ Fax: +44 (0) 23 8031 2642 UK ====================================================================================== The information contained in this message is confidential and may be legally privileged. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, dissemination, or reproduction is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

1 0

lexical_cast specializations
by Cory Nelson 22 Feb '05

22 Feb '05

How about adding some specializations to use wstringstring when given a wstring? -- Cory Nelson http://www.int64.org

1 0

RE: regex/string algorithm problem
by The Grumpiest Man You Know 22 Feb '05

22 Feb '05

Boy! You guys are SPOOKY good. I wrestle with something 'til I give up and then I go to write a report and while I formulate the words you start feeding back answers! The reason the code I sent "hangs" is because it's iterating over a zero length match. which consumes 0 characters of input per loop. I must do that once a year in any language I use, you think I'd learn huh? If I can reproduce the segfault and I can't see why it's my fault, can I post that too? Or can we skip that and have y'all start channeling me the clues now. :) Thanks again for your time. -- Blue Skies

3 3

shared_ptr: proper removal from STL Containers?
by Jeremy Hill 21 Feb '05

21 Feb '05

Greetings, I have only recently begun exploring boost, and I must say that I have found it very interesting. In particular I've been focusing on boost::shared_ptr. However, I'm not quite sure how to 'deallocate' shared_ptrs that are in a Container, such as a vector. I'd like to issue some pseudocode to help put things in perspective: class Descriptor { public: bool valid; Descriptor() : valid(true) {} } struct InvalidDesc { bool operator()(Desc_ptr &d) { return (*d).valid; } }; class Desc_broker { private: vector< boost::shared_ptr< Descriptor > > desc_list; public: //These functions are, in this order, called elsewhere: void fun_1() { <conditionally invalidate Descriptors> }; void fun_2() { <iterate through desc_list and do stuff> }; void cleanup() { desc_list.erase( remove_if(desc_list.begin(), desc_list.end(), InvalidDesc()), desc_list.end() ); } }; There is the class 'Descriptor' that is contained within a shared_ptr, which is wrapped in the 'Desc_broker' class. Once a Descriptor is invalidated, such as in fun_1() above, it is no longer needed. I'll need to get rid of invalid Descriptors before the vector is iterated through in fun_2(). However, since the shared_ptr for the invalid Descriptor will not go out of scope, to the best of my knowledge I'll need to help it along by using something along the lines of 'cleanup', which will remove all desc_ptrs whose Descriptors are invalid (via std::remove_if and the InvalidDesc predicate). However, this feels wrong to me because it seems like it is against what shared_ptrs are trying to accomplish. And, in fact, Boost agrees--I receive this on cleanup(): assertion "px != 0" failed: file "/usr/local/include/boost/shared_ptr.hpp", line 253 Aborted (core dumped) What is the correct way to remove the invalid Descriptors? Also, I apologize if this is considered the unacceptable topic "Requests for help interpreting the C++ standard." If that is the case, please tell me so that I may not offend in future posts. Thank you, Jeremy Hill

2 2

Re: problem with lambda and function<>
by Arturo_Cuebas＠bpmicro.com 21 Feb '05

21 Feb '05

In my previous post the sample code was a lot more than what what necessary to ask the question. I could have given this simpler example: #include <boost/function.hpp> #include <boost/lambda/lambda.hpp> #include <boost/lambda/bind.hpp> using namespace boost; using namespace boost::lambda; int f(void) { return 5; } int main(void) { int test = 0; (_1 = bind(&f))(test); // No compile error function<int (void)> functorized_f(&f); (_1 = functorized_f)(test); // Compile error return 0; } This is what my question really boils down to: just like naming delayed variables, is it possible to predefine and name the result of a call to bind() outside a lambda expression? /*what goes here?*/ bound_f = bind(&f); (_1 = bound_f)(test);

1 0

boost::filesystem -- handling dead symlinks
by Matthias Kaeppler 21 Feb '05

21 Feb '05

Hello, I wonder if there is any means of telling boost::filesystem::directory_iterator to skip broken symlinks. It's sort of an annoyance working with them, since operations like is_directory will throw when invoked on a broken symlink. I am keeping a vector of boost::filesystem::pathS, and as soon as I operate on a broken symlink, an exception will be thrown. I do catch it, but that doesn't really help since the program will return from the method where the exception was thrown. I would find it much more convenient to simply skip these broken files, instead of jumping out of the procedure (IMO it's not even exceptional behavior, dead symlinks are pretty common). Any idea what I can do about this? -- Matthias Kaeppler

3 4

MPL iterator category
by Philippe Mori 21 Feb '05

21 Feb '05

In C++ Template Metaprogramming book, there is the expression i::category in tables 5.1, 5.2 and 5.3 that says that the result is convertible to mpl::forward_iterator_tag, mpl::bidirectional_iterator_tag and mpl::random_access_iterator_tag respectively. Since a random access iterator is bidirectional iterator which is in turn a forward iterator, I was expecting that i::category for a bidirectional iterator would also be convertible to mpl::forward_tag which is not the case. So if an algorithm has to works differently for random-access iterator but it the same for forward and bidirectional iterator, it seems to me that I would need some extra logic to uses forward iterator algorithm if I have a bidirectional iterator as theree are no implicit conversion. In fact, in the implementation we derives from int_<n> where n is 0, 1 or 2 depending on the iterator type. Philippe

3 2

boost::normal_distribution in boost 1.32
by Roman 21 Feb '05

21 Feb '05

Hi all. I observe boost::normal_distribution always return "nan" with all RNGs whereas other distributions behave normally. I'm talking about boost 1.32 - in earlier version boost::random has different interface.

2 2