October 2012 - Boost - lists.preview.boost.org

[thread] call_once doesn't call even once
by Kim Barrett 11 Oct '12

11 Oct '12

In boost 1.52.0 beta1 In boost/thread/pthread/once.hpp, near the head of the file, is the following conditional snippet: #ifdef SIG_ATOMIC_MAX typedef sig_atomic_t uintmax_atomic_t; ... #else ... #endif Well, sig_atomic_t may be a signed type, and in fact on the Linux system I'm testing on it is a typedef for int [suse12.1, but I suspect it doesn't really matter.] POSIX says "Possibly volatile-qualified integer type ...". This led to boost::call_once never calling the function, because there is a comparison in call_once (epoch<this_thread_epoch) where I'm seeing values of 0 and -2 respectively for those variables, that doesn't go in the expected direction when uintmax_atomic_t is a signed type rather than the expected unsigned type. I bet there are other places that get confused by this being an unexpectedly signed type. I'm working around this to continue my testing of 1.52beta1 by commenting out the offending conditional code and just using the code in the #else clause. The relevant code is new code, introduced since boost 1.51. This is a serious regression that should be a blocker for the 1.52 release. I've filed a bug for this: https://svn.boost.org/trac/boost/ticket/7499

2 1

[coroutine] new versions
by Oliver Kowalke 11 Oct '12

11 Oct '12

I've uploaded two re-factored versions - I think most of the suggestions from the review are implemented (namespace is not corrected and documentation not updated yet). 1.) http://ok73.ok.funpic.de/boost-coroutine-self.zip 2.) http://ok73.ok.funpic.de/boost-coroutine-coro.zip Version 1) requires that coroutine-fn has only one argument == coroutine<>::self_t. Other arguments are accessed via coroutine<>::self_t::get< int >() and results via coroutine<>::get(). interface provides input/output iterators. typedef coroutine< int( int, int> > coro_t; int fn( coro_t::self_t & c) { int x = c.get< 0 >(); int y = c.get< 1 >(); c.yield( x +y); ... } coro_t coro( fn); int res = c( 3, 7).get(); Version 2) requires that coroutine-fn has only one argument too == coroutine<> with inverted signature. Other arguments are access via coroutine<>::get(). interface provides input/output iterators. typedef coroutine< int( int, int> > coro_t; int fn( coroutine< tuple< int, int >( int) & c) { int x = c.get().get< 0 >(); int y = c.get().get< 1 >(); c( x +y); ... } coro_t coro( fn); int res = c( 3, 7).get(); Both implementations are not optimized - I think we should get a small and clean interface first. Comments? regards, Oliver

5 19

[preprocessor] Variadics suggestion
by Kitten, Nicholas 11 Oct '12

11 Oct '12

Hi Folks, First of all, I'd like to say "thank you" to Edward Diener and Paul Mensonides for incorporating variadics support into Boost.Preprocessor, which has been on my wishlist for a long time. In fact, I wanted it badly enough that I've been using my own slightly modified version of the library assuming variadics for a while now, and I was interested to see what a cross-platform version would look like (mine was only tested on MSVC). I think the chosen approach of converting variadics to non-variadics is probably superior to the breaking algorithm changes I made in my own version, and I would humbly suggest a few more additions in the same spirit. The reason I chose to use variadics in the first place was to simplify the user interface for the common case of manipulating what I'll call a "variadic sequence," (a series of concatenated tuples), which I wanted to look similar to the following: #define FILTER_PARAMETERS (A, int, 3)\ (B, float, 2.0f)\ (C, const char*, "Howdy!") Of course, without variadics you need either a set of macros for each tuple size, or else double parenthesis around each tuple, which becomes even more burdensome when users are also required to parenthesize inner arguments, leading to gems like this one: #define FILTER_PARAMETERS ((A, (TypeConverter<double, float>), (TypeConverter<double,float>())) My solution admitting the preferred format was to replace most private SEQ_*(X) macros with SEQ_*(...), which also required modifying SEQ_ELEM() and SEQ_HEAD() to return (X) instead of X. However, it occurs to me now that a conversion function to go from variadic to regular sequences would've been easier to implement and backwards compatible; see the attached file, which I've tested in basic cases on MSVC 10 and gcc-4.3.4. The usage would be: #define SEQ (a,b,c)(1,2,3,4) BOOST_PP_VARIADIC_SEQ_TO_SEQ( SEQ ) // expands to ((a,b,c))((1,2,3,4)) I'm submitting this because I couldn't find a way to use some combination of TUPLE/VARIADICS and SEQ transformations to do the same thing succinctly, but if I'm just missing something, please let me know. Next, I would suggest having a documented IS_EMPTY(...) function for detecting an empty variadic list. Since is_empty.hpp already exists for single arguments (though undocumented), I would guess the variadic version would look quite similar. My own (MSVC) version is attached. Finally, I would suggest using the preceding IS_EMPTY(...) function to allow VARIADIC_SIZE(...) to return 0, i.e. something along the lines of: # define BOOST_PP_VARIADIC_SIZE(...) BOOST_PP_IIF( BOOST_PP_IS_EMPTY(__VA_ARGS__), 0, BOOST_PP_VARIADIC_SIZE_I( __VA_ARGS__ ) ) where BOOST_PP_VARIADIC_SIZE_I is the current definition of BOOST_PP_VARIADIC_SIZE. Thanks, -Nick Kitten Software Engineer Center for Video Understanding Excellence ObjectVideo, Inc.

