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

[TTI] library now status?
by osyo manga 07 Oct '12

07 Oct '12

Hi. What is the state of Boost.TTI ? I seem to have not changed for more than one year in boost-svn. Thanks.

2 1

[exception] boost::throw_exception vs deriving from boost::exception
by John Salmon 07 Oct '12

07 Oct '12

I'd like to use Boost.Exception's error_info capabilities in an existing code base. It seems to me that I have two choices: 1 - find all the 'throw my_except(...)' in the code base and replace them with boost::throw_exception(my_except(...)). 2 - find all the struct my_except{...} definitions in the current code base and replace them with: struct my_except: virtual boost::exception {...} I find #2 more appealing for the following practical reasons: - there are fewer locations to change. Exceptions are defined less often and in fewer places than they are used. - there is less to remember. Developers who write new throw expressions need to remember nothing. Developers who define new exceptions must remember to derive them from boost::exception, but this is much less common. Are there reasons I should prefer boost::throw_exception instead? I can only think of one: boost::throw_exception also adds N2179 support via enable_current_exception. This isn't a current concern, but our compilers (gcc and clang) already support N2179 directly, so we can use std::current_exception rather than boost::current_exception if the need arises. Are there other reasons to prefer boost::throw_exception? Thanks John Salmon

3 2

[Phoenix] lambda_tests.test fails on gcc 4.3-4.8 with BOOST_RESULT_OF_USE_DECLTYPE
by Michel Morin 07 Oct '12

07 Oct '12

First, thanks Eric for fixing incompatibility between Phoenix and decltype-based result_of. This is really a great fix! I ran Phoenix test-suite on * clang 3.1, 3.2 (trunk) * gcc 4.4-4.7, 4.8 (experimental) with * C++03, C++11 + BOOST_RESULT_OF_USE_DECLTYPE, C++11 + BOOST_RESULT_OF_USE_TR1 The only failure is lambda_tests.test (i.e. scope/lambda_tests.cpp) on gcc 4.4-4.7 with C++11 + BOOST_RESULT_OF_USE_DECLTYPE. Is this caused by deficiency of N3276 decltype support? P.S. What was the main reason for the incompatibility between Phoenix and decltype-based result_of? And how did you fix it? Regards, Michel

2 4

[lexical_cast] exception type for overflow
by Jochen Wilhelmy 06 Oct '12

06 Oct '12

Hi! i would expect that lexical_cast<uint16_t>("65536") and numeric_cast<uint16_t>(lexical_cast<int>("65536")) would throw the same exception boost::numeric::positive_overflow. but lexical_cast throws a bad_lexical_cast. is it possible to change lexical_cast so that it also throws positive_overflow if the error comes from the overflow and not from the lexical parsing? -Jochen

3 2

[countertree] Formal Review Request
by Francisco José Tapia 05 Oct '12

05 Oct '12

Hi all, I would like to request a formal review of the library “Countertree + Suballocator” [countertree] Project location ( zip file with code and documentation) : https://dl.dropbox.com/u/8437476/works/countertree_code_doc.zip Quick view of documentation with code download : https://dl.dropbox.com/u/8437476/works/countertree/index.html For the people who don't know this project, this is a description : *COUNTERTREE* This library is an implementation of a binary red-black counter tree. This tree have an additional counter in each leaf. This permit the access to the elements by the position, like in a vector. It is a random access container with random access iterators . Based on this tree we have : - With unordered information we have vectors (countertree::vector_tree) with identical interface than std::vector. The vector_tree have the same speed inserting and deleting in any position (all the operations are O(log N)).It is slower than std:vector inserting and deleting at end, but much faster for to insert and delete in any other position. - With ordered information, we have in the countertree namespace the classes set, multiset, map and multimap, with identical interface than the STL classes, with the plus of access to the elements by position, like in a vector. The iterators are random access , and you can subtract two iterators in a O(log N) time for to know the number of nodes between them (even with the end( ) and rend( ) iterators) *SUBALLOCATOR* In the allocation of equal size elements ( as in STL list, set, multiset,map and multimap), when the number of elements grows, many allocators begin to have speed problems. For to improve the speed, many allocators request to the Operating System big chucks of memory ( pool allocators). With this, the allocator don't need request memory to the operating system for each allocation. But many allocators don't return well the unused chucks of memory to the Operating System and the memory used by the allocator is the maximum used, never decrease . The *suballocator is a solution to these problems*, and others memory problems described in the suballocator page. The suballocator is a layer between the allocator and the data structures, compatible with any allocator with the STL definition. The suballocator request memory to the allocator, and return to it when unused. The suballocator replace to the allocator in the allocation of equal size elements With the suballocator a) *We have a very fast allocation* *(around 2 times faster than the std::allocator of GCC 4.7, CLANG 3.0 and 3 times than Visual Studio 10 *See details in the *Suballocator Benchmark*)* b) *Return the suballocator return memory to the allocator, this can use in the allocation of others types of data or for return to the *Operating System, decreasing the memory used by the program, *( as you can see in the *Suballocator Benchmark *)* c) *You can use with any allocator if it is according with the STL definition*. The suballocator provides speed and memory management to any allocator. d) Even the time of the allocation is a small part of the time spent in the insertion in a std::set, the suballocator obtain time reductions over over the 30% respect the std::allocator. The secret is the cache performance due to the data locality improvement. *COUNTERTREE + SUBALLOCATOR* The join of the two ideas provide us data structures with a suballocator built-in. They are, in the namespace countertree, the vector_tree_pool, set_pool, multiset_pool,map_pool and multimap_pool, with identical interface than the STL classes but better performance for big number of elements It is fast, useful and easy to understand and use,. They are the like the STL classes with a few additional functions. This library is designed thinking in programmers with a basic knowledge of C++. As I say in the documentation, if you know the STL classes vector, set , multiset, map , multimap and allocator, you know more than 95% needed for to use this library. I showed the library to several friends and colleagues, and one of them said me “If your potential users are not experts, and they need more than 5 minutes to understand what's the goal of the library and what they can do with it, many of them leave the page.... , and the library”. The first page of the documentation explain the library, the reasons and what can do. And in the next pages show the details and how can do in a a easy way. I had checked this code with GCC 4.7 , CLANG/LLVM 3.0 and Visual C++ 10 ( all with 32 and 64bits.). In code of the project is composed by the code of the classes, the test programs, the benchmarks programs used and mentioned in the documentation, and several examples of the code I had checked all the requirements for to request the review. But I am not sure if all is OK. If you miss something or something is wrong , please , mail me and I will correct as soon as possible Sincerely yours Francisco Tapia fjtapia(a)gmail.com

