- Boost - lists.boost.org

[thread][1.35.0] Updated win32 condition variable implementation
by Anthony Williams 21 Apr '08

21 Apr '08

Hi all, Apologies to those who have been experiencing problems using boost.thread condition variables on Windows. I have checked in a new tentative fix to SVN trunk, and would be grateful if people could put it through its paces. Thank you for your patience, Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

1 0

svn trac of "array" component
by Chris Weed 21 Apr '08

21 Apr '08

Hi, I wanted to add a trac request for code to serialize boost::array, but "array" does not seem to be a component choice. I am going to choose "Other" instead. Chris

2 2

Re: [boost] shared_mutex deadlocks?
by Peter Dimov 21 Apr '08

21 Apr '08

>> How often, on what platform? > > Every time, on a dual core Pentium D running XP64. The program is compiled > as 32 bit with MSVC 7.1. It looks like a livelock rather than a deadlock, > since the program keeps spinning its wheels at 100% but never completes. > The writer thread is probably either blocked or starved. This happens on > another (quad core) machine too for which I don't know the specs at the > moment. The other box is XP32 w/ Q6600. Another interesting tidbit is that if I move the focus from the cmd window in which the test is running, it completes. Go figure. The writer thread is likely being starved, no idea why or how.

4 3

Boost.Filesystem: No complete API documentation available?
by Jens Seidel 21 Apr '08

21 Apr '08

Hi, I tried using Boost.Filesystem to remove some files. The tutorial http://www.boost.org/doc/libs/1_35_0/libs/filesystem/doc/index.htm mentions remove_all() but I really failed to find it's documentation. Also the "Using the Reference Documentation" entry in the right box of this page is a non existing link. PS: The tutorial contains also the following error: " else if ( itr->leaf() == file_name ) // see below" "The expression itr->path().leaf() == file_name, in the line commented // see below, " Please note that "itr->path().leaf()" is not the same as "itr->leaf()" so that's a minor error! Jens

1 0

[spirit] warnings for vc8 in trunk
by Thorsten Ottosen 21 Apr '08

21 Apr '08

Hi, I get al lot of these warnings: D:\boost\trunk\boost/spirit/core.hpp(13) : warning C4083: expected 'string'; found identifier 'warning' fromt this code: #if defined(_MSC_VER) || defined(__BORLANDC__) || defined(__DMC__) # pragma message (warning "This header is deprecated. Please use: boost/spirit/include/core.hpp") #elif defined(__GNUC__) || defined(__HP_aCC) || defined(__SUNPRO_CC) || defined(__IBMCPP__) # warning "This header is deprecated. Please use: boost/spirit/include/core.hpp" #endif The problem is due to the "warning" before the text. I don't know if removing this breaks some of the other compilers. Btw, do we have BOOST_WARNING( "foo" ) yet, or would it be an idea to add it? best regards -Thorsten

2 2

Disabling compiler warnings in tests (was Filesystem bug report)
by John Maddock 21 Apr '08

21 Apr '08