9 29

[GIL] interleaved_ptr as part of API?
by Mateusz Loskot 11 Oct '12

11 Oct '12

Hi, I wonder, why the definitions of interleaved_ptr [1] and and interleaved_ref [2] are provided as examples, instead of included as part of the Boost.GIL API? IMO, these make useful general-purpose utility and it could be easily copied into <boost/gil/utilities.hpp>, couldn't it? Or, into official set of Boost.GIL extensions, at least. [1] http://www.boost.org/doc/libs/release/libs/gil/example/interleaved_ptr.hpp [2] http://www.boost.org/doc/libs/release/libs/gil/example/interleaved_ref.hpp Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 3

[GIL] interleaved_ptr not advances correctly
by Mateusz Loskot 11 Oct '12

11 Oct '12

Hi, Recently, I suggested [1] to include interleaved_ptr as part of Boost.GIL API. Unfortunately, I have been experienced problems while using interleaved_ptr. I posted Christian with a small code example and brief testing suggests interleaved_ptr does not advance correctly, what leads to images corruption. I assumed using interleaved_ptr would be a nice way to avoid reinterpret_cast when attaching raw bytes buffer into image views. Despite the cast is perfectly fine, it potentially raises red alert questions (not uncommon already, here or on StackOverflow). The simple test is to iterate over pixels and rewrite from input array (vector bitmap) to output array (vector bitmapOut) using views created in two ways: 1) cast to pixel type pointer 2) using interleaved_ptr Here are two images of what I get generated into bitmapOut array: Case 1) gives correct output http://www.flickr.com/photos/mloskot/8074130396/ Case 2) gives incorrect output http://www.flickr.com/photos/mloskot/8074130218/ Here is code [2] of the sample test: (there is no load_image() provided as it would bloat the example with too specific details) /// BEGIN /////////////////////////////////////////////////////////////////////////////////////////////////// // How to use Boost.GIL views attached to bytes array with interleaved_ptr, // versus view constructed with cast to pixel type ////////////////////////////////////////////////////////////////////////////////////////////////////// std::size_t w = 512; std::size_t h = 256; std::size_t sizeRow = 1536; // 24 bits per pixel, Windows DIB std::size_t sizeImage = sizeRow * h; std::vector<unsigned char> bitmap(sizeImage); std::vector<unsigned char> bitmapOut(sizeImage); // here bitmap is filled with data (e.g. read from file, generated in memory, etc.) // bitmap = load_image() // 1) //////////////////////////////////////////////////////////////////////////////////////////////// auto src = boost::gil::interleaved_view(w, h, reinterpret_cast<boost::gil::rgb8_pixel_t const*>(&bitmap[0]), sizeRow); auto dst = boost::gil::interleaved_view(w, h, reinterpret_cast<boost::gil::rgb8_pixel_t*>(&bitmapOut[0]), sizeRow); assert( !boost::gil::equal_pixels(src, dst) ); // loop taken from boost::gil::transform_pixels for (std::ptrdiff_t y=0; y<src.height(); ++y) { auto srcIt=src.row_begin(y); auto dstIt=dst.row_begin(y); for (std::ptrdiff_t x=0; x<src.width(); ++x) { // Simple rgb8_pixel_t to rgb8_pixel_t assignment dstIt[x] = srcIt[x]; } } assert( boost::gil::equal_pixels(src, dst) ); // 2) //////////////////////////////////////////////////////////////////////////////////////////////// typedef interleaved_ptr<unsigned char*, rgb_layout_t> rgb8_interleaved_ptr; typedef interleaved_ptr<const unsigned char*, rgb_layout_t> rgb8c_interleaved_ptr auto src = boost::gil::interleaved_view(w, h, gil::rgb8c_interleaved_ptr(&bitmap[0]), sizeRow); auto dst = boost::gil::interleaved_view(w, h, gil::rgb8_interleaved_ptr(&bitmapOut[0]), sizeRow); assert( !boost::gil::equal_pixels(src, dst) ); // loop taken from boost::gil::transform_pixels for (std::ptrdiff_t y=0; y<src.height(); ++y) { auto srcIt=src.row_begin(y); auto dstIt=dst.row_begin(y); for (std::ptrdiff_t x=0; x<src.width(); ++x) { // Interleaved_ref points to first channel of current pixel, right? // Is this access and assignment of colour components incorrect? dstIt[x][0] = srcIt[x][0]; // R dstIt[x][1] = srcIt[x][1]; // G dstIt[x][2] = srcIt[x][2]; // B } } assert( boost::gil::equal_pixels(src, dst) ); // This assertion fails! // 1/2 to 1/3 of bitmapOut is black (pixels with value 0) /// END ////////////////////////////////////////////////////////////////////////////////////////////////////// Perhaps the access to pixels and colour components should be realised with srcIt[x * num_channels]; My e-mail is not a request for help, in fact, but a kind of bug report or warning. Because the interleaved_ptr is not part of Boost.GIL but provided as an example, I don't think it's worth a ticket on Trac. I just thought it may be worth to archive this issue in the list and make the interleaved_ptr authors and other users aware of the problem. [1] http://lists.boost.org/Archives/boost/2012/10/197199.php [2] https://gist.github.com/3866213 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[Windows 8 Apps]
by Johannes Sartisohn 11 Oct '12