4 9

[graph][heap][coroutine] interruptable dijkstra shortest path function
by Alex Hagen-Zanker 05 Oct '12

05 Oct '12

[apologies for double posting, send it to wrong list before] Hi, A few months ago I posted here to gauge interest for an interruptable and resumable version of the dijkstra_shortest_path algorithm. The initial response was positive, but Jeremiah considered the proposed solution lacking compared to an algorithm object model that inverts the control over the algorithm, Additional to my original solution, I now have two implementations of the algorithm object model. 1. Visitor based interruption. This is my original approach. It separates the algorithm into an init and main function. The main function asks the visitor if it should be halted afer each iteration. After halting, the main function can be used to resume the calculation. auto dijkstra = make_dijkstra_object(graph, named_parameters); dijkstra.init_from_sources(sources); dijkstra.expand( interruptor); dijkstra.expand( other_interruptor); auto distance_map = dijkstra.get<vertex_distance_t>(); auto color_map = dijkstra.get<vertex_color_t>(); 2. Algorithm object implementation. This was suggested by Jeremiah. The algorithm object iterates from control point to control point in the algorithm. Giving at each stop access to the intermediate results of the algorithm. The two implementations are: a) Using the [Coroutine] library that is currently under review to step in and out of the function. b) Fragmenting the function into many subfunctions that are chained together and the other works by fragmenting the original algorithm into a number of small interlinked functions starting at one control point and returning at the next. The interface of a and b is exactly the same and it works like this: auto dijkstra = make_dijkstra_object(graph, sources, named_parameters); while(dijkstra.next() ) { control_point cp = dijkstra.get_control_point(); vertex u = dijkstra.get_u(); auto distance_map = dijkstra.get<vertex_distance_t>(); if(cp == cp_finish_vertex && get(distance_map, u) > 42) { cout << "far enough" << endl; break; } } auto distance_map = dijkstra.get<vertex_distance_t>(); The algorithm object offers most flexibility for interweaving multiple searches. The visitor based solution on the other hand is more efficient. The latter has no loss in performance compared to the existing dijkstra functions. The coroutine algorithm object was extremely easy to implement but it is not very efficient. Does anybody have a suggestion how that can improve? Besides these interruptable and resumable shortest path searches, there are a few more advantages to the implementation. a. All dijkstra parameters are bundled in a light-weight dijkstra_state object that is returned by algorithms, giving direct access to all results of the algorithm, for instance: auto dijkstra_state = dijkstra_shortest_paths(graph, sources, no_named_parameters() ); auto distance_map = dijkstra_state.get<vertex_distance_t>(); b. Named parameters (old style) are also used for the priority queue and the color map c. Boost.Heap mutable queues can be used with Boost.Graph via the named parameter interface. It doesn't help performance now, but may be a good base for experimentation. d. Separation of the dijkstra shortest path algorithm in init and main function makes it easier to provide custom initialization. For instance: multiple sources or only re-initializing changed vertices Can anybody use this? The latest version is here: http://people.pwf.cam.ac.uk/ahh34/dijkstra.zip Kind regards, Alex p.s. below are timings for a large graph: bimba_6M.obj... 2090 ms. Boost Graph Library 2121 ms. With interruption visitor 5601 ms. With Coroutine(*) 2621 ms. With fragmented functions (*) 2840 ms. With Boost.Heap (*) halting at all control points of the dijkstra visitor

8 21

[chrono] bad use of constexpr (was: [1.52.0] Beta release candidates available)
by Eric Niebler 05 Oct '12

05 Oct '12

