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

[date_time] nanosec resolution compile problem
by Christopher Lux 02 Jun '07

02 Jun '07

Hi, i am trying to use date_time with nanosec resolution for the fractional seconds part. So i define BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG in my projects using date_time. Now i get the compiler warning below. I found out that the problem in the said function is that in boost/date_time/date_duration.hpp the struct duration_traits_adapted defines the int_type as long and not as int_64t. The warning is generated in the add_time_duration() funtion of the split_timedate_system class. So i imagine that this is a bigger issue, because if the durations get bigger than what a long can hold (what will happen fast with nanosec resolution) the problems will come. Can this be resolved with an small fix to the duration_traits_adapted struct or have there to be more fixes? Here the compiler warning (VS.net 2005 SP1) boost\boost/date_time/time_system_split.hpp(189) : warning C4244: 'initializing' : conversion from '__int64' to 'long', possible loss of data D:\_devel\schism_wc_x86\schism\projects\cmake\..\..\ext\inc\boost\boost/date_time/time_system_split.hpp(180) : while compiling class template member function 'boost::posix_time::simple_time_rep boost::date_time::split_timedate_system<config>::add_time_duration(const boost::posix_time::simple_time_rep &,boost::posix_time::time_duration)' with [ config=boost::posix_time::posix_time_system_config ] D:\_devel\schism_wc_x86\schism\projects\cmake\..\..\ext\inc\boost\boost/date_time/time.hpp(52) : see reference to class template instantiation 'boost::date_time::split_timedate_system<config>' being compiled with [ config=boost::posix_time::posix_time_system_config ] D:\_devel\schism_wc_x86\schism\projects\cmake\..\..\ext\inc\boost\boost/date_time/posix_time/ptime.hpp(32) : see reference to class template instantiation 'boost::date_time::base_time<T,time_system>' being compiled with [ T=boost::posix_time::ptime, time_system=boost::posix_time::posix_time_system ] -chris -- Christopher Lux | | Bauhaus University Weimar | Faculty of Media - Virtual Reality Systems Group

2 2

datetime istream and ostream operators don't match
by Lothar Werzinger 02 Jun '07

02 Jun '07

compile the attached cppunit test with -DHIDE_BOOST_DATETIME_BUGS=false to see where datetime ostream operator produces an output that the datetime istream operator can not digest. Lothar -- Lothar Werzinger Dipl.-Ing. Univ. framework & platform architect Tradescape Inc. 111 West St. John Street, Suite 200 San Jose, Ca 95113 email: lothar(a)tradescape.biz web: http://www.tradescape.biz

2 1

[Boost.Test 1.34] Multiple instances of unit_test_log_t singleton
by Kolya 01 Jun '07

01 Jun '07

Hi, All! I am using Boost.Test library in my own application and I have included boost/test/unit_test.hpp in many my cpp-files. When I used boost version 1.33.1 all works fine. But in version 1.34 I have following compiler error: file1.obj : error LNK2005: "class unit_test_log_t::boost::unit_test_log_t & boost::unit_test::`anonymous namespace'::unit_test_log" (?unit_test_log@?A0xa35d3712@unit_test@boost@@3AAVunit_test_log_t@23@A) already defined in file2.obj After including boost/test/unit_test.hpp class unit_test_log has multiple instances. See boost/test/unit_test_log.hpp for details: BOOST_TEST_SINGLETON_INST( unit_test_log ) It means that following code will be included in many cpp-files! namespace { unit_test_log_t & inst = unit_test_log_t::instance(); } When I replace BOOST_TEST_SINGLETON_INST( unit_test_log ) in boost/test/unit_test_log.hpp with namespace {extern unit_test_log_t & unit_test_log;} and in one of my cpp-files add: namespace boost { namespace unit_test { BOOST_TEST_SINGLETON_INST( unit_test_log ) } } all works fine May be I do not understand something? Is there any legal workaround from this situation? I do not like touch boost core files by myself. Thank you! VC++ 7.1, boost 1.34, xp sp2.

4 6

[TR1] Configuration macros
by Scott Meyers 01 Jun '07

01 Jun '07

