September 2013 - Boost - lists.preview.boost.org

smart_ptr doesn't work when built with gcc on AIX
by Florent Guiliani 03 Sep '13

03 Sep '13

Hi, The Boost 1.54 smart_ptr atomic API code only supports the IBM xlC compiler under AIX. The attached patch make it also support the gcc compiler. I wanted to fill in a ticket for it on https://svn.boost.org/trac/boost/newticket but for some reason the ticket was classified as a spam by Trac. Anyone could help me here? One issue is the _sync*() APIs doesn't work when built optimized with GCC 4.8.0 on AIX 6.1 and 7.1 (and so the patch assume they don't work with all versions of GCC on AIX), so the patch undefine BOOST_SP_HAS_SYNC to prevent using those APIs. Another issue is the builtins.h file that Boost uses is missing, because it is installed as part of xlC. Under gcc, this patch will define assembly versions of the 2 builtins that are used in sp_counted_base_aix.hpp. Hope this gets through, -- Florent

1 0

[git] b2 headers not producing headers
by Ahmed Charles 02 Sep '13

02 Sep '13

I've tried following the instructions here: https://svn.boost.org/trac/boost/wiki/TryModBoost The 'b2 headers' command doesn't see to actually produce a boost directory. Is this supposed to work or is it just too soon?

3 2

[smart_ptr] Proposal to extract intrusive_ref_counter from Boost.Log
by Andrey Semashev 01 Sep '13

01 Sep '13

Hi, I'd like to move intrusive_ref_counter class from Boost.Log to Boost.SmartPtr. The class is intended to be used as a base class for a user's class that is intended to be used with intrusive_ptr. The class implements a reference counter and the related intrusive_ptr_add_ref/intrusive_ptr_release operations, so the user doesn't have to do that himself. Usage example: class my_class : public intrusive_ref_counter { }; intrusive_ptr< my_class > p = new my_class(); Besides just simplifying intrusive_ptr usage, the base class can be used as a sort of "void" as in shared_ptr< void >. I.e. intrusive_ptr< intrusive_ref_counter > can refer to object of any class that follows this protocol. Implementation: boost/log/utility/intrusive_ref_counter.hpp

5 10

Re: [boost] [utility] Proposal to extract some components from Boost.Log
by Daryle Walker 01 Sep '13

01 Sep '13

I don’t think you need a “constexpr_if.” You can unconditionally put BOOST_CONSTEXPR in the definition. This will unconditionally add “constexpr” to the member operator (for C++11 systems), which will be ignored if the compiler determines that the attached function (or a particular call) is disqualified from being used in constant expressions. So any extra preprocessor work, or a variant macro, is unnecessary. Sent from Windows Mail From: Andrey Semashev Sent: ‎Sunday‎, ‎September‎ ‎01‎, ‎2013 ‎4‎:‎40‎ ‎AM To: boost(a)lists.boost.org On Sunday 01 September 2013 03:27:06 Daryle Walker wrote: > > Date: Wed, 28 Aug 2013 12:14:51 +0400 > > From: andrey.semashev(a)gmail.com > > > > 1. BOOST_EXPLICIT_OPERATOR_BOOL() macro for defining explicit operator > > bool() for a class. > > a. It isn't marked "constexpr." I can add that myself before using > "BOOST_EXPLICIT_OPERATOR_BOOL" in "boost/rational.hpp," but what happens if > someone corrects it in "explicit_operator_bool.hpp"? Will the (temporary) > double definition cause an error? Well, since there isn't a constexpr_if or something, I don't see a way to add it to BOOST_EXPLICIT_OPERATOR_BOOL. I could add BOOST_EXPLICIT_OPERATOR_BOOL_PP(pre, post), which would add pre() and post() before and after the operator signature. For example:

3 4

[multimethods] Proposal: Open Multi-Methods
by Jean-Louis Leroy 01 Sep '13

01 Sep '13