On 10/5/2012 8:56 AM, Lemay.Steve wrote: > Here's the first problem that pops up for me... QNXNTO gcc 4.7.1 > > qcc.compile.c++ D:\boostBuild_QCC_1_52_0_beta1\boost\bin.v2\libs\chrono\build\qcc\release\link-static\target-os-qnxnto\threadapi-pthread\threading-multi\chrono.o > In file included from ./boost/chrono/chrono.hpp:11:0, > from ./boost/chrono/detail/inlined/chrono.hpp:13, > from libs\chrono\src\chrono.cpp:14: > ./boost/chrono/duration.hpp: In static member function 'static constexpr float boost::chrono::detail::chrono_numeric_limits<float, true>::lowest()': > ./boost/chrono/duration.hpp:355:56: error: call to non-constexpr function 'static std::numeric_limits<float>::_Ty std::numeric_limits<float>::max()' > ./boost/chrono/duration.hpp: In static member function 'static constexpr double boost::chrono::detail::chrono_numeric_limits<double, true>::lowest()': > ./boost/chrono/duration.hpp:363:57: error: call to non-constexpr function 'static std::numeric_limits<double>::_Ty std::numeric_limits<double>::max()' > ./boost/chrono/duration.hpp: In static member function 'static constexpr long double boost::chrono::detail::chrono_numeric_limits<long double, true>::lowest()': > ./boost/chrono/duration.hpp:371:61: error: call to non-constexpr function 'static std::numeric_limits<long double>::_Ty std::numeric_limits<long double>::max()' > cc: d:/qnxsdk/qnxsdk6.5-001/host/win32/x86/usr/lib/gcc/i486-pc-nto-qnx6.5.0/4.7.1/cc1plus caught signal 1 > > "QCC" -Wc,-ftemplate-depth-128 -DFD_SETSIZE=2048 -march=k8-sse3 -mtune=k8-sse3 -mmmx -msse3 -mfpmath=sse -mno-3dnow -mstackrealign -Wc,-fPIC,-std=c++0x,-std=gnu++0x -O3 -Wc,-finline-functions -Wc,-Wno-inline -Wc,-Wall -DBOOST_ALL_NO_LIB=1 -DBOOST_All_STATIC_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -I"." -c -o "D:\boostBuild_QCC_1_52_0_beta1\boost\bin.v2\libs\chrono\build\qcc\release\link-static\target-os-qnxnto\threadapi-pthread\threading-multi\chrono.o" "libs\chrono\src\chrono.cpp" > > ...failed qcc.compile.c++ D:\boostBuild_QCC_1_52_0_beta1\boost\bin.v2\libs\chrono\build\qcc\release\link-static\target-os-qnxnto\threadapi-pthread\threading-multi\chrono.o... > common.copy D:\boost\include\boost\checked_delete.hpp > D:\boost_1_52_0_beta1\boost\checked_delete.hpp > 1 file(s) copied. > common.copy D:\boost\include\boost\chrono.hpp > D:\boost_1_52_0_beta1\boost\chrono.hpp > 1 file(s) copied. > qcc.compile.c++ D:\boostBuild_QCC_1_52_0_beta1\boost\bin.v2\libs\chrono\build\qcc\release\link-static\target-os-qnxnto\threadapi-pthread\threading-multi\process_cpu_clocks.o > In file included from ./boost/chrono/process_cpu_clocks.hpp:18:0, > from ./boost/chrono/detail/inlined/process_cpu_clocks.hpp:19, > from libs\chrono\src\process_cpu_clocks.cpp:17: > ./boost/chrono/duration.hpp: In static member function 'static constexpr float boost::chrono::detail::chrono_numeric_limits<float, true>::lowest()': > ./boost/chrono/duration.hpp:355:56: error: call to non-constexpr function 'static std::numeric_limits<float>::_Ty std::numeric_limits<float>::max()' > ./boost/chrono/duration.hpp: In static member function 'static constexpr double boost::chrono::detail::chrono_numeric_limits<double, true>::lowest()': > ./boost/chrono/duration.hpp:363:57: error: call to non-constexpr function 'static std::numeric_limits<double>::_Ty std::numeric_limits<double>::max()' > ./boost/chrono/duration.hpp: In static member function 'static constexpr long double boost::chrono::detail::chrono_numeric_limits<long double, true>::lowest()': > ./boost/chrono/duration.hpp:371:61: error: call to non-constexpr function 'static std::numeric_limits<long double>::_Ty std::numeric_limits<long double>::max()' > cc: d:/qnxsdk/qnxsdk6.5-001/host/win32/x86/usr/lib/gcc/i486-pc-nto-qnx6.5.0/4.7.1/cc1plus caught signal 1 For the record, I hit the same thing recently. In my case, it was a recently built clang that picked up an older libstdc++. The trouble is, just because a compiler supports constexpr doesn't mean the standard library does. Chrono doesn't seem to be making that distinction. It would be great to get this fixed for final release. -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

Boost.Generic, C++0x Concepts, and C++1y Concepts
by Matt Calabrese 05 Oct '12

05 Oct '12

