- Boost - lists.boost.org

[date_time] CodeWarrior fixes.
by Rene Rivera 07 May '05

07 May '05

I put in some fixes to clear out some of the CodeWarrior regressions. Only four types of problems still exist: 1. There are DLL tests that use std::locale, directly or indirectly I don't know, but they should be marked as expected-to-fail. 2. There are tests that fail because boost.serialization lib fails to build. I'll eventually get to checking why that doesn't build. 3. There are two tests that now compile, but fail at runtime with an access violation. From previous experience it looks like accessing a vtable method through a NULL pointer. The tests are the two *_time_input_facet. 4. There's an unexplained compiler confusion at: boost\date_time\date_parsing.hpp:262: data type is incomplete Possibly the compiler is trying to instantiate too early? Don't really know. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

2 1

[Test] Thread-safety
by Cliff Green 07 May '05

07 May '05

Silly me - I should have looked in the Boost.Test Open Issues page a couple of days ago instead of wasting my time trying to solve some multi-threading problems in my own code. So a couple of enhancement requests (for Gennadiy, or appropriate person): 1. Please state clearly in the Boost.Test documentation that it is not thread-safe. I looked all through the pages (both the current release and the 1.31 release) but the only place I find mention of thread-unsafety is in the Open Issues page. The FAQ page would also be a good place to mention Boost.Test thread-unsafety, besides the main page (and places like Usage Recommendations, Examples, Compilation, etc). 2. Please consider adding thread-safeness to the Boost.Test libraries. I know this is not a simple request, and there may be other priorities ... but many of my (and my team's) unit tests are multi-threaded, and it's a shame to not be able to use Boost.Test (or even know which, if any, parts are thread-safe). It's a nice testing framework, IMO. Note that I don't need the whole library itself to be threaded, just to be able to do things like BOOST_MESSAGE and BOOST_EQUAL within my own testing threads. (I'll offer whatever help I can provide, within the constraints of my available time.) Many thanks! Cliff

4 4

Re: [boost] BOOST_FOREACH review results
by brangdon＠cix.compulink.co.uk 07 May '05

07 May '05

In-Reply-To: <989aceac050505060373e68a1(a)mail.gmail.com> caleb.epstein(a)gmail.com (Caleb Epstein) wrote (abridged): > > What about the name? Shouldn't it be "BOOST_FOR_EACH"? > > Why? Because of the distinct English words? Yes. And for consistency with other C++ macros, algorithms and keywords. I've argued at greater length in the other thread. -- Dave Harris, Nottingham, UK.

5 5

Re: [boost] Singleton Review: GCC compiler errors
by Jason Hise 06 May '05

06 May '05

Sorry about the duplicate messages, thunderbird seemed to be having a problem. Hoping it's fixed now. Jason Hise wrote: > Tom Brinkman wrote: > >> Was the "singleton" library tested on GCC. I'm getting many compiler >> errors on 3.34. > > It was a while back, but many changes have been made since then. I'll > see if I can track down a copy of gcc to try compiling with it myself. Actually, now that I'm looking into it it appears that Dev C++ uses a port of GCC by default, and I have successfully tested the latest version with Dev C++, getting no warnings or errors. What error messages are you getting? -Jason

3 2

[test] PATCH: putenv usage incorrect
by Caleb Epstein 06 May '05

06 May '05

http://tinyurl.com/72sj8 This test is failing on numerous platforms, some for the fact that "putenv" takes a non-const char* (Linux, Solaris, perhaps others). Attached is a patch for environment.ipp which changes it to use the setenv function on non-Windows systems. I believe this is a POSIX standard function (via BSD). I think this cleans up the code a bit, removing the raising of getenv/putenv into namespace std, when they are I think clearly non-std functions. -- Caleb Epstein caleb dot epstein at gmail dot com

3 6

[property_map] test program fix.
by John Maddock 06 May '05

06 May '05

The following fix gets the property_map test that's currently failing with several high-quality compilers, building OK (at least with vc7.1, I can't test with MWCW, but that compiler has the same issue with the existing test so it should fix it). Is this OK to commit? John. diff -r1.1 dynamic_properties_test.cpp 110c110 < BOOST_CHECK(get<std::string>("nada",props,std::string("3.14")) == "pi"); --- > BOOST_CHECK(get("nada",props,std::string("3.14")) == "pi");

1 0

[Integer] Mac OS X: WCHAR_MIN != std::numeric_limits<wchar_t>::min()
by Douglas Gregor 06 May '05

06 May '05

The title says it all: the Mac OS X system headers are inconsistent about the minimum value of a wchar_t. The C++ <limits> header has it right, but the definition of WCHAR_MIN in <cwchar>/<wchar.h> is wrong (0). If there are no complains, I'm going to commit the following patch. I don't believe this will affect CodeWarrior on the Mac, but I can't test against it. Index: integer_traits.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/integer_traits.hpp,v retrieving revision 1.26 diff -u -r1.26 integer_traits.hpp --- integer_traits.hpp 17 Dec 2004 11:56:15 -0000 1.26 +++ integer_traits.hpp 6 May 2005 15:46:36 -0000 @@ -88,7 +88,9 @@ template<> class integer_traits<wchar_t> : public std::numeric_limits<wchar_t>, -#if defined(WCHAR_MIN) && defined(WCHAR_MAX) + // Don't trust WCHAR_MIN and WCHAR_MAX with Mac OS X's native + // library: they are wrong! +#if defined(WCHAR_MIN) && defined(WCHAR_MAX) && !defined(__APPLE__) public detail::integer_traits_base<wchar_t, WCHAR_MIN, WCHAR_MAX> #elif defined(__BORLANDC__) || defined(__CYGWIN__) || defined(__MINGW32__) || (defined(__BEOS__) && defined(__GNUC__)) // No WCHAR_MIN and WCHAR_MAX, whar_t is short and unsigned: Doug

1 0

building boost
by Stefan Seefeld 06 May '05

06 May '05

I'm using some of the recent features of boost, and so I updated regularly from cvs and recompile. However, as was noted before, a simple 'bjam' will take a *lot* of time, and consume a *lot* of disk space. Right now I'm seeing almost 900 MB in my boost tree and that doesn't even count all the space taken by boost once 'bjam install' has finished. I'd really like to see an option to instruct boost.build only to produce one set of libraries, such as release-multithread-shared (falling back to static if shared isn't available). I don't care how such an option would be spelled, and whether that would become the default build target or not. But the current situation is quite wastefull, IMO. Thanks, Stefan

2 2

[program_option] allow_unregistered now works
by Vladimir Prus 06 May '05

06 May '05

Since this was the most requested change for program_options, I though I'd post specific announcement. I've committed a change that finally makes command_line_parser::allow_unregistered to work as expected. Assuming you get command line like: --foo=10 --bar=15 --biz 5 -cd -d10 and registered options are "foo" and "-c", where "-c" takes no value, parsing that command line will give you the following list of options: ("foo", "10") ("bar", "15") * ("biz", ) * ("5") (positional) ("-c", ) ("-d", ) * ("-d", "10) * The 'option' instances corresponding to option marked with '*' will have 'unregistered' member set to true. With that information it's possible to: 1. Collect all unregistered option as process them separately. 2. Construct a new command line from unregistered options and pass it to some application. In the above example, reconstructed command like would be --bar=15 --biz 5 -d -d10 There are some notes of interest. First, the option class don't keep the original tokens it was created from. The unregistered option can technically arrive from user-provided 'additional parser' where 'original tokens' are not even present. Second, for 'sticky' short options, like '-cd' above, the library can break them in parts. Again, in example we get: ("-c", ) ("-d", ) * The 'c' letter is recognized, and the 'd' letter is not. I find this behaviour better than marking the entire '-cd' as unrecognised. Finally, the new functionality might not work nice with long options that start with a single dash (allow_long_disguise style option): -foo will be considered as short option '-f' with value 'oo', and never as long option 'foo'. Feedback is appreciated! I was also asked for 'allow_unregistered' support for config file. I agree this might be good, but given that config file never supported it in any form, it's clearly a new feature, and will have to wait till 1.33 is released. - Volodya

3 3

[policy_ptr]std_ptrs.hpp's include target missing & incomplete shared_ptr emulation
by Larry Evans 06 May '05

06 May '05

The file: std_ptrs.hpp contains: #include "policy/boost.hpp" yet there's no policy/boost.hpp. However, there is: boost_policies.hpp However, in that file, the shared_storage class, contains: detail::shared_count count_; IOW, count_, unlike that in shared_ptr, contains no information about the type of pointee_; hence, I can't understand how policy_ptr's smart_ptr<...>, can emulate boost's shared_ptr with existing policies. What have I missed?

2 3