11 Oct '12

Hello everyone, I've searched the boost website and the mailing list archives back to january and didn't find any helpful information on my subject. My question is whether there are plans to support compiling the boost library for Windows 8 using only the WinRT APIs. That is, to support boost for Windows Store/Metro Style apps in Windows 8. Or is there already a way (e.g. via preprocessor direcitve) that I didn't find, to disable the unsupported Win32 API calls when compiling on Windows? Cheers Johannes

3 3

[build] Boost Build v2 documentation refer to "bjam"
by Klaim - Joël Lamotte 11 Oct '12

11 Oct '12

Hi, http://www.boost.org/boost-build2/doc/html/bbv2/overview/invocation.html I suppose this doc have not been updated in a long time? It still use "bjam" instead of "b2". Joel Lamotte

3 3

[boost-python, boost-build] building "hello" boost-python tutorial sample with python 3.2 on Archlinux
by Roland Puntaier 10 Oct '12

10 Oct '12

Hello! Today I have tried boost-python tutorial with Arch Linux and Python3.2. In case somebody else tries this, here are the problems that I've encounter: - I've created ~/user-config.jam with this line using python : 3.2 : /usr/bin/python ; - the current boost-build of arch is 2.0_m12-3 This still uses "print" without "(" in boost-build/tools/python.jam The nightly build of boost-build has it corrected: local full-cmd = $(python-cmd)" -c \"from sys import *; print('"$(format:J=\\n)"' % ("$(exprs:J=,)"))\"" ; - Arch has python3.2 includes in /usr/include/python3.2mu (I wonder why!) This is not detected by b2 / bjam. I worked around this by changing boost-build/tools/python.jam: includes ?= $(prefix)/include/python$(version)mu ; - the sample jamroot file in the tutorial http://www.boost.org/doc/libs/1_51_0/libs/python/example/tutorial/Jamroot assumes a boost root folder. Since boost include and lib are separate with the arch boost installation, I've commented out "use-project". Then I had to give a direct reference to libboost_python3.so. diff -u Jamroot.org Jamroot =========================== --- Jamroot.org 2012-10-10 22:21:32.928426203 +0200 +++ Jamroot 2012-10-10 22:23:15.318762363 +0200 @@ -13,14 +13,13 @@ # Specify the path to the Boost project. If you move this project, # adjust this path to refer to the Boost root directory. -use-project boost - : ../../../.. ; +#use-project boost : ../../../.. ; # Set up the project-wide requirements that everything uses the # boost_python library from the project whose global ID is # /boost/python. project - : requirements <library>/boost/python//boost_python ; + : requirements <library>/usr/lib/libboost_python3.so ; # Declare the three extension modules. You can specify multiple # source files after the colon separated by spaces. It would be great to have comments pointing to the right solution for python 3.2 and an installed boost directly in the tutorial's sample jamroot file. - Roland