Hey everyone, It's been a while since I've made an appearance on this list, but I was contacted regarding the recent discussion of concepts here and Lorenzo's taking the reins of a concept library, and decided to poke my head in. First, I apologize to the community for not getting Boost.Generic on the sandbox earlier (if you are unfamiliar with Boost.Generic, see my 2011 BoostCon talk http://blip.tv/boostcon/boost-generic-concepts-without-concepts-5262126 and/or the corresponding slides https://github.com/boostcon/2011_presentations/raw/master/thu/Boost.Generic… ). I've gotten numerous emails about it since 2011 and I decided to commit the current state of Boost.Generic to the sandbox today. It is still based on the "old" concepts of C++0x with pseudo-signatures. You can find it in the "generic" subdirectory of the sandbox. That said, I'm not sure anyone even cares about Boost.Generic anymore given that the standard seems to be diverging from how it originally was approaching concepts, but here it is anyway. Similarly, I'm not sure there is any interest from people for me to continue developing Boost.Generic, so I guess this is a check for interest again. And, very briefly, without getting too political here (not that my opinion has any bearing) but I personally do not agree with some of the recent design changes for what may turn out to be C++1y concepts -- specifically I think pseudo-signatures were better overall and the C++0x form of associated types was much more useful than what is currently described, especially concerning associated type deduction, which no longer appears to be possible. But I don't think this discussion is suitable for the Boost mailing list and I don't want to ruffle too many feathers beyond that, so I'll take that elsewhere. For this reason, though, I [currently] do not have a desire to support that form of concepts in my library, though I do plan to resume work on Boost.Generic. A recap of what's gone on since my Boostcon talk, for anyone who even remembers it -- I haven't been actively developing Boost.Generic for over a year as I have been busy with other things, but coincidentally in the past couple of weeks I've gone back to it and decided to update some things due to a trick I realized I could use to get full compatibility with the C++0x working paper for explicit concept map templates (N2914's 14.10.3.2 paragraph 3 highlights why it's non-trivial, see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf) Since then, I've had renewed interest in the project and have updated various facilities. Stuff that changed since my presentation back in 2011 -- it now supports variadic concepts using the syntax ,,, (see line 28 of boost/generic/std_concept/concepts/predicate.hpp for a simple example). All 135 of the concepts from N2914 are now implemented, though not all are working, especially ones that are not auto and use refinement (I'm still in the process of making the concept map backend changes). All of the std_concepts/concepts tests should be working, and same with std_concept/support_concepts tests, with GCC and Clang only failing on FreeStoreAllocatable (in slightly different ways). I'm updating some of the implementation to use the new Boost.Preprocessor variadic macro support that didn't exist when I started development, and Boost.Generic now also is starting to use Edward Diener's variadic_macro_data_library that's in the sandbox. I've only recently test on GCC 4.7 and Clang 3.1, both with libstdc++ on Windows. I don't think any other compilers will be able to handle it because of the amount of C++11 features currently in use... Visual C++ in particular will likely have no chance of compiling ANY of it, even if you use the fully preprocessed form of the library that I provided on the sandbox. Specifically, I currently require the updated C++11 SFINAE support, variadic templates, and template aliases, among other features which I don't believe Visual C++ yet supports. If you want to see how to use the library, for now you'll have to watch the talk, look at the slides, and/or go into generic/test/libs/generic/test/std_concept and examine the tests that are there (the latter will probably be the most enlightening in terms of using the predefined concepts). As for the tests, the ones you should look at if you want to understand how to use the predefined concepts are in the test directory's std_concept/concepts and std_concept/support_concepts subdirectories. If you want to see the syntax for creating your own concepts, the ones in std_concept/concepts are the best choice to look at, as they are simple and most do not require compiler intrinsics, unlike the support_concepts which rely on C++11 type_traits and the C++0x std::True concept. I also recently integrated Boost.Wave support to easily generate preprocessed versions of all of the concepts in the library. You can use the preprocessed headers, including Dave's suggested #line support, without having to run Boost.Wave yourself. To do this you just define a couple of macros when you build the tests. This decreases build times by over 50% on both Clang and GCC -- the tests for me in Clang go from over 7 minutes to just over 3 minutes if I use the preprocessed headers. To activate this support you need the two defines in the following format (easiest to just define them via the command-line) // NOTE: Do not use quotes around the path -- also realize that the path ends in the middle of the word generic, This is necessary. #define BOOST_GENERIC_PREPROCESSED_ROOT put_your_COMPLETE_path_to_boost_sandbox_here/generic/include/boost/gen // Also #define BOOST_GENERIC_USE_PREPROCESSED_HEADERS This will use completely preprocessed concepts, with errors properly pointing to the non-preprocessed headers, and effectively gets rid of all of the "from macro invocation" notes you'd see in clang and gcc 4.8 whenever you hit one of the Boost.Generic generated static_asserts in the non-preprocessed form. It is recommended that you use the preprocessed form unless you are making changes to the library-provided concepts, since compile-times are greatly reduced by using them and error messages are improved. Anyway, as I said, I do not personally like the direction that concepts seem to be going and so I do not currently have much of an interest in implementing what is currently proposed, however, buried somewhere in the source of Boost.Generic I believe is an early implementation of the library that was more similar to how concepts are specified in N3351, though I stopped maintaining it a long time ago -- it allowed for the specification of givens and arbitrary expression matching similar to the current design, with a brief demonstration given in my 2011 Boostcon talk (slide 20: https://github.com/boostcon/2011_presentations/raw/master/thu/Boost.Generic…) It might be useful to revive this now that standard concepts may be going in that direction, but again, I do not think this is a good idea and was why I was convinced by others to switch development to pseudo-signatures to begin with. -- -Matt Calabrese

