May 2008 - Boost - lists.preview.boost.org

[date_time] Documentation Fix (time_period)
by Bryan Petty 30 Jun '08

30 Jun '08

Hi, Attached is a quick patch to switch the placement of the time_period(ptime,ptime) and time_period(ptime,time_duration) examples to their correct locations. Regards, Bryan Petty

2 2

boost::result_of and C++03
by Eric Niebler 30 Jun '08

30 Jun '08

My experience developing Proto has taught me a hard lesson about the ResultOf protocol that I thought I would share. Maybe someone here can tell me if/where I've gone wrong. There's a part of Proto (proto::call<>) that takes function objects, passes arguments to them and returns the result. I use result_of to compute the return type. Fine. Proto defines a function object, make_foo, whose behavior depends on the lvalue/rvalue-ness of its arguments. So for instance: // Return type of make_foo when passed a rvalue // int and an lvalue float: result_of< make_foo( int, float & ) >::type Like a good citizen, I've written make_foo's function call operator to recognize reference_wrapped and non-const-ref arguments as representing lvalues and all others as rvalues. (This is because C++03 doesn't have rvalue references.) Fine. Now, given some function type F (which may or may not be make_foo) and some arguments a0...an (which may or may not be lvalues), how do I invoke F? The strictly correct thing to do would be to wrap lvalues in reference_wrappers before passing them to F. If I don't, make_foo will do the wrong thing. However, Proto needs to work with function objects in the wild, very few of which do the right thing with reference_wrapped arguments, in my experience. What to do? I don't know. This business of needing to reference_wrap objects to get correct lvalue/rvalue semantics is a deal-breaker for Proto transforms. If I needed to wrap each lvalue argument before forwarding it to the next transform, and unpack each argument within each tranform, it would: a) Make writing transforms extremely tedious. b) Kill compile times with lots of unnecessary mpl::if_, is_reference, reference_wrapper and unwrap_reference instantiations. For these reasons, I've decided that Proto's transforms will use a different function object protocol. None of that will be visible from the outside. Transforms will still look like TR1-style function objects. But transforms will provide a separate interface for internal consumption that doesn't have this rvalue/lvalue problem. The problem, as I see it, stems from the fact that the return type calculation is separated from the function invocation. struct blarg { template<typename This, typename Arg> struct result< This( Arg ) > { // OK, if Arg is a reference, then it's an lvalue! }; template<typename Arg> typename result< make_foo( ??? ) >::type operator()( Arg const & arg ) { // whoops, I don't know here if arg is an lvalue or rvalue } }; If function objects were instead written like this ... struct blarg { template<typename Arg> struct impl { // OK, if Arg is a reference, it's an lvalue typedef ... result_type; result_type operator()(typename add_const_ref<Arg>::type arg) { // The right thing can happen here. } }; }; ... the problem goes away. -- Eric Niebler Boost Consulting www.boost-consulting.com

13 65

[1.36.0] Release schedule set
by Beman Dawes 23 Jun '08

23 Jun '08

The 1.36.0 release schedule has been set. For details, see http://svn.boost.org/trac/boost/wiki/ReleaseSchedule The milestones are: *Note well: Changes must always be committed to trunk and be stable on trunk regression testing before being merged to branches/release.* * *May, 2008:* branches/release opens for all stable changes, including bug fixes, major library upgrades, and, with permission, new libraries. Breaking changes should be coordinated with libraries affected. * *June 19, 2008:* branches/release closes for new libraries and major upgrades or breaking changes to existing libraries. Still open for bug fixes and minor changes to all libraries. * *July 3, 2008:* branches/release closes for routine minor changes and fixes. Still open for serious problem fixes. * *July 10, 2008:* branches/release closes for all library changes except when specific permission given by release manager(s). * *July 17, 2008 (sooner if possible):* Beta 1 target date. Further betas and/or release candidates as feedback dictates. * *July 31, 2008:* Release ship date. --Beman

18 44

Workaround for a msvc 7.1 & 8.0 bug surfaced in the boost 1.35 release part II
by Okko Willeboordse 19 Jun '08

19 Jun '08