Folks, There is now a new Boost.Config header: <boost/config/warning_disable.hpp> That selectively disables some compiler warnings that are hard or impossible to get rid of otherwise. Docs are here: http://svn.boost.org/svn/boost/trunk/libs/config/doc/html/boost_config/guid… This also fixes the problems that Boost.Filesystem had trying to disable these, the following patch removes the #defines, and uses the new header to silence the warnings, I've tested this with VC++ 7.1, 8 and 9 and Intel 10.1. Beman: let me know if you want me to commit. Enjoy! John. Index: test/fstream_test.cpp =================================================================== --- test/fstream_test.cpp (revision 44538) +++ test/fstream_test.cpp (working copy) @@ -11,8 +11,7 @@ // See http://msdn.microsoft.com/msdnmag/issues/05/05/SafeCandC/default.aspx // But at least in VC++ 8.0 betas, their own libraries use the problem // practices. So turn off the warnings. -#define _CRT_SECURE_NO_DEPRECATE -#define _SCL_SECURE_NO_DEPRECATE +#include <boost/config/warning_disable.hpp> #include <boost/filesystem/fstream.hpp> #include <boost/filesystem/operations.hpp> Index: test/operations_test.cpp =================================================================== --- test/operations_test.cpp (revision 44538) +++ test/operations_test.cpp (working copy) @@ -11,9 +11,7 @@ // See http://msdn.microsoft.com/msdnmag/issues/05/05/SafeCandC/default.aspx // But at least in VC++ 8.0 betas, their own libraries use the problem // practices. So turn off the warnings. -#define _CRT_SECURE_NO_DEPRECATE -#define _SCL_SECURE_NO_DEPRECATE - +#include <boost/config/warning_disable.hpp> #include <boost/filesystem/operations.hpp> #include <boost/filesystem/convenience.hpp> #include <boost/cerrno.hpp> Index: test/wide_test.cpp =================================================================== --- test/wide_test.cpp (revision 44538) +++ test/wide_test.cpp (working copy) @@ -12,8 +12,7 @@ // See http://msdn.microsoft.com/msdnmag/issues/05/05/SafeCandC/default.aspx // But at least in VC++ 8.0 betas, their own libraries use the problem // practices. So turn off the warnings. -#define _CRT_SECURE_NO_DEPRECATE -#define _SCL_SECURE_NO_DEPRECATE +#include <boost/config/warning_disable.hpp> #include <boost/filesystem/config.hpp> # ifdef BOOST_FILESYSTEM_NARROW_ONLY Index: test/convenience_test.cpp =================================================================== --- test/convenience_test.cpp (revision 44538) +++ test/convenience_test.cpp (working copy) @@ -12,8 +12,6 @@ // See http://msdn.microsoft.com/msdnmag/issues/05/05/SafeCandC/default.aspx // But at least in VC++ 8.0 betas, their own libraries use the problem // practices. So turn off the warnings. -#define _CRT_SECURE_NO_DEPRECATE -#define _SCL_SECURE_NO_DEPRECATE #include <boost/filesystem/convenience.hpp> namespace fs = boost::filesystem;

3 3

[egg] Review (at last)
by Giovanni Piero Deretta 20 Apr '08

20 Apr '08