3 16

[Review Report] ODEInt accepted
by Steven Watanabe 04 Oct '12

04 Oct '12

AMDG The review of the ODEInt library submitted by Mario Mulansky and Karsten Ahnert ended last Friday. Many thanks to everyone who participated in this review. The library is ACCEPTED into Boost unconditionally. Summary: 7 ACCEPT 1 ABSTAIN Reviews: http://lists.boost.org/Archives/boost/2012/09/196733.php http://lists.boost.org/Archives/boost/2012/09/196882.php http://lists.boost.org/Archives/boost/2012/09/196883.php http://lists.boost.org/Archives/boost/2012/10/196966.php http://lists.boost.org/Archives/boost/2012/10/196965.php http://lists.boost.org/boost-users/2012/09/76089.php http://lists.boost.org/boost-users/2012/09/76058.php http://lists.boost.org/boost-users/2012/09/76069.php Other comments: http://lists.boost.org/Archives/boost/2012/09/196756.php The reviews were overwhelmingly positive. Most reviewers were satisfied with the library documentation and interfaces. Issues: These were points brought up by reviewers. The authors are free to accept or reject any of these at their discretion. - A number of minor documentation corrections. - Automatically deduce the correct algebra from the state type. - Use a default initial step size. - Allow breaking out of the algorithms In Christ, Steven Watanabe

2 1

Who maintains boost MPI?
by Ralf Grosse-Kunstleve 04 Oct '12

04 Oct '12

Hi, we're looking for someone to merge a simple patch: https://svn.boost.org/trac/boost/ticket/6123 Ralf

4 4

[release] permission to merge proto fix to release?
by Eric Niebler 04 Oct '12

04 Oct '12

I would like to merge the following changeset to release: https://svn.boost.org/trac/boost/changeset/80820 It's a bug fix for Proto that fixes a failing Phoenix test. The change is only 1 day old, but many of the Sandia testers have cycled already. OK to merge? -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 1

[contract] SFINAE question for concepts
by Lorenzo Caminiti 04 Oct '12

04 Oct '12

Hello all, I have a SFINAE question. The following correctly returns false for eq1<x>::value when x has no operator== template< typename T > struct eq1 { T a; T b; template< typename TX > static char check ( TX a, TX b, char(*)[sizeof (std::is_convertible<decltype(a == b), bool>) ]); template< typename TX > static long check ( ... ); static const bool value = sizeof(char) == sizeof check<T>(a, b, 0); }; However, the following implementation that uses bool{a == b} incorrectly returns true for eq2<x>::value even if x has no operator==... why? BTW, if I just use (a == b) instead of bool{a == b} then it works... template< typename T > struct eq2 { T a; T b; template< typename TX > static char check ( TX a, TX b, char(*)[sizeof bool{a == b} ]); template< typename TX > static long check ( ... ); static const bool value = sizeof(char) == sizeof check<T>(a, b, 0); }; A complete example is attached. I'm using clang++ 3.2 with -std=c++0x. Thanks, --Lorenzo

2 3

[uuid] Merge changes to release
by Andrey Semashev 03 Oct '12

03 Oct '12

Hi, I've noticed that changeset https://svn.boost.org/trac/boost/changeset/80501 was not merged to release branch. The changeset removes a few warnings (including the ones about uninitialized variables) and fix tickets 7375 and 6118. The tests look good. Are these changes planned for 1.52?

3 2

[contract] static if instead of assertion requirements
by Lorenzo Caminiti 03 Oct '12

03 Oct '12