1 0

[graph] Bug in metric_tsp_approx_tour?
by Morten Strandberg 10 Oct '12

10 Oct '12

Hello, I have an application where I need to approximately solve the traveling salesman problem. I tried metric_tsp_approx_tour_from_vertex, just following the boost test code. The function works as long as the provided start vertex is zero, but given any other vertex I get rubbish back. For example, given a graph with ten vertices, the returned tour can be of length 4. I am using the following graph type: typedef adjacency_matrix<undirectedS, no_property, property<edge_weight_t, double> > Graph; and the following call: metric_tsp_approx_tour_from_vertex(graph, start_v, back_inserter(tour)); Am I doing something wrong, or is this a bug? Regards, /Morten

2 1

Gauging interest in time code for broadcasters...
by Joseph Van Riper 10 Oct '12

10 Oct '12

I'd like to know if anyone might take interest in a header library that supports working with time code (as in, 01:00:00:00 which is 107892 drop-frames, or 108000 frames at 30 fps). The library would simply convert between frames (as a long) and boost::posix_time::time_duration types according to the kind of time code, and would parse or output strings according to the kind of time code. From there, you'd just leverage boost::posix_time::time_duration for any calculations you need. I realize this is kind of a special-interest library, but the broadcasting field seems so wide that something like this might be useful to quite a few people, so I thought I'd ask. - Trey

3 7

[contract] first attempt to N3351 concepts
by Lorenzo Caminiti 10 Oct '12

10 Oct '12

Hello all, I made a first attempt to sketch how N3351-like concepts will look into Boost.Contract (just for the find algorithm and its concepts for now): http://contractpp.svn.sourceforge.net/viewvc/contractpp/branches/stl_concep… This code doesn't compile quite yet but I played with its bits and pieces enough to conclude that it should be implementable as listed. It will take quite a bit of time and effort to implement this... Please tell me what you think now so I don't waste time implementing this design if it has issues. Thanks a lot! --Lorenzo

4 9

[config] explicit call of operator templates / msvc bug workaround
by Stefan Strasser 10 Oct '12

10 Oct '12