I'm having trouble understanding the information at http://www.boost.org/doc/html/boost_tr1/config.html, and having already spent a fair amount of time running test programs and pouring over the output of the preprocessor for various compilers, I'm hoping that somebody in the know can just explain things to me. My goal is simple: use Boost.TR1 such that if my compiler ships with a library with support for whatever TR1 component I want to use, I'll get that native support. But if the library that ships with the compiler lacks support for the TR1 component I need, I want to fall back on the Boost implementation, if there is one. And I want to uniformly refer to TR1 components as if they are in the namespace std::tr1. My reading of the above-referenced page leads me to believe that this is the behavior I'm supposed to get by default. And it's consistent with the tests I've performed using VC8 and g++ 4.1. But then I read this: > The configuration macros used by each TR1 component are documented in each library section (and all together in the Boost.Config documentation), but defining BOOST_HAS_TR1 will turn on native TR1 support for everything (if your standard library has it), which can act as a convenient shortcut. This kind of suggests that I should define BOOST_HAS_TR1. Should I? So far I have not. And then I read this: > Boost.TR1 does not currently enable gcc's native TR1 implementation as this is currently in an early stage of development. However, you may choose to do so by defining BOOST_HAS_GCC_TR1. This pretty clearly suggests that I should define BOOST_HAS_GCC_TR1. Should I? So far, I have. I've also found that unless I define it like this, > #ifdef __GNUC__ > #define BOOST_HAS_GCC_TR1 > #endif compilation with VC8 fails, which I find kind of strange. Here's an error I get: > D:\C++\Boost\Current\boost/tr1/type_traits.hpp(11): fatal error C1083: Cannot open include file: 'type_traits': No such file or dire > ctory Why should defining BOOST_HAS_GCC_TR1 have any effect on a VC8 compilation? All clarification about the correct settings of TR1 configuration macros for at least VC8 and g++ 4.1 would be much appreciated. Thanks, Scott

3 5

Bind & Memory Leakage
by Sudhir Parikh 01 Jun '07

01 Jun '07