Hello all, I was reading the proposal to add "static if" to C++1x and I will use such a syntax for assertion requirements: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3329.pdf Current syntax for assertion requirements: postcondition( back() == value, requires boost::has_equal<T>::value ) Will be replaced with static if: postcondition( static if(boost::has_equal<T>::value) ( back() == value ) // optional else ( ... ) ) If there were interested, I could even provide a separate BOOST_STATIC_IF(const_condition, then_code, else_code)... however, such a macro could only be used at namespace and class scope, not a function scope :( --Lorenzo

2 2

Boost.Thread does not compile from trunk
by Jeremiah Willcock 02 Oct '12

02 Oct '12

It seems like <boost/thread/future.hpp> is missing an #include of <iostream> and produces errors about missing definitions of cout, etc. because of that. It looks like that is debugging code that may not have been intended to be committed. -- Jeremiah Willcock

2 1

Re: [boost] Fwd: ODEInt review
by Karsten Ahnert 02 Oct '12

02 Oct '12

Hi Greg On 10/02/2012 09:11 PM, Karsten Ahnert wrote: > Hi Freg, Sorry for misspelling!

1 0

Fwd: ODEInt review
by Steven Watanabe 02 Oct '12

02 Oct '12

-------- Original Message -------- Subject: ODEInt review Date: Wed, 26 Sep 2012 11:48:18 -0400 From: Reese, Greg Dr. <greg.reese(a)miamioh.edu> To: watanabesj(a)gmail.com <watanabesj(a)gmail.com> CC: Reese, Greg Dr. <greg.reese(a)miamioh.edu> Please always state in your review, whether you think the library should be accepted as a Boost library! Absolutely! - What is your evaluation of the design? Good. Good use of policies Is it necessary to set an initial step size on the adaptive integrators? Shouldn't they be able to figure this out on their own? If the size is needed, maybe it could have a default value so the user doesn't have to pass the argument. - What is your evaluation of the implementation? Appears to be good but I didn't look at code in detail. - What is your evaluation of the documentation? Excellent! Probably the best documentation of any Boost library. Suggestions: 1) Add general explanation of "observers", e.g., what they do, sample uses. 2) In documentation of example programs, add plots of outputs. These help users decide if the program ran correctly and if they're interpreting the outputs correctly - What is your evaluation of the potential usefulness of the library? Extremely useful to C++ programmers who want to incorporate ODE solutions into their code - Did you try to use the library? With what compiler? Did you have any problems? Used Microsoft Visual C++ 2012. No problems. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 2-3 hours. Read through documentation, ran a number of sample programs - Are you knowledgeable about the problem domain? Yes Suggestion for future (not current!) version - add capability for user routines to stop the Integration process. This is useful for breaking out of periodic solutions, for stopping the computations if the solution attains meaningless values, and for limiting the amount of running time. See, for example, "Event Location" at http://www.mathworks.com/help/matlab/math/ordinary-differential-equations.h… Perhaps this capability can be incorporated into the observers. Greg Reese

3 3

Fwd: [Review] ODEint review
by Steven Watanabe 02 Oct '12

02 Oct '12

-------- Original Message -------- Subject: [Review] ODEint review Date: Fri, 28 Sep 2012 22:56:56 +0200 From: André Bergner <andre.bergner.0(a)gmail.com> To: boost(a)lists.boost.org CC: watanabesj(a)gmail.com === ODEINT REVIEW === I vote for 'YES'. The library ODEint should be accepted and integrated into boost. Boost features many scientific/numeric applications already. Differential equations are fundamental enough to be added to boost's math/numeric category and enhance the scientific use cases of boost. _____________________________________________ What is your evaluation of the design? ODEint features a modern C++ (concept based as opposed to of polymorphism) which improves performance and flexibility tremendously. It demonstrates very well the power of a functional programming style - algorithms and containers are separated strictly. In particular parallelization comes almost for free by 'just' changing the container type. This is one very nice feature I like a lot. The design allows inter-portability to a great extend. Pretty much everything can be exchanged and adapted to specific needs. _____________________________________________ What is your evaluation of the implementation? I did not dive into all the internals deeply. But from what I've seen ODEint is well implemented and its internal structure make sense. Here the well designed interface helps the internals to be structured clearly as well. _____________________________________________ What is your evaluation of the documentation? The documentation is pretty good. It is covering many use-cases in detail and demonstrates the high flexibility of ODEint (CUDE/thrust, etc.) with many examples (missing a lot in some other boost libs). It becomes clear how it is used and what can be done with it. Nevertheless, for somebody not familiar with the topic of differential equations the purpose of the library is unclear from a quick glance into the overview. I would extend the overview with a short introduction (one or two paragraphs, links to wikipedia) of the topic, especially with some demonstrative example in words (e.g. physics engine in computer games or something similar). Concerning a more technical detail of the lib, I would like to have one large html file instead of many linked small ones. This would improve reading and in particular searching a lot. Btw., this is also true for many other boost libraries. I miss some notes about ODEint and C++11 (e.g. some obvious such as lambda should be mentioned, what about literals as units). Further, from a mathematical point of view also some comments about the application to partial differential equations would be useful. For somebody with experience in the field this might be obvious but for a beginner this would be helpful. _____________________________________________ What is your evaluation of the potential usefulness of the library? ODEint has many applications in a huge amount of scientific and engineering fields. It has the potential to become the de-facto standard for solving ODEs and high performance computing. Further, some less obvious use-cases might be: particle systems (quite popular in entertainment apps these days), network layout algorithm, etc... Within its field of application this library is very feature complete and can compete with many standard libs (matlab, python, ...) with ease. I think that ODEint makes the best compromise between simplicity in use and computational performance while not giving up general flexibility. It also features many things (error correction, symplectic methods, ...) not present in many competing libraries. _____________________________________________ Did you try to use the library? With what compiler? Did you have any problems? I was using the library for quite some time with several compilers (gnu, clang, intel). _____________________________________________ How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I was using the library one year age intensively. However, within this year I was not using it due to a different working field of mine. But I was following its improvements. _____________________________________________ Are you knowledgeable about the problem domain? Yes, I used the library extensively. I was successfully combining it with boost::graph to integrate network of coupled differential equations. Best regards, --- André Bergner

1 0

[1.52.0] Release branch closed except by permission, beta next week
by Marshall Clow 02 Oct '12

02 Oct '12

Hello everyone, The release branch is now closed for all changes except by permission from one of the release managers. The beta release is planned for next Monday. Please can you write your entries for the release notes soon. As always you can edit them directly using subversion at: https://svn.boost.org/svn/boost/website/public_html/live/feed/history/ Or you can email them to Daniel James <dnljms(a)gmail.com>. The release notes are linked from the main page soon after the beta is released, so it would be complete by then. Thanks, -- Marshall

1 2

[iterator] Minor comment typo in iterator_facade.hpp
by Team OSS 02 Oct '12

02 Oct '12

Hi! Patch attached for fixing it. It's our first contribution to the open-source community ;) Best regards, NINJA

2 1

Boost Range Joined Range
by Ali Nakipoglu 02 Oct '12

02 Oct '12

How can i create copy a joined_range type and it contents? Any alternatives to make this? For example typedef std::vector<int> VectorT; typedef joined_range< VectorT, VectorT> JoinedRangeT; VectorT vector0, vector1; JoinedRangeT joinedRange0( vector0, vector1 ) // I need this JoinedRangeT joinedRange1 = copyAnyRangeOrContainer( joinedRange0 ); Im planning to use your advices to design copyAnyRangeOrContainer function, so that it can create deep copies from given range or containers that are can be vector,map, joined_range<T1,T2> or even joined_range<joined_range<T1,T2>, joined_range<T1, T2> > Thank you! -- Ali Nakipoglu

3 2

[BGL] graph/properties.hpp (vertex_property) [PATCH]
by Shaun Jackman 01 Oct '12

01 Oct '12

Hi, vertex_property and edge_property should inherit publicly from vertex_property_type and edge_property_type. A patch follows. ./ContigGraph.h:55:39: error: 'type' is a private member of 'boost::mpl::eval_if<boost::detail::has_vertex_property_type<DirectedGraph<ContigProperties, Distance>, mpl_::bool_<false>>, boost::detail::get_vertex_property_type<DirectedGraph<ContigProperties, Distance>>, boost::no_property>' typedef typename vertex_property<G>::type vertex_property_type; ^ /usr/local/include/boost/graph/properties.hpp:251:49: note: constrained by implicitly private inheritance here template <class Graph> class vertex_property: vertex_property_type<Graph> {}; ^~~~~~~~~~~~~~~~~~~~~~~~~~~ Cheers, Shaun --- graph/properties.hpp.orig 2012-09-27 11:37:48.000000000 -0700 +++ graph/properties.hpp 2012-10-01 10:43:34.000000000 -0700 @@ -248,8 +248,8 @@ >::type type; }; - template <class Graph> class vertex_property: vertex_property_type<Graph> {}; - template <class Graph> class edge_property: edge_property_type<Graph> {}; + template <class Graph> class vertex_property: public vertex_property_type<Graph> {}; + template <class Graph> class edge_property: public edge_property_type<Graph> {}; template <typename Graph> class degree_property_map