[ sorry for the delay, it was general election time here in Italy and I had to return home for voting ] - What is your evaluation of the design? Good. I think that the overall structure is pretty good (see the thread between me and the author). I did have reserves on some details, but the author tried to clarify most of my doubts. I still have some problems with some minor parts: * nestN: I still do not understand how this works. It certainly isn't more readable than bind expressions. It should dropped from egg, redesigned or simply relegated as an implementation detail. * Pipable functions: I think that the pipability details in egg are too convoluted. The Pipable and Ambi concepts are a little fuzzy, and the latter badly needs a better name. Personally I think that the '|' operator should perform functional composition (and treat non callable objects as if they were stubs), but I do not think that this view is popular. Most uses of the pipe operator for pipelines are similar to the usage in egg. * Most higher order functions and builders in egg can be used in pure type expressions using result_of without nee to provide the runtime counterpart. This is very useful if your functions are stateless, but I think that using the result_of syntax plus the static_ for this purpose is not very intuitive. I would prefer an approach with pure mpl meta-functions. Most of the quirks of egg (like the MajorFunctionObject concept, which is simply PolymorphicFunctionObject, except that it works with lambda), could be fixed with helps from other boost libraries: Lambda should be result_of compatible, both using result_of to deduce result types of user function objects and also using the result<> protocol for its own function objects. Also it would be great if both boost.bind and boost.lambda closures where default constructible (to a singular value maybe?) and, in the case of lambda, assignable (which would eliminate the need for the 'regular' wrapper. - What is your evaluation of the implementation? I didn't specifically take a look at it. I know that the author took great pains to make it work on as many compilers as possible (and workarounding more than one compiler bug) - What is your evaluation of the documentation? I think that the documentation is the only major problem of the library. IMHO one of the biggest (if not the biggest) selling point of Boost is the high quality of its documentation. Egg documentation is definitely not on par. In particular: * The quick start section reads simply as a showoff of some of the features of the library. It doesn't really explain anything. All the magic is still hidden. Also it covers only some part of the library and the examples are pretty arcane. It really need to show real life use cases and give a step by step explanation of all the features used. * The reference documentation is too formal. It is very hard to understand the formalism used, (and the lack of a true tutorial doesn't help of course). There is too much use of (obscure) examples and 'valid expressions', and often a clear explanation in English of what a function does is lacking. * It shows that the author is not an English speaker, but I think that many native speakers in the boost community can lend an hand here - What is your evaluation of the potential usefulness of the library? Very useful, at least if you take a functional approach to C++ and need polymorphic function object. I think that it would work very well when used with libraries like Fusion, Spirit, Proto and of course, Lambda that make great use of polymorphic function objects. - Did you try to use the library? Not as much as I wanted. I run the test suite and played around with the examples. - With what compiler? # g++ -v Target: i486-Linux-gnu Configured with: ../src/configure Linux gnu Thread model: posix gcc version 4.3.0 20070414 (experimental) - Did you have any problems? Most of the test suite compiled even if with many warnings (mostly due to "type qualifiers ignored on function return type"). Few tests ICEd the compiler. I think that the cause is that this compiler is very recent and egg hasn't been tested with it yet or maybe because it is an experimental snapshot of gcc. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? An in-depth study of the documentation. I didn't study the implementation directly, the author explain a good part of it to me. - Are you knowledgeable about the problem domain? Yes, I have written a library somewhat similar to egg. - Please always state in your review, whether you think the library should be accepted as a Boost library! Yes, but only after a mini review of the documentation only. I believe that the author will be able to come up with an excellent documentation. - Final comments Unfortunately I think that with so few reviews (just mine for now?), the library will have an hard time getting into Boost at this time. Probably the author didn't do a good job at selling it, even if many expressed interest in the past. If the library were to be rejected, I think that the author should resubmit a just a subset of it for inclusion, which would have a far greater chance to be appreciated and evaluated in a short time. This subset, IMHO, should concentrate on stateless function objects and should at least contain: * 'poly' which is a very convenient way to write polymorphic function * 'compose', 'curryN' and 'lazy' especially if, in addition to the higher order functions, the corresponding mpl metafunctions are provided to build polymorphic function objects types (without passing via result_of). * 'always', 'identity', and 'apply' are generally useful and simple enough that can go in the "basic package". Other advanced features, like pipability and infix notation (I like this one!) could then be evaluated once the basic functionality has been sold :). So should more hard-core functional capabilities like memoization and the fix point combinator. Support for static initialization of function objects could also come in a second time.

4 5

Egg Review ends today
by dan marsden 20 Apr '08

20 Apr '08

The review of the Egg library by Shunsuke Sogame ends today. If anybody is still considering doing a review, please do still submit it, even if it is a few days late. It will take a short while for me to summarise the discussion during the review period. The review result will be posted shortly. Thanks Dan Marsden Review Manager __________________________________________________________ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html

1 0

[testing] summary of supported platforms?
by Neal Becker 20 Apr '08

20 Apr '08

Where can I find a test matrix showing which platforms are working with which boost versions?

1 0

[TR1] Test failures with VC9 + MS TR1
by Richard Webb 20 Apr '08

20 Apr '08

I've run a set of regression tests against Trunk with VC9 and the release MS TR1. Results are @ http://beta.boost.org/development/tests/trunk/developer/tr1.html, under the RW_WinXP_VC runner. A couple of observations: 1) The test_regex\std_test_regex tests are failing because basic_regex doesnt have an 'empty' member. However, the TR1 spec doesnt seem to say that it should? 2) The test file @ "libs/config/test/has_tr1_regex_fail.cpp" says: #ifndef BOOST_HAS_TR1_ARRAY #include "boost_has_tr1_regex.ipp" Shouldnt that be #ifndef BOOST_HAS_TR1_REGEX ? As far as the other failures go: some of them are 'by design' (e.g. is_base_of) due to MS following the current proposed spec rather than sticking to the TR1 draft, but others i'm not sure about (e.g. result_of). Anyone got any thoughts? Thanks, Richard Webb

2 8