Hi all, Boost 1.35 triggers msvc 7.1 & 8.0 to export a local type named CRITICAL_SECTION declared in detail/lwm_win32_cs.hpp into the global namespace. This causes 'ambiguous identifier' compiler errors upon attempts to use (the global Windows type) CRITICAL_SECTION. Please refer to; [boost.pool] Workaround for a msvc 7.1 & 8.0 bug surfaced in the boost 1.35 release 4/8/2008 3:52 PM and; Changeset link: http://svn.boost.org/trac/boost/changeset/44480 Above fixes problems caused by usage of CRITICAL_SECTION in Boost itself namely in pool/detail/mutex.hpp. However usage of CRITICAL_SECTION outside Boost still gives problems. For example; #include <boost/archive/text_iarchive.hpp> typedef int CRITICAL_SECTION; CRITICAL_SECTION cs; or (real live case); #include <boost/archive/text_iarchive.hpp> #include <atlcore.h> Results in 'ambiguous identifier' compiler errors. I attached a patch of detail/lwm_win32_cs.hpp that fixes this. Note that; 1. a real solution to the problem would be to alter Boost such that the VS compiler bug is no longer triggered. 2. more local types, other then CRITICAL_SECTION, may have the same problem. Kind regards, Okko Willeboordse Index: lwm_win32_cs.hpp =================================================================== --- lwm_win32_cs.hpp (revision 45417) +++ lwm_win32_cs.hpp (working copy) @@ -17,8 +17,15 @@ // http://www.boost.org/LICENSE_1_0.txt) // +// 'CRITICAL_SECTION' type has been renamed here due to a MSVC 7.0, 7.1 & 8.0 +// bug causing this local type to be exported into the global namespace, later +// causing 'ambiguous identifier' compiler errors if anyone attempts to use the +// global Windows CRITICAL_SECTION type without using its fully qualified name +// '::CRITICAL_SECTION'. + #ifdef BOOST_USE_WINDOWS_H # include <windows.h> +typedef CRITICAL_SECTION CRITICAL_SECTION_RENAMED_TO_AVOID_VS_BUG; #endif namespace boost @@ -29,7 +36,7 @@ #ifndef BOOST_USE_WINDOWS_H -struct CRITICAL_SECTION +struct CRITICAL_SECTION_RENAMED_TO_AVOID_VS_BUG { struct critical_section_debug * DebugInfo; long LockCount; @@ -43,10 +50,10 @@ #endif }; -extern "C" __declspec(dllimport) void __stdcall InitializeCriticalSection(CRITICAL_SECTION *); -extern "C" __declspec(dllimport) void __stdcall EnterCriticalSection(CRITICAL_SECTION *); -extern "C" __declspec(dllimport) void __stdcall LeaveCriticalSection(CRITICAL_SECTION *); -extern "C" __declspec(dllimport) void __stdcall DeleteCriticalSection(CRITICAL_SECTION *); +extern "C" __declspec(dllimport) void __stdcall InitializeCriticalSection(CRITICAL_SECTION_RENAMED_TO_AVOID_VS_BUG *); +extern "C" __declspec(dllimport) void __stdcall EnterCriticalSection(CRITICAL_SECTION_RENAMED_TO_AVOID_VS_BUG *); +extern "C" __declspec(dllimport) void __stdcall LeaveCriticalSection(CRITICAL_SECTION_RENAMED_TO_AVOID_VS_BUG *); +extern "C" __declspec(dllimport) void __stdcall DeleteCriticalSection(CRITICAL_SECTION_RENAMED_TO_AVOID_VS_BUG *); #endif // #ifndef BOOST_USE_WINDOWS_H @@ -54,7 +61,7 @@ { private: - CRITICAL_SECTION cs_; + CRITICAL_SECTION_RENAMED_TO_AVOID_VS_BUG cs_; lightweight_mutex(lightweight_mutex const &); lightweight_mutex & operator=(lightweight_mutex const &);

7 13

[Units] A first step to ease the usage of Units' quantities inside of functors created with the Lambda library
by Torsten Mähne 18 Jun '08

18 Jun '08

