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

Compiling with Visual C++ 2005 Express Edition
by Keith Weintraub 23 Nov '05

23 Nov '05

Folks, I am having trouble compiling and building boost with Visual C++ 2005 Express Edition. It gets a lot of the job done with the command (under cygwin): bjam "-sTOOLS=vc-8_0" "-svc80_ROOT=C:\Program Files\Microsoft Visual Studio 8\VC" That directory is where my VC++ is installed. In addition the bjam script (which I treat as a black box) could not find the vsvers32.bat script which I ran by hand. I had to do that to get anything to work. The last run that I did ignored about 126 "targets" and had errors in 82 "targets". Some (maybe all, since they all scrolled by so quickly) said that windows.h could not be found. Can anyone help me with this? Thanks for your time, KW

6 5

Re: [Boost-users] program_options: wild write
by Peter Whaite 22 Nov '05

22 Nov '05

Vladimir Prus <ghost(a)cs.msu.su> wrote: > Merrill Cornish wrote: > > > graph_file is a positional parameter. So should it be added to the > > option_description list? > > Yes, how else would you specify the type of the value? > positional_options_description only specifies translation from > position on the command line to option name, the option still has to > be registered. I've added a warning to the docs. I'm sure a warning will help as that's not at all obvious in the current documentation. A comment in the example would be useful too. It took me a while for the penny to drop the first time I used this library. FWIW my (now obviously erroneous) reasoning was that a positional_options_description was just another kind of options_description, and that "input-file" was in both of them in example/program_options.cpp so it could be used as both an option and a positional argument. I only wanted it as a positional parameter, so I omitted it from the options_description. I also found myself wanting to generate a usage message like this... po::positional_options_description pd; cout << "Usage: " << progname << " [options]" << pd << endl; rather than having to loop through pd. But these are minor things. Thank you for a very useful library. --- Peter Whaite.

1 0

Re: [Boost-users] lambda and shared_ptr?
by Mark Santaniello (AMD) 22 Nov '05

22 Nov '05