2 2

[coroutine review] late review + comments
by Jeffrey Lee Hellrung, Jr. 01 Oct '12

01 Oct '12

Apologies to Hartmut, Oliver, and the community for my late presence regarding the recently reviewed Coroutine library. I finally had a good block of time this afternoon/evening to look through the documentation [1], so I figured, even if Hartmut doesn't count this as a formal review, at least Oliver can use these comments to improve the documentation. First, if I were to vote on whether Coroutine should be accepted, it would be CONDITIONAL ACCEPTANCE just based on present documentation issues. At a minimum, the documentation needs some fixing up, but I also think Oliver should address the design and interface suggestions Vicente, Eugene, and others (I myself haven't yet gone through the entire discussion yet, though I've been meaning to) have had, which mostly seem to have merit, and then present an updated. Unfortunately, I can't come up with a specific list of said suggestions, but I trust Oliver can pick through the discussion as well as I can :/ Second, I would really like to see some form of this library in Boost :) One thing that benefits the documentation of a library with a seemingly nontrivial design space (like Coroutine) is a comparison with past and present solutions. A quick google search of "c++ coroutine" found 3 libraries that ostensibly implement coroutines or an approximation thereof [2-4]. I haven't gone through these quite yet, but I'd like to see why one should use the proposed Coroutine library over these alternatives (even a 1-line justification, like "Library X lacks critical feature Y, by design" or "Library X does not work on platform Z" would be sufficient.) I think some documented research to justify the existence of this library is warranted. My specific comments on the documentation follow (I just copy/pasted from a Google document, so I hope this doesn't format badly...). I'm pretty sure some of what's below repeats what someone else has said, but, for completeness, I just included everything that initially came to mind as I was reading the documentation. - Rename namespace boost::coro to (e.g.) boost::coroutine or something similarly spelled out and not (arguably cryptically) abbreviated. - "Executing a coroutine" - s/it can migrated/it can be migrated/ - The first example uses “coro_t c( boost::bind( f, _1 ) );”; I’m confused as f is a binary function, but the boost::bind expression only works for unary functions. - “The coroutine-function, as well as its arguments, if any, are copied into the coroutine's state.” Can you elaborate on what you mean by “its arguments...are copied into the coroutine’s state”? You must mean when you call the coroutine, i.e., the copying of the coroutine-function and the copying of the coroutine-function’s arguments occur at different times, right? - The example with output uses ctx when (I believe) you mean c. Also, it implies that coroutine<>::is_complete actually executes the coroutine-function, which seems non-intuitive to me; I would expect it to be non-modifying and only indicate whether the coroutine-function has completed or not. - s/preemtive/preemptive - “Calling coroutine<>::operator()() from inside the same coroutine results in undefined behaviour.” Can you give an example of how one could possibly mistakenly do this? - s/allways/always - “The arguments passed to coroutine<>::operator()(), in one coroutine, is returned by coroutine<>::self_t::yield() in the other coroutine or, if it is the first call to coroutine<>::operator()() ( coroutine was not started), the coroutine-function will be entered and the arguments are passed to coroutine-function on entry.” I think I know what you’re trying to say here, but talking about 2 coroutines when your examples only have one coroutine object is ripe for confusion. Either clarify your terminology, clarify this explanation of the signature, or both. - The fact that self_t::yield() must package its return value into a boost::tuple (when the coroutine-function has more than one argument beyond self) suggests to me that we should strive for more uniformity between how the coroutine-function is initially entered (now with explicitly separate arguments) and subsequently continued (now with a packaged set of arguments). A couple of suggestions: - Force all coroutine-functions to be nullary or unary (sans the self argument); one can manually address more than one argument via boost::tuple packaging, and maybe boost::coro::coroutine could automatically package >1 argument up into a boost::tuple to convenience. You may also want to provide a macro (named, e.g., BOOST_TUPLE_UNPACK) that can can unpack a tuple into variables, e.g., something that looks like BOOST_TUPLE_UNPACK( ( int x ) ( int y ), tuple ); - Use a coroutine-function signature that looks something like void f(coro_t::self_t & self) { BOOST_TUPLE_UNPACK( ( int x0 ) ( int y0 ), self.arguments() ); // … BOOST_TUPLE_UNPACK( ( int x1 ) ( int y1 ), self.yield() ); } Perhaps equivalently, one can always call self.arguments() to get the most recently passed set of arguments. - “coroutine-function with multiple arguments” - Isn’t the boost::bind in this example superfluous? - “Exit a coroutine-function” - yield_break or yield_return? You mention both. - There are 2 “Important” notes on forced_unwind exceptions that appear to say the same thing. - “Stack unwinding” - I’m starting to get really confused by your uses of boost::bind; “boost::bind( fn, _1 )” when fn is a nullary function??? I guess you forgot the self_t argument? If so, again, why is boost::bind even necessary? Did you check that these examples actually compile? - The default behavior of the destructor of always unwinding the stack seems entirely reasonable, but the preconditions you list seem entirely unreasonable and unsafe! Basically, I’m reading that { coro::coroutine< void ( ) > c; } results in undefined behavior, as the preconditions for the destructor are not met. This almost has to be a documentation error. Further: “After unwinding, a coroutine is complete.” I was under the impression that unwinding only occurs in the destructor of the coroutine, at which point the coroutine object does not exist anymore, so what coroutine are you referring to, and even if you’re referring to the recently destructed coroutine, in what way is it complete? - “Executing a generator” - s/The default StackAllocator concept/The default StackAllocator/ - Be consistent on when you use StackAllocator, stack-allocator, etc. I.e., what do you mean by each? - “The first argument of generator-function...”: You mean the *only* argument? - s/The generator-function executed/The generator-function is executed/ - Same notes as at the bottom of “Executing a coroutine”. - “Exit a generator-function” - Again, yield_break or yield_return? - “boost::bind( fn, _1, _2 )” ??? Huh? How is “a” bound within fn, then??? - s/self_yield/self.yield/ - It’s unclear to me why a separate generator class is provided in addition to the coroutine class. Can you explain what the differences are? E.g., I don’t see why coroutine can’t also have an operator unspecified-bool-type () rather than is_complete. - “Performance” - 10 doesn’t seem like a very convincing sample size. If you can’t nail down the CPU cycles and time exactly via theoretical analysis of the assembly code, then I don’t see what’s preventing you from using a sample size several orders of magnitude larger than 10! Okay, now time to go through the second half of the recent Coroutine discussion... - Jeff [1] http://ok73.ok.funpic.de/boost/libs/coroutine/doc/html/index.html [2] http://code.mozy.com/projects/mordor/ [3] http://www.akira.ruc.dk/~keld/research/COROUTINE/ [4] http://dunkels.com/adam/pt/

2 1

[spirit] Symbols parser with overlapping symbols
by Andrey Semashev 01 Oct '12

01 Oct '12

Hi, I wonder how qi::symbols parser behaves when it contains partially overlapping symbols. For example: qi::symbols< char, int > syms; syms.add("a", 1); syms.add("aaa", 2); What will this parser return when "aaa" is passed as input? I couldn't find it in the docs.

2 1