- Boost-users - lists.boost.org

Re: [Boost-users] Compiling with Visual C++ 2005 Express Edition
by Keith Weintraub 23 Nov '05

23 Nov '05

Folks, Thanks for all the kind help. I solved my problem by doing something similar to what Mr Kozicki suggested. Only I did it on the command line. All works fine now. Thanks again, KW

1 0

Newbie build problem
by Rob Marsden 23 Nov '05

23 Nov '05

I too am having similar problems to Keith Weintraub with regard to failed and skipped targets. I applied the suggested addition of the Platform SDK, to the include paths, but in the process I had to reboot my machine (for unrelated reasons). Since then, I get virtually nothing actually built (quite a leap backwards really :-) The symptom I get is related to expansion of the compiler name, as the messages are all of the type: '/Zm800' is not recognised as an internal command... etc or '/nologo' is not ... The environment is Win2K with VC6 and the Intel compiler v8.0 (9 on order). The command line is bjam "-sTOOLS=intel-win32" install Now there's a certain familiarity about this problem, but at my age, memory doesn't serve me all that well. So what's the answer? -- Rob Marsden Gistix (Northern) Limited

1 0

boost.thread problem
by magazine.lihuiba 23 Nov '05

23 Nov '05

I'm a newbie to boost, and I'm trying to use boost.thread together with STLport in VC6. When I compile my project in debug version, I get a error message saying "fatal error C1189: #error : 'Build options aren't compatible with pre-built libraries'", the error code is in auto_link.hpp in boost directory: # if (defined(__SGI_STL_PORT) || defined(_STLPORT_VERSION)) && (defined(_STLP_OWN_IOSTREAMS) || defined(__STL_OWN_IOSTREAMS)) # if defined(_DEBUG) && (defined(__STL_DEBUG) || defined(_STLP_DEBUG)) # define BOOST_LIB_RT_OPT "-gdp" # elif defined(_DEBUG) # define BOOST_LIB_RT_OPT "-gdp" # pragma message("warning: STLPort debug versions are built with /D_STLP_DEBUG=1") # error "Build options aren't compatible with pre-built libraries" # else # define BOOST_LIB_RT_OPT "-p" # endif But I don't get this error message in release version. What can I do?

2 1

[program_options] Finding out the type of the options
by Giuseppe Vacanti 23 Nov '05

23 Nov '05

Hello, I'm using program_options, and I want to be able to learn what the option type is by manipulating an options_description object. As I illustrate in the example below (boost 1.33), I can do this if the option has been given a default value. Could anyone suggest a wasy to this for options without a default? The story behind this question is that I would like to be able to build a simple GUI parameter dialog based on the options_description, and I want to map different types to different widgets. Thanks, Giuseppe #include <boost/program_options.hpp> #include <boost/filesystem/path.hpp> #include <iostream> #include <vector> #include <string> #include <algorithm> #include <iterator> template<typename T> bool type_is (const boost::any & v) { return v.type() == typeid(T); } struct MyType { MyType() : x(0) {} MyType(double d) : x(d) {} double x; }; std::ostream & operator<<(std::ostream & os, const MyType & mt) { os << mt.x; return os; } std::istream & operator>>(std::istream & is, MyType & mt) { is >> mt.x; return is; } using namespace std; namespace po = boost::program_options; int main(int ac, char * av[]) { typedef vector<string> type; po::options_description desc1("Allowed options 1"); desc1.add_options() ("switch", po::value<bool>(), " a boolean switch") ("numbers", po::value<type>(), "a list of numbers") ("number", po::value<double>()->default_value(42), "the number") ; po::options_description desc2("Allowed options 2"); desc2.add_options() ("mytype", po::value<MyType>()->default_value(MyType(123.4)), "my type") ; po::options_description cmdlinedesc; cmdlinedesc.add(desc1).add(desc2); po::variables_map vm; po::store(po::parse_command_line(ac, av, cmdlinedesc), vm); po::notify(vm); typedef std::vector< boost::shared_ptr<po::option_description> > VOD; const VOD & pk = cmdlinedesc.options(); for(VOD::const_iterator K = pk.begin(); K != pk.end(); ++K){ cout << " [ " << (*K)->long_name() << " - " << (*K)->description() << " ] "; boost::shared_ptr< const po::value_semantic > sem = (*K)->semantic(); boost::any default_store; bool has_default = sem->apply_default(default_store); if(has_default) cout << " has default "; if(type_is<double>(default_store)) cout << " = (double) " << boost::any_cast<double>(default_store); if(type_is<bool>(default_store)) cout << " = (bool) " << boost::any_cast<bool>(default_store); if(type_is<MyType>(default_store)){ MyType x = boost::any_cast<MyType>(default_store); cout << " = (MyType) " << x; } cout << endl; } }

2 3

progress_timer, incorrect timing
by __PPS__ 23 Nov '05

23 Nov '05

I got strange results with boost::progress_timer - it shows timings like 1.45s whereas it took about 15 sec. to complete a routine. It used to work ok, but I have no idea why it just doesn't work anymore! I use freebsd 4.11 and clocks_per_sec is defined 128. sysconf(_SC_CLK_TCK) also returns 128, but clock counter is not correct completely. I wrote simple test class, to see what's wrong: struct Timer { clock_t t; time_t tt; Timer() : t(clock()), tt(time(0)){} ~Timer(){ std::cout << "Elapsed interval: " << (static_cast<double>(clock() -t))/CLOCKS_PER_SEC << "s " << (time(0)-tt) << "s\n" ; } }; this is the output: Elapsed interval: 1.52344s 33s 1.52 s <- output by boost::progress_timer. so, you may see that measured time is completely wrong. I rewrote it with microtime(...) and it works correctly now. any ideas what's wrong, why clock() doesn't work anymore? Wouldn't that be a good idea to use microtime for unices? thanks

3 4

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