> Mark Santaniello (AMD) wrote: > >>> template< typename T > > >>> boost::function<T(T)> foo( T n_ ) > >>> { > >>> //Works, but leaks n > >>> //T *n = new T( n_ ); > >>> > >>> //Doesn't work > >>> boost::shared_ptr<T> n( new T(n_) ); > >>> > >>> return ( *n += _1 ); > >> > >> I think that you need to wrap n in boost::lambda::constant: > >> > >> return *constant(n) += _1; > >> > >> Without it, *n is evaluated immediately. > >> > >>> } > >> > > > > Peter, > > > > Thanks for the reply. I must be doing something dumb, > because now I'm > > getting a build error. > > > > I think this *might* be the important part: > > /usr/include/boost/detail/is_incrementable.hpp:59: error: > no match for > > 'operator++' in > > > '++boost::detail::is_incrementable_::impl<boost::shared_ptr<int> >::x' > > Apparently, boost::detail::is_incrementable doesn't work on > your compiler; this in turn breaks boost::indirect_reference > and the return type deduction for lambda's operator*. But I > should also note that *constant(n) += _1 doesn't seem to work > even when the compiler supports is_incrementable, because for > some reason, Lambda thinks that dereferencing a const pointer > yields a const reference. > > return ret<int&>( *constant(pn) ) += _1; > > compiles for me, though. > Ahh, thanks Peter this helps a ton. Seems like gcc 4.0.2 doesn't like is_incrementable. I tried gcc 3.3.6, however, and it worked fine. I also had success with MSVC 8.0. -Mark

1 0

[iostreams] stream and ios_base::binary
by Pedro Lamarão 22 Nov '05

22 Nov '05

Is there a way to construct a boost::iostreams::stream with the ios_base::binary flag? I'd be really happier without the line-ending treatment... -- Pedro Lamarão

3 4

[serialization] Incorrect assertion in basic_binary_oprimitive?
by Zach Laine 22 Nov '05

22 Nov '05

I agree with the objection raised by the original poster. The assertion in archive/basic_binary_oprimitive.hpp should more properly be an exception. Standard library ostreams fail silently when in an error state (including std::ofstreams that fail to open a file). Writing a std::string, int, double, or any other data to a default-constructed std::ostream is a no-op. The only exception to this appears to be writing a boost::serialization archive to a std::ostream, which under some circumstances fails with an abort when "assert(os.good());" fails in archive/basic_binary_oprimitive.hpp. There is also an exception thrown based on the state of the ostream in the same function as this assertion. The user can choose to catch this if she decides that the default std::ostream failure policy (a no-op) is acceptible. By putting the assertion in there, you force the user to always have a valid, writable std::ostream, which is precisely the opposite of what the user expects from years of using std::ostreams.

1 0

Re: [Boost-users] program_options: wild write
by Merrill Cornish 22 Nov '05

22 Nov '05

Pedro, graph_file is a positional parameter. So should it be added to the option_description list? By the way, in one run in which I provided one positional parameter on the command line, the code then recognized graph_file; but claimed it was an unknown option. [sigh...] Merrill

2 1

serialization: efficient binary archive
by __PPS__ 22 Nov '05

22 Nov '05

Hello, I want to write simple binary searialization class. the serialized data should be as compact as possible, e.g. I don't want to have "serialization::archive" string etc, since most of the time I need really basic serialization performed into many separate archives: something like hunrdreds of archives that contain simple int, or string. I also don't need any versioning. These data serializations are for a short period of time (automatically removed after a few minutes), to share data between multiple processes on the same machine. Basicly, I need to serialize many key-value pairs, and then to be able to extract values by their keys. Keys are simple strings, values can be anything. Since I cannot use boost::any for value part, then I decided to go a way around. I'll have a map that maps string keys to the serialized binary string of value, and then this big map is serialized. The other process then deserializes this map and if it accesses some value it also needs to deserialize the value. I really need simple searialization, something like i:1234,s[5]:Hello for int(1234) and string("Hello") with all the numbers serialized in binary etc, without any BE/LE code - always the same machine used. I think it would be really enough for me to have serialization of numbers, strings and binary data, but I want to use boost::serialization to allow users to insert objects of their own classes in that key-value pairs. basicly, my goal is to create such class that maps string keys to any data, then all this map is serialized and some other process deserializes this map and accesses values by keys. Is there's something in serialization library you could suggest me to look at. I viewed demo_fast_archive, but I cannot find good info on creating my own archive classes. It seems that my problem would be completely solved if there were some way to serialize boost::any, in this case I would only needed to serialize std::map<std::string,boost::any> thanks

2 1

program_options: wild write
by Merrill Cornish 22 Nov '05

22 Nov '05

I'm making progess on using program_options. Using std::exception& gave me the real error message; but problems still remain. po::options_description desc("Options"); desc.add_options() ("help,h", " Display this help message.") ("version", " Display the version... .") ("limit", po::value<unsigned int>()->default_value(1), " This is the concurrency limit ...") ); // specify the single, required graph file positional parameter po::positional_options_description pd; pd.add("graph_file", 1); po::variables_map vm; po::store(po::command_line_parser(argc, argv). options(desc). positional(pd).run(), vm); po::notify(vm); //... code that references vm... I still can't get the positional parameter, but I've got other problem to research first. The options_descriptions above defines --limit as an unsigned integer with a default value of 1. It does get a default value of 1, and it will let you specify another unsigned integer value. But if you specify a non-unisgned integer (e.g., --limit=xxx or --limit=-5), then it bypasses the exception handling and calls Dr. Watson. The reported error is a wild write to unwritable memory. Any ideas how to chase this problem? Merrill

4 3

[serialization] trouble with member_saver / member_save ?
by William Kemper 22 Nov '05

22 Nov '05

In 1.33.0 split_member uses: template<class Archive, class T> struct member_saver { static void invoke( Archive & ar, const T & t, const unsigned int file_version ){ access::member_save(ar, t, file_version); } }; And member_save looks like: template<class Archive, class T> static void member_save( Archive & ar, //const T & t, T & t, const unsigned int file_version ){ t.save(ar, file_version); } So the compiler complains about converting a const T to a non const T. It's curious that the source has the const T& in member_save commented out. Is there a workaround for this? Or is it planned to be fixed in the next release?

2 1

Re: [Boost-users] lambda and shared_ptr?
by Mark Santaniello (AMD) 22 Nov '05

22 Nov '05

> > template< typename T > > > boost::function<T(T)> foo( T n_ ) > > { > > //Works, but leaks n > > //T *n = new T( n_ ); > > > > //Doesn't work > > boost::shared_ptr<T> n( new T(n_) ); > > > > return ( *n += _1 ); > > I think that you need to wrap n in boost::lambda::constant: > > return *constant(n) += _1; > > Without it, *n is evaluated immediately. > > > } > Peter, Thanks for the reply. I must be doing something dumb, because now I'm getting a build error. I think this *might* be the important part: /usr/include/boost/detail/is_incrementable.hpp:59: error: no match for 'operator++' in '++boost::detail::is_incrementable_::impl<boost::shared_ptr<int> >::x' The 799B source file is here: http://mark.santaniello.net/files/hof2.cpp The 19KB error message is here: http://mark.santaniello.net/files/err.txt :) -Mark

2 1