Hi, I am working on library that pretty much implements what Pirkelbauer, Solodkyy and Stroustrup describe in their paper "Open Multi-Methods for C++" - although there are some divergences. I have posted it on GitHub: https://github.com/jll63/multimethods. Please examine the files in the "examples" directory to get an idea of how to use it. Salient features are: * syntax: is relatively uncluttered. There are no limitations on the number of virtual arguments. Virtual and non-virtual arguments can be arbitrarily mixed. Multiple inheritance is supported, with some limitations - see below. * speed: close to a virtual function call when the hierarchies involved in the virtual arguments collaborate with the library. Calling a method that does nothing, with a single virtual argument in a single inheritance hierarchy is 33% slower than the equivalent virtual function call. The difference becomes unnoticeable if the functions perform a few simple maths operations. See tests/benchmarks.cpp. * size: the dispatch table is constructed in terms of class groups. This results, most of the time, in a table devoid of redundancies. The size is bounded by the product of the number of specializers - not classes - in each dimension. * support for "foreign" class hierarchies: the library can be used without modifications to existing classes, at the cost of lower performance. Collaborating and foreign arguments can be freely mixed. Performance is still quite good, see the benchmarks. * next: a pointer to the next most specialized method is available inside method specializations - see examples/next.cpp. Alternatively, it is possible to call a specialization directly. Current limitations are: * restrictions on hierarchy: the classes involved in a method call must have a single root. Repeated inheritance is not supported. Multiple inheritance is supported, provided that the two conditions above are respected. * no overloading: multi-methods are implemented as constexpr function objects. This does not allow for overloading. This restriction can be easily side-stepped by wrapping multi-methods with different names in a set of overloaded functions. I know how to make multi-methods functions instead of objects, at the cost of a slightly less nice syntax for specializers. This is open to discussion. Besides, the library differs from Stroustrup et al's paper on the following points: * a specializer specializes only one multi-method: what would "next" mean otherwise? What would its static type be? * pure multi-methods are allowed: if called, an exception is thrown. This seems a better choice given that most of the time the declared virtual arguments will be abstract classes anyway. The library is essentially feature complete (if anything ever is). I am now going to work on the documentation, a build system, some clean up and compatibility (I tested it only with g++ 4.7.2 only so far). Is there interest in the Boost community for this stuff? If yes, I will adapt it to the guidelines and submit it for formal review. Of course, suggestions are welcome. Thank you for your time, Jean-Louis Leroy

5 10

[thread] MinGW/gcc compile error in thread.cpp
by Emil Dotchevski 01 Sep '13

01 Sep '13

Building the trunk version, I get this on MinGW: gcc.compile.c++ ..\..\..\bin.v2\libs\thread\build\gcc-mingw-4.7.2\debug\link-sta tic\threading-multi\win32\thread.o ..\..\..\libs\thread\src\win32\thread.cpp: In member function 'bool boost::threa d::start_thread_noexcept()': ..\..\..\libs\thread\src\win32\thread.cpp:238:9: error: reference to 'uintptr_t' is ambiguous In file included from c:\mingw\bin\../lib/gcc/mingw32/4.7.2/include/stdint.h:3:0 , from c:\mingw\bin\../lib/gcc/mingw32/4.7.2/../../../../include/ wchar.h:479, from c:\mingw\bin\../lib/gcc/mingw32/4.7.2/include/c++/cwchar:4 6, from c:\mingw\bin\../lib/gcc/mingw32/4.7.2/include/c++/bits/pos types.h:42, from c:\mingw\bin\../lib/gcc/mingw32/4.7.2/include/c++/bits/cha r_traits.h:42, from c:\mingw\bin\../lib/gcc/mingw32/4.7.2/include/c++/string:4 2, from ..\..\../boost/date_time/c_time.hpp:18, from ..\..\../boost/date_time/time_clock.hpp:16, from ..\..\../boost/thread/thread_time.hpp:9, from ..\..\../boost/thread/win32/thread_data.hpp:10, from ..\..\../boost/thread/thread_only.hpp:15, from ..\..\..\libs\thread\src\win32\thread.cpp:17: Emil

3 2