BoundsChecker is reporting a memory leak for every 'bind' call. I am using the threadpool includes, v 0.2.3, with "libboost_thread-vc71-mt-gd-1_33_1.lib", MSVC 7.1. Any help is appreciated. The usage is similar to the following working example: void task(int param1) { // performs some task printf("%d : Param1 : %d\n", GetCurrentThreadId(), param1); Sleep(1000); } void foo() { boost::threadpool::pool tp(5); // Threadpool with 5 threads while (1) { for (int i = 0; i < 10; i++) { // Seems like there is memory allocation which is not // deallocated after returning from the function call. tp.schedule(boost::bind(task, i)); } tp.wait(); // wait to finish off the remaining tasks Sleep(5000); // sleep for 5 seconds } }

2 1

[Unit Test] default FPC_STRONG limtations when checking close to 0.
by Chris Fairles 01 Jun '07

01 Jun '07

After wondering why my BOOST_CHECK_CLOSE(some_number_close_to_zero, 0.0) hadn't been working, I found that the default comparison type is FPC_STRONG which means the ration between the abs val of the difference and BOTH values must be < tolerance but this doesn't turn out to be true (running through what safe_fpt_division outputs atm ... difference between 0.0{0} and 0.0 std::numeric_limits<double>::epsilon(){-2.2204460492503131e-16} exceeds 0.01% It should work using FPC_WEAK but I can't find a way through the test_tools to easily change this. I have three solutions at this time. 1) Use BOOST_CHECK_SMALL. However, I have code that loops through matrix indicies like: for (int j = 0; j < matrix.col; j++) for (int i = 0; i < matrix.row; i++) BOOST_CHECK_CLOSE(matrix(i,j), data(i,j), tolerance); I'm going to have to use an if statement for the special case where I'm testing against 0 and it doesn't use the tolerance anyway so the test is completely different. Theres another number to determine "how small" the number should be. 2) Use check_is_close explicitly and change the default comparison type to FPC_WEAK. This means going outside the nice auto-unit-test and test-tools framework which although I'm fine with, other programmers writing test cases on my team might not be. 3) Define my own macro to simplify solution 2. Something along the lines of: CHECK_IS_CLOSE_WEAK(x,y,t) { check_is_close(x ,y,t, FPC_WEAK); } Are there any other recommended solutions?

2 3

[smart_ptr] shared_ptr and shared_array of const
by Tim Day 31 May '07

31 May '07

The ability to assign a shared_ptr<T> to shared_ptr<const T> is useful for controlling which parts of software have write access to the shared object, so I'm surprised that while e.g boost::shared_ptr<int> sp(new int); boost::shared_ptr<const int> csp=sp; compiles fine, and prohibits e.g *csp=0;, the equivalent for shared_array doesn't compile: boost::shared_array<int> sa(new int[10]); boost::shared_array<const int> csa=sa; // not allowed [The gcc 4.1.2 error is "conversion from ‘boost::shared_array<int>’ to non-scalar type ‘boost::shared_array<const int>’ requested"] I'm looking to prevent modification of elements of csa of course. The obvious alternative is to use a shared_ptr to a std::vector of course: boost::shared_ptr<std::vector<int> > sv(new std::vector<int>(10)); boost::shared_ptr<const std::vector<int> > csv=sv; // fine // (*csv)[0]=0; // prevented by const, as intended However, it's unclear to me exactly why the shared_array of const doesn't work as expected. Am I missing some necessary detail to make it work, is shared_array simply less featureful (the header is certainly shorter) or is there some reason it can't work ? Thanks for any explanation Tim [I'm using boost 1.33.1]

1 0

Error compiling Boost.Python library on Solaris
by Belousov, Arkadiy, GCM 31 May '07

31 May '07

Hello all! I have a compilation error with Boost 1.34.0, Sun Workshop 11 compiler. Compiling Python library, I get "libs/python/src/object/class.cpp", line 458: Error: Overloading ambiguity between "boost::python::api::getattr<boost::python::scope, char[11], boost::python::str>(const boost::python::scope&, const char(&)[11], const boost::python::str&)" and "boost::python::api::getattr(const boost::python::api::object&, const char*, const boost::python::api::object&)". The code in question is object module_prefix() { return object( PyObject_IsInstance(scope().ptr(), upcast<PyObject>(&PyModule_Type)) ? object(scope().attr("__name__")) : api::getattr(scope(), "__module__", str()) <<===== ); } Of course, casting the string constant to (const char*) solves the problem, even though I realize it's not a boost-like solution. The rest of 1.34 compiles perfectly for me (thanks are in order - excellent job!). The exact version of the compiler is $ CC -V CC: Sun C++ 5.8 Patch 121017-07 2006/11/02 Sincerely, Arkadiy Belousov ----------------------------------------- ******************************************************************* * This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorized to retain, read, copy or disseminate this message or any part of it. ******************************************************************* *

2 1

unified documentation
by Rob Agar 31 May '07

31 May '07

hi all It seems to me (as a newcomer) that the one thing boost needs is documentation in a unified structure. I'm thinking of something along the lines of the MS .NET class library or the Java class references. The existing documentation for the libraries I have used so far are very hard to navigate - they seem to be more aimed at standards committees than end users. As an end user, the first thing I need is an easily navigated tree just listing all the namepaces, functions, classes, typedefs etc. As a start does anyone have a doxygen config file for generating a simple function list and class hierarchy? cheers Rob Agar

6 12

1_33_1 VC8 crash in program_options::cmdline
by Søren Holstebroe 31 May '07

31 May '07

This problem was found in boost 1.33.1 using VC++ 8.0. I haven't tried 1.34.0, but the cmdline code seems unchanged. from cmdline.cpp -------------------------------------- std::vector<option> cmdline::parse_long_option(std::vector<string>& args) { vector<option> result; const std::string& tok = args[0]; if (tok.size() >= 3 && tok[0] == '-' && tok[1] == '-') { string name, adjacent; string::size_type p = tok.find('='); if (p != tok.npos) { name = tok.substr(2, p-2); adjacent = tok.substr(p+1); if (adjacent.empty()) throw invalid_command_line_syntax(name, invalid_command_line_syntax::empty_adjacent_parameter); } else { name = tok.substr(2); } option opt; opt.string_key = name; if (!adjacent.empty()) opt.value.push_back(adjacent); opt.original_tokens.push_back(tok); result.push_back(opt); args.erase(args.begin()); } return result; } -------------------------------------- The line args.erase(args.begin()); crashes in MS VC++ 8.0 in release optimized configuration, though it works fine in debug mode. Could this be a compiler problem with loop unrolling and the const std::string& tok = args[0]; reference ? As seen in the stack trace, std::vector::erase tries to copy a "Bad Ptr" string and obviously fails miserably. Interestingly the program hangs in std::_Distance2 if I provide no command line arguments (it looks like a very long bad pointer loop, not an infinite loop). I might try recompiling boost with different compile options, but it is quite time consuming to experiment with. best regards Søren Holstebroe Code: namespace po = boost::program_options; po::options_description desc("Allowed options"); desc.add_options() ("help", "produce help message") ; po::variables_map vm; po::store(po::parse_command_line(argc, argv, desc), vm); po::notify(vm); Stack trace: > msvcr80.dll!memcpy(unsigned char * dst=0x00c20048, unsigned char * src=0xabababab, unsigned long count=458755) Line 188 Asm msvcr80.dll!memcpy_s(void * dst=0x00c20048, unsigned int sizeInBytes=458767, const void * src=0xabababab, unsigned int count=458755) Line 67 + 0xc bytes C msvcp80.dll!std::char_traits<char>::_Copy_s(char * _First1=0x00c20048, unsigned int _Size_in_bytes=458767, const char * _First2=0xabababab, unsigned int _Count=458755) Line 576 C++ msvcp80.dll!std::basic_string<char,std::char_traits<char>,std::allocator<char> >::assign(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & _Right=<Bad Ptr>, unsigned int _Roff=0, unsigned int _Count=4294967295) Line 1059 + 0x2c bytes C++ msvcp80.dll!std::basic_string<char,std::char_traits<char>,std::allocator<char> >::operator=(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & _Right=<Bad Ptr>) Line 1044 C++ PS.Vision.Console.exe!std::_Copy_opt<std::basic_string<char,std::char_traits<char>,std::allocator<char> > *,std::basic_string<char,std::char_traits<char>,std::allocator<char> > *>() + 0x4a bytes C++ PS.Vision.Console.exe!std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >::erase() + 0x2d bytes C++ PS.Vision.Console.exe!boost::program_options::detail::cmdline::parse_long_option() + 0x28e bytes C++ PS.Vision.Console.exe!boost::_mfi::mf1<std::vector<boost::program_options::basic_option<char>,std::allocator<boost::program_options::basic_option<char> > >,boost::program_options::detail::cmdline,std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > &>::operator()() + 0x40 bytes C++ PS.Vision.Console.exe!boost::_bi::list2<boost::_bi::value<boost::program_options::detail::cmdline *>,boost::arg<1> >::operator()<std::vector<boost::program_options::basic_option<char>,std::allocator<boost::program_options::basic_option<char> > >,boost::_mfi::mf1<std::vector<boost::program_options::basic_option<char>,std::allocator<boost::program_options::basic_option<char> > >,boost::program_options::detail::cmdline,std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > &>,boost::_bi::list1<std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > &> >() + 0x22 bytes C++ PS.Vision.Console.exe!boost::_bi::bind_t<std::vector<boost::program_options::basic_option<char>,std::allocator<boost::program_options::basic_option<char> > >,boost::_mfi::mf1<std::vector<boost::program_options::basic_option<char>,std::allocator<boost::program_options::basic_option<char> > >,boost::program_options::detail::cmdline,std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > &>,boost::_bi::list2<boost::_bi::value<boost::program_options::detail::cmdline *>,boost::arg<1> > >::operator()<std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > >() + 0x2d bytes C++ PS.Vision.Console.exe!boost::detail::function::function_obj_invoker1<boost::_bi::bind_t<std::vector<boost::program_options::basic_option<char>,std::allocator<boost::program_options::basic_option<char> > >,boost::_mfi::mf1<std::vector<boost::program_options::basic_option<char>,std::allocator<boost::program_options::basic_option<char> > >,boost::program_options::detail::cmdline,std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > &>,boost::_bi::list2<boost::_bi::value<boost::program_options::detail::cmdline *>,boost::arg<1> > >,std::vector<boost::program_options::basic_option<char>,std::allocator<boost::program_options::basic_option<char> > >,std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > &>::invoke() + 0x1d bytes C++ PS.Vision.Console.exe!boost::function1<std::vector<boost::program_options::basic_option<char>,std::allocator<boost::program_options::basic_option<char> > >,std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > &,std::allocator<boost::function_base> >::operator()() + 0x5b bytes C++ PS.Vision.Console.exe!boost::program_options::detail::cmdline::run() + 0x371 bytes C++ PS.Vision.Console.exe!boost::program_options::basic_command_line_parser<wchar_t>::run() Line 102 + 0x12 bytes C++ PS.Vision.Console.exe!boost::program_options::parse_command_line<wchar_t>(int argc=5, wchar_t * * argv=0x003b5718, const boost::program_options::options_description & desc={...}, int style=0, boost::function1<std::pair<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::basic_string<char,std::char_traits<char>,std::allocator<char> > const &,std::allocator<boost::function_base> > ext={...}) Line 119 + 0x9d bytes C++

1 0