Hello, I'm pleased to see so much activity in the development of Boost.Units recently. I try to apply it myself in some code to model physical systems. There it helps me a lot to ensure the correct use of the model parameters inside the model equations and to ensure the correct composition of components to a system model. Certain component behaviour, I would like to parametrize for each component instance by passing a functor describing, e.g., a signal waveform or a non-linear relation between to quantities. I therefore tried to combine Boost.Units with Boost.Lambda and Boost.Function. I noticed that currently Units and Lambda use two independent systems of trait classes to determine the return type of algebraic operations like +, -, *, /. This requires to litter the lambda expression with a lot of ret<return_type>(...) function calls to construct a functor containing boost::units::quantity<U, V> instances. However, the trait classes used by Units and Lambda are very similar, so I created as a first solution a header file <lambda.hpp> (see attachment), which extends Boost.Lambda's return type reduction system through partial specialization to use Boost.Units' trait classes in case boost::unit::quantity<U,V> are involved in operator[+|-|*|/]() calls. Maybe it's also useful for others and could even become part of Boost.Units after some further improvements. However, there are some open issues: - Can some of the partial specializations be dropped? - Is there a need to add other specializations (e.g, for boost::units::unit<Dim, System, Enable>)? - Is there a way to work around boost::lambda:bind's limitation concerning the binding of overloaded functions? The required static_cast to the function pointer (referring, e.g., a function from boost/units/cmath.hpp) is tedious. The attached small test program <units_with_lambda_test.cpp> demonstrates its usage and tedious bind issue, for which I haven't found a solution yet. Boost.Lambda requires calls to functions to be postponed using boost::lambda::bind(), so that they are executed not only once upon functor creation but at each functor call. Bind has the unfortunate limitation that it cannot resolve calls to overloaded functions. Thus, each time a call to an overloaded function (e.g., all functions defined in <boost/units/cmath.hpp>) is made, a lengthy static_cast<return_type (*)(argument_type)>(function_name) is needed for the first bind argument to help the compiler to find the overloaded function, which can accept the function arguments passed by the other bind arguments. Could this be somehow avoided or at least the syntax simplified? I'm thinking of, e.g., a templated function or (more ugly) a preprocessor macro adding the required static_cast based on some trait class or typeof. I'm looking forward to your feedback. Best regards, Torsten Maehne .DEFAULT_GOAL := all # Install locations of Boost 1.35 and Boost.Units BOOSTROOT := /opt/boost_1_35_0 BOOSTUNITS := /opt/boost_units CPPFLAGS := -I$(BOOSTROOT)/boost/tr1/tr1 -I$(BOOSTROOT) -I$(BOOSTUNITS) CXXFLAGS := -g -Wall % : %.o $(CXX) $(LDFLAGS) $^ $(LOADLIBES) $(LDLIBS) -o $@ | c++filt .PHONY : all clean all : units_with_lambda_test units_with_lambda_test : units_with_lambda_test.o units_with_lambda_test.o : units_with_lambda_test.cpp lambda.hpp clean : -rm units_with_lambda_test *.o *~ semantic.cache

4 17

uniform_real: min_arg < max_arg
by Neal Becker 17 Jun '08

17 Jun '08

Can we please change assert(min_arg < max_arg); to assert (min_arg <= max_arg) ? Otherwise, breaks on corner case.

2 3

The need for a 1.35.1 release
by James Talbut 15 Jun '08

15 Jun '08

As a user I am concerned about the lack of a 1.35.1 release. We cannot use 1.35 because it contains a bug. When 1.36 is released it will fix this bug, but it will also inevitably introduce new bugs some of which may also be show-stoppers for us. Which means we have to wait for 1.37, and so on... We need to have bugfix releases for released version of boost that do not change anything that is not absolutely necessary to fix bugs. Without this we are going to have to manually patch bugs as fixes come out, which makes a mockery of the whole idea of having boost releases (and makes boost much less appealing as a library). Jim P Consider the environment. Please don't print this email. ________________________________________________________________________ This e-mail, and any attachment, is confidential. If you have received it in error, do not use or disclose the information in any way, notify me immediately, and please delete it from your system. ________________________________________________________________________

5 5

CORBA iimplementation for Boost interest?
by Jonathan Biggar 13 Jun '08

13 Jun '08

I've been working on a C++ CORBA implementation for a long time. I've considered making it open source in the past, but I hadn't seen the exact niche for it to fill. Now that Boost 1.35 is out, including ASIO and the new Threads implementation, I'm considering retargeting my implementation to only use boost libraries for underlying services. I'd be quite happy to contribute my implementation to boost, if there's enough interest for me to proceed. So, what do you all think? -- Jon Biggar Floorboard Software jon(a)floorboard.com jon(a)biggar.org

11 55

Bug in iterator_range when NDEBUG not defined but boost asserts are enabled
by John Reid 11 Jun '08

11 Jun '08

iterator_range.hpp defines is_singular() if NDEBUG is not defined but it calls is_singular through the BOOST_ASSERT macro. Unfortunately it is possible to enable BOOST_ASSERT and have NDEBUG defined which leads to a compilation error. To see this compile the iterator_range.cpp example included with the library with the following defines: gcc -DBOOST_ENABLE_ASSERT_HANDLER -I/usr/local/src/boost-trunk/ -DNDEBUG -c iterator_range.cpp John.

4 3

Property Tree Library status?
by Jonathan Biggar 08 Jun '08

08 Jun '08

Is this finally going to make it into a release? 1.36? -- Jon Biggar Floorboard Software jon(a)floorboard.com jon(a)biggar.org

3 4