Hi, is there already a macro in Boost.Config that allows you to insert the "template" keyword in the following code for those compilers that require it? struct functor{ template<class T> void operator()(); }; template<class F> void g(F f){ f.template operator()<int>(); //(1) works with GCC and comeau f.operator()<int>(); //(2) works with MSVC } this apparently only applies to operator calls. MSVC accepts both (1) and (2) for regular functions. (instantiating the operator template with an object of type T as argument, like mpl::for_each does, is not an option. I can't construct T.) thanks, Stefan

6 10

[1.52] error on WinCE
by Jochen Wilhelmy 10 Oct '12

10 Oct '12

Hi! on WinCE I get errors of this type: boost/smart_ptr/detail/sp_counted_base_w32.hpp(73) : error C3861: 'InterlockedIncrement': identifier not found BOOST_USE_WINDOWS_H is not defined _WIN32_WCE is 0x600 therefore there is only _InterlockedIncrement (with leading underscore) in boost/detail/interlocked.hpp -Jochen

2 1

[math] build failure with BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS
by Kim Barrett 10 Oct '12

10 Oct '12

I'm attempting to upgrade from boost 1.49 to boost 1.52 beta1, and have run into a problem building the math libraries. It seems that defining BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS no longer works, leading to build failures if it is defined. This worked in boost 1.49, where I was defining it in $BOOST_ROOT/boost/math/tools/user.hpp as described in the comments therein. I've filed a ticket for this problem: https://svn.boost.org/trac/boost/ticket/7485

2 1

[1.52] release branch reopened for bug fixes ONLY
by Eric Niebler 09 Oct '12

09 Oct '12

Now that we have released the first beta, the release branch is open for bug fixes. Only bug fixes, please.[*] No new features. No new libraries. You do not need a release manager's approval to merge a bug fix. The earlier you can merge your bug fixes, the better. The branch will close again for final release preparations on Oct 29. As usual, you can see the release calendar here: http://www.boost.org/development/index.html [*] Changes to documentation are always allowed. -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

[config] Handle upcoming XP-target toolset of VC11
by Lars Viklund 09 Oct '12

09 Oct '12

Hi list. Microsoft are testing their update system for Visual Studio 2012 [1], which includes a v110_xp toolset [2] for "restoring" support for building software that may run on Windows XP. In essence, it uses a repurposed Windows 7 SDK with the VS 2012 compiler, instead of the Windows 8 SDK used in the normal v110 toolset. What implications do you think this has for Boost.Config and all the things predicated on MSC_VER, as this decorrelates the compiler version from the Windows SDK it uses. Has anyone installed these pre-release bits and given it a shot? (I've mailed boost-build@ about the Boost.Build implications.) [1] http://blogs.msdn.com/b/visualstudioalm/archive/2012/10/08/visual-studio-20… [2] http://blogs.msdn.com/b/vcblog/archive/2012/10/08/10357555.aspx -- Lars Viklund | zao(a)acc.umu.se

3 2

[GIL] Small docs update suggestion on cached_location_t
by Mateusz Loskot 09 Oct '12

09 Oct '12

Hi, I've stumbled upon old thread on "locator and cached_location_t" [1] There are some interesting explanations which I believe is worth to add to Boost.GIL docs. Particularly, I believe the following Lubomir's clarification should be added as first paragraph documenting cached location: "Cached location is meant to be used as a quick way to get to neighborhood pixels if you need to read or write a neighboring location frequently relative to a given locator." Currently, notion of cached location is documented in the GIL design guide [1] but it makes users to deduce answer to "What the cached locator is for?". BTW, I wanted to provide patch, but I'm not sure where this update should be put or if I should submit a ticket. [1] http://lists.boost.org/Archives/boost/2010/12/174157.php [2] http://www.boost.org/doc/libs/1_51_0/libs/gil/doc/html/gildesignguide.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 1

[graph] msvc compile failure with filtered_graph and dijkstra
by Jürgen Hunold 09 Oct '12

09 Oct '12

Hi, some of our old graph algorithm seems to have broken using msvc with 1.51. The failure can be reproduced with the attached testcase on trunk and 1.51. The error starts with E:\Home\hunold\src\devel\boost\boost/graph/properties.hpp(222) : error C2039: 'type' : is not a member of 'boost::vertex_property_type<G>' which point in the direction of the last changes to properties.hpp. The test code break with msvc-9.0 (full error included) and msvc-11.0. Everything compiles with gcc-4.6.2 on Kubuntu 12.04 and mingw-w64. Any ideas what msvc does not grok here? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

2 5

[contract] concept error messages
by Lorenzo Caminiti 09 Oct '12

09 Oct '12

Hello all, Main purposes of concepts are to (a) document the type requirements and (b) generate useful error messages when a type does not met the requirements. I'd like to discuss how the ideal error messages should look like when a given type does not model the specified concepts. One point of discussion is: In case a type doesn't model a concept, should the compiler generate an hard error or the function/class template should simply be removed from the overload/specialization set? For example, consider: template< typename T> requires EqualityComparable<T> bool equal ( T a, T b ) // #1 { return a == b; // #3 } ... struct x { explicit x(char const*); }; x abc("abc"); equal(abc, abc); // #2 Let's assume we want an hard error then I think ideally the compiler should generate two errors: 1) An error at line #1 indicating that the concept EqualityComparable<T> is not modeled. Ideally this error will read: line #1: failed to model concept EqualityComparable<T> 2) An error at line #2 indicating that the call equal(abc, abc) cannot be resolved. Ideally this error will read: line #2: no matching call for function equal 3) Note that no error should be generated from within the equal function implementation (line #3, etc) because the concept is not modeled so the function definition should not be compiled. Now, this is what I was able to actually implement. === Option A) Using enable_if === template< typename T > typename std::enable_if< AlwaysTrue<T>::value && contract::std::EqualityComparable<T>::value, bool>::type equal1 ( T const& a, T const& b ) { return a == b; } ... equal1(abc, abc); // 08.cpp:44 08.cpp:44:5: error: no matching function for call to 'equal1' equal1(abc, abc); ^~~~~~ [...] This error is not ideal because it only satisfies 2) and 3) but not 1). It does not give information about which concept was not modeled -- you don't see EqualityComparable or "concept failed" anywhere in the error. (Clang actually mentions EqualityComparable in a "note" following the error (see below) but that's not a message that can be relied on across different compilers.) Users can use this approach if they don't want an hard error but they only want to remove the function from the overload set on concept failure. === Option B) Using concept_check === template< typename T > typename contract::concept_check< AlwaysTrue<T>::value, contract::std::EqualityComparable<T>::value, bool>::type equal2 ( T const& a, T const& b ) { return a == b; } ... equal2(abc, abc); // 08.cpp:45 In file included from 08.cpp:5: include/contract/concept_check.hpp:61:5: error: static_assert failed "model concept number 2" static_assert(Concept2, "model concept number 2"); ^ ~~~~~~~~ [...] 08.cpp:45:5: error: no matching function for call to 'equal2' equal2(abc, abc); ^~~~~~ This also satisfies 2) and 3) however it only partially satisfies 1). The error mentions the number of the concept "2" but not its name EqualityComparable (that's probably OK) but the error line number refers to the file implementing concept_check and not to the point of declaration of equal2. In other words, the error for 1) does not indicate line #1 (that's probably acceptable but not ideal). Note that the error for 1) is generate using a static_assert so it is portable. === Option C) Using CONCEPT_CHECK macro === CONTRACT_CONCEPT_CHECK( // 08.cpp:26 (template< typename T >), (AlwaysTrue<T>) (contract::std::EqualityComparable<T>), bool, equal3 ) ( T const& a, T const& b ) { return a == b; } ... equal3(abc, abc); // 08.cpp:45 08.cpp:26:1: error: static_assert failed "model concept number 2: contract::std::EqualityComparable<T>" CONTRACT_CONCEPT_CHECK( ^~~~~~~~~~~~~~~~~~~~~~~ [...] 08.cpp:46:5: error: no matching function for call to 'equal3' equal3(abc, abc); ^~~~~~ [...] These errors satisfy all 1), 2), and 3) however the use of macros makes clang generate lots of "notes" to backtrace the macro expansion (there's probably a way to disable these notes, plus they are not actual errors and can be ignored). Note that the concept name EqualityComparable appears in the static assertion error message so it is guaranteed to be printed portably among compilers. I'm thinking that these are all valid ways to check concepts. Eventually, Boost.Contract macros will use B) (given that the lib already uses macros to declare functions). However, if users want to use Boost.Contract macros to declare a concept but they want to use enable_if or contract::concept_check to check it, they can do so (in case they don't want to use the lib macros to declare their functions). Complete error messages (including "notes"): 08.cpp:44:5: error: no matching function for call to 'equal1' equal1(abc, abc); ^~~~~~ 08.cpp:12:5: note: candidate template ignored: disabled by 'enable_if' [with T = x] AlwaysTrue<T>::value && contract::std::EqualityComparable<T>::value, ^ In file included from 08.cpp:5: include/contract/concept_check.hpp:61:5: error: static_assert failed "model concept number 2" static_assert(Concept2, "model concept number 2"); ^ ~~~~~~~~ 08.cpp:19:20: note: in instantiation of template class 'contract::concept_check<true, false, bool>' requested here typename contract::concept_check< ^ 08.cpp:21:13: note: while substituting deduced template arguments into function template 'equal2' [with T = x] bool>::type equal2 ( T const& a, T const& b ) ^ 08.cpp:45:5: error: no matching function for call to 'equal2' equal2(abc, abc); ^~~~~~ 08.cpp:21:13: note: candidate template ignored: substitution failure [with T = x] bool>::type equal2 ( T const& a, T const& b ) ^ 08.cpp:26:1: error: static_assert failed "model concept number 2: contract::std::EqualityComparable<T>" CONTRACT_CONCEPT_CHECK( ^~~~~~~~~~~~~~~~~~~~~~~ include/contract/concept_check.hpp:40:33: note: expanded from macro 'CONTRACT_CONCEPT_CHECK' BOOST_PP_SEQ_FOR_EACH_I(CONTRACT_CONCEPT_CHECK_ASSERT_, ~, concepts) \ ^ ../../../boost_1_50_0.cyg/boost/preprocessor/seq/for_each_i.hpp:27:69: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I' # define BOOST_PP_SEQ_FOR_EACH_I(macro, data, seq) BOOST_PP_FOR((macro, data, seq (nil), 0), BOOST_PP_SEQ_FOR_EACH_I_P, BOOST_PP_SEQ_FOR_EACH_I_O, BOOST_PP_SEQ_FOR_EACH_I_M) ^ ../../../boost_1_50_0.cyg/boost/preprocessor/repetition/detail/for.hpp:22:78: note: expanded from macro 'BOOST_PP_FOR_1' # define BOOST_PP_FOR_1(s, p, o, m) BOOST_PP_FOR_1_C(BOOST_PP_BOOL(p(2, s)), s, p, o, m) ^ note: (skipping 7 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all) ../../../boost_1_50_0.cyg/boost/preprocessor/seq/for_each_i.hpp:45:80: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I_M_IM' # define BOOST_PP_SEQ_FOR_EACH_I_M_IM(r, im) BOOST_PP_SEQ_FOR_EACH_I_M_I(r, im) ^ ../../../boost_1_50_0.cyg/boost/preprocessor/seq/for_each_i.hpp:50:62: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I_M_I' # define BOOST_PP_SEQ_FOR_EACH_I_M_I(r, macro, data, seq, i) macro(r, data, i, BOOST_PP_SEQ_HEAD(seq)) ^ include/contract/concept_check.hpp:23:5: note: expanded from macro 'CONTRACT_CONCEPT_CHECK_ASSERT_' static_assert(CONTRACT_CONCEPT_CHECK_COND_(i), "model concept number " \ ^ 08.cpp:26:1: note: in instantiation of template class 'contractXconceptXcheckXequal3X30<true, false>' requested here CONTRACT_CONCEPT_CHECK( ^ include/contract/concept_check.hpp:50:14: note: expanded from macro 'CONTRACT_CONCEPT_CHECK' typename CONTRACT_CONCEPT_CHECK_CLASS_(func_name)< \ ^ include/contract/concept_check.hpp:11:23: note: expanded from macro 'CONTRACT_CONCEPT_CHECK_CLASS_' BOOST_PP_SEQ_CAT((contractXconceptXcheckX)(func_name)(X)(__LINE__)) ^ ../../../boost_1_50_0.cyg/boost/preprocessor/seq/cat.hpp:30:7: note: expanded from macro 'BOOST_PP_SEQ_CAT' )(seq) \ ^ note: (skipping 18 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all) ../../../boost_1_50_0.cyg/boost/preprocessor/seq/cat.hpp:35:37: note: expanded from macro 'BOOST_PP_SEQ_CAT_O_I' # define BOOST_PP_SEQ_CAT_O_I(a, b) a ## b ^ <scratch space>:91:1: note: expanded from macro 'contractXconceptXcheckXequal3X' contractXconceptXcheckXequal3X30 ^ ../../../boost_1_50_0.cyg/boost/preprocessor/seq/fold_left.hpp:295:51: note: expanded from macro 'BOOST_PP_SEQ_FOLD_LEFT_F' # define BOOST_PP_SEQ_FOLD_LEFT_F(op, st, ss, sz) st ^ 08.cpp:29:11: note: while substituting deduced template arguments into function template 'equal3' [with T = x] bool, equal3 ^ include/contract/concept_check.hpp:53:5: note: expanded from macro 'CONTRACT_CONCEPT_CHECK' func_name ^ 08.cpp:46:5: error: no matching function for call to 'equal3' equal3(abc, abc); ^~~~~~ 08.cpp:29:11: note: candidate template ignored: substitution failure [with T = x] bool, equal3 ^ include/contract/concept_check.hpp:53:5: note: expanded from macro 'CONTRACT_CONCEPT_CHECK' func_name ^ 5 errors generated. --Lorenzo

5 20

[result_of] BOOST_RESULT_OF_USE_DECLTYPE in a C++03 mode with libc++
by Michel Morin 08 Oct '12

08 Oct '12

This is just a small note related to boost::result_of. When BOOST_RESULT_OF_USE_DECLTYPE is defined, boost::result_of tries to use decltype-based implementation (regardless of the compiler's decltype support). Surprisingly, in a C++03 mode, libc++ defines `decltype` using `__typeof__`: Bug 12488 (WONTFIX): decltype can be used in C++03 with no errors, no warnings http://llvm.org/bugs/show_bug.cgi?id=12488 So, when used with libc++, boost::result_of can be used with BOOST_RESULT_OF_USE_DECLTYPE even in a C++03 mode. Regards, Michel

2 3

[config] libs not supporting std::u16string and std::u32string.
by Vicente J. Botet Escriba 08 Oct '12

08 Oct '12

Hi, compiling Boost.Ratio/io Boost.Chrono/io with compilers supporting |char16_t and |char32_t fails if the library don't provides std::u16string and std::u32string. Could we add a macro |BOOST_NO_CXX11_HDR_STRING||| (c++11 is not completely provided) or the two more specific |||BOOST_NO_CXX11_U16STRING||| and |||BOOST_NO_CXX11_U32STRING||| for these cases? Best, Vicente || ||

4 7

Is Boost Broken?
by Robert Ramey 08 Oct '12

08 Oct '12

At Boost Con 2010 I made a presentation in which I suggested changes in boost to permit it to continue to prosper. This presentation was titled: "Is Boost Broken?" Here's the video link - but it doesn't seem to work any more http://blip.tv/boostcon/robert-ramey-is-boost-broken-4166775 And the slides http://www.rrsd.com/software_development/boost/BoostCon2010/boost_con_2010.… And a thread of the discussion in the aftermath. http://boost.2283326.n4.nabble.com/quot-Is-Boost-Broken-quot-post-script-td… The response was encouraging but sorry to say that note much concrete has come of it ... until now. I've implemented most of these ideas as a website - Boost Library Incubator - www.blincubator.com which is intended to help library authors and provide a place where libraries can be developed prior to the review process. This touches on just about all of Boost workflow and initiatives in one way or another. This includes Modularization, Documentation standards and preperation, Testing and Test Reporting, Deployment. Probably the main underlying ideas here are: a) Decoupling and Modularization of libraries in general and boost in particular. b) Workflow to improve code quality b) leverage on "free" tools, technologies, and facilities to get most bang for the buck. As a "teaser", I've included a new library "safe numerics" which addresses a long running sore in the C language. It's a serious proposal for a library, but my main interest is to have a prototype to develope the next concept. I'm very much tempted to comment on the current state of development of web technologies - the that would take me waaaay of topic and we'll leavel that for another time. Looking forward to feedback from boost enthusiasts. Robert Ramey

3 3

[type_traits] common_type and SFINAE
by Lorenzo Caminiti 08 Oct '12

08 Oct '12

Hello all, common_type<T, U>::type is defined in a way that gives a hard compiler error if T and U do not have a common type (this is also how common_type is implemented in C++11). An alternative design (I'm not sure if implementable) would have been to not define the type member in case T and U have no common type. This way I could use SFINAE to detect if common_type<T, U>::type does not exist and therefore if T and U have not common type -- so to implement N3351's concept Common<T, U>. Is there a way to implement this alternative design? Thanks. --Lorenzo

8 22

[graph] kick out or replace transitive_reduction()?
by Johannes Lorenz 08 Oct '12

08 Oct '12

Hi, shall the transitive_reduction function (transitive_reduction.hpp) of boost_graph ever be used? I ask because * I can find no docs about it * It is unhandy to use, since the nodes are permuted (in opposite to transitive_closure(), which offers a version with *constant* permutation) * I've found bugs in the header, which were stated to be bugs by the original author (asked him via email) If this function should not be used, I'd write a very simple one, using the formula from [1]. Note that this will only work for DAGs, but that's better than nothing. What do you think? Regards, Johannes [1] http://en.wikipedia.org/wiki/Transitive_reduction#Graph_algorithms_for_tran…

1 0

[1.52.0] Beta release candidates available
by Marshall Clow 08 Oct '12

08 Oct '12

Release candidate files for 1.52.0 beta 1 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: 61a852c923c7e27d84fd2e6336d787f2 *boost_1_52_0_beta1_rc1.tar.gz 956fb476326ee634225c683612493fdd *boost_1_52_0_beta1_rc1.tar.bz2 703663eca3122152031c5555e26845c0 *boost_1_52_0_beta1_rc1.zip b277b6f36ead9df9a0754c868956f30c *boost_1_52_0_beta1_rc1.7z Thanks, --The release managers

5 6