- Boost - lists.preview.boost.org

[optional] warning removal
by Vicente J. Botet Escriba 21 Oct '12

21 Oct '12

Hi, can I commit this simple patch Best, Vicente svn diff ../../../boost/optional/ Index: ../../../boost/optional/optional.hpp =================================================================== --- ../../../boost/optional/optional.hpp (revision 81020) +++ ../../../boost/optional/optional.hpp (working copy) @@ -890,12 +890,12 @@ template<class T> inline -bool operator == ( none_t x, optional<T> const& y ) +bool operator == ( none_t , optional<T> const& y ) { return equal_pointees(optional<T>() ,y); } template<class T> inline -bool operator < ( none_t x, optional<T> const& y ) +bool operator < ( none_t , optional<T> const& y ) { return less_pointees(optional<T>() ,y); } template<class T>

3 3

[thread] Integration with Chrono and DateTime (was: [release][1.52] Release Notes)
by Andrey Semashev 20 Oct '12

20 Oct '12

On Oct 13, 2012 12:10 AM, "Vicente J. Botet Escriba" < vicente.botet(a)wanadoo.fr> wrote: > > Le 12/10/12 21:51, Andrey Semashev a écrit : > >> On Oct 12, 2012 8:35 PM, "Vicente J. Botet Escriba" < >> vicente.botet(a)wanadoo.fr> wrote: >>> >>> Hi, >>> Why you don't want to depend on Boost.Chrono? >> >> Because I want to minimize dependencies (especially, binary build >> dependencies). > > Me too, I want to limit dependencies :) Fair enough. Perhaps, we could absract away Boost.Thread from both libraries? Seems like a logical solution for a case like this. For example, Boost.Thread could define an internal interface for integrating with time units from different libraries. Chrono and DateTime would support this interface, and Boost.Thread could also provide the necessary glue for std::chrono integration. I think, Boost.Thread could use its own time units internally and use ADL-found functions to convert from other time units. Boost.Thread will not depend on either timing library then. Does this look viable? >> Unlike Boost.DateTime, Boost.Chrono is not needed by my library, so this >> would really be a false dependency. > > If you don't need time related thread facilities you could set BOOST_THREAD_DONT_USE_CHRONO. Would this work for you? Yes, that's what I'm doing now. I'm using DateTime units for timed functions. >> I understand that the dual interface adds more redundancy but does it >> really require active maintenance? The code has been there for quite some >> time, it's well tested and doesn't require additional work. >> >> > Any addition code has its influence on how the library could evolve. I really would prefer to remove these interfaces for Boost 1.56. I think that 1 year and a half is enough time to move to the new interface. Then I think library decoupling is the right way even more.

5 15

Boost.log: set_channel name dynamically for a basic_composite_logger
by syvyi 20 Oct '12

20 Oct '12

Hi, how to set attribute dynamically for a composite logger? lass my_logger_mt : public src::basic_composite_logger< char, my_logger_mt, src::multi_thread_model<boost::log_mt_nt5::aux::light_rw_mutex>, src::features< src::severity< severity_levels >, src::exception_handler, src::channel< std::string > > > { BOOST_LOG_FORWARD_LOGGER_CONSTRUCTORS(my_logger_mt) }; -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-log-set-channel-name-dynamically-f… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 34

[thread] deprecating Mutex::scoped_lock and Mutex::scoped_try_lock and boost::condition
by Vicente J. Botet Escriba 20 Oct '12

20 Oct '12

Hi, I would like to deprecate the following features in Boost.Thread: * Mutex::scoped_lock and Mutex::scoped_try_lock so that we can make mutex types independent from locks. The user should use instead unique_lock<Mutex> and the new public class try_unique_lock. * condition: This was there for forward compatibility since 1.35. The user should use instead condition_variable_any. What do you think? Best, Vicente

4 9

boost::python feature request: unique_ptr, interfaces and factory functions
by Maxim Yegorushkin 20 Oct '12

20 Oct '12

Hi Boost, I am using boost::python to expose a C++ API into Python. The class I would like to export is: struct Subscriber { virtual ~Subscriber() = 0; static std::unique_ptr<Subscriber> create(); }; It's an interface with a factory function returning a std::unique_ptr<>. I would like to be able to export it in the following manner: BOOST_PYTHON_MODULE(pub_sub) { boost::python::class_< Subscriber , std::unique_ptr<Subscriber> , boost::noncopyable >("Subscriber") .def(boost::python::init<>, Subscriber::create) ; ; } I.e., the python wrapper would hold a std::unique_ptr<Subscriber> and use Subscriber::create() factory function as a constructor for Python Subscriber class. The above code doesn't compile with boost-1.51.0 for two reasons: * std::unique_ptr<> is not supported by boost::python. On the other hand, std::auto_ptr<> is. * The factory function can't be used used as a Python object constructor. I thought there could be a way to specialize certain boost::python traits/metaclasses to make it work with std::unique_ptr<> and factory functions as constructors, but couldn't figure it out. The workaround I managed to get working is: std::auto_ptr<Subscriber> createSubscriber() { return std::auto_ptr<Subscriber>(Subscriber::create().release()); } BOOST_PYTHON_MODULE(pub_sub) { // Expose the class. boost::python::class_< Subscriber , std::auto_ptr<Subscriber> , boost::noncopyable >("Subscriber_", boost::python::no_init) ; ; // Expose its factory function. boost::python::def("Subscriber", createSubscriber); } I.e., std::unique_ptr<> gets replaced with std::auto_ptr<>, the Python class is renamed to Subscriber_ and the factory function gets exported as Subscriber allowing for Python syntax: import pub_sub s = pub_sub.Subscriber() # however assert isinstance(s, pub_sub.Subscriber) # fails assert isinstance(s, pub_sub.Subscriber_) # succeeds So, I was wondering if there are ways to make my original Python class export syntax work? -- Maxim

1 0

[test] new features use c++11 features
by Jürgen Hunold 19 Oct '12

19 Oct '12

Hi Gennadiy, the new features introduced in revision 81010 and81011 use c++ features unconditionally. This breaks compilation of Boost.Test on all older compilers. Even the recent gcc-4.6 (Ubuntu 12.04). The critical places are: std::tuple std::shared_ptr std::false_type std::remove_cv those can be replaced with std::tr1:: equivalents using boost/tr1. See a quick patch attached. The usage of std::enable_if is critical, as I could not find it in boost::tr1. But this should be available as boost::enable_if and be detected by the appropriate Boost.Config macro. And at least gcc-4.6.3 ist missing the angle bracket hack, so closing ">>" template argument lists are interpreted as operator >>. Also patched. Could you please try your changes with an older compiler first? As I can not use c++11 at the moment (I'm stuck with gcc-4.2) I would like to use the new features with this older compiler. 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 4

[iterator] Using zip_iterator with std::pair
by "Claas H. Köhler" 19 Oct '12

19 Oct '12

Hi! I would like to use the boost::zip_iterator with std::pair. Unfortunately this does not work out of the box, but there exists a namespace boost::detail::tuple_impl_specific, which apparently needs to be specialised for each tuple type. I managed to re-implement tuple_meta_transform and tuple_meta_accumulate for std::tuple, which seems to be straightforward. However, there are functions of the form template<typename Tuple, typename Fun> complex_result_type tuple_transform(const Tuple&, Fun) which have to be overloaded as well, if I am not mistaken. However, overloading this with something like template<typename... Args, typename Fun> complex_result_type tuple_transform(const std::tuple<Args...>&, Fun) is probably not going to work, since this would be a partial template specialisation of a function. What is the recommended way of proceeding here? Or am I making things to complicated and there exists a simpler solution to using the zip iterator with std::pair / std::tuple. Any support would be appreciated. Regards Claas P.S: I am using boost 1.50 with gcc-4.6 and the C++11 standard.

3 11

[graph] dijkstra_shortest_paths solution stability
by Jan Hudec 18 Oct '12

18 Oct '12

Hello All, I need to implement an algorithm, that uses dijkstra's algorithm as key component. However it has two additional requirements on it: 1. If for any two vertices u, v there is an edge and a path of the same length through additional vertices, the direct edge is always selected and 2. If for any two vertices u, v there is more than one shortest path, all calculates shortest path trees that include path u, v contain the same path between those vertices. Now the article that describes the algorithm uses additional property with random values to disambiguate the paths, but I am sure the following two simple rules will achieve the effect more easily: 1. When u is reached at the same distance through two vertices, v and w, the one with lower distance from start will be used in the shortest path tree. 2. When u is reached at the same distance through two vertices, v and w, that both have the same distance from start, the one that comes first in some arbitrary fixed total ordering will be used inthe shortest path tree. These rules are trivially implementable by: 1. Not updating the parent map if the new distance is not strictly less. 2. Using additional criterion in the heap comparing the vertices by index or descriptor if they have the same tentative distance. Now I suspect rule 1 is already satisfied though it's not documented. And if rule 2 is not satisfied, would it be more generally useful and worth, possibly optionally, implementing in the library? -- Jan 'Bulb' Hudec <bulb(a)ucw.cz>

3 2

Fix some "unused variable" warnings
by Martin Martin 18 Oct '12

18 Oct '12

Hi, I'm using boost with clang++, with some style-related warnings turned on, and got a few warnings for unused variables. Here's the patch; are you interested in these changes? If so, is there a better way to get them to you? Thanks, Martin --- boost_1_51_0/boost/date_time/dst_rules.hpp 2008-02-27 15:00:24.000000000 -0500 +++ boost_1_51_0-fixed/boost/date_time/dst_rules.hpp 2012-10-18 09:31:08.433591299 -0400 @@ -369,11 +369,11 @@ const time_duration_type&) { return is_not_in_dst; } - static bool is_dst_boundary_day(date_type d) + static bool is_dst_boundary_day(date_type) { return false; } static time_duration_type dst_offset() diff '--unified=5' -r boost_1_51_0/boost/optional/optional.hpp boost_1_51_0-fixed/boost/optional/optional.hpp --- boost_1_51_0/boost/optional/optional.hpp 2010-12-18 16:29:39.000000000 -0500 +++ boost_1_51_0-fixed/boost/optional/optional.hpp 2012-10-18 09:31:50.737591130 -0400 @@ -888,16 +888,16 @@ // none vs optional<T> cases // template<class T> inline -bool operator == ( none_t x, optional<T> const& y ) +bool operator == ( none_t, optional<T> const& y ) { return equal_pointees(optional<T>() ,y); } template<class T> inline -bool operator < ( none_t x, optional<T> const& y ) +bool operator < ( none_t, optional<T> const& y ) { return less_pointees(optional<T>() ,y); } template<class T> inline bool operator != ( none_t x, optional<T> const& y )

2 1

[container] #7531 shadowing warnings under gcc
by Jeffrey Lee Hellrung, Jr. 18 Oct '12

18 Oct '12

Ion: I just wanted to make sure you see this. I can identify and make the necessary changes to trunk then release if you want me to. https://svn.boost.org/trac/boost/ticket/7531 Thanks, - Jeff

1 0

[graph] Efficiency of index map in dijkstra_shortest_paths
by Jan Hudec 18 Oct '12

18 Oct '12

Hello, The dijkstra_shortest_paths function requires an index map that maps vertices to index in range [0, num_vertices(g)). However there are several practially important algorithms that requite calculating shortest path trees with many times from each vertex, but each tree only spanning small fraction of an otherwise huge graph. I am somewhat concerned about allocating arrays of the size of the graph (that has millions of vertices) over and over (hundred million or more times) when many scans will stop after hundreds of vertices. Note that filtering the graph is not an option, because the stopping condition is given by radius or number of scanned vertices, but you obviously don't know which vertices will be scanned. Is there an option to use associative container for the queue indices? Or would it be useful to add it? Thanks Jan -- Jan 'Bulb' Hudec <bulb(a)ucw.cz>

3 5

[pool2] Requests for comment
by DUPUIS Etienne 18 Oct '12

18 Oct '12

Greetings, I am currently working on a replacement for boost ::pool. I have a few questions regarding what would be an ideal implementation. Hopefully some members of the Boost mailing list will be able to help me answering these questions. The first question requires to look at the source code; my other questions are more general. First question : I have started by defining a pool object which manage fixed size buffers of a given object type. Documented code is found here : http://svn.boost.org/svn/boost/sandbox/pool2/boost/pool/pool.hpp. The code is short and hopefully well documented. Note that the 'ThreadSafe' template parameter is currently ignored; I have not implemented thread safety yet. My question is about the "pool growth policy". This policy defines how the pool grows when it needs to allocate more memory. This policy is given as a parameter to the pool constructor. Should this policy be a template argument instead ? Moreover, if the policy is a template argument, I could add a constant 'MaximumNumberOfTimesThePoolWillBeGrown' into the policy class. This constant would allow me to replace the std::vector() which holds allocated pointers with a static array. Is this the right solution ? Other questions : - I have defined a pool class which manage fixed sized buffers of some object T. Do we also need a pool class that can manage variable sized buffers of some object T ? - From a pool, I can implement a pool_allocator which inherits from std::allocator, exactly like it was done in the original boost::pool. Do we need something else ? Thank you for your valuable insights, Etienne Dupuis Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute modification, édition, utilisation ou diffusion non autorisée est interdite. Si vous avez reçu ce message par erreur, merci de nous en avertir immédiatement. ATEME décline toute responsabilité au titre de ce message s'il a été altéré, déformé, falsifié ou encore édité ou diffusé sans autorisation. This message and any attachments are confidential and intended solely for the addressees. Any unauthorized modification, edition, use or dissemination is prohibited. If you have received this message by mistake, please notify us immediately. ATEME decline all responsibility for this message if it has been altered, deformed, falsified or even edited or disseminated without authorization. Note: To protect against computer viruses, e-mail programs may prevent sending or receiving certain types of file attachments.

9 20

[coroutine] final version?
by Oliver Kowalke 17 Oct '12

17 Oct '12

a final (?) version of boost.coroutine is available at http://ok73.ok.funpic.de/boost-coroutine.zip In contrast to the original concept coroutine<> is not similar to a function/functor. 1.) the coroutine-fn is started at construction of coroutine<> - helps to solve some problems related to the last 'yield'-operation - similar to the behaviour of boost::thread - arguments which have to be the first arguments of coroutine-fn must be applied to coroutine<>-ctor (arguments()) 2.) coroutine<>::operator() returns a reference to the coroutine instead the return-value 3.) return-values must be accessed via coroutine<>::get() regards, Oliver

2 2

[smart_ptr] [shared_ptr] BOOST_NOEXCEPT patch
by Antony Polukhin 17 Oct '12

17 Oct '12

Hi, There is a trivial patch in ticket #7523 that marks some functions of Boost.SmartPtr library as noexcept. I'll test the patch for some more time and if there will be no objections, I'll commit it to trunk after boost_1_52_0 release. Any suggestions and comments are welcomed. -- Best regards, Antony Polukhin

1 0

[lexical_cast] cast of int8_t
by Jochen Wilhelmy 16 Oct '12

16 Oct '12

Hi! In a previous message I asked if lexical_cast could throw boost::numeric::positive_overflow when the parsing is ok but the value too large for the target type. this turned out to be difficult because it breaks existing code, alternatively there could be another exception derived from bad_lexical_cast that indicates the overflow but this seems to be a lot of work. another question is why does lexical_cast treat int8_t and uint8_t like char? technically I see no reason for this as c++ has three types: char, signed char and unsigned char. in my code I use only char for characters and signed/unsigned char as numbers. I know that the standard stream operator << treats signed/unsigned char as char but I know no explanation for this (I consider it a bug ;-) -Jochen

5 4

[type_erasure] any and shared_ptr
by Christophe Henry 16 Oct '12

16 Oct '12

Hi Steven, I need to use the associated types but don't get them to do what I need. Consider struct Pointee : public boost::enable_shared_from_this<Pointee> { void foo() { std::cout << "Pointee::foo called" << std::endl; //shared_from_this(); std::cout << "Pointee::foo end" << std::endl; } }; Pointee needs to be enable_shared_from_this for some reason, which forces me to use it in a shared_ptr. I reused your pointee / pointer structures: template<class T> struct pointee { typedef typename mpl::eval_if< boost::type_erasure::is_placeholder<T>, mpl::identity<void>, boost::pointee<T> >::type type; }; template<class T = _self> struct pointer : mpl::vector< copy_constructible<T>, dereferenceable<deduced<pointee<T> >&, T> > { typedef deduced<pointee<T> > element_type; }; I (naively) tried to define a pointee concept: typedef mpl::vector< pointer<>, same_type<pointer<>::element_type,_a >, relaxed_match, has_foo<void()> > PointeeConcept; // will not compile, shared_ptr<Pointee> has no foo... boost::shared_ptr<Pointee> p (new Pointee) ; any<PointeeConcept> ap (p); ap.foo(); So in the end I had to resort to a wrapper: struct PointeeWrap { PointeeWrap(boost::shared_ptr<Pointee>p):myPointee(p){} void foo() { std::cout << "PointeeWrap::foo called" << std::endl; myPointee->foo(); } boost::shared_ptr<Pointee> myPointee; }; BOOST_TYPE_ERASURE_MEMBER((has_foo), foo, 0); typedef any< mpl::vector< relaxed_match, copy_constructible<>, has_foo<void()> > > AnyPointee; boost::shared_ptr<Pointee> p (new Pointee); PointeeWrap wrap(p); AnyPointee ap(wrap); ap.foo(); But this will become tedious with an increasing number of members. Is there a better way? Thanks, Christophe

2 2

[mpl] Nested BOOST_MPL_ASSERT fails on VC11
by Steven Watanabe 15 Oct '12

15 Oct '12

AMDG I just ran into the following bug: template<class T> struct test : T { BOOST_MPL_ASSERT((T)); }; BOOST_MPL_ASSERT((test<T>)); I've reworked BOOST_MPL_ASSERT to avoid the problem in the attached patch. Okay to commit? In Christ, Steven Watanabe

3 4

[GIL] default_color_converter from float to integer should clamp
by Fabien Castan 15 Oct '12

15 Oct '12

Hi, The conversion from floating point image to 8 bits or 16 bits image should clamp instead of writing arbitrary values... // a floating point image, with some pixel values < 0.0 and > 1.0 boost::gil::rgba32f_view_t HDR; // use default_color_converter to convert this HDR image to 8 bits boost::gil::png_write_view( "LDR.png", boost::gil::color_converted_view<boost::gil::rgba8_pixel_t>( HDR ) ); The 8 bits LDR image contains arbitrary cast conversion values, that are not very nice. The conversion from floating point to integer values has no other valid solution than clamping. So I suggest this patch, for the file "boost/gil/channel_algorithm.hpp": @@ -272,7 +272,13 @@ template <typename DstChannelV> struct channel_converter_unsigned<bits32f,DstChannelV> : public std::unary_function<bits32f,DstChannelV> { DstChannelV operator()(bits32f x) const { typedef typename detail::unsigned_integral_max_value< DstChannelV >::value_type dst_integer_t; - return DstChannelV( static_cast< dst_integer_t >(x*channel_traits<DstChannelV>::max_value()+0.5f )); + + const bits32f convertedValue = x * channel_traits<DstChannelV>::max_value() + 0.5f; + const bits32f clampedValue = std::min( + (bits32f)channel_traits<DstChannelV>::max_value(), + std::max( (bits32f)channel_traits<DstChannelV>::min_value(), convertedValue ) ); + + return DstChannelV( static_cast< dst_integer_t >(clampedValue) ); } }; Regards, Fabien Castan

3 2

[asio::ssl] TLS support
by ToBeKi＠gmx.de 15 Oct '12

15 Oct '12

Hello all, in asio::ssl context/context_base i couldn't find any TLS 1.1/1.2 method implementations. Is it missing/not supported yet? If so is there a roadmap supporting versions 1.1/1.2? Best, kito

1 0

[config] call to destructor of temporary
by Vicente J. Botet Escriba 15 Oct '12

15 Oct '12

Hi, I have had some trouble debugging some code with clang-2.9 c++0x. The reason was a known bug on the compiler as it doesn't call the destructor of temporaries at the end of the expression. Is there a macro stating this missing feature? Best, Vicente

4 4

maybe a bug in boost.iostreams
by leiming2006 15 Oct '12

15 Oct '12

Hello, I'm using boost 1.5.1 in windows 7 with vc 2010 express. today I'm trying using boost.iostreams with audio samples, whose char_type is not char or wchar_t. thought I failed at the end, but I guess that I found a bug in the library. In the file boost\iostreams\chain.hpp, line 136, I wonder if it's typedef linked_streambuf<Ch, Tr> streambuf_type; not typedef linked_streambuf<Ch> streambuf_type; Regards, LeiMing

1 0

[program options] Support for storage to 'optional' objects
by Chris Glover 15 Oct '12

15 Oct '12

Hi, Recently when using the Boost Program options library, I was surprised to find that I was unable to pass a boost.optional object to store supplied options in. For example; namespace bpo = boost::program_options; boost::optional<std::string> opt_str; bpo::options_description desc("Allowed options"); desc.add_options() ("help", "produce help message") ("opt", bpo::value(&opt_str), "Something optional") // Store value of 'opt' in 'opt_str' ; What I expected to happen would be that 'opt_str' would be valid if 'opt' is supplied by the user, and not valid otherwise. However, the above code causes a compile error deep within lexical_cast because, of course, performing such an operation on a boost.optional doesn't make sense. The attached patch to Program Options rectifies the issue by filtering out optional objects within before calling lexical_cast, but to be honest, I'm not sure if this is the correct approach or if this is even a desirable feature. I like the idea of setting an optional object this way instead of testing the variables_map later on, but perhaps there's something I am missing or a better way to accomplish the same thing. Please have a look and let me know your thoughts. Thanks, -- chris

1 0

[contract] concepts: pseudo-signatures vs. usage patterns
by Lorenzo Caminiti 14 Oct '12

14 Oct '12

On Tue, Oct 9, 2012 at 7:16 PM, Dave Abrahams <dave(a)boostpro.com> wrote: > on Tue Oct 09 2012, Lorenzo Caminiti <lorcaminiti-AT-gmail.com> wrote: >> >> 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): >> [...] >> Please tell me what you think now > > Since you asked what I think, > > "pseudo-signatures > usage patterns" Hello all, Can we write down pros and cons for concepts implemented via pseudo-signatures (C++0x-like and Boost.Generic) vs. usage patterns (N3351 and Boost.Contract)? Who wants to start? Matt, Dave, Andrzej, ... I can compile a qbk table with what we discuss. Thanks. --Lorenzo

10 68

[quickbook] Cross-Referencing Source-Snippets
by Matt Calabrese 14 Oct '12

14 Oct '12

I'm currently documenting the Generic library and the documentation itself imports a lot of code from the source files directly (the best documentation for a concept generally involves showing the concept definition itself, and importing it means the code won't be out of sync with the documentation). This imported source code references other concepts and I'd like to be able to have each one of these referenced concepts be a clickable link that brings the person to the documentation for that concept (I.E. in http://generic.nfshost.com/generic/standard_concepts/concepts/equivalencere… the user should be able to click on "Predicate" in the imported source code to see the documentation for the Predicate concept). So, I tried the simplest solution -- make a quickbook macro called Predicate that results in a link to the corresponding Predicate documentation. After a quick test, everything worked fine with one exception -- the name of the section linked to is also "Predicate" and that seems to be causing the link in the generated table of contents to no longer work properly, pointing to a page that doesn't exist even though it displays the link with the proper name (note that the cross-reference links still seem to work fine, it's just the links in the table of contents that break). I realize that I'm doing something hacky here, so if anyone has a better solution, let me know. If this is the best approach, is there a way that I can keep the name of the section the same as the macro name? I.E. Is there some trick I can use to prevent the macro from being expanded when I use it in the section declaration? Keep in mind that I can't simply use templates here instead of macros because the macros are expanded from within imported, working code snippets. I also can't postpone defining the macro until after the section is declared since sections are presented in alphabetical order, meaning that an earlier section's code may reference a later section's code based on dependencies. -- -Matt Calabrese

2 2

[pointee] partially specialize for pointer types?
by Jeffrey Lee Hellrung, Jr. 14 Oct '12

14 Oct '12

Right now, boost::pointee<T*> is evaluated to T via evaluation of boost::detail::is_incrementable<T*>. Unfortunately, this causes a hard error when T is incomplete. See [1] for motivation on why this might be undesirable. It seems there's no loss in partially specializing boost::pointee for pointer types to allow it to be used for incomplete types. Ditto for boost::indirect_reference. Are there issues with this that I might be missing? As both pointee and indirect_reference seem to fall under the purview of Boost.Iterator, I would take responsibility of making this change and adding appropriate unit tests for the incomplete type case. - Jeff [1] https://svn.boost.org/trac/boost/ticket/5965

1 0

Terminology check.
by Larisse Voufo 14 Oct '12

14 Oct '12

Hello -- What would happen to be the C++ word for: name lookup + overload resolution? I would have thought it was "name resolution", but the standard seems to be suggesting otherwise. Thanks, -- Larisse.

2 1

[iterator] [documentation] need help generating
by Jeffrey Lee Hellrung, Jr. 13 Oct '12

13 Oct '12

I'm a n00b regarding Boost's documentation generation. I've gone through https://svn.boost.org/trac/boost/wiki/BoostDocs/GettingStarted to set up my system (Windows 7, MSVC9, try to do everything from the Windows command line). I then navigate to trunk\libs\iterator\doc and run b2 (the b2 I have from the 1.51.0 release; would that matter?). I get -------- don't know how to make <p..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug\threading-multi-object(xinclude-scanner)@987>iterator.xml ...found 37 targets... ...updating 5 targets... ...can't find 1 target... ...can't make 2 targets... common.mkdir ..\..\..\bin.v2\libs\iterator\doc common.mkdir ..\..\..\bin.v2\libs\iterator\doc\msvc-9.0 common.mkdir ..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug common.mkdir ..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug\threading-multi quickbook.quickbook-to-boostbook ..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug\threading-multi\iterator.xml Generating Output File: ..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug\threading-multi\iterator.xml quickbook\iterator.qbk:24: warning: Quickbook version undefined. Version 1.1 is assumed quickbook\concepts.qbk:159: warning: line breaks generate invalid boostbook (will only note first occurrence). quickbook\facade.qbk:491: warning: in column:6, unexpected character: ` [...lots more warnings of this nature...] quickbook\facade.qbk:612: warning: in column:52, unexpected character: ` quickbook\utilities.qbk:77: warning: in column:14, unexpected character: ` quickbook\utilities.qbk:77: warning: in column:44, unexpected character: ` quickbook\utilities.qbk:79: warning: in column:12, unexpected character: ` quickbook\utilities.qbk:79: warning: in column:15, unexpected character: ` quickbook\utilities.qbk:109: warning: in column:14, unexpected character: ` quickbook\utilities.qbk:109: warning: in column:46, unexpected character: ` ...skipped <p..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug\threading-multi>iterator.docbook for lack of <p..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug\threading-multi-object(xinclude-scanner)@987>iterator.xml... ...skipped <phtml>standalone_HTML.manifest for lack of <p..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug\threading-multi>iterator.docbook... ...skipped 2 targets... ...updated 6 targets... -------- Then I run it again: -------- ...found 37 targets... ...updating 2 targets... xslt-xsltproc.windows ..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug\threading -multi\iterator.docbook xslt-xsltproc-dir.windows html\standalone_HTML.manifest Error: no ID for constraint linkend: indirecct. ...updated 2 targets... -------- This seems to throw everything into trunk\libs\iterator\doc\html. However, these generated html documents don't seem to be the same as those in the Boost releases. For example, the table of contents is deeper in the generated index.html than the 1.51.0 release one (which looks be identical to trunk/libs/iterator/doc/index.html), and it lacks documentation for function_input_iterator. It seems like I'm doing something wrong, and I'm not really sure what to make of the various errors and warnings I'm getting. Would anyone be kind of enough to help me out here? Oh, my user-config.jam file, located in "C:/Users/Jeffrey/", looks like -------- using xsltproc : C:/Users/Jeffrey/boost-tools/libxslt-1.1.26.win32/bin/xsltproc.exe ; using boostbook : C:/Users/Jeffrey/boost-tools/xml/docbook-xsl-1.77.1 : C:/Users/Jeffrey/boost-tools/xml/docbook-xml-4.2 ; using quickbook : %BOOST_ROOT%/dist/bin/quickbook ; -------- BOOST_ROOT refers to my Boost 1.51.0 installation, and C:/Users/Jeffrey/boost-tools/bin is part of my path. Let me know if other information is needed. TIA, - Jeff

2 3

[addressof] Intel C++ 13 Warning (Cannot be suppressed)
by Joshua Boyce 13 Oct '12

13 Oct '12

addressof.hpp causes a warning under Intel C++ 13 when using the highest warning level, which cannot be suppressed using the regular #pragma directives. This causes problems when compiling user code with warnings as errors, as the header causes an error which cannot be disabled. The root of the issue seems to be that ICC thinks that an rvalue is being passed to a function which takes a non-const ref, however in this case I think it's a false positive (ICC apparently isn't smart enough to notice and analyze the implicit conversion operator). My simple workaround is to turn the temporary into an lvalue and pass that instead. After making this change I tested under MSVC 12, GCC 4.7, ICC 13, and Clang 3.1 (all under Windows) and recorded no changes in number of failed compiles or tests. Is this an acceptable change that could be merged into trunk? Thanks.

1 1

[contract] toward N3351 concepts
by Lorenzo Caminiti 13 Oct '12

13 Oct '12

Hello all, I'm reading N3351: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3351.pdf It's a bottom-up approach to define concepts starting from what's needed by STL algorithms. So far so good--I like it probably more than C++0x concept proposals--N331 is simpler :) However, N3351 STL design is not fully compatible with the current STL specifications--maybe N3351 is better, more mathematically sound? In N3351, concepts are boolean constants: ``We can define concepts as simple (constant) Boolean expressions. This is useful when building constraints predicated on non-syntactic and non-semantics properties of types.`` So I can implement concepts in C++11 as boolean meta-functions using expression SFINAE to check the requirements and enable_if to disable generic algorithms when the instantiated types don't model the concepts (i.e., the concept's boolean meta-function is false). For example, that's the case for the bool{a== b} and bool{a!=b} expressions of the EqualityComparable concept below. However, N3351 says that axioms should not be checked by the compiler... ``Axioms express the semantics of a concept’s required syntax; they are assumed to be true and must not be checked by the compiler beyond conformance to the C++ syntax. Any additional checking is beyond the scope of the compiler’s translation requirements. The compiler must not generate code that evaluates axioms as preconditions, either. This could lead to program errors if the evaluated assertions have side effects. For example, asserting that distance(first, last) > 1 when the type of those iterators is istream_iterator will consume the first element of the range, causing the assertion to pass, but the algorithm to have undefined behavior.'' So what am I supposed to do with axioms? Do nothing? Axioms are just "comments" that document the semantic? For example: `` concept EqualityComparable<typename T> = requires (T a, T b, T c) { bool { a == b }; bool { a != b }; axiom { a == b <=> eq(a, b); } // true equality axiom { a == a; // reflexive a == b => b == a; // symmetric a == b && b == c => a == c; // transitive } axiom { a != b <=> !(a == b); } // complement }; So, EqualityComparable<T> is true if T 1. has == and != with result types that can be converted to bool 2. == compares for true equality 3. == is reflexive, symmetric, and transitive 4. != is the complement of == However, the compiler can only check the first of these conditions. The rest must be verified through other means (i.e. manually). '' Thanks, --Lorenzo

16 82

Re: [boost] Boost CRC maintainer (Daryle Walker) missing in action?
by Olaf van der Spek 13 Oct '12

13 Oct '12

On Sat, Mar 10, 2012 at 2:06 PM, Olaf van der Spek <ml(a)vdspek.org> wrote: > On Mon, Nov 28, 2011 at 1:11 AM, Daryle Walker <darylew(a)gmail.com> wrote: >> I can look at it once I've finished my new setup. >> >> I had to reset my computer after a partial crash years ago. I never >> got around to recreating my programming setup. My computer had been >> at its maximum Operating System level back then, which is now 3 >> versions behind. For the past few months, I've had my sister's old >> laptop, with Windows Vista, and am trying to add a programming setup >> to it now. > > Hi Daryle, > > Any updates on these two? > > https://svn.boost.org/trac/boost/ticket/3030 > https://svn.boost.org/trac/boost/ticket/5970 Mr Walker? Have you gone missing in action again? :( -- Olaf

1 0

[1.52] compile errors with xcode / apple llvm 4.1
by Jochen Wilhelmy 13 Oct '12

13 Oct '12

Hi! Had anybody success in compiling an own project that uses boost with xcode 4.5.1 / apple llvm 4.1? I get this error: In file included from /Users/jwilhelmy/Coding/Install/include/boost/type_traits.hpp:35: In file included from /Users/jwilhelmy/Coding/Install/include/boost/type_traits/has_operator.hpp:42: In file included from /Users/jwilhelmy/Coding/Install/include/boost/type_traits/has_post_decrement.hpp:34: .../boost/type_traits/detail/has_postfix_operator.hpp:143:109: error: expected expression BOOST_STATIC_CONSTANT(bool, value = (sizeof(check(((make<Lhs>() BOOST_TT_TRAIT_OP),make<has_operator>())))==sizeof(::boost::type_traits::yes_type))); ^ .../boost/config/suffix.hpp:392:72: note: expanded from macro 'BOOST_STATIC_CONSTANT' # define BOOST_STATIC_CONSTANT(type, assignment) static const type assignment ^ -Jochen

1 0

build err Boost 1.51.0 for PPC64 - is this a real error?
by david.hagood＠gmail.com 12 Oct '12

12 Oct '12

I have a reproducible error attempting to build Boost 1.51.0 for a PPC64 system: libs/context/src/asm/fcontext_ppc64_sysv_elf_gas.S:225: Error: syntax error; found `@', expected `,' libs/context/src/asm/fcontext_ppc64_sysv_elf_gas.S:225: Error: junk at end of line: `@plt' libs/context/src/asm/fcontext_ppc64_sysv_elf_gas.S:249: Error: syntax error; found `@', expected `,' libs/context/src/asm/fcontext_ppc64_sysv_elf_gas.S:249: Error: junk at end of line: `@plt' I've seen one other person report this online, but I've seen no follow-ups. 1) Is this a known issue in 1.51.0? 2) Is there a patch? 3) Should I try the 1.52.0 Beta instead? I'd rather not spend all the time building it to find there is an issue. I have 1.51.0 for PPC32, i686, X86_64, and ARM - it's just the PPC64 that fails.

2 2

Augmented trees
by Phil Endecott 12 Oct '12

12 Oct '12

Dear Experts, I find myself in need of an augmented tree. My problem is something like [but not exactly] this: - Say I have a line of text, i.e. a sequence of characters, in a variable-width font; each character stores its width in pixels. - I need to efficiently insert and remove characters. - I need to efficiently find the range of characters that spans a given range of pixels. It seems to me that an augmented tree lets me do all of those operations in log(N) time - and no other data structure offers the same performance. I'm aware of two augmented trees that have been proposed here. Francisco Jose Tapia has proposed "Countertree", but this only stores the count of elements not the sum of a property of the elements (i.e. the widths in my example). Vadim Stadnik has proposed stl_ext_adv, which is a doubly-augmented B+ tree. Has anyone looked at Vadim's code since it was proposed last year? I have a couple of concerns about Vadim's proposal: 1. It uses B+ trees, and in the discussion it was suggested that these are inferior to red-black trees in some way. 2. In order to get the property to be accumulated (i.e. the widths in my case) it requires that arithmetic can be done on the stored type itself; this is fine for e.g. a sequence of ints, but if the stored type is a struct it is necessary to add various "unnatural" operator overloads. I think I would prefer it to have some sort of user-supplied accessor to get the property to be accumulated. Is there any other work that I've overlooked? Is there a "friendly" red-black tree implementation somewhere that could be augmented relatively easily? Regards, Phil.

8 9

[1.52.0] Beta1 release available
by Daniel James 11 Oct '12

11 Oct '12

Boost release 1.52.0 beta 1 is now available from SourceForge See https://sourceforge.net/projects/boost/files/boost/1.52.0.beta.1/ This release contains numerous enhancements and bug fixes for existing libraries. For details of what's in the release, see http://www.boost.org/users/history/version_1_52_0.html. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

4 8

[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

[1.52.0] [request permission to merge to release] Changeset 80790
by Jeffrey Lee Hellrung, Jr. 30 Sep '12

30 Sep '12

As I was updating the Release Notes for 1.52.0, I thought about a recently introduced restriction on function_input_iterator (due to addressing ticket #5825 [1] in [2]) that could be relaxed. trunk changeset is here: https://svn.boost.org/trac/boost/changeset/80790 I think it's pretty benign but given that the release branch is closed tomorrow (Monday) and the beta rc is just a few days after that, I figured that whether and when this gets merged to release is up to the release managers. Please advise, - Jeff [1] https://svn.boost.org/trac/boost/ticket/5825 [2] https://svn.boost.org/trac/boost/changeset/80467

1 1

Inspection tool run
by Paul A. Bristow 30 Sep '12

30 Sep '12

I've been trying to get Boost.Math off the Sinners List on the Inspection Report at http://boost.cowic.de/rc/inspect-trunk.html#math. It last ran 25 July 12, so I can't see if I have succeeded yet. When can I expect it to run again? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

8 12

[website] Latest version of page links
by Daniel James 30 Sep '12

30 Sep '12

Hello all, I finally got round to finishing off the links from old documentation to the latest version. It's a little hacked in so the markup isn't wonderful, and it only works for libraries whose documentation is altered by the site's php scripts. That's usually the documentation with no frames and the green header (some libraries put the green header in themselves, it won't work for them). At the moment it's just on the beta site, for example: http://beta.boost.org/doc/libs/1_49_0/libs/phoenix/doc/html/index.html Not all pages have a page in the same location in the most recent version, so for some pages you will just get a link to the latest documentation list: http://beta.boost.org/doc/libs/1_41_0/doc/html/boost/units/si/constants/cod… This will go live soonish. I might tweak it a little first, maybe change the wording on the notices, but it's pretty much done for now. Please try it out with your favourite documentation to check I haven't made too much of a mess. thanks, Daniel

2 2

Review Wizard Status Report for September 2012
by Ronald Garcia 29 Sep '12

29 Sep '12

============================================== Review Wizard Status Report for September 2012 ============================================== News ==== 1. Boost 1.51.0 Released. New Libraries: 1) Context 2. Multiprecision Accepted 3. Type Erasure Accepted 4. Contract Reviewed 5. Coroutine Reviewed 6. ODEInt Reviewed 7. Contract Accepted 8. Polygon Extensions integrated into Polygon Open Issues =========== The following libraries have review managers, but have not yet been scheduled for review: * Range Extensions - added May 2012; review manager: Neil Groves. The following libraries have been reviewed and await reports from their review managers: * Predef - reviewed February 2012; review manager: Joel Falcou. * Coroutine - reviewed September 2012; review manager: Hartmut Kaiser. The following libraries have been accepted to Boost, but have not yet been submitted to SVN: * Constrained Value - accepted September 2010; author: Robert Kawulak. * GIL.IO - accepted January 2011; author: Christian Henning. * Contract - accepted September 2012; author: Lorenzo Caminiti. The following libraries have been accepted and submitted to SVN, but have not yet appeared in a release: * Atomic - accepted July 2011; author Helge Bahmann. * Type Traits Introspection - accepted August 2011; author: Edward Diener. * Lockfree - accepted August 2011; author: Tim Blechmann. The following libraries have been accepted provisionally to Boost, but have not been submitted for mini-review and full acceptance: * Endian - accepted provisionally November 2011; author: Beman Dawes. * Log - accepted provisionally March 2010; author: Andrey Semashev. General Announcements ===================== As always, we need experienced review managers. Please take a look at the list of libraries in need of managers and check out their descriptions. In general review managers are active boost participants, including library contributors, infrastructure contributors, and other mailing list participants with a substantial track record of constructive participation. If you can serve as review manager for any of them, email Ron Garcia or John Phillips, "rxg at cs dot cmu dot edu" and "phillips at pacific dot mps dot ohio-state dot edu" respectively. We are also suffering from a lack of reviewers. While we all understand time pressures and the need to complete paying work, the strength of Boost is based on the detailed and informed reviews submitted by you. If you are interested in reviewing a library but won't have time during the review period, you can always prepare your review ahead of time. No rule says you can only work on a review during the review period. A link to this report will be posted to www.boost.org. If you would like us to make any modifications or additions to this report, please email Ron or John. The review schedule is an unordered list of the libraries awaiting review. As such, any library on the schedule can be reviewed once the developer is ready, a review manager has been secured, and the manager, developer, and wizards agree on a date to schedule the review. Review Schedule =============== * Join (M) * Pimpl (M) * Sorting (M) * Quaternions, Vectors, Matrices (M) * Variadic Macro Data (M) * Block Pointer (M) * Singularity (M) * Extended Complex Numbers (M) * Metaparse (M) * Polygon: Voronoi Extensions * Coroutine * Range Extensions * Nowide (M) * Array (M) * TypeIndex (M) ``(M)`` marks libraries that need review managers. -------------------- Join ---- :Author: Yigong Liu :Review Manager: Needed :Download: http://channel.sourceforge.net/ :Description: Join is an asynchronous, message based C++ concurrency library based on join calculus. It is applicable both to multi-threaded applications and to the orchestration of asynchronous, event-based applications. It follows Comega's design and implementation and builds with Boost facilities. It provides a high level concurrency API with asynchronous methods, synchronous methods, and chords which are "join-patterns" defining the synchronization, asynchrony, and concurrency. Pimpl ----- :Author: Vladimir Batov :Review Manager: Needed :Download: https://github.com/boost-vault/Miscellaneous/blob/master/Pimpl.zip :Description: The Pimpl idiom is a simple yet robust technique to minimize coupling via the separation of interface and implementation and then implementation hiding. This library provides a convenient yet flexible and generic deployment technique for the Pimpl idiom. It's seemingly complete and broadly applicable, yet minimal, simple and pleasant to use. Sorting ------- :Author: Steven Ross :Review Manager: Needed :Download: https://github.com/boost-vault/Sorting :Description: A grouping of 3 templated hybrid radix/comparison-based sorting algorithms that provide superior worst-case and average-case performance to std::sort: integer_sort, which sorts fixed-size data types that support a rightshift (default of >>) and a comparison (default of <) operator. float_sort, which sorts standard floating-point numbers by safely casting them to integers. string_sort, which sorts variable-length data types, and is optimized for 8-bit character strings. All 3 algorithms have O(n(k/s + s)) runtime where k is the number of bits in the data type and s is a constant, and limited memory overhead (in the kB for realistic inputs). In testing, integer_sort varies from 35% faster to 2X as fast as std::sort, depending on processor, compiler optimizations, and data distribution. float_sort is roughly 70% faster than std::sort. string_sort is roughly 2X as fast as std::sort. Quaternions, Vectors, Matrices ------------------------------ :Author: Emil Dotchevski :Review Manager: Needed :Download: http://www.revergestudios.com/boost-qvm/ :Description: QVM defines a set of generic functions and operator overloads for working with quaternions, vectors and matrices of static size. The library also defines vector and matrix data types, however it allows users to introduce their own types by specializing the q_traits, v_traits and m_traits templates. Variadic Macro Data ------------------- :Author: Edward Diener :Review Manager: Needed :Download: `Boost Sandbox <http://svn.boost.org/svn/boost/sandbox/variadic_macro_data/>`__ :Description: This library adds support and functionality for variadic macros to Boost as well as integrating variadic macros with the Boost PP library without changing the latter library in any way. Block Pointer ------------- :Author: Phil Bouchard :Review Manager: Needed :Download: https://svn.boost.org/svn/boost/sandbox/block_ptr/ :Description: Deterministic memory manager of constant complexity capable of handling cyclic collections. Singularity ----------- :Author: Ben Robinson :Review Manager: Needed :Download: https://github.com/cppmaven/Singularity :Description: The Singularity Design Pattern allows you to restrict any class to a single instance. Unlike the infamous Singleton, Singularity gives you direct control over the lifetime of the object, does not require you to grant global access to the object, nor does it limit you to the default constructor for that object. Extended Complex Numbers ------------------------ :Author: Matthieu Schaller :Review Manager: Needed :Download: http://code.google.com/p/cpp-imaginary-numbers/ :Description: The library is an extension of the std::complex class addressing two issues: 1. The standard does not guaranty the behaviour of the complex class if instantiated with types other than float/double/long double. 2. Some calculation where pure imaginary numbers (i.e. multiples of sqrt(-1)) appear are unnecessarily slowed down due to the lack of support for these numbers. The code I submit contains two interleaved classes boost::complex and boost::imaginary which can be instantiated with any type T provided T overloads the usual arithmetic operators and some basic (real) mathematical functions depending on which complex function will be used. It is thus an extended version of Thorsten Ottosen's n1869 proposal (http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1869.html) Metaparse --------- :Author: Abel Sinkovics :Review Manager: Needed :Download: http://abel.web.elte.hu/metaparse/metaparse.zip :Description: Metaparse is a library for constructing parsers parsing at compile-time based on template metaprogramming. The parsers built with the library take boost::mpl::strings as input and can produce - types - objects (types with public static members) - callable C++ functions (types with public static method) - template metafunction classes as output (based on the input being parsed). On compilers supporting constexpr the library provides the following syntactic sugar for writing the input of the parsers: BOOST_STRING("this is a string") The library can be used for implementing DSLs in C++, including DSLs making C++ template metaprogramming easier (see examples). Polygon: Voronoi Extensions --------------------------- :Author: Andril Sydorchuk :Review Manager: Lucanus Simonson :Download: http://svn.boost.org/svn/boost/sandbox/gtl/ :Description: This library extends Boost.Polygon with the following features: - Robust and efficient implementation of the sweepline algorithm that allows to construct Voronoi diagram, Delaunay triangulation and medial axis of a set of points and line segments. - Coordinates of the output geometries are computed within the 64 machine epsilon relative error (6 mantissa bits). - Voronoi diagram data structure that allows efficient traversal and data association with the output Voronoi graph. - No 3rd party dependencies (e.g. GMP, MPFR), all the required multiple precision types are implemented as part of the library. - The input and output coordinate type domains are configurable via coordinate type traits, thus allowing to compute coordinates of the Voronoi vertices within any required precision. - The full construction of the Voronoi diagram of 100 000 points takes only 0.27 seconds (see benchmarks). Coroutine --------- :Author: Oliver Kowalke :Review Manager: Hartmut Kaiser :Download: http://gitorious.org/boost-dev/boost-dev/archive-tarball/coroutine :Description: This library is an implementation of coroutines and generators using Boost.Context. Range Extensions ---------------- :Author: Akira Takahashi :Review Manager: Neil Groves :Download: https://github.com/faithandbrave/OvenToBoost :Description: This project adds some features of the Oven Range Library to Boost.Range. Features: - Additional Range Adaptors (taken, taken_while, dropped, dropped_while, elements, elements_key, memoized, outdirected) - Extensions for using Lambda (regular function, regular operator) - Infinite Range (iteration function) - and additional range utilities. Nowide ------ :Author: Artyom Beilis :Review Manager: Needed :Download: http://cppcms.com/files/nowide/ :Description: This library makes cross platform Unicode aware programming easier. It provides an implementation of standard C and C++ library functions, such that their inputs are UTF-8 aware on Windows without requiring to use Wide API. Array ----- :Author: Brian Smith :Review Manager: Needed :Download: https://github.com/BrianJSmith/Array :Description: The array class is a C++11 compatible implementation of static multidimensional arrays. TypeIndex --------- :Author: Antony Polukhin :Review Manager: Needed :Download: https://github.com/apolukhin/type_index :Description: TypeIndex is an extended C++11 type_index library, that * works with disabled RTTI * can store const-volatile-reference info about types (if user requested it) * has all the functionality of std::type_index * has portable across compilers and platforms functionality for getting demangled type names * works across modules/shared libraries * does not require C++11 to work Libraries under development =========================== See http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction for a current listing of libraries under development.

3 5

[Review] ODEInt review starts today, September 19, ends September 28
by Steven Watanabe 28 Sep '12

28 Sep '12

AMDG The review of Karsten Ahnert and Mario Mulansky's ODEInt library starts today September 19th and will end on September 28. -------------------------------------- About the library: odeint provides routines for numerically solving Ordinary Differential Equations, a task heavily required when approaching scientific problems numerically. In odeint we have implemented the most common algorithms in a modern, generic way which provides several advantages over existing implementations. The main focus of odeint is to separate algorithms from the underlying basic computation unit. This allows for example to easily use the power of modern GPUs via CUDA or OpenCL to speed up computational heavy simulations. Features: - provides most of the standard algorithms, including step size control, dense ouput and extrapolation routines - symplectic routines for Hamiltonian systems - implicit routines based on boost::ublas (MTL4 in progress) - high level integrate functions - interchangeable computation backend with existing bindings to CUDA and OpenCL - native support of ODEs defined for complex values - support of Boost.Units in most of the algorithms - support of arbitrary precision types You can download the library and view the documentation here: zip: http://github.com/headmyshoulder/odeint-v2/zipball/master github: http://headmyshoulder.github.com/odeint-v2/ docs: http://headmyshoulder.github.com/odeint-v2/doc/index.html -------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? In Christ, Steven Watanabe

6 8

Contributing a thread pool class
by BOLTON Gawain 28 Sep '12

28 Sep '12

Hello, It seems that boost's "thread" library does not have a thread pool class. It does have a thread_group class but this class is has the following limitations: 1. It does not limit the number of threads created. 2. Threads added are not managed and raw pointers are used exposing the developer to memory leaks. 3. The API deals with threads and not "tasks" to be executed by a thread. As such I have developed a thread pool class which allows for: · A maximum number of "worker" threads to configured. · Arbitrary "tasks" to be submitted by any thread and executed by one of the worker threads. o Worker threads are created as and when needed. · Worker threads can terminate after being idle a configurable amount of time. o They will be re-created if needed afterwards. The amount of code is quite small (< 500 lines including blank lines, API usage document in the header file and comments) and just uses standard C++ and boost thread functionality. My question is, would the boost community be interested in such a contribution to the thread library? I apologize in advance if this is the Nth time such a contribution has been proposed and rejected. I have developed this while working for my employer (a French bank called Société Générale). I have my manager's support and am in the process of obtaining agreement from my employer to get permission to submit the thread pool class developed. Cheers, Gawain Bolton Domino Development ITEC/CTT/GEF/TED 17 cours Valmy 92 800 Puteaux France Telephone : +33 1 42 13 52 43 ************************************************************************* This message and any attachments (the "message") are confidential, intended solely for the addressee(s), and may contain legally privileged information. Any unauthorised use or dissemination is prohibited. E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. ************ Ce message et toutes les pieces jointes (ci-apres le "message") sont confidentiels et susceptibles de contenir des informations couvertes par le secret professionnel. Ce message est etabli a l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee est interdite. Tout message electronique est susceptible d'alteration. La SOCIETE GENERALE et ses filiales declinent toute responsabilite au titre de ce message s'il a ete altere, deforme ou falsifie. *************************************************************************

3 2

Release branch closing for new features
by Marshall Clow 27 Sep '12

27 Sep '12

[ resending because it doesn't seem to have gone through ] So, we missed announcing this on Monday, so we're pushing back the deadline until Friday. On (tomorrow) Friday, Sep 29th, the release branch will close for new features, and be open only for bug fixes and doc fixes. On Tuesday, October 2nd, the release branch will close except by permission from the release managers. This is in preparation for the first 1.52.0 beta, scheduled for Monday, Oct 8th. -- The release managers

1 0

[reminder] [Review] ODEInt review ends tomorrow September 28
by Steven Watanabe 27 Sep '12

27 Sep '12

AMDG The review of Karsten Ahnert and Mario Mulansky's ODEInt library will end tomorrow. Only a few reviews have been submitted so far. If you plan to submit a review, please let me know. If anyone needs more time, we can see about extending the review period. -------------------------------------- About the library: odeint provides routines for numerically solving Ordinary Differential Equations, a task heavily required when approaching scientific problems numerically. In odeint we have implemented the most common algorithms in a modern, generic way which provides several advantages over existing implementations. The main focus of odeint is to separate algorithms from the underlying basic computation unit. This allows for example to easily use the power of modern GPUs via CUDA or OpenCL to speed up computational heavy simulations. Features: - provides most of the standard algorithms, including step size control, dense ouput and extrapolation routines - symplectic routines for Hamiltonian systems - implicit routines based on boost::ublas (MTL4 in progress) - high level integrate functions - interchangeable computation backend with existing bindings to CUDA and OpenCL - native support of ODEs defined for complex values - support of Boost.Units in most of the algorithms - support of arbitrary precision types You can download the library and view the documentation here: zip: http://github.com/headmyshoulder/odeint-v2/zipball/master github: http://headmyshoulder.github.com/odeint-v2/ docs: http://headmyshoulder.github.com/odeint-v2/doc/index.html -------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? In Christ, Steven Watanabe

1 0

heap corruption on windows due to windows_file_codecvt
by Pedro Larroy 27 Sep '12

27 Sep '12

Hi When using debug mode in windows with boost_filesystem there's "Debug Assertion Failed!" in _CtrIsValidHeapPointer When operator new is redefined it causes windows_file_codecvt not to be released with the matching release that it allocated it. We reported this to Microsoft as seems it's a bug in their STL. But so far, I tried with VS2012 and the bug seems not fixed... There's a workraround in boost that we are using for the moment: This has to be changed in path.cpp to fix it: - std::locale loc(global_loc, new windows_file_codecvt); + std::locale loc(global_loc, _NEW_CRT windows_file_codecvt); Should this fix be applied in boost until is fixed on Microsoft's side? This is a very nasty issue that will happen only with a redefined operator new. (For example we are using new with the sacalable allocator of tbb). Regards. Pedro.

1 0

[context] boost::ctx::?
by Dave Abrahams 27 Sep '12

27 Sep '12

ctx seems like a needlessly short abbreviation. Wouldn't it be better and more consistent with the rest of Boost to ask users to write using namespace ctx = boost::context; if they want something short? -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

9 13

[shared_ptr][thread] spinlock initialization
by Yi Ding 27 Sep '12

27 Sep '12

I started using the spinlock in boost/smart_ptr/detail/spinlock.hpp and discovered that it needs to be manually initialized, even for the spinlock_sync version, which became a nasty bug when it manifested itself. This seems a bit out of sync with the rest of the mutexes in boost::thread. Now, I'm guessing that the fact that the spinlock is in boost::detail means that it's not really for outside consumption (newbie boost user here), but is there something in the works that will be? In the meantime, would it be possible to automatically initialize the spinlock (trivial in the case of spinlock_sync) or are there architectural issues with that? Otherwise, could we add a comment that says "in order to use these spinlocks you must initialize with BOOST_DETAIL_SPINLOCK_INIT" or "move along, these aren't the spinlocks you're looking for."

3 2

Problem using dijkstra_shortest_paths with Boost 1.51
by John Wiegley 27 Sep '12

27 Sep '12

Hello, I tried building my Ledger project today with Boost 1.51 and clang --std=c++11, and received the following error: --8<---------------cut here---------------start------------->8--- /usr/local/include/boost-1_51/boost/mpl/eval_if.hpp:38:26: error: no type named 'type' in 'boost::no_property' typedef typename f_::type type; ~~~~~~~~~~~~~^~~~ [...] /Users/johnw/Projects/ledger/src/history.cc:455:3: note: in instantiation of function template specialization 'boost::dijkstra_shortest_paths<boost::filtered_graph<boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, boost::property<boost::vertex_name_t, const ledger::commodity_t *, boost::property<boost::vertex_index_t, unsigned long, boost::no_property> >, boost::property<boost::edge_weight_t, long, boost::property<boost::edge_price_ratio_t, std::__1::map<boost::posix_time::ptime, ledger::amount_t, std::__1::less<boost::posix_time::ptime>, std::__1::allocator<std::__1::pair<const boost::posix_time::ptime, ledger::amount_t> > >, boost::property<boost::edge_price_point_t, ledger::price_point_t, boost::no_property> > >, boost::property<boost::graph_name_t, std::__1::basic_string<char>, boost::no_property>, boost::listS>, ledger::recent_edge_weight<boost::adj_list_edge_property_map<boost::undirected_tag, long, long &, unsigned long, boost::property<boost::edge_weight_t, long, boost::property<boost::edge_price_ratio_t, std::__1::map<boost::posix_time::ptime, ledger::amount_t, std::__1::less<boost::posix_time::ptime>, std::__1::allocator<std::__1::pair<const boost::posix_time::ptime, ledger::amount_t> > >, boost::property<boost::edge_price_point_t, ledger::price_point_t, boost::no_property> > >, boost::edge_weight_t>, boost::adj_list_edge_property_map<boost::undirected_tag, ledger::price_point_t, ledger::price_point_t &, unsigned long, boost::property<boost::edge_weight_t, long, boost::property<boost::edge_price_ratio_t, std::__1::map<boost::posix_time::ptime, ledger::amount_t, std::__1::less<boost::posix_time::ptime>, std::__1::allocator<std::__1::pair<const boost::posix_time::ptime, ledger::amount_t> > >, boost::property<boost::edge_price_point_t, ledger::price_point_t, boost::no_property> > >, boost::edge_price_point_t>, boost::adj_list_edge_property_map<boost::undirected_tag, std::__1::map<boost::posix_time::ptime, ledger::amount_t, std::__1::less<boost::posix_time::ptime>, std::__1::allocator<std::__1::pair<const boost::posix_time::ptime, ledger::amount_t> > >, std::__1::map<boost::posix_time::ptime, ledger::amount_t, std::__1::less<boost::posix_time::ptime>, std::__1::allocator<std::__1::pair<const boost::posix_time::ptime, ledger::amount_t> > > &, unsigned long, boost::property<boost::edge_weight_t, long, boost::property<boost::edge_price_ratio_t, std::__1::map<boost::posix_time::ptime, ledger::amount_t, std::__1::less<boost::posix_time::ptime>, std::__1::allocator<std::__1::pair<const boost::posix_time::ptime, ledger::amount_t> > >, boost::property<boost::edge_price_point_t, ledger::price_point_t, boost::no_property> > >, boost::edge_price_ratio_t> >, boost::keep_all>, f_max<long>, boost::distance_combine_t, boost::bgl_named_params<boost::iterator_property_map<long *, boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, const ledger::commodity_t *, boost::property<boost::vertex_index_t, unsigned long, boost::no_property> >, unsigned long>, long, long &>, boost::vertex_distance_t, boost::bgl_named_params<boost::iterator_property_map<unsigned long *, boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, const ledger::commodity_t *, boost::property<boost::vertex_index_t, unsigned long, boost::no_property> >, unsigned long>, unsigned long, unsigned long &>, boost::vertex_predecessor_t, boost::no_property> > >' requested here dijkstra_shortest_paths(fg, /* start= */ vs, ^ --8<---------------cut here---------------end--------------->8--- My graph type is: typedef adjacency_list <vecS, // Store all edges in a vector vecS, // Store all vertices in a vector undirectedS, // Relations are both ways // All vertices are commodities property<vertex_name_t, const commodity_t *, property<vertex_index_t, std::size_t> >, // All edges are weights computed as the absolute difference between // the reference time of a search and a known price point. A // filtered_graph is used to select the recent price point to the // reference time before performing the search. property<edge_weight_t, long, property<edge_price_ratio_t, price_map_t, property<edge_price_point_t, price_point_t> > >, // Graph itself has a std::string name property<graph_name_t, std::string> > Graph; The full source is located here: https://github.com/jwiegley/ledger/blob/next/src/history.cc What has changed in Boost.Graph since 1.50? The same code builds fine with all the same compiler options using that version. Thanks, -- John Wiegley BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

2 4

[odeint] Documentation comments
by John Bytheway 27 Sep '12

27 Sep '12

This is not a review, just a few things I've caught while reading the odeint docs. Mostly cosmetic issues, but a couple of deeper questions. * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/getting… - "They also occur if partial differential equations (PDEs) are discretized in one coordinate."; wouldn't you have to discretize in all but one coordinate? * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/getting… - I see no mention of any headers except the global one boost/numeric/odeint.hpp. Is it useful or possible to include only parts of the library? * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/getting… - "a simple function calculating f(x)'"; I think you mean either "f(x)" or "x'", not "f(x)'". * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/tutoria… - There's one case here where you use "--" as an em dash. "on the example of explicit_error_rk54_ck -- a 5th order Runge-Kutta method". There are various other places throughout the docs which use just "-" for em dash. It would be best if you could use a proper em dash character, but in any case you should be consistent. * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/tutoria… - "which lead to the whole new subject of Chaos Theory"; s/lead/led/ * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/tutoria… - "the so called Rosenbrock method"; is "so called" necessary? * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/tutoria… - "the first numerical experiment which has been implemented on a computer in 1953. It was studied at Los Alamos on one of the first computer (a MANIAC I) and it triggered a whole new tree of mathematical and physical science."; This is ambiguous (it could mean the first experiment amongst those in 1953). If you really mean it was the first computational numerics experiment then you should probably say something like "the first numerical experiment to be implemented on a computer. It was studied at Los Alamos in 1953 on one of the first computers (a MANIAC I) and triggered a whole new tree of mathematical and physical science." - "For example the unit test for Boost.Units take up to 4 GB of memory at compilation."; are you referring to the unit tests of Boost.Units, or a unit test of odeint that uses Boost.Units? Please clarify. - The matrix-as-state example has a bug: for( size_t j=0 ; j<x.size2() ; ++j ) dxdt( 0 , j ) = dxdt( 0 , x.size1() -1 ) = 0.0; should be for( size_t j=0 ; j<x.size2() ; ++j ) dxdt( 0 , j ) = dxdt( x.size1() -1, j ) = 0.0; This bug makes me think that you ought to provide a debug mode where every entry in dxdt is set to NaN before calling the system operator(), and then they are checked to be non-NaN afterwards. Of course, this would only work for types with a NaN value, but I think all your examples do have that (except maybe the multiprecision types). - "This is in principle all"; awkward phrasing, perhaps "In principle this is all" - I assume you know about the unfinished chunk of docs re PDEs and equations on networks. - "for full support the min( x , y ), max( x , y ), pow( y , y ) must be callable"; what are x and y? Is it significant that pow has both arguments equal but min and max don't? I hope the requirements on the numeric type are laid out more formally elsewhere; please link to that. - "We exemplary show this for a Hamiltonian system"; "exemplary" doesn't work here. You could use s/exemplary show/demonstrate/. * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/tutoria… - "simply to small"; s/to/too/ * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/odeint_… - "Implicit solvers do only work"; s/do // - "They safe a part of their history" s/safe/save/ - In the section on controlled steppers, the formulae are getting sufficiently complex that it might be worth trying to use TeX-generated pngs rather than straight HTML (as is done in Boost.Math, e.g. <http://www.boost.org/doc/libs/1_51_0/libs/math/doc/sf_and_dist/html/math_to…>) - I can't figure out what the three lines after table 1.6 are about. - The long line "boost::numeric::odeint::result_of::make_dense_output< r..." in Dense output steppers is too long for my screen; can you break it? - The resizing policy names are a bit clumsy; I think always_resize, initially_resize, and never_resize might be better. - "Typical use cases for this kind of resizer are self expanding lattices like shown in the tutorial"; can you link to the relevant example in the tutorial? - "So it might be suitable that the system function itself is a pair of functions, one for computing the deterministic and one for the stochastic part. The first element of the pair simply computes the deterministic part while the second the stochastic one."; this is rather redundant; how about "So it might be suitable that the system function is a pair of functions. The first element of the pair computes the deterministic part and the second the stochastic one." * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/odeint_… - Personally I think the ranges are more useful than the iterators, so it would be nice if they were mentioned in the section title (e.g. "Iterators and Ranges") - "that is you write the above example in a shortified form"; "shortified" is not a word; perhaps "so you can write this example in a more succinct form". * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/odeint_… - The note "odeint already includes all the code presented here, see gsl_wrapper.hpp, so gsl_vectors can be used straight out-of-box. The following description is just for educational purpose." is duplicated in the subsequent paragraph. - Using x/y for element-wise division in vector_space_algebra seems potentially contentious. Similarly for abs. Perhaps it would be better to provide a customization point in boost::numeric::odeint as you have done with vector_space_reduce, whose default implementations use / and abs as in the current scheme. That way people will not be required to implement potentially misleading operators for their types. - "vector_space_reduce_impl< state_type >::reduce( state , operator , init )"; you probably shouldn't use the keyword "operator" as an identifier here. * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/odeint_… - "the state_type of the stepper must not necessarily be used to call the do_step method"; I'm not sure what this means; should it be "the state_type of the stepper need not necessarily be used to call the do_step method" * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/concept… - Concepts are normally written without underscores, so SymplecticSystem rather than Symplectic_System. * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/concept… - In various places you have ScaleSum/N/ with literal '/' characters, where I presume they were intended to be formatting to make 'N' italics. - Rather than having a dedicated array_algebra, could you not have range_algebra automatically switch to the more efficient implementation when it detects a suitable State type? I hope to get a chance to play with the library later and submit a proper review. For now, congratulations on an impressive library. John Bytheway

3 6

[test] Patches to improve test log detail for better thirdparty integration
by Jamie Allsop 26 Sep '12

26 Sep '12

In light of recent discussions regarding Boost.Test I've created 3 tickets in trac with patches against trunk that incrementally improve the ease with which Boost.Test can be integrated with thirdparty continuous integration tools, while at the same time improving the output offered. These are patches we've been using for some time locally, the recent discussions highlighted the importance of pushing patches like these to a wider audience. In summary the key changes are: * https://svn.boost.org/trac/boost/ticket/7410 * all test cases/suites have file and line information captured so that external tools can use the Boost.Log output to create links into the source tree, answering questions like, "What is this test case?". It is possible to simply follow the link and see. * https://svn.boost.org/trac/boost/ticket/7417 * update the Boost.Test log output to include summary status information when a test case or suite is completed. This includes the test status, assertions passed and total assertions. This allows live test status to be viewed and nicer tools to be built around this. For example each test can be shown starting, in progress and then complete with the resulting status in detail. I should note that Boost.Test reports currently output this additional test status but this is done only on completion of all tests and so cannot be used to show live progress. * this additional test status as part of the log can be easily captured using regular expressions if HRF is used and many IDEs will allow colourisation, autolinking and so on using similar approaches. * https://svn.boost.org/trac/boost/ticket/7397 * update Boost.Test to use the new Boost.Timer classes introduced in Boost 1.48. This can be suppressed through the use of a macro should the old timers be preferred. The new Boost.Timer provides much better timing information than the old Boost.Timer library. You should refer to the library itself for an explanation of why the previous timer library was deprecated: http://www.boost.org/doc/libs/1_51_0/libs/timer/doc/index.html These patches address what I believe to be important missing features of Boost.Test. We have been using these patches in our systems with Boost 1.49 and enjoy very nice CI integration with Trac Bitten and our Scons build tools. I would therefore encourage those that use Boost.Test and who are interested in these patches in general to take a look. The Boot.Timer patch is important as it also addresses compile issues. See the recent thread here: http://thread.gmane.org/gmane.comp.lib.boost.devel/234411 Gennadiy - assuming you find these acceptable they could be committed to trunk. I don't have commit privileges to do it myself and besides they need reviewed first. Also I would prefer a closer look was taken at the impact they might have on Boost.Test's tests. Finally I should also note that one reason for providing the BOOST_TEST_USE_DEPRECATED_TIMER macro was to circumvent the issue of the new Boost.Timer depending on Boost.System. I don't recall if Boost.System can used header-only? I certainly remember a lot of discussion about it. Jamie

2 2

[test] Support use of test tools and report generation in non-test programs - facilitating test/validation modes
by Jamie Allsop 26 Sep '12

26 Sep '12

An important use case that we have is the ability to run test scenarios on a production binary by specifying a 'test' mode. In test mode we essentially run through a series of different scenarios, asserting various conditions, comparing expected results and so on. In order to minimise the custom code we needed for this we decided to make use of Boost.Test. All the test tools are there, report generation and so on. In addition we have all the report analysis tools in place to interpret the output. The problem however, is that Boost.Test essentially requires a custom main() function. Either one of the ones provided by Boost.Test or one performing Boost.Test specific initialisation. In our production systems we have, like many, a fairly standard main() that ensures uniform behaviour across binaries and we do not want to pollute that with Boost.Test specific code. Notably we also do not want to pollute our command line parameters or configuration with 'global' Boost.Test arguments to control the test report output. Finally we want to control exactly when the tests are executed. I've created ticket #7419 to cover this use case and have also attached a small patch that facilitates the capabilities required to support it. https://svn.boost.org/trac/boost/ticket/7419 Essentially the patch does two things: * It allows boost::unit_test_framework::init() to be called more than once. The result is to reset the test status and master test suite so that new tests can be added and new reports generated through multiple calls. The CLA parsing is also reset. Recent changes to this code may make my call to clear() redundant. I'll let Gennadiy be the judge of that. * This first change then allows the framework setup and teardown to be encapsulated in a helper class (not provided in the patch but one could be). In our systems we use a helper class that exposes a simple API that allows the user to implement a method where test units can be added directly to the master test suite - see the ticket for an example. As I said the patch focuses solely on enabling the possibility of writing such a class, not the class itself. * It provides scoped Boost.Test arguments for the commandline when BOOST_TEST_USE_QUALIFIED_COMMANDLINE_ARGUMENTS is defined. All command line arguments are then called --boost.test.<argument> for example --boost.test.log_level instead of --log_level. This of course means that all Boost.Test related arguments will not clash with any program arguments. On its own this is a generally useful feature as it allows custom main() functions to pass arguments down to other components during simple unit testing. The patch attached is based on a patch against boost 1.49. The one attached to the ticket is for trunk. Again this is a small patch that is genuinely useful so I'd like to see it make its way into trunk. As far as I know there are no side-effects for adding these changes, tests all pass and so on. Jamie

1 0

Formal Review Request [stl_ext_adv]
by Vadim Stadnik 26 Sep '12

26 Sep '12

Hi all, I would like to request a formal review of the library “STL extensions based on advanced data structures” [stl_ext_adv]. Project location: https://github.com/vstadnik/stl_ext_adv_review Quick view of documentation: http://dl.dropbox.com/u/51041088/stl_ext_adv_review/doc/index.html The previous version of this library is based on dynamically allocated data structures. It was discussed by Boost community in this thread: http://boost.2283326.n4.nabble.com/stl-ext-adv-Interest-in-advanced-data-st… The new version has two major improvements. It offers more efficient array based data structures and extensions of move semantics functions of STL containers. I am looking for the review manager. I would really appreciate if someone interested in advanced data structures could take this role. Early comments are welcome! Regards, Vadim Stadnik SUMMARY The proposed library [stl_ext_adv] offers augmented array based B+ trees and STL containers that support the interfaces of the C++03 sequences and associative containers. The library offers a number of extensions and performance improvements that are not available in C++03 and C++11 standard containers. OVERVIEW Both sequences and associative containers support: - random access iterators; - logarithmic time insert and erase operations for a single element anywhere within a container; Sequences support: - the union of interfaces of the C++03 sequence containers: std::list, std::deque and std::vector; - complete set of move semantics functions splice() and split() that guarantee logarithmic complexity in the worst case; Associative containers support: - equally efficient access to elements by their keys and positions; - logarithmic time search operations using keys of the container elements; - logarithmic time split operations in the general case and logarithmic time merge operations in special cases. One basic container implements the efficient algorithm accumulate(), which sums up any consecutive elements of a container in logarithmic time. The algorithm is fundamental to many important applications, such as the numerical integration and statistics. The array based data structures improve locality of reference and offer more efficient algorithms against equivalent dynamically allocated data structures. The wide set of the efficient member functions provided by the new containers makes them useful to improve the performance of algorithms using the standard containers with at least one relatively inefficient operation or a bidirectional iterator.

1 0

Boost/utility : addressof.hpp Error due to usage of Werror flag.
by GAURAV GUPTA 26 Sep '12

26 Sep '12

Hi , While using Boost (ver 1.51.0) file "addressof.hpp" I am getting following errors: *Boost/1.51/Inc/boost/utility/addressof.hpp:41:69: error: cast from 'char*' to 'std::vector<std::pair<std::basic_string<char>, std::basic_string<char> > >*' increases required alignment of target type [-Werror=cast-align] cc1plus: all warnings being treated as errors* I need to use "Werror" flag in my application. Any solution for this problem? *It works fine if i use . Is it the correct solution?* diff -Naur a/boost/utility/addressof.hpp boost/utility/addressof.hpp --- a/boost/utility/addressof.hpp +++ boost/utility/addressof.hpp @@ -37,7 +37,8 @@ static inline T * f( T & v, long ) { return reinterpret_cast<T*>( - &const_cast<char&>(reinterpret_cast<const volatile char &>(v))); + reinterpret_cast<void*>(&const_cast<char&>(reinterpret_cast<const volatile char &>(v)))); } -- Regards, Gaurav

1 0

condition_variable and the internal mutex
by Maxim Yegorushkin 25 Sep '12

25 Sep '12

Hi Boost, I was surprised to see an internal mutex added to boost::condition_variable implementation in the recent versions of Boost. Quick internet searched revealed that this was done to better support thread cancellation: http://permalink.gmane.org/gmane.comp.lib.boost.devel/210235 That thread ends with a suggestion to add back a zero-overhead pthread_cond_t wrapper and no reply. So I was wondering whether there plans to reinstate that wrapper or should Boost users that are not concerned with thread cancellation but are rather concerned with code performance drop using boost::condition_variable and resort to writing their own wrapper? -- Maxim

2 2

Interest in mmapped container library
by Dmitry Prokoptsev 25 Sep '12

25 Sep '12

Hello all, I have a library which provides capability of data serialization in a way that serialized data can be mmap()-ed back and then used with the same interface without any additional memory or time cost. A short usage example: https://gist.github.com/3656916 Is there an interest in such library? -- Dmitry Prokoptsev

2 2

Boost:Foreach Werror flag's problem in foreach.hpp
by GAURAV GUPTA 25 Sep '12

25 Sep '12

Hi , While using Boost (ver 1.51.0) file "foreach.hpp" I am getting following errors: Boost/1.51/Inc/boost/foreach.hpp:454:5: error: cast from 'char*' to 'std::vector<std::pair<std::basic_string<char>, std::basic_string<char> > >*' increases required alignment of target type [-Werror=cast-align] cc1plus: all warnings being treated as errors I need to use "Werror" flag in my application. Any solution for this problem? -- Regards, Gaurav

3 2

[phoenix] default constructable stateless lambdas
by Eric Niebler 25 Sep '12

25 Sep '12

While answering a question about Phoenix on stackoverflow[^1], I discovered that Phoenix lambda types are default-constructable, so long as all the terminals are also default constructable. That's handy when the terminals are stateless. Can it (the default-constructability) be relied on? It doesn't appear to be documented. C++11 lambdas have the nice property that stateless ones are implicitly convertible to raw function pointers. This can be implemented for Phoenix if we can rely on the default-constructability of Phoenix lambda types. In my stackoverflow answer I show how. It'd be pretty cool if this were a standard part of all Phoenix lambdas. Is there interest? Incidentally, I think it's really, really cool that Phoenix allows this kind of extensibility. It's a very nice example of the benefits of the introspection capabilities built into Phoenix. Perhaps this could be worked into the docs somehow? [^1]: http://stackoverflow.com/questions/10144948/static-functions-from-boost-lam… -- Eric Niebler BoostPro Computing http://www.boostpro.com

4 6

[config] gcc-4.4 and BOOST_NO_SFINAE_EXPR
by Eric Niebler 25 Sep '12

25 Sep '12

As part of our work to make result_of sfinae-friendly, Daniel Walker and I have discovered that gcc-4.4 doesn't have very good support for generalized sfinae for expressions. Can we get BOOST_NO_SFINAE_EXPR defined for it? Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com

4 9

[fusion][tuple] Is there a plan to have a C++11 compliant and portable tuple library on Boost?
by Vicente J. Botet Escriba 24 Sep '12

24 Sep '12

Hi, In order to implement some features in Boost.thread I need a tuple that supports move semantics for its arguments. I see that there is an effort to provide move semantics when rvalue references are supported by the compiler. Is there a plan to have a C++11 compliant tuple library on Boost that uses the Boost.Move library on compilers that don't support rvalue references? Best, Vicente

4 5

(no subject)
by Davlet Panech 24 Sep '12

24 Sep '12

http://yoga-island.ru/wp-content/plugins/akismet/google.html?hi=vby.jdg&fxc…

1 0

[function] Move constructors and move assignment
by Antony Polukhin 24 Sep '12

24 Sep '12

Hi, There is a patch in ticket #7330, that adds move semantics to Boost.Function. It looks pretty trivial, so if there will be no objections, I'll commit it to trunk at the end of next week. -- Best regards, Antony Polukhin

2 3

[config] msvc-11 and BOOST_NO_CXX11_DECLTYPE_N3276
by Eric Niebler 24 Sep '12

24 Sep '12

Houston, we have a problem.... I've been grappling with a regression in proto due to the use of decltype in boost::result_of on msvc-11. I've concluded that msvc's support for N3276 is just not up to the task. The details are in the following bug report: https://connect.microsoft.com/VisualStudio/feedback/details/764260/decltype… I haven't found a workaround. I'm worried about downstream breakage when 1.52 is released. My suggestion: define BOOST_NO_CXX11_DECLTYPE_N3276 for msvc-11 and live with TR1 result_of for a bit longer. <sigh> -- Eric Niebler BoostPro Computing http://www.boostpro.com

3 2

[trac] Add result_of component
by Michel Morin 24 Sep '12

24 Sep '12

result_of does not have a trac component. But I think it's worth adding result_of component. Here is maintainer's information: [maintainer] djwalker [name] Daniel Walker Regards, Michel

2 4

[locale] Normalization and transformation
by Denis Arnaud 23 Sep '12

23 Sep '12

Hi, following is a sample program playing with text conversion features of Boost.Locale (Boost version 1.48.0 on Linux Fedora 17), as seen in the documentation (http://unicode.org/reports/tr15/#Norm_Forms and http://www.boost.org/doc/libs/1_51_0/libs/locale/doc/html/index.html) ___________________________________________________________ #include <boost/locale.hpp> int main() { // Get the global localisation backend boost::locale::localization_backend_manager locBEMgr = boost::locale::localization_backend_manager::global(); // Select ICU backend as default locBEMgr.select ("icu"); // Set this backend globally boost::locale::localization_backend_manager::global (locBEMgr); // Create a generator that uses this backend. boost::locale::generator locGen (locBEMgr); // Create locale generator with the system default locale std::locale::global (locGen ("")); // Test string with accents (french word for "side") std::string sideFR ("Côté"); // Test the Boost Locale string conversions std::cout << "Original: " << sideFR << std::endl <<"Upper " << boost::locale::to_upper (sideFR) << std::endl <<"Lower " << boost::locale::to_lower (sideFR) << std::endl <<"Title " << boost::locale::to_title (sideFR) << std::endl <<"Fold " << boost::locale::fold_case (sideFR) << std::endl << "Normalised - [NFD]: " << boost::locale::normalize (sideFR, boost::locale::norm_nfd) << "; [NFC]: " << boost::locale::normalize (sideFR, boost::locale::norm_nfc) << "; [NFKD]: " << boost::locale::normalize (sideFR, boost::locale::norm_nfkd) << "; [NFKC]: " << boost::locale::normalize (sideFR, boost::locale::norm_nfkc) << std::endl; return 0; } ___________________________________________________________ The output is: _____________________________________________________ Original: Côté Upper CÔTÉ Lower côté Title Côté Fold côté Normalised - [NFD]: Côté; [NFC]: Côté; [NFKD]: Côté; [NFKC]: Côté ____________________________________________________ Apparently, there is no difference in the normalization forms, whatever method is used (NFC, NFD, NFKC, NFKD). I would expect that NFD and NFKD would produce a different result. But maybe my (UTF8-based) Linux terminal recomposes automatically the letters and accents, so that we do not see the difference? Or is it a feature of Boost.Locale, which I overlooked? Let me state my goal. I use Xapian (http://xapian.org/docs/) as a full-text matching engine, and I feed it with texts of various languages and scripts, all in UTF8. Xapian will typically match keywords with the same forms and cases; in other words, I cannot choose or influence the collation algorithm (http://www.unicode.org/reports/tr10/) which corresponds to the third or fourth in Xapian (AFAIU). To give a sample, if the "Côté" word has been indexed by Xapian, "cote" will not match with it. So, I would like Xapian to index both forms ("Côté" and "cote"), so that both forms match. When a user gives me a string to match against the index, I will first try to match the string itself, then transform it (http://www.icu-project.org/icu-bin/translit) and try to match the transformed version. So, my question is: Is Boost.Locale capable of transforming Unicode strings, for instance to remove accents? A good example is provided by the first answer to the StackOverflow question: http://stackoverflow.com/questions/144761/how-to-remove-accents-and-tilde-i… In other words, I would like to apply the "NFD; [:M:] remove; NFC" transformation, as is possible with the ICU library. The following is a code sample showing how to do that: ____________________________________________________ // ICU #include <unicode/translit.h> #include <unicode/unistr.h> #include <unicode/ucnv.h> int main() { // Create a Normalizer UErrorCode status = U_ZERO_ERROR; const char* lNormaliserID = "NFD; [:M:] Remove; NFC;"; lNormaliser = Transliterator::createInstance (lNormaliserID, UTRANS_FORWARD, status); // Register the Transliterator Transliterator::registerInstance (lNormaliser); UnicodeString myString ("Côté"); lNormaliser->transliterate (myString); std::cout << "Normalized version without accents" << toUTF8String (lQueryString) << std::endl; return 0; } ____________________________________________________ Do not hesitate if you have suggestion, feedback, work around... Kind regards -denis

1 1

[thread] patch to suppress msvc warnings
by Jürgen Hunold 22 Sep '12

22 Sep '12

Hi Vicente, I get lots of noisy warning from win32/thread_data.hpp Example: boost/thread/win32/thread_data.hpp(90) : warning C4251: 'boost::detail::thread_data_base::thread_handle' : class 'boost::detail::win32::handle_manager' needs to have dll-interface to be used by clients of struct 'boost::detail::thread_data_base' Patch suppressing those attached. Okay to commit? 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 3

[lockfree] some msvc fixes
by Jürgen Hunold 22 Sep '12

22 Sep '12

Hi Tim, please find a patch attached that fixes. a) fixes for min-max-guideline violations (triggers if windows.h is include and NOMINMAX is not defined) b) some conversion warnings in the tests. Okay to commit? 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 1

Possible header error on boost/geometry/algorithms/area.hpp
by chedi toueiti 22 Sep '12

22 Sep '12

Hi, This is my first email on the list, and I hope I'm mistaking this, but while compiling mapnik with the latest boost revision from svn repo (trunk rev 80625), I got this error: /home/osm/boost-trunk/boost/geometry/algorithms/area.hpp:31:49: error: boost/geometry/geometries/variant.hpp: No such file or directory So I changed the file like as I thought fit: Index: boost/geometry/algorithms/area.hpp =================================================================== --- boost/geometry/algorithms/area.hpp (revision 80625) +++ boost/geometry/algorithms/area.hpp (working copy) @@ -28,7 +28,7 @@ #include <boost/geometry/core/ring_type.hpp> #include <boost/geometry/geometries/concepts/check.hpp> -#include <boost/geometry/geometries/variant.hpp> +#include <boost/variant/variant.hpp> #include <boost/geometry/algorithms/detail/calculate_null.hpp> #include <boost/geometry/algorithms/detail/calculate_sum.hpp> and now everything compiles fine, so I hope this will be helpful. -- *Chedi Toueiti* * Due to the constant fluctuation in customer personalities, we cannot be responsible for the mental stability of any one member of our staff. ** My opinions may have changed, but not the fact that I am right. *** I always try to go the extra mile at work, but my boss always finds me and brings me back.

1 0

[coroutine] Experimenting with interfaces
by Eugene Yakubovich 21 Sep '12

21 Sep '12

I've been playing around with coroutines by trying to solve some "real" problems (in pseudo C++, without compilation). One thing that I noticed is that symmetry is important. For example, for a chess simulation: class move { ... }; class board { ... }; // Each player has his own instance of the board class void player(coroutine<move(move)> opponent, move his, board brd) { while( !brd.is_mate() ) { brd.opponent_move(his); move mine = ...; brd.my_move(mine); his = opponent(mine); } } void white(coroutine<move(move)> opponent) { board brd(WHITE); move mine = ...; brd.my_move(mine); his = opponent(mine); player(opponent, his, board); } void black(coroutine<move(move)> opponent, move his) { board brd(BLACK); player(opponent, his, brd); } void play() { coroutine<move(move)> b(black); white(b); } It's very convenient that "both sides" have the same type. It makes it easy to write the common player() routine. Another thing to note is that the coroutine function returns void. I found that to basically be always true -- I never needed to use the 'return' to pass back the last value. Like the next example shows, it's also very convenient to have stack unwinding as running the coroutine to completion is not always natural. In the example above, coroutine<move(move)> has a coroutine function with signature void(move). In some cases, it's even more convenient to have a void() signature as in the following example implementing a TCP server using blocking sockets. struct request { ... }; struct reply { ... }; bool exit = false; // set to 'true' by Ctrl+C handler void server(coroutine<reply(request)> c, unsigned short port) { socket ls; ls.listen(port); while( !exit ) { socket s = ls.accept(); while( !exit ) { request req = s.recv(); reply rep = c(req).get(); s.send(rep); if( rep == "logout" ) break; } } } void run() { coroutine<reply(request)> srv(std::bind(server, 2121)); request req = srv.get(); while ( !exit ) { reply rep = ...; if( srv(rep) ) req = srv.get(); } } Also, in the first example, coroutine::operator() returned T (like fn call) but this example required the use of get(). The function call way (op() returns T) is also convenient since it allows one to write code that works generically with coroutines or functions: template <typename C> void timer(C c, chrono::seconds interval) { while( interval != chrono::seconds::zero() ) { this_thread::sleep_for(interval); interval = c(interval); } } chrono::seconds tick(chrono::seconds last_interval) { std::cout << "tick" << std::endl; return last_interval; } // use with function timer(tick, chrono::seconds(1)); // use with coroutine coroutine<chrono::seconds(chrono::seconds)> c( [](coroutine<chrono::seconds(chrono::seconds)> c, chrono::seconds i) { timer(c, i); } ); chrono::seconds s = c(chrono::seconds(1)); s = c(2*s); s = c(3*s); s = c(5*s); I'm not sure what this means for the best interface but I did want to share these thoughts and examples. Regards, Eugene

3 7

[test] Trunk broken: What happened to test_exec_monitor?
by John Maddock 21 Sep '12

21 Sep '12

Testing on Trunk is apparently broken as the test_exec_monitor target has been removed from Boost.Test Trunk as of revision #74642. A quick grep shows 22 Jamfiles and over 200 targets dependent upon this. Whats happened? John.

14 68

[coroutine] interface suggestion
by Oliver Kowalke 21 Sep '12

21 Sep '12

I forgot a suggestion made by Vicente: 5.a coroutine<>::caller_t provides function bind() which must be called after coroutine::caller_t::yield() returned in order to get the parameters int f( caller_t & c, strg & s, int x) { c.yield( 7); // alternative c( 7) c.bind( s, x); // s and x will contain new values given by caller } alternative: because the user could forget to invoke bind(): int f( caller_t & c, strg & s, int x) { c.yield( 7, s, x); // alternative c( 7, s ,x) } Oliver

3 18

: [coroutine][review] not really a review
by Robert Ramey 21 Sep '12

21 Sep '12

I took a cursory look at the coroutine (or is it context) documentation. Is this all there is? It's really inadequate even to evaluate the library - much less use it for anything. I very much like Giovani's implementation and used in at least one other project. I don't remember why it wasn't accepted - not that it matters now. I would like to request that all the documentation, examples, etc. from the previous package be folded into the the current one - should it be accepted. This facility is 20 years overdue - I know this as I had to role my own 20 years ago! It's also foreign to many programmers who could benefit from it. It must come with motivating documentation to be worthwhile. Robert Ramey

1 0

Timer & Boost.Test incompatibility
by Craig Henderson 20 Sep '12

20 Sep '12

Hi, I am starting a new project. I am using boost::timer::cpu_timer from boost/timer/timer.hpp and Boost.Test When I include boost/test/included/unit_test.hpp in my unit test suite, I get compilation errors where boost::timer is declared as a class where previously it's defined as a namespace: boost/timer.hpp(45): error C2869: 'boost::timer' : has already been defined to be a namespace boost/test/impl/framework.ipp(153): error C2882: 'timer' : illegal use of namespace identifier in expression boost/test/impl/framework.ipp(153): fatal error C1903: unable to recover from previous error(s); stopping compilation Environment: Boost 1.51.0 MSVC 2012 Windows 7 Is this a known conflict? Is there any workaround? Thanks -- Craig

4 5

[coroutine] interface suggestion
by Oliver Kowalke 20 Sep '12

20 Sep '12

my suggestion: 1. the lib provides both coroutine<> and generator<> 2. coroutine<> is special routine allowing to enter and leave a function multiple times 3. coroutine<> first template arg defines the signature of the function accepted by coroutine<> 4. coroutine<>::operator() return type is equal to the return type of signature (template arg) 5. function accepted by coroutine<> first arg allows to suspend coroutine<> == jump back to caller of coroutine<>::operator() -> it has to be discussed if this type is of coroutine<> with an 'inverted' signature (as proposed by Giovanni) or not 6. generator<> returns a set of values in a sequence 7. generator<> has only one template arg defining the return type 8. function accepted by generator<> is required to return void 9. generator<>::operator() returns optional< return_type > 10. generator<> is not a range because - 'A Range provides iterators for accessing a half-open range [first,one_past_last) of elements and provides information about the number of elements in the Range.' -> a generator can not determine how many elements it will return - generator<> can only provide a single pass: 'For any Range a, [boost::begin(a),boost::end(a)) is a valid range, that is, boost::end(a) is reachable from boost::begin(a) in a finite number of increments.' -> if the function accepted by generator<> loops for ever it violates the range invariant typedef generator< int > gen_t; void f( gen_t::caller_t & caller) { while ( true) { caller( 7); } } 11. on top of generator<> something like an iterator could be provided: typedef generator< int > gen_t; gen_t gen( f); enumerator< gen_t > i( gen): enumerator< gen_t > e; while ( i != e) { cout << * i++ << "\n"; } Oliver

3 2

[coroutine][review] Very Late Review
by Giovanni Piero Deretta 19 Sep '12

19 Sep '12

Hi all, This review is way after the deadline, so feel free to ignore my vote, but I hope that the feedback will be useful anyway. First of all, I vote to accept the library with the current interface. I see that Oliver agreed to significant interface changes which I hope these will be subject to a minireview before final acceptance. - What is your evaluation of the documentation? Adequate for someone that already has some knowledge of coroutines and generators, but it lacks an introduction on the topic. Like other reviewers I also suggest that some of the more interesting examples should be presented and discussed in the documentation. Also, a few topics should be discussed more in details: * Why thread local storage cannot be referenced in threaded applications with a brief descritption of what is, IMHO, a GCC TLS bug. * What is the exact meaning of the preserve FPU flags (which, as far as I understand, it really makes it optional to preserve the FPU context), not the FPU registers themselves - What is your evaluation of the potential usefulness of the library? Very useful. This library is long due in Boost. - Did you try to use the library? With what compiler? Did you have any problems? No, I did not try. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? In depth study. - Are you knowledgeable about the problem domain? yes, I have implemented similar functionality before. - What is your evaluation of the design and implementation? The interface as proposed for review is very close to my original boost.coroutine interface and as such I of course think is adequate. I think that the interface can be improved (which is one of the reasons that i never submitted my library for review). Since the beginning of the review period, a lot of interface changes have been proposed, some of which I like, some I don't. About the design: I do not believe that the coroutine should be parametrized on do_unwind (insert something about not parametrising on behaviour here :) ). The behaviour of boost.coroutine should be explicit from the type and one shouldn't have suprises when unwinding a coroutine. Please chose to either assert or explicit unwind on destruction. I prefer the former, as per std::function, but would prefer the latter to parametrization. I also dislike the preserve_fpu flag, but I understand what it is there for and could live with it. Still it should be harder to misuse: make it an enum, and move it last in the constructor parementer list, so that specifying a stateful allocator (BTW, I assume these are supported), shouldn't require to specify this flag. I like the idea that has been proposed during the review that the result of a coroutine should be retrivable at any time via a get method. I dislike the proposed optional<T> result for operator(). If the previous delayed result functionality is implemented, operator() should just return *this, so that the subsequent get() call can be chained or the result tested for non empty. This change has the potential of deeply affecting the interface, so I would really like to see it subject to a mini review before acceptance. The coroutine object has both the concept of a not-a-coroutine and of a completed coroutine. This is confusing, and should be conflated to 'empty' state, analogous to an empty std::function. In addition to simplifying the documentation and the interface, it should also slightly improve the implementation. Operator bool should return !empty as per std::function. It has been suggested that coroutine::self be removed an have a thread specific object. I strongly disagree with this option. First of all it will make it too easy to break type safety: typedef this_coroutine<int(int)> this_coro; typedef this_coroutine<void()> that_coro; coroutine<int(int)>([]{ that_coro::yield(); // oops compiles fine, UB at runtime. }); Of course you can find ways to break even code with the explicit self syntax, but the above is, IMHO, just too dangerous. In practice, one need to pass the signature to any code that wants to yield anyway, so might as well pass the self object around, at least one can rely on template type deduction. Also, one does not really want arbitrary code to yield out of the coroutine as this can be dangerous (think of code between yield statements as a sort of critical section) as invariants can be broken or mutices held. Instead I suggest doing away with a separate self type and instead making the first parameter to the coroutine functor a full fledged coroutine, with simmetric signature: coroutine<int(void)> my_coroutine([](coroutine<void(int)> caller) { caller(10); }); int i = my_coroutine(); This means that the parameter no longer represent the coroutine itself, but, more logically, the caller coroutine. This makes very obvious the analogy between coroutines and channels. It also blurs the division between symmetric and asymmetric coroutines. Bonus points if you had a function that infers the coroutine singnature from the coroutine functor operator() (I like to call this function callcc for obvious reasons [ http://en.wikipedia.org/wiki/Call-with-current-continuation] auto my_coroutine = callcc([](coroutine<void(int)> caller) { ... } ); This would obviously work only if the functor is monomorphic, but it interacts very nicely with C++11 lambdas. I do not like the separation between coroutines and generators. Instead the generator class should be dropped. The reason that I had generator as a separate class in the original coroutine SoC is because I wanted to give it iterator semantics (this also required internally using a reference counted pointer to make the iterator copiable, which I disliked). Instead I propose to make every coroutine<T()> fulfill the the input range concept and every coroutine<void(T)> fulfill the output range concept (this is a functionality not covered by generators). In practice it means that for these classes of coroutines, begin and end are defined returning appropriate iterator (i.e. some very thin layers around the coroutine itself). As a range is required to survive its iterator anyway, the iterators can simply use plain pointers to the coroutine. The last suggestion works very well if coupled with the suggestion of making 'self' a full coroutine: std::vector<int> a = { ... }; std::vector<int> b = { ... }; std::cout << "The result of 'merge(a,b) is:\n"; for(auto x : callcc([&](coroutine<void(int)> c) { std::merge(a.begin(), a.end(), b.begin(), b.end(), c.begin()); }) { std::cout << x << "\n"; } I thought modelling generalized coroutines<T(T)> as ranges, but I have yet to find a good model. Enough abot the interface; I have some more comments about the Implementation: The code is readable (it helps if you are familiar with the topic) even if, as other reviewers have noted, is almost free of comments. The nest of base classes required to handle all possible coroutine signatures is quite overwhelming though and I think it could be significantly reduced. I was able to trace through the execution paths I was interested into, but it required quite a bit of back and forward between implementation files. The coroutine object itself holds a reference counted pointer to the implementation. As the coroutine is movable but not copyable, I do not think that reference counting is needed. The coroutine itself should consists of two raw pointers: a pointer to the target context and a pointer to the result slot. You need this pointer anyway, because, if I understand correctly, you are planning to allow retriving the result slot at any time after the operator() and yield call. I think that the implementaiton is not as eficient as possible. I strongly believe that a coroutine call should be as fast as a normal functiona call as possible. As such it is important to optimize operator() and yield as much as possible. Ideally, no code should be executed other than calling context::jump_fcontext. I will detail below how such an implementation is possible: Operator() needs to check at every call whether the coroutine has started and decide whether to call impl->start or impl->resume. This is a very predictable branch, but every instruction counts, and as a minimum the branch will increase instruction cache pressure and decoding bandwith. Similarly, there is a branch after the internal resume call to detect whether the coroutine has terminated and another one to check whether exceptions should be thrown. The first branch can be removed by moving the complexity to the constructor: a redy-to-start context should be indistinguishable from a suspended context. The branch on is_complete can be removed by making sure that a resume on on-complete also pass the pointer to the return slot via the native_resume result. The check for pending exceptions can be removed if context switches that cause exceptions to be thrown on the target context are modified to create an artificial stack frame on top of the called stack that runs a function that throws the exception only when necessary. This would require a small (but useful) addition to boost.context interface. The flag manipulation can be removed by completely removing the flags. The only state you really need to know is whether the coroutine is empty (which can be signaled by having a null pointer to context) and whether any result is available (that can be signaled by having a null pointer to result slot). Both pointers are updated by each call to resume(). As the internal context implementation only allows passing a single value, this would require an additional level of indirection. The indirection can be removed by changing the context jump_fcontext api to return a structure of two pointers: the existing parameter plus an additional pointer to the calling context. As most ABI allow to return small structures in registers, this can be implemented quite eficiently. Another source of ineficiency and indirection is the constructor, which while not as critical as task switching itself, it should still be fast. To construct a coroutine two dynamic allocations are currently needed, one to allocate the control block (i.e. the derived class from context base), one to allocate the stack. I suggest completely removing the control block, instead placing the allocator and the coroutine functor itself directly in the stack frame of the trampoline. To do this, after allocating the stack, the constructor switches to the target context trampoline and passes to it apointer to the functor and allocator pairs from constructor stack, which are moved to local variables. This will also implicitly type erase both the allocator and the functor. Similarly, there is noneed to store the two caller and calle fcontextes, which can be mantained as local variables inside inside coroutine::operator(), and yield respectively. The previously described additional parameter returned by impl->resume allows to eficiently retrieve the other context. These stack allocations are not unlike what is aready done for result slot which is located inside yield or operator(). As there is no control block any more, cleanup can no longer be done inside its destructor. Instead, after the context has unwound, the trampoline switches to the calling context stack and executes a cleanup function on top of it (this is the same functionality need to implement the exception throwing as described before). This cleanup function can safely destroy first the coroutine functor and then deallocate the stack. The cleanup function then returns null for both the calling context pointer and result slot, signaling that the coroutine has exited. I have a sketch implementation of most of the suggestions above here https://github.com/gpderetta/Experiments/blob/scheduler/switch.hpp(examples here https://github.com/gpderetta/Experiments/blob/scheduler/switch_test.cc) That's all so far; I'll try to come with further comments; I'm sorry for the wall of text, I wrote it in one go and didn't have time to cut it down. Good luck with the review! -- gpd

4 9

[type_erasure] Difficulties with const
by Christophe Henry 19 Sep '12

19 Sep '12

Hi Steven, I have a const problem. Consider the following classes: struct Something { Something(const char* n): myName(n){} std::string const& getName()const { return myName; } std::string myName; }; struct Container { typedef std::vector< AnyNameable > PublicData; Container() { Something s1("bla"); Something s2("blabla"); myData.push_back(s1); myData.push_back(s2); } PublicData getData()const { PublicData res; for (Data::const_iterator it = myData.begin(); it != myData.end() ; ++it) { res.push_back(AnyNameable(*it)); } return res; } private: typedef std::vector< Something > Data; Data myData; }; Container is simply a class returning its "Something", hidden behind AnyNameable (nice way to realize C++ Coding Standards Item 42 BTW). I have a simple test function: void test() { Container c; Container::PublicData data = c.getData(); for (Container::PublicData::const_iterator it = data.begin(); it != data.end() ;++it) { AnyNameable a(*it); std::cout << "data: " << a.getName() << std::endl; // auxiliary question: why does this not work if I use const _self&? //std::cout << "data: " << (*it).getName() << std::endl; } } int main() { test(); return 0; } Now comes the interesting part. If I define AnyNameable using the concept interface, all goes (almost) well: template<class C, class T> struct getName { static T apply(C const& cont) { return cont.getName(); } }; namespace boost { namespace type_erasure { template<class C, class T, class Base> struct concept_interface< ::getName<C, T>, Base, C> : Base { T getName() { return call(::getName<C, T>(), *this); } }; } } typedef any< mpl::vector< getName<_self,std::string const&>, relaxed_match, copy_constructible<>, typeid_<> >, const _self& > AnyNameable; This compiles and outputs as expected. Problem 1: This will not compile std::cout << "data: " << (*it).getName() << std::endl; Hmmm ok not so bad. I'll gladly pay the extra line. (interestingly, it would compile and work without const) Problem 2: if I use the MEMBER macro: BOOST_TYPE_ERASURE_MEMBER((has_getName), getName, 0); typedef any< mpl::vector< has_getName<std::string const&()>, relaxed_match, copy_constructible<>, typeid_<> >, const _self& > AnyNameable; Then the code does not compile, unless I accept to give up all of my consts. On one hand, I will find it a easier job to sell type_erasure with the macro, OTOH, I will not give up my consts ;-) Would it be possible to have the macro AND const-correctness? Attached, a small test with the complete code. Thanks, Christophe

2 3

Interest in a GPU computing library
by Kyle Lutz 19 Sep '12

19 Sep '12

This is a call for interest in a GPU computing library for Boost. I have been working on the library in my spare time for the past month or so and it’s reached a point where I am ready for feedback. Below gives a brief overview, some notes on the design, and a small example of the library which I’ve named Boost.Compute. --- Overview --- * C++ library for general-purpose computing on GPUs/Accelerators * Based on OpenCL (Open Computing Language) * Header-only implementation * API inspired by the STL, Boost and Thrust * Boost dependencies: Config, Utility, Iterator, Exception, Preprocessor, TypeTraits, StaticAssert, MPL, Proto --- Design --- OpenCL is a framework for writing programs that run on parallel computing devices such as GPUs and multi-core CPUs. The OpenCL language is based on C99 with a few extensions to simplify writing parallel and vector-based code. More background: http://en.wikipedia.org/wiki/OpenCL. The core of the Boost Compute library is a thin C++ wrapper over the OpenCL C API. It provides classes for creating and managing various OpenCL entities such as contexts, buffers, devices and kernels. These classes are written in a style consistent with Boost and the C++ standard library. Written on top of the core library is a partial implementation of the C++ STL which includes common containers (e.g. vector<T>, array<T, N>) and algorithms (e.g. copy, find_if, sort) along with a few extensions (e.g. scatter, exclusive_scan, flat_set<T>). The aim of Boost.Compute’s STL API is to provide a familiar interface to developers wanting to easily write new code or port existing code to run on GPU devices. It also features a few “fancy” iterators inspired by the Boost.Iterator library such as transform_iterator<>, counting_iterator<>, and permutation_iterator<>. Furthermore, a lambda expression library was written using Boost.Proto which allows for mathematical expressions to be defined at the call site of an algorithm and then be executed on the GPU. For example, to multiply each element in a vector by the square root of itself and then add four: transform(v.begin(), v.end(), v.begin(), _1 * sqrt(_1) + 4); --- Example --- Below is a small example of using the Boost.Compute API to sort a vector of int values: // create vector of random values on the host std::vector<int> host_vector(10000); std::generate(host_vector.begin(), host_vector.end(), rand); // create a compute context for the default gpu device boost::compute::context gpu_context = boost::compute::default_gpu_context(); // create a vector on the gpu boost::compute::vector<int> device_vector(gpu_context); // transfer the values to the device device_vector = host_vector; // sort the values on the device boost::compute::sort(device_vector.begin(), device_vector.end()); // transfer the sorted values back to the host boost::compute::copy(device_vector.begin(), device_vector.end(), host_vector.begin()); --- Conclusion --- The Boost Compute library provides a useful, intuitive, and familiar interface for running high-performance parallel code on GPU devices. Incorporating Boost.Compute into the Boost libraries would make GPU computing readily accessible to a large number of C++ developers. All comments and feedback are welcome and greatly appreciated. Thanks, Kyle

17 34

[graph] msvc failure on trunk
by Jürgen Hunold 19 Sep '12

19 Sep '12

Hi all, currently all graph test with msvc on trunk fail with: C:\Users\BoostTest\Trunk\boost\boost/pending/property.hpp(101) : error C2182: 'lookup' : illegal use of type 'void' C:\Users\BoostTest\Trunk\boost\boost/pending/property.hpp(101) : see reference to class template instantiation 'boost::lookup_one_property_internal<boost::property<Tag,T,Base>,boost::vertex_bundle_t>' being compiled See http://www.boost.org/development/tests/trunk/developer/output/DrWeb_x86-boo… bin-v2-libs-graph-test-basic_planarity_test-test-msvc-9-0-debug-address- model-32-threading-multi.html for details. It seems this affects mscv-9.0 and 10.0. 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 2

[geometry] [polygon] What's the relationship?
by Dave Abrahams 19 Sep '12

19 Sep '12

Could someone please explain the relationship, if any, betweeen these two libraries? They seem to cover similar domains. Do they interoperate? Is one better than the other for certain kinds of problems? Was Boost.Polygon once called the Geometry Template Library, as suggested by the BoostCon 2009 slides? Boy, that's confusing. Lastly, could we get these libraries' documentation to mention one another and explain the information I'm asking for? Thanks in advance for answering. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

5 5

[date_time] merge from trunk to release
by Vicente J. Botet Escriba 19 Sep '12

19 Sep '12

Hi, I have tried to merge (https://svn.boost.org/trac/boost/changeset/80051) Boost.DateTime from trunk to release to merge and I suspect that the svn merge tools has not been used since a long time. I'm getting a long diff with a lot of mergeinfo. Property changes on: boost/date_time/gregorian_calendar.ipp ___________________________________________________________________ Deleted: svn:mergeinfo Reverse-merged /trunk/boost/date_time/gregorian_calendar.ipp:r38329-41356,41778,41955,41983,42067,42076,42080,42141,42424,42988-42990,43112-43113,43209-43210,43799,44807,44825,44897,45097-45098,45264,45283,46445,46508,46544,46580,46632,46673-46674,46790,46801,46803-46804,46808,46819-46820,46826-46829,46832,46936,47024-47027,47058,47064,47086,47093,47254,47283,47301,47389,47392,47401,47456,47754,47768,47793-47794,47797,47938,47940,47942,47985-47987,47993,48089,48204,48226,48252,48280,48478,48496,48663,48695,48729-48730,48973,49111,49118,49121-49122,49131,49254,49333,49345-49346,49424,49433,49510,49586,49601,49620,49627-49628,49691,49693,49945,49970-49971,49980,49996-49998,50019-50020,50024-50027,50059,50237,50240,50244,50312,50413,50447,50486,50497,50516,50997,50999,51031,51045,51066,51104,51120,51171,51189,51210,51239,51253,51284,51311,51337,51400,51410,51413,51422,51448-51449,51862,51881,51909,51912,51961,52231,52258,52425,52773,52866,52879-52881,52937,53048,53050,53061-53062,53125,53141,53143,53187,53211-53212,53218-53219,53233,53261,53293,53343,53425,53462,53476,53478,53544,53577,53619,53648-53649,53651,53671-53672,53682,53699,53751,53780,53790,53800,53802,53888,54385,54594,54873,54914,55097-55100,55132,55138,55140,55146,55151,55159,55184-55185,55224,55370,55470,55473,55484,55500,55507,55528,55573,55656,55667-55670,55698,55718,55723,55728-55729,55749,55780,55838,55877-55902,55905-55917,55921-55922,55990-55992,56009-56010,56014-56017,56020,56028,56077,56089,56097,56116-56117,56125-56128,56140,56147,56202,56207,56300-56302,56319,56321,56328-56329,56339,56346-56349,56360,56362-56363,56374,56440-56441,56454,56461,56468,56473,56557-56563,56570-56571,56603,56633,56651,56654,56658,56682,56697-56699,56715,56717-56719,56732,56796-56797,56855-56856,56859-56860,56868,56922,56942,56988-56989,57005-57006,57008,57126,57139,57150-57153,57159,57170,57174,57177,57196,57249,57290,57346-57348,57388-57389,57393,57395,57412,57433,57479,57520,57525-57526,57542,57544,57559-57560,57580,57592-57593,57601,57613,57618,57631,57645-57646,57663,57665,57670-57672,57694-57695,57703-57704,57706,57708,57710,57717-57718,57721,57724,57726,57730,57732,57734-57738,57748,57751,57757-57759,57782,57790,57826,57828,57830,57859,57863,57865,57869-57871,57875-57877,57892,57894-57896,57898,57901-57907,57909-57911,57913-57914,57923,57928-57930,57933-57934,57939,57944,57949,57951,57953-57955,57957-57958,57973-57974,57986,58005,58034-58035,58037-58039,58041-58043,58047-58049,58057,58061,58071,58073-58074,58082-58083,58086-58087,58090-58091,58093-58094,58105-58109,58114,58117-58118,58120-58121,58123-58125,58127-58129,58145-58146,58148,58171-58172,58179-58181,58183,58196,58219,58246,58270,58272,58275,58279,58295,58297-58298,58306,58310,58323,58333,58356,58375,58378-58379,58392,58400-58401,58407-58408,58412-58415,58427,58437-58439,58444,58452-58453,58467,58469,58491-58492,58501,58520,58531,58533,58555,58563-58565,58570,58574,58576,58588-58589,58598,58602,58611,58621-58630,58634-58636,58647-58652,58670-58671,58694-58695,58698-58699,58703-58708,58713-58721,58740,58761-58762,58768-58770,58772,58779,58782-58783,58793,58796-58799,58824,58850-58851,58859,58865,58870-58871,58876,58887,58900,58914-58920,58942-58943,58965-58966,58971,58994-58995,59005,59062-59063,59103-59106,59129-59134,59141-59142,59156,59163-59168,59241-59242,59244-59248,59256-59257,59277,59341-59344,59347-59361,59374-59376,59390,59407,59413,59416-59417,59420-59424,59440-59441,59486-59491,59496,59519-59522,59537-59538,59540-59543,59574,59583-59584,59618,59628,59662,59667,59713-59726,59729,59734,59742,59748,59761,59795,59854,59910,59928-59935,59937,59946,60078-60079,60126-60127,60141-60143,60152-60155,60164,60172,60178,60180-60181,60184-60185,60190-60192,60195-60199,60201,60210,60216-60218,60220,60225-60227,60256-60260,60279-60280,60282-60283,60295-60296,60313,60315,60335-60336,60339-60340,60343-60357,60359,60365-60366,60373,60380,60384-60385,60391,60395,60403,60451-60453,60455,60470-60472,60479,60485,60494-60496,60503,60526-60527,60608,60610-60611,60615,60619-60620,60624,60633,60639,60645-60646,60651,60657,60659,60669-60671,60681-60683,60685,60687,60689,60692,60705-60707,60717-60725,60738,60740,60743-60746,60750,60752,60756,60767,60769-60770,60775,60781,60788,60817-60820,60828-60829,60849-60850,60859-60861,60869,60874,60882-60885,60888,60899-60900,60916-60923,60925,60938-60941,60958,60961-60962,60995-61000,61002,61009-61010,61012-61013,61015-61016,61055-61064,61074,61076,61085,61100-61101,61104,61117,61122-61124,61127-61128,61131,61151-61152,61155-61156,61159,61165,61171-61172,61174,61179,61182-61183,61185,61190-61192,61194,61212-61214,61217-61225,61230-61232,61234-61240,61244-61251,61254,61257,61262-61266,61273-61276,61282-61287,61290-61292,61294-61299,61302-61303,61307-61308,61310-61312,61315-61326,61328,61330-61331,61333-61336,61338-61340,61342-61344,61347-61348,61350-61357,61360,61367-61369,61371-61373,61381,61384,61388-61392,61398,61405,61416,61421-61422,61424-61426,61435,61437,61445-61451,61460,61462,61465-61468,61471,61475-61481,61483,61489,61491-61492,61499-61503,61506,61510,61514-61515,61520-61521,61523-61525,61543,61547-61549,61551,61553,61564-61569,61573-61582,61606,61643,61645,61649,61668-61669,61674-61677,61679,61696-61699,61708,61717,61723,61726-61728,61748,61750,61764,61766,61769,61782-61783,61788,61795-61796,61824,61832,61838,61841,61843-61844,61856,61858-61859,61876,61881,61918-61919,61925,61928,62042,62046,62051,62074,62080-62081,62084,62098-62099,62116,62139,62142-62148,62150-62152,62165-62166,62176,62182-62184,62245-62246,62248,62251,62255,62259,62271,62368,62371-62373,62394,62404-62406,62426,62479,62497-62499,62506,62530-62533,62535,62545,62547-62550,62556-62558,62579,62592-62593,62595,62605-62607,62609,62611,62616-62620,62622,62626-62630,62660-62661,62671,62678,62683-62684,62686,62693,62698,62725-62727,62736,62753-62754,62781,62798,62811,62825,62827,62829,62897-62898,62909,62926-62927,62932-62935,62937,62951-62952,62957,62960-62966,62972,62984,62994,62998-63000,63002,63004,63006,63012,63016,63020-63021,63023-63024,63031,63033-63039,63048-63049,63057,63084,63086-63088,63091-63094,63097-63098,63101,63125-63128,63137-63147,63149-63155,63180,63188-63204,63217,63221-63225,63227,63234,63240-63241,63244,63247,63260-63261,63268-63270,63274,63276-63280,6328: and much more. Even if the modifications to merge were simple, the diff file is more that 200K lines. I have made a diff between the trunk and the release and the single differences are due to a $Date tag that includes the commit date. Hrrr. Could this merge be done? I could do it if permission is granted from the author or the release manager team. Best, Vicente

3 5

How to bind program termination with end-of-stream in Boost.Process 0.5?
by alfC 18 Sep '12

18 Sep '12

Hi, I have a simple question about the latest Boost.Process 0.5 library. Namely how to How to bind program termination with end-of-stream in Boost.Process 0.5? For example, in this example http://www.highscore.de/boost/process0.5/boost_process/tutorial.html#boost_… One can make a look to read the output of the process until the program finishes, but the stream is not invalid after program termination. ... while(std::getline(is, s)){ // is is an stream associated with a process (e.g. '/usr/bin/ls') std::cout << "read: " << s << std::endl; } std::clog << "end" << std::endl; // never reach ... I originally posted the question in http://stackoverflow.com/questions/12329065/how-to-bind-program-termination… but now I think it can be overlooked there. Since now there seems to be extra layers (Boost.Streams) it may be that I don't know how to set up the file_descriptor_source, etc. BTW, the solution to this question can be used to improve the example code in http://www.highscore.de/boost/process0.5/boost_process/tutorial.html Thanks, Alfredo -- View this message in context: http://boost.2283326.n4.nabble.com/How-to-bind-program-termination-with-end… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 10

VS2012 and bootstrap
by Pedro Larroy 18 Sep '12

18 Sep '12

Hi I'm trying to compile boost with VS2012 in the exact same way that it succeeds with VS2010. And get an error w32_getreg.c: fatal error C1083: Cannot open include file: 'windows.h' Anyone knows how to solve this? Thanks. Pedro.

1 0

[ANN] ODB C++ ORM 2.1.0 released, adds support for Uuid, Multi-Index
by Boris Kolpackov 18 Sep '12

18 Sep '12

Hi, I am pleased to announce the release of ODB 2.1.0. ODB is an open source object-relational mapping (ORM) system for C++. It allows you to persist C++ objects to a relational database without having to deal with tables, columns, or SQL and without manually writing any of the mapping code. Major new features in this release: * Ability to use accessor/modifier functions and expressions to access data members. In most cases ODB is capable of discovering suitable accessor/modifier functions automatically. * Support for virtual (imaginary) data members that can be used to handle the C++ pimpl idiom as well as aggregate or dis-aggregate real data members. * Ability to define database indexes on data members. Multi-member indexes as well as indexes with database-specific index types, methods, and options are supported. * Support for mapping extended database types, such as geospatial types, user-defined types, collections (arrays, table types, etc.), key-value stores, XML, JSON, etc., to suitable C++ types. * The Boost profile library now provides persistence support for the Uuid and Multi-Index container libraries. * The Qt profile library now provides persistence support for the QUuid type. * Support for generating single (combined) database schema file from multiple C++ header files. This release also adds support for Visual Studio 2012 and Clang 3.1. Specifically, all the runtime libraries, examples, and tests now come with project/solution files for Visual Studio 2012 in addition to 2010 and 2008. A more detailed discussion of these features can be found in the following blog post: http://www.codesynthesis.com/~boris/blog/2012/09/18/odb-2-1-0-released/ For the complete list of new features in this version see the official release announcement: http://www.codesynthesis.com/pipermail/odb-announcements/2012/000018.html ODB is written in portable C++ and you should be able to use it with any modern C++ compiler. In particular, we have tested this release on GNU/Linux (x86/x86-64), Windows (x86/x86-64), Mac OS X, and Solaris (x86/x86-64/SPARC) with GNU g++ 4.2.x-4.7.x, MS Visual C++ 2008, 2010, and 2012, Sun Studio 12, and Clang 3.1. The currently supported database systems are MySQL, SQLite, PostgreSQL, Oracle, and SQL Server. ODB also provides profiles for Boost and Qt, which allow you to seamlessly use value types, containers, and smart pointers from these libraries in your persistent classes. More information, documentation, source code, and pre-compiled binaries are available from: http://www.codesynthesis.com/products/odb/ Enjoy, Boris

1 0

[contract] static_assert in contracts or not?
by Lorenzo Caminiti 18 Sep '12

18 Sep '12

Hello all, If static assertions make sense within contracts (preconditions, postconditions, and class invariants) is a questions that has been raised by both Vicente and Andrzej. I don't have a definitive answer so I'd like to discuss with the ML. On Wed, Aug 29, 2012 at 2:48 PM, Andrzej Krzemienski <akrzemi1(a)gmail.com> wrote: > (6) > Static assertions: is there any value in providing them, given that we > already have this ability in Boost? I see that N1962 decided to abandon > them; I am pretty sure the reason was that static_assert was already there. > They somehow do not fit conceptually into the model of preconditions, > postconditions and invariants. Precondition, for instance tries to detect a > run-time condition occurring immediately before a function is called this > time. Static assertion is not even executed then. What point is there in > putting such assertion into the precondition? Documentation says " static > assertions can be selectively disabled depending on where they are > specified [...] so it is still important to logically associate them with > preconditions, postconditions, etc." -- technically this sentence makes > logical sense, but can you think of a single example where this selective > disabling of assertions would be useful? What is the point in disabling > such assertions at all, if they cost you nothing in run-time? I propose to > remove them and give a sort of recommendation that software quality is > assured by using a number of fairly independent tools: DbC, concepts, > static assertions. I think we can break down the question in two parts. Let's assume N1962 is accepted into C++1x so we have both contracts and static_assert. 1) Would you expect to be able to use static_assert within contract assertions (preconditions, postconditions, and class invariants)? Note that only boolean conditions are allowed by N1962 within contracts, general code is not allowed, therefore this is not a trivial question. For example, would you expect to be able to do the following option A: template< typename To, typename From > To* memcopy ( To* to, From* from ) precondition{ static_assert(sizeof(To) >= sizeof(From), "destination too small"); static_assert(boost::is_convertible<From, To>::value, "incompatible types"); to; // pointer not null from; // pointer not null } { // ... } In this case, would it ever make sense to use static_assert in postcondition and/or class invariants even if that were allowed? Or would you just use static_assert in the body, option B: template< typename To, typename From > To* memcopy ( To* to, From* from ) precondition{ to; // pointer not null from; // pointer not null } { static_assert(sizeof(To) >= sizeof(From), "destination too small"); static_assert(boost::is_convertible<From, To>::value, "incompatible types"); // ... } I don't like this because the assertions are about the specifications (they assert a requirement of the interface) so they should go in the declaration and not in the implementation. Or maybe the assertions should be represented as concept requirements on To and From, option C: template< typename To, typename From > requires SizeofGreaterEqual<To, From>, Convertible<From, To> To* memcopy ( To* to, From* from ) precondition{ to; // pointer not null from; // pointer not null } { // ... } (Only we don't have concepts...) 2) Let's assume, we answered option A to question 1): template< typename To, typename From > To* memcopy ( To* to, From* from ) precondition{ static_assert(sizeof(To) >= sizeof(From), "destination too small"); static_assert(boost::is_convertible<From, To>::value, "incompatible types"); to; // pointer not null from; // pointer not null } { // ... } Would you expect these static_asserts to be disabled when precondition compilation and checking is turned off at compilation time? I'd think so. Thanks. --Lorenzo

4 11

[contract] future directions
by Lorenzo Caminiti 18 Sep '12

18 Sep '12

Hello all, Now that Boost.Contract has been accepted :D, I couldn't help but to share where I see the library going next :) First of all, I'll have to put Boost.Contract in one of the upcoming Boost releases and I know that will be a lot of work! After that however, I see the library pursuing the following future directions: 1) Reduce compilation times (both preprocessor and template meta-programming optimizations) and possibly improve the (preprocessor) syntax error messages. IMO the x30 compilation time is the largest barrier for the lib adoption in production code, much more so than the strange syntax. I think the 2nd largest barrier is the cryptic syntax errors. The rationale is that you can learn a new syntax especially if that's the only way to program C++ contracts (assuming you actually need contracts) but if your projects takes 1 months instead of 1 day to compile and/or if the compiler errors don't help you understand what you did wrong, you will find it very hard to use the lib in large projects. 2) Support concepts similarly to Boost.Generic (N2081) and/or N3351. This will probably be for C++11 only but many of us wish concepts were part of C++11 and I think many people will favor a lib that supports them (e.g., many people were interested in Boost.Generic). 3) Refactor the macro parsing code so the syntax can be extended by the user. Ideally, this will result in something like Boost.Proto for the preprocessor, maybe "Boost.PreprocessorProto" (even if the actual API might be different and not necessarily equivalent to Boost.Proto API because dealing with macro expansions instead of the template expressions). I don't know if any of the above can actually be achieved but if I'll have time after the 1st Boost.Contract release I'll start working on these projects in the listed order of priority. Thanks. --Lorenzo

1 0

[graph] "get" bundled properties removed?
by Fabien Castan 17 Sep '12

17 Sep '12

Hi, The "get" function for bundled properties has been removed in the 1.51 release of boost and I don't know what is the new way to do this. This code doesn't compile anymore: > boost::write_graphviz( os, g.getGraph(), > make_simple_node_writer( get( &Vertex::_name, g.getGraph() ) ), > make_simple_node_writer( get( &ProcessEdge::_name, g.getGraph() ) ) ); https://github.com/tuttleofx/TuttleOFX/blob/master/libraries/tuttle/src/tut… The following code has been completely removed from "boost/graph/adjacency_list.hpp": " // Support for bundled properties #ifndef BOOST_GRAPH_NO_BUNDLED_PROPERTIES template<typename OutEdgeListS, typename VertexListS, typename DirectedS, typename VertexProperty, typename EdgeProperty, typename GraphProperty, typename EdgeListS, typename T, typename Bundle> inline typename property_map<adjacency_list<OutEdgeListS, VertexListS, DirectedS, VertexProperty, EdgeProperty, GraphProperty, EdgeListS>, T Bundle::*>::type get(T Bundle::* p, adjacency_list<OutEdgeListS, VertexListS, DirectedS, VertexProperty, EdgeProperty, GraphProperty, EdgeListS>& g) { typedef typename property_map<adjacency_list<OutEdgeListS, VertexListS, DirectedS, VertexProperty, EdgeProperty, GraphProperty, EdgeListS>, T Bundle::*>::type result_type; return result_type(&g, p); } template<typename OutEdgeListS, typename VertexListS, typename DirectedS, typename VertexProperty, typename EdgeProperty, typename GraphProperty, typename EdgeListS, typename T, typename Bundle> inline typename property_map<adjacency_list<OutEdgeListS, VertexListS, DirectedS, VertexProperty, EdgeProperty, GraphProperty, EdgeListS>, T Bundle::*>::const_type get(T Bundle::* p, adjacency_list<OutEdgeListS, VertexListS, DirectedS, VertexProperty, EdgeProperty, GraphProperty, EdgeListS> const & g) { typedef typename property_map<adjacency_list<OutEdgeListS, VertexListS, DirectedS, VertexProperty, EdgeProperty, GraphProperty, EdgeListS>, T Bundle::*>::const_type result_type; return result_type(&g, p); } template<typename OutEdgeListS, typename VertexListS, typename DirectedS, typename VertexProperty, typename EdgeProperty, typename GraphProperty, typename EdgeListS, typename T, typename Bundle, typename Key> inline T get(T Bundle::* p, adjacency_list<OutEdgeListS, VertexListS, DirectedS, VertexProperty, EdgeProperty, GraphProperty, EdgeListS> const & g, const Key& key) { return get(get(p, g), key); } template<typename OutEdgeListS, typename VertexListS, typename DirectedS, typename VertexProperty, typename EdgeProperty, typename GraphProperty, typename EdgeListS, typename T, typename Bundle, typename Key> inline void put(T Bundle::* p, adjacency_list<OutEdgeListS, VertexListS, DirectedS, VertexProperty, EdgeProperty, GraphProperty, EdgeListS>& g, const Key& key, const T& value) { put(get(p, g), key, value); } #endif " What is the replacement to this "get" accessor? Regards, Fabien

2 4

unable to merge trunk
by Oliver Kowalke 17 Sep '12

17 Sep '12

could I get a little bit more time to merge trunk into release? currently subversion fails with strange errors: svn merge ../../../boost-trunk/libs/context svn: error executing »xxdiff-subversion«: return value: 255, parameter: in directory ».«, Basename: doc/.svn/tmp/svn-z6MhPR /tmp/svn-1pKQPw doc/.svn/tmp/svn-wdZ3Xa svn: error reading answer of REPORT request from hdd Oliver

2 2

[Review.Contract] Vicente's review
by Vicente J. Botet Escriba 17 Sep '12

17 Sep '12

Hi, here is my short review. My vote is YES subject to these condition. * Removal of the Concepts part. The use of Boost.ConceptCheck to emulate C++ concepts proposal is in my opinion erroneous. Boost.Concept.Check is used to assert the actual parameter satisfy statically the concept conditions, while if I'm not wrong the C++ Concepts proposal use the requires clause to state the conditions of a possible instantiations. Using the same grammar with different semantics is confusing. In a last resort, if this feature is preserved, the requires keyword must be changed by another one. * static assertions are removed from the pre/post conditions. They can be moved to a specific "static assertions" section at the same level than the requires clause. This section could also include the concept check included now in the requires clause. * The library extends the EDSL to use directly C++11 features, in particular move semantics. Now that since the C++11 standard is released, more and more people are using C++11 specific features. I, in particular, will not use Contract if I can not make use of C++11 features provided by the compiler. * The contract broken handlers are noexcept, so that adding contracts don't change the original prototype. === STANDARD REVIEW QUESTIONS === * What is your evaluation of the design? While Lorenzo has show that using the preprocessor we can define a EDSL that is close to the native syntax (besides the parentheses stuff), the resulting interface is *closed* and interacts badly with c++ features not taken in account by the EDSL. I'm guessing that the user can not extend this EDSL without modifying the library. This is also the case of other libraries that make use of the pre-procesor to define a EDSL as Boost.Parameters or Toward Boost.Generics. It will be great if the user can extend the EDSL, but I suppose this could be very hard, if not impossible. I understand that Lorenzo is trying to reduce the preprocessor time using whatever is needed, but making the interface more complex would not help to improve the usability. I'm not sure the _TPL macros are really needed and whether the resulting code could perform better or not. * What is your evaluation of the implementation? I've not look inside. * What is your evaluation of the documentation? Very good. I would appreciate if the documentation includes a sections showing what is behind the scenes, what is generated by these macros. It would be great if you add a section/table with all the limitations, as e.g. these ones * Function and array types cannot be directly used as function parameter types within the contract macros ... * Each function parameter must always specify both its type and its name (parameter names can instead by omitted in usual C++ declarations). * All tokens must be specified in the fixed order listed in theGrammar section (it is not possible to specify postconditions before preconditions,|volatile| before|const| for member functions, etc). * Unfortunately, this library does not allow to specify contracts for unions. * Unfortunately, when member initializers are specified, the constructor body must be defined together with its declaration and contract * What is your evaluation of the potential usefulness of the library? I don't think the library could be used in a industrial context. The domain of this preprocessor EDSL is too large (C++ declarations + contracts + named parameters + concepts) and we will need to expand it yet to be useful (c++11, compiler specifics, ...). While the syntax is quite close to C++ syntax the library intends to emulate, the compiler errors will be quite unreadables. * Did you try to use the library? With what compiler? Did you have any problems? No. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I have not do a in-depth study. I has been concentrated inspecting the usability of the library and trying to identify the limitations it could introduce. * Are you knowledgeable about the problem domain? Yes, from a theoretical point of view. I have never used contract programming in real world projects. Best, Vicente

4 12

[Review:Contract]
by Roland Bock 17 Sep '12

17 Sep '12

Hi, first of all, YES, the library should be included in BOOST, in my opinion. In addition: * What is your evaluation of the design? Very cool. Looks like a 1:1 translations from some good algorithm books into code :-) * What is your evaluation of the implementation? I spent some time browsing through the macro code hoping it would help me to solve a problem of my own which looked similar (turned out it wasn't). Never being a fan of too much macro code, I have to say that this is very nicely written! My only concerns: - It seems to me that the implementation is spread over more files than necessary. It made following the call stack a bit tiresome. - I a bit torn between a) Steven's comment who would like to see CONTRACT_OLDOF being replaced by the would-be keyword in a possible future standard b) boost macros being clearly visible as such, leaving translation to future standard keywords to the user of the library, e.g. #define foreach BOOST_FOREACH I tend towards b). * What is your evaluation of the documentation? Excellent! * What is your evaluation of the potential usefulness of the library? It is a very good proof of concept and hopefully the basis for continued discussions about including contracts into the C++ language. Due to a lack of formal contracts in much of day to day programming and the enormous compile time overhead, I don't see the library being used all over the place anytime soon, but I expect it to be used in generic algorithms, helping both developers and library users. * Did you try to use the library? With what compiler? Did you have any problems? Sadly: No. Did not find the time. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent a few hours with the code, maybe two hours with the documentation and I followed some of the discussions during the review period. * Are you knowledgeable about the problem domain? I would not call myself an expert, but I know enough to say: I'd really like to have Boost.Contract available the next time I write a mission-critical function/class/library! Best regards, Roland PS: Sorry for being late. I'm hoping for lenience since the review period was announced a bit late as well :-)

4 8

What Should we do About Boost.Test?
by Dave Abrahams 17 Sep '12

17 Sep '12

Hi All, I was just going through Boost.Test to try to figure out how to teach it, and while it looks to have substantial value, it is also in quite a mess. It contains loads of features that are exercised in the examples/ directory but neither included in any of the tests nor documented. There are facilities for command-line argument parsing! There are "decorators" that turn on/off features for test cases. There is support for mock objects! These are cool and sometimes necessary features, but who knew? The third tutorial page (http://www.boost.org/doc/libs/1_51_0/libs/test/doc/html/tutorials/new-year-…) has a glaring typo in the code examples: "BOOST_AUTO_EST_CASE". There's no reference manual at all. There are nearly-identical files in the examples/ directory called "est_example1.cpp" and "test_example1.cpp" (Did the "t" key on someone's keyboard break?) I could go on, but where would I stop? I don't know what to do about this. Because of the lack of redundancy (i.e. tests and documentation), it's hard to tell whether this library is correct or even to define what "correct" should mean. It seems like, as long as the code is incompletely / incorrectly documented and tested, it's just someone's personal coding project that we happen to keep shipping with Boost, and not really a library for general use. This situation reflects poorly on Boost as a whole and the fact that it centers around a _testing_ library, which is concerned with robustness... well, let's just say that the irony isn't lost on me. I don't mean this posting as an attack on Gennadiy in any way, but I think the situation is unacceptable and therefore am opening a discussion about what should happen. As a straw man, I'll make this suggestion: - Boost.Test is officially deprecated in the next release - Its documentation, such as it is, is removed from the release after that - Meanwhile, other tests in Boost that use this library are rewritten to use a different mechanism

1 1

[Review:Contract] Boost.Contract Library is Accepted
by Dave Abrahams 17 Sep '12

17 Sep '12

Lorenzo Caminiti's Boost.Contract Library is hereby accepted into Boost. I will be brief but that should in no way be construed as a lack of enthusiasm. Reviewing the review commentary was a genuine pleasure. Anyone interested in this domain could learn a lot by going through the threads the way I did. There were five "yes" votes, one of which was very late (but I'm counting it), and one of which was conditional, and one "no" vote. I am accepting the library unconditionally because of Lorenzo's demonstrated responsiveness to issues. He gave thoughtful responses to the review comments and entered every issue raised that remained open into a bug database (http://sourceforge.net/apps/trac/contractpp/report/3) Congratulations, Lorenzo! -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

4 4

boost::asio::detail::win_iocp_io_service
by xakepp35 17 Sep '12

17 Sep '12

good time of day. i need to extend some basic boost functionality and performance by 1) variable timeouts in poll/run 2) replacing GetQueuedCompletionStatus with GetQueuedCompletionStatusEx and parallelized vectored i/o handling with single kernel/user transition so how can i replace win_iocp_io_service with my own implementation without modifying it's code inside "io_service.hpp"? there are HARD-CODED strings inside "io_service.hpp" like namespace detail { typedef win_iocp_io_service io_service_impl; } which better be something like user #define or template with default argument (like allocator) how do you suppose user may provide it's own implementation? how can i use my_iocp_io_service, declared and implemented within my executable's sources? -- View this message in context: http://boost.2283326.n4.nabble.com/boost-asio-detail-win-iocp-io-service-tp… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[review][coroutine] A Late Review
by Stewart, Robert 17 Sep '12

17 Sep '12

Coroutine should be accepted into Boost conditionally. My hesitation comes from the seemingly significant design and interface changes occurring during the review. I'm unsure how the current state compares to the library I reviewed. This leaves me wondering what is being accepted. I don't think the functionality of the library is changing, so I'm confident in accepting it on that basis. However, I think that a mini-review is needed to verify the finished design and documentation before final acceptance. ***** What is your evaluation of the design? I dislike the namespace. "coro" is meaningless and awkward. The namespace name should be "coroutines" (since there is a class named "coroutine", it must be plural). What users may choose as an alias is another matter. I wonder whether assertions can be added to flag calls of operator() from within a coroutine or generator. I know that's undefined behavior, but an assertion will catch the mistake in non-optimized builds. ***** What is your evaluation of the implementation? The source has major whitespace issues. It looks like a botched tab-to-spaces conversion. The move assignment operators do a self-assignment check. That is a "performance bug", as Howard Hinnant puts it. There are no comments in the code. This means Oliver's own maintenance will be harder, but it particularly means that it will be harder for anyone else to pick up the library's maintenance to help or replace Oliver in the future. The code looks well factored, though I certainly didn't spend a long time studying it. ***** What is your evaluation of the documentation? There is no Motivation section. The documentation must catch the attention of the reader right on the first page. Why should anyone care about this library? What can it do for them? Why should anyone spend time reading the rest of the documentation? Overall, the documentation is a good introduction to the library. The examples are appropriate for tutorial purposes, but there is a complete lack of non-trivial examples to illustrate how the library can be employed. What can one do with this library that isn't possible otherwise? What is better, according to any number of criteria like less code, faster, etc., using this library? How much of the interface remains what was designed by Giovanni Piero Deretta? Given all of the changes during the review, I wonder how much remains. The "Executing a coroutine" section of coroutine.html could do with a sentence about the coroutine-function's signature as, say, a new, third sentence in the first paragraph: "The coroutine-function can take arguments and return values as discussed in the next section." The "Exceptions in coroutine-function" section of coroutine.html, and the corresponding section of generator.html, suggests that exceptions must be thrown using Boost.Exception. Is that the intent? If so, you need to make that point clear. I suppose that isn't true in C++11. Also, what is the namespace of forced_unwind? This section is the first mention of it, so one is left to wonder if it belongs to the library or not. The "FPU preserving" sections of coroutine.html and generator.html imply that the library allows to prevent preserving the FPU registers, but gives no information about how that is done or where to read more about it. Also, the note, in those sections, references "ABIs", but gives no references and fails to specify which ABIs are meant. The coroutine and generator synopses, in coroutine/coroutine.html and generator/generator.html, are confusing. The definition of self_t refers to undefined types T and R. The synopsis of coroutine suggests that the type is not copyable Some detailed comments are at the end of this message. ***** What is your evaluation of the potential usefulness of the library? I think this library will be extremely useful. I think it could have profound implications for the design of libraries that rely on multiple threads today. Indeed, there is a use case in some current code in one of our applications that, I think, would be simplified yet improved by using this library. - Did you try to use the library? With what compiler? Did you have any problems? Unfortunately, and despite the lateness of my review, I've had no time to try it. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent several hours reading the documentation, and a fraction of that looking over the code. ***** Are you knowledgeable about the problem domain? No. ___________________ Documentation Comments ________________ coroutine/coroutine.html The illustration of make_coroutine() is accompanied by no description, so f() should be omitted. It adds nothing one cannot infer from the signature and raises questions about what c and, in turn, f() actually does. In the first warning, s/coroutine/a coroutine/. In the second, s/::FlsAlloc(), ::FlsFree()/::FlsAlloc() and ::FlsFree()/. s/stack-allocator/stack allocator/ Odd internal spacing for parentheses: one space after the open parenthesis, and no space before the close parenthesis. s/operator()()/operator()/ s/flags, and stack and instruction/flags, stack, and instruction/ s/value of local variable is preserved/value of local variable i is preserved/ "yield was called so we returned" is confusing. The coroutine hasn't been called by that point. That comment should probably be, "while the coroutine hasn't returned" (or "finished"). In Transfer of data, the last sentence of the second paragraph (after the note) is rather confusing and includes a grammatical error. I suggest this instead: "The arguments passed to coroutine<>::operator(), in one coroutine, are passed to coroutine<>::self_t::yield() in the other coroutine, except for the first invocation of coroutine<>::operator(), which passes them to the coroutine- function, instead." The example in Transfer of data could use with a few more comments. Specifically, "int x = c(7)" could use the comment, "x is 7 because c(7) passes 7 to fn, where self.yield(i) passes i == 7 back", and "x = c(10)" could use the comment, "x is 10 because c(10) causes "self.yield(i)" to return 10 in fn(), so fn() returns j == 10". While you're at it, s/j == 10 because c( 10) in main()/j == 10 because of c(10) in main()/. The coroutine-function with multiple arguments example deserves some comments explaining why yield() gets one int argument and returns a two-int tuple and why the function returns one int, to tie those aspects into the Signature template argument. The Exit a coroutine-function section discusses yield_break(), but the example calls yield_return(). In the Important note within Exit a coroutine-function, s/complete (can not resumed/complete and cannot be resumed/. In Stack unwinding, s/(stack is unwound by default)/(the default)/. In FPU preserving's note, s/ABIs the/ABIs, the/. ________________ coroutine/coroutine/coroutine.html In the Effects of the template constructor, s/stack before destructing it/stack before releasing it/. In the Effects of the function call operator, the wording can be improved: "Invokes the coroutine-function with the supplied arguments, returning the argument passed to self_t::yield()." Likewise, the Throws clause: "Any exception emitted by the coroutine-function or coroutine_terminated if self_t::yield_break() is called." The Effects of self_t::yield() can be improved: "Returns execution control to the calling context, arranging for the calling context's operator() to return r." (You need to make the argument list "(R r)" for that description.) Next, yield() needs a "Returns" clause: "Returns: " Arguments passed to the calling context's operator()." Change the Effects clause for yield_break() to: "Marks the coroutine complete and returns execution control back to the calling coroutine in such a way as to cause the calling coroutine's operator() to emit a coroutine_terminated exception." ______________ generator.html s/yielding a values/yielding values/ s/and can be returned/, so they can be returned/ make_generator() is not introduced. The illustration of make_generator() is accompanied by no description, so f() should be omitted. It adds nothing one cannot infer from the signature and raises questions about what c and, in turn, f() actually does. (If you choose to keep it, perhaps "g" is a better identifier for a generator.) In the second note, s/::FlsAlloc(), ::FlsFree()/::FlsAlloc() and ::FlsFree()/. Also, that same information is marked as a warning for coroutine. In the warning, s/If generator/If a generator/. There are no comments in most of the examples on this page. The fifth paragraph of Executing a generator needs to be rewritten to fix mistakes and improve clarity: "A generator is usually called inside a loop. The generator- function calls generator<>::self_t::yield() to produce a value. When the generator is called a second or subsequent time, the generator-function resumes execution after the yield() call. If a generator-function must be called no more, it can call generator<>::self_t::yield_break()." The sixth paragraph also needs to be rewritten: "The generator-function is invoked the first time from the generator's constructor. generator<>::operator() can be called while the generator is valid (while generator<>::operator unspecified_bool_type() returns true). When the generator-function cannot return more values, it can return a value or call generator<>::self_t::yield_break(). The latter returns execution control back to the caller and marks the generator complete. Note that generator<>::operator() does not thrown an exception, unlike a coroutine." (It isn't clear whether returning from a generator-function marks a generator complete.) In the last Executing a generator example, the "yield was called so we returned" comment within main() is a bit unclear. I suggest, "calls fn()" on g's construction and "fn()called self.yield(), so control returned here" on "while (g)". In the Important note within Exit a generator-function, s/complete (can not resumed/complete and cannot be resumed/. _______________ generator/generator.html The Effects clause of operator() would be better separated into an Effects and a Return clause: "Effects: " Invokes the generator-function." "Returns: " The value passed to self_t::yield() by the generator-function." Likewise, for self_t::yield(): "Effects: " Returns execution control to the calling context such that generator<>::operator() returns r in the calling context. "Returns: " The arguments passed to generator<>::operator() in the " calling context." The Effects clause for self_t::yield_break() is incorrect. I suggest the following: "Marks the generator complete and returns execution control to the calling context." _____ Rob Stewart robert.stewart(a)sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 2

Proposed new RAII Library
by Andrew Sandoval 17 Sep '12

17 Sep '12

I'd like to propose a new Boost library for RAII wrapper classes that I think could be standardized to help promote the use of RAII. Though shared_ptr, scoped_ptr, etc. greatly enhance the use of RAII, I propose two additional classes. The first of these is RAIIFunction (I'm open to other names and coding conventions). This one is very simple, but powerful. It's a small wrapper (using composition) around std::tr1::function, that simply calls the function on scope-exit, in the normal case. Unlike Boost.ScopeExit, it uses no macros. Anything that can be assigned to a std::tr1::function<AnyType> taking no parameters will work with it, so lambdas are perfect -- and allow for all of the associated benefits like capturing variables by reference, etc. It also works with std::tr1::bind / boost::bind, with no placeholders. // // RAIIFunction<> Written by Andrew L. Sandoval 2011/2012 // Include guard here #include <functional> // // An RAII class that works with std::tr1::bind and lambdas // NOTE: making a const RAIIFunction prevents the use of Invoke() // and Cancel() and operator=(fn) which is often appropriate // NOTE: m_func copies the original function object, so that const and // non-const refs can be passed in, etc. template <typename TRet> class RAIIFunction { private: std::tr1::function<TRet ()> m_func; bool m_bInvoke; RAIIFunction(); RAIIFunction(const RAIIFunction &); void operator=(const RAIIFunction &); public: RAIIFunction(const std::tr1::function<TRet ()> &fn) : m_func(fn), m_bInvoke(true) { } void operator=(const std::tr1::function<TRet ()> &fn) { if(m_bInvoke) { m_func(); } m_bInvoke = true; m_func = fn; } ~RAIIFunction() { if(m_bInvoke) { m_func(); } } void Cancel() { m_bInvoke = false; } TRet Invoke(bool bRelease = false) { m_bInvoke = !bRelease; return m_func(); } }; Examples: const RAIIFunction<void> closeDB = ([pDB]() { if(pDB) { sqlite3_close(pDB); } }); // // while example... bool bContinue = true; RECORD record = { }; while(bContinue) { // Ensure that no matter how the loop wraps (continue or fall-through) the next // record is grabbed or the loop terminates... const RAIIFunction<void> loopAdvance = ([&bContinue]() { bContinue = SomeCallThatGetsAnotherRecord(record); }); // A bunch of record processing here ... } // // A convoluted example that shows assignment, etc. RAIIFunction<int> mb = std::tr1::bind(MessageBoxW, HWND_TOP, L"Present pop-up prompt again?", L"Test", MB_TOPMOST|MB_YESNO); int iMB = mb.Invoke(true); if(IDYES != iMB) { mb = ([]() ->int { dprintf("Printing what the user didn't wanted popped up" " on scope-exit...\n"); return 0; }); -- The other one I call just RAIIWrapper, and it works with static deleter functions taking a single argument of the type being delete. Since it includes a lot more code (much of which could probably be replaced with type_traits code), I'll just show examples of usage below to gauge interest. I first used an earlier version of this in an environment where the standard function required a goto ErrorExit (like Microsoft example driver code in the WDK) to clean-up all of the resources. The original concern was that the c++ class would bloat the deliverable size. This class proved to be as tight as the goto equivalent. It uses one macro that I'll include below. The class takes 3 template parameters: 1) The type of the deleter function, 2) the deleter function, and 3) a no-delete value that defaults to NULL. // // Simplify usage with a macro: #define RAIIDeleter(deleterFunction) decltype(&deleterFunction), deleterFunction // Example: const RAIIWrapper<RAIIDeleter(CloseHandle), INVALID_HANDLE_VALUE> hFile = CreateFile(pwzFileName, GENERIC_WRITE, FILE_SHARE_WRITE, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); if(!hFile.IsValid()) { // handle error... } // Similar but using the default no-delete value (NULL): const RAIIWrapper<RAIIDeleter(CloseHandle)> hEvent = CreateEvent(NULL, FALSE, FALSE, NULL); -- I've found that using RAII consistently can dramatically improve code quality. It forces the coder to think about resource lifetime at inception rather than at exit points, etc. Much of what I've shown above can be done with scoped_ptr or shared_ptr, but these specialized classes put the focus on RAII and resource management. Please let me know your thoughts. I'd love to see this become part of Boost, and hopefully eventually part of the C++ standard library. Thank You, Andrew Sandoval

13 56

[rational] optional over/underflow checking
by Dan Searles 17 Sep '12

17 Sep '12

>> https://svn.boost.org/svn/boost/sandbox/rational Sandbox now includes the test driver. All the updates are in the single rational header file, so this is a relatively small update. Rational.h, however, has had small updates before. This update centers on adding an optional over/underflow check, that would generate an exception if the result of an operation could not be represented with full numeric precision. Seeking comments on the update and any steps/requirements needed to get the update accepted for release. BTW, are there any status updates on the unlimited precision numeric class effort? Thanks, Dan Searles

2 1

Re: [boost] [result_of] Usage guidelines
by Andrey Semashev 17 Sep '12

17 Sep '12

Ok, here is my second take on this. I've attached a patch with my changes. 1. I moved the guidelines to a separate section in order not to clutter the formal result_of description. 2. I seperately outlined the C++11 and C++03 recommendations. 3. I left the result_of examples. I think they illustrate the result_of usage quite well, but I'll be happy if someone comes up with something better. 4. I rephrased some of the wording about result<> usage, in response to Jeffrey's reply. Comments are welcome.

4 6

[ASIO] async SSL operations unnecessary serialized?
by Michał Madziar 16 Sep '12

16 Sep '12

Hello all. It looks like all openssl_operation handlers are synchronized on io_service allowing only one connection to be processed at the a time. As I understand this orginated from the time when libopenSSL didn't support multi-threaded applications, but it slows down everything a lot. Adding locking function, and getting rid of strand_->wrap in lines 320, 385 in file boost/asio/ssl/detail/openssl_operation.hpp allows SSL connections to be used in multiple threads simultaneously solving the problem. Or do I miss something? I've attached simple line-based echo server which demonstrates the problem: openssl s_client -connect localhost:10001 #x 2 telnet localhost 10000 #x 2 After sending something in each connection TCP and one SSL work in parallel, second SSL waits with receiving until first one finishes it's write. After patching all connections work in parallel. -- Pozdrawiam Michał 'michoo' Madziar

2 3

{Review] Coroutine reviewstarts today, September 3rd
by Hartmut Kaiser 16 Sep '12

16 Sep '12

Hi all, The review of Oliver Kowalke's Boost.Coroutine library starts today, September 3rd 2012, and will end on September 12th. I really hope to see your vote and your participation in the discussions on the Boost mailing lists! ----------------------------------------------------- About the library: Boost.Coroutine provides templates for generalized subroutines (coroutines) which allow multiple entry points for suspending and resuming execution at certain locations. It preserves local state/data and allows re-entering subroutines more than once (useful if state must be kept across function calls). Coroutines can be viewed as a language-level construct providing a special kind of control flow. You can download the library and the view documentation here: docs: http://ok73.ok.funpic.de/boost/libs/coroutine/doc/html/ src: http://ok73.ok.funpic.de/boost.coroutine.zip --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards Hartmut Review Manager

7 23

[result_of] Make result_of doc separate from utility.htm
by Michel Morin 15 Sep '12

15 Sep '12

The documentation of result_of is contained in monolithic utility documentation: http://www.boost.org/libs/utility/utility.htm But I think result_of is worth having its own (i.e. separate) documentation. Comments? Regards, Michel

1 0

[ublas] Trunk testing broken
by Belcourt, Kenneth 15 Sep '12

15 Sep '12

Someone forgot to commit a file? error: Unable to find file or target named error: 'test_ticket7296.cpp' error: referred to from project at error: '../libs/numeric/ublas/test'

2 1

[nowide] Library looks for a review manager
by Artyom Beilis 15 Sep '12

15 Sep '12

Hello, The project Boost.Nowide searches a review manager: What is Boost.Nowide: --------------------- Boost.Nowide is a library implemented by Artyom Beilis that make cross platform Unicode aware programming easier. The library provides an implementation of standard C and C++ library functions, such that their inputs are UTF-8 aware on Windows without requiring to use Wide API. Documentation: http://cppcms.com/files/nowide/html/ Downloads: http://cppcms.com/files/nowide/ Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/

3 7

[system] Patches to apply when BOOST_ERROR_CODE_HEADER_ONLY or BOOST_NO_EXCEPTIONS are defined
by Vicente J. Botet Escriba 15 Sep '12

15 Sep '12

Hi, I have added some simple patches for these two tickets https://svn.boost.org/trac/boost/ticket/7347:duplicate symbol while BOOST_ERROR_CODE_HEADER_ONLY is defined https://svn.boost.org/trac/boost/ticket/7149:system failed to compile with BOOST_NO_EXCEPTIONS defined when -fno-exceptions is NOT used Could I apply them to trunk? Best, Vicente

1 0

[system] Patches to apply when BOOST_ERROR_CODE_HEADER_ONLY or BOOST_NO_EXCEPTIONS are defined
by Vicente J. Botet Escriba 15 Sep '12

15 Sep '12

Hi, I have added some simple patches for these two tickets https://svn.boost.org/trac/boost/ticket/7347:duplicate symbol while BOOST_ERROR_CODE_HEADER_ONLY is defined https://svn.boost.org/trac/boost/ticket/7149:system failed to compile with BOOST_NO_EXCEPTIONS defined when -fno-exceptions is NOT used Could I apply them to trunk? Best, Vicente

1 0

[Review:Contract] Very late review
by John Bytheway 15 Sep '12

15 Sep '12

I was out of touch for most of the review period, but I wanted to submit a review of Contract anyway. The review manager is of course welcome to ignore my comments or otherwise give them short shrift as he sees fit as a consequence of this delay, but I hope Lorenzo will welcome more feedback :). Firstly, I would like to add my voice to those who are congratulating Lorenzo on the quite remarkable feat this library represents. It has obviously required extensive and careful thought and effort to reach this state. It is primarily because of this evident conscientiousness that I will vote YES, I think the library should be accepted into Boost. I concur with previous reviewers that it is unlikely to suit industrial use, but it is an important experiment, and one which will benefit from the additional exposure granted by inclusion in Boost. My review follows. Problems using the library ========================== I only experimented very briefly, but found one problem (which may well be a clang bug, but you should probably investigate). The following program I tried works with gcc-4.7.1 but not with clang r163674 (both in C++11 mode): #include <contract.hpp> CONTRACT_FUNCTION( int (postinc) ( (int&) value ) precondition( value < std::numeric_limits<int>::max() ) ) { return value++; } int main() { int i = std::numeric_limits<int>::max(); postinc(i); return 0; } The first few errors with clang all look like: In file included from contract-failure-test.cpp:1: In file included from .../contractpp_0_4_1/include/contract.hpp:14: .../contractpp_0_4_1/include/contract/broken.hpp:359:7: error: call to object of type 'thread_variable<broken_contract_handler>' is ambiguous { aux::broken_handlers<>::precondition(context); } ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .../contractpp_0_4_1/include/contract/aux_/thread_variable.hpp:42:5: note: conversion candidate of type 'void (*)(const contract::from &)' operator T() const { // Sync so must return object copy (by value). ^ .../contractpp_0_4_1/include/contract/aux_/thread_variable.hpp:49:5: note: conversion candidate of type 'void (*)(const contract::from &)' operator T() const volatile { // Sync so must return object copy (by value). ^ Minor issues in the docs ======================== (I'm not mentioning issues already raised in another review) Tutorial -------- - I think it's slightly unfortunate that your example function name ("postinc") shares a four-character prefix with "postcondition". This threw me a couple of times when I was reading too fast. - "specify both its type and its name (parameter names can instead by omitted in usual C++ declarations)" -- I found this phrasing confusing. I think you were planning to remove this constraint anyway so it doesn't matter, but FWIW I would recommend something like "specify both its type and its name (unlike conventional C++ declarations, where parameter names may by omitted)". - "and assigning it to the return keyword" -- also confusing. Perhaps "and assigning to it from the return keyword" - "destructors cannot specify neither preconditions nor postconditions" -- double negative; should be "destructors can specify neither preconditions nor postconditions" - The whole "Forward Declarations and Body Definitions" section is a bit odd. The code example doesn't seem to match up with the text. For example, you say "less and natural::get are defined together with their declarations", but in fact less is forward-declared at the top of the file with no definition. Advanced topics --------------- - "the postcondition result = n * factorial(n - 1) has factorial computation complexity" -- this is not true; the factorial function as defined here has linear complexity, not factorial complexity. (If it were using arbitrary precision integers it would be something like O(n^2 log(n)^2) but still certainly polynomial, not super-exponential!) - "preconditions cannot only be weakened" -- again s/cannot/can/ Named parameters ---------------- - By using "requires" here in the pseudocode example with a different meaning from the rest of the library you are further muddying the waters. If you change the "requires" keyword that is used by the library to something else (as discussed below) then this will no longer be a problem. - In footnote 61 (Boost.Parameter bug) could you please link to the bug so that future readers will know when it is fixed. Doxygen ------- You've mentioned a few times the the Doxygen preprocessor can't cope with your preprocessor metaprogramming. Have you submitted bugs to Doxygen? Do you know how receptive they are to improving their preprocessor conformance? This library might be a compelling incentive for them to do so. Design issues ============= The vast majority of the design is clearly well-grounded in existing practice and practicality. Nevertheless, I have a few issues to raise. Concepts -------- I agree with the earlier thread that you should not use the term "requires" in the way you currently are, because it has a different meaning in the Concepts proposal. Alternatives as discussed there such as "check" would be an improvement. Contract broken message ----------------------- The above example program generates the following broken contract report: precondition number 1 "value < std::numeric_limits<int>::max()" failed: file "contract-failure-test.cpp", line 8 I would like my editor (Vim, though this comment applies equally to others) to automatically take me to the line where the failure occurred. I could of course configure it appropriately, but it might make your users lives easier if you used a standard error format which editors will recognize by default, such as: contract-failure-test.cpp:8:precondition number 1 "value < std::numeric_limits<int>::max()" failed Furthermore, I suspect that it is quite likely that these contract broken messages might occur at odd times, such as when the program is in the midst of printing something else to stdout/stderr, so it might be a good idea to prefix all your messages with a newline. Best of all, perhaps, would be to provide a customization point for the message format (which doesn't entail changing all five broken handlers). This would allow me to make these changes to the messages without disturbing other users. Contract broken handlers ------------------------ Based on your example, I presume that if I install a custom handler for broken contracts, and that handler returns without throwing, then execution will simply continue merrily without regard to the detected contract violation. I can see why you might feel the need to provide such functionality ... but my first instinct is that if a custom handler returns the library should take over and call std::terminate anyway (this is similar to the way that a constructor function-try block will not allow you to swallow an exception thrown by a base or member constructor). But I don't feel strongly about this. At the least, you should document this turn of events more clearly; I only figured it out from the very last footnote in advanced topics. Configuration macros -------------------- This is my biggest concern with the library at present. You provide the various macros for configuration (CONTRACT_CONFIG_NO_PRECONDITIONS etc. as in <contract/config.hpp>). However, they are all essentially global constants. Suppose I am writing an application that depends on a library, and they both use contracts in their declarations. I would like to have only preconditions active for the library, but all contracts checked for the application. There is no way to achieve this. CONTRACT_CONFIG_DO_NOT_SUBCONTRACT_PRECONDITIONS causes a similar but different problem. If the library subcontracts preconditions then I can't disable them for my application. I think you need to provide a means to turn the various features on and off on a per-project basis. As one suggestion, suppose that you took extra arguments to your macros, so that the above example became: CONTRACT_FUNCTION( MYAPP_NO_PRECONDITIONS, MYAPP_NO_POSTCONDITIONS, int (postinc) ( (int&) value ) precondition( value < std::numeric_limits<int>::max() ) ) { return value++; } and then I define a wrapper macro for my app which substitutes these arguments for me, and therefore the example becomes: MYAPP_CONTRACT_FUNCTION( int (postinc) ( (int&) value ) precondition( value < std::numeric_limits<int>::max() ) ) { return value++; } Or perhaps rather than many variables it would be better to have a single MYAPP_CONTRACT_CONFIG value which contained all of them (as a preprocessor tuple, say) which was passed in similarly. Anyway, I'm sure you can think of something appropriate. Philosophical issues ==================== Finally, I'd like to go off on a bit of a tangent and talk about a philosophical problem with the design. It has been touched on by other reviewers but I'd like to go into more detail. Your library design is very syntactically invasive. As the docs indicate, this makes it unfamiliar, slow to compile, and potentially difficult to debug. But none of these is the worst problem. To worst problem is that only one library can do this. You've already seen this, and done your best to integrate the other Boost libraries that have similar requirements (Parameter and Concept) but this approach doesn't scale. I'm sure at least one of the many reflection libraries proposed to Boost does something similar. Will you integrate that too? What about non-Boost libraries. The only scalable solution is to write a framework for customized definitions. You've mentioned the possibility of using the knowledge your alternate syntax has to expose extra data (e.g. function access level) at preprocessor time. But that's not enough. It would have to allow other library authors to inject code into definitions in the way Contract or Parameter needs to; even provide whole new definition syntaxes as Property does. Given such a framework, each other library (Contract, Parameter, a reflection library, and whatever else) would be written using the framework. It should then be possible to use whichever a user desires, at the same time, for the same declaration, without those libraries having any knowledge of each other. Such a framework would be akin to the language customization features that some other languages have (and which have also been mentioned in other threads of this review). To be clear, I am certainly not demanding, nor even proposing, that you implement such a framework. I think it would be extremely difficult -- more trouble than it's worth. It would also be very dangerous (for all the same reasons that it is dangerous to be able to customize the language on the fly). So long as Contract remains a primarily experimental library the current design is perfectly adequate. I just think that this direction is the logical conclusion of your efforts, and wanted to bring it to your attention (though you've probably already had similar thoughts). Standard review questions ========================= * What is your evaluation of the design? Barring issues mentioned above, it is an excellent attempt to solve a very difficult problem. * What is your evaluation of the implementation? I did not examine it. * What is your evaluation of the documentation? I did not read the reference; the rest was very good, with minor nits as above. * What is your evaluation of the potential usefulness of the library? It has significant potential for use in small projects, to spread the idea of contract programming, serve as a proof of concept and influence future standardisation efforts. It is unlikely to see use in large scale industrial programming. * Did you try to use the library? With what compiler? Did you have any problems? Very briefly, with compilers and problems mentioned above. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent three evenings reading the docs and writing my review, and have been following the development of the library on the list since its first appearance. I would have liked to do more experiments, but my review was already late enough! * Are you knowledgeable about the problem domain? Not to any notable degree. Congratulations again to Lorenzo on achieving something I would have thought impossible; with luck it might inspire me to actually try contract programming. John Bytheway

2 1

[preprocessor] automatic recursion curiosity
by Lorenzo Caminiti 14 Sep '12

14 Sep '12

Hello all, I have a curiosity about an implementation detail of Boost.Preprocessor: How does the lib implement Automatic Recursion? >From the docs under Topic > Reentrancy > Automatic Recursion: http://www.boost.org/doc/libs/1_51_0/libs/preprocessor/doc/index.html `` Using automatic recursion to reenter various sets of macros is obviously much simpler. It completely hides the underlying implementation details. So, if it is so much easier to use, why do the state parameters still exist? The reason is simple as well. When state parameters are used, the state is known at all times. This is not the case when automatic recursion is used. The automatic recursion mechanism has to deduce the state at each point that it is used. This implies a cost in macro complexity that in some situations--notably at deep macro depths--will slow some preprocessors to a crawl. '' I have not looked at the source code and I'm looking for the glory details. However, I'd like to understand at a high level how Boost.Preprocessor is able to implement Automatic Recursion behind the scene (it just bothers me not being able to imagine how this is actually done and why it is expensive on some preprocessors). Can anyone provide a quick explanation or point me to some email thread / docs that explain that? Thanks a lot! --Lorenzo

2 1

[Review.Coroutine] Vicente's review
by Vicente J. Botet Escriba 13 Sep '12

13 Sep '12

Hi, I understand that Oliver is busy as all of us and that it is better to provide first the minimal and well designed scope he is confident with. I expect however that Oliver will add soon symmetric coroutines based on the work done by Giovanni in a near future. - What is your evaluation of the design? I have some suggestions about changing the interface, but I'm not sure all of them could be implemented in an efficient way. * The use of thecoro_t::self_t & self parameter makes too much noise. This parameter must be forwarded to any function that could yield the coroutine. An alternative design using a thread specific pointer could allow to access the current coroutine int f20() { typedef this_coroutine<int(void)> this_coro; this_coro::yield(5); } Is the rationale for using self_t to get better performances? Maybe both interfaces could be provided. * There is an asymmetry between the value returned the last time and the others. self.yield( i); // OTHERS return i; // LAST This asymmetry forces the user to manage the last return in a specific case, changing the readability of the code. I would prefer coroutine function returns void. voidfn( coro_t::self_t & self) { self.yield(1); self.yield(2); } * If this is not adopted, the implementation should check at compile time that the return type of the coroutine function is the one of the signature. * The access to the actual coroutine parameters is asymmetric, letting access to old actual parameters that can point to objects that have already been destroyed. Maybe the self_t object could take care of this (or this_coroutine). We can use a get<> function to give access to the actual parameters. int f20(coro_t::self_t & self) { self.yield(2*self.get<0>()); } int f20() { typedef this_coroutine<int(int)> this_coro; this_coro::yield(2*this_coro::get<0>()); } Or even use some kind of bind parameter int f20(coro_t::self_t & self) { int i; int j; self::bind(i, j); self.yield( i + j ); } int f20() { int i; int j; typedef this_coroutine<int(int)> this_coro; this_coro::bind(i, j); this_coro::yield( i + j ); } If bind is adopted, the implementation could use it to store directly the actual parameters, instead of needing to store them in the self_t instance and them returning them when yield is called. */As// Boost.Coroutine is able to transfer user exceptions, and there is no difference between calling to coroutine<>::self_t::yield_break()/ and throwing/coroutine_terminated,/both (/coroutine<>::self_t::yield_break()/ and throwing/coroutine_terminated)/be removed from the library. The same applies for generators. * noexcept specifier should be added to class coroutine { // ... coroutine() BOOST_NOEXCEPT; coroutine( coroutine && other) BOOST_NOEXCEPT; coroutine & operator=( coroutine && other) BOOST_NOEXCEPT; explicitoperator bool() const BOOST_NOEXCEPT; bool is_complete() const BOOST_NOEXCEPT; //... }; void swap( coroutine & l, coroutine & r) BOOST_NOEXCEPT; The same applies to generator. * Type-erase on the Allocator parameter as the standard std::packaged_task does. * Make coroutine/generator classes to follow the allocator aware standard protocol adding the constructor with the standard allocator. A specializations of the use_allocator template should be added for this purpose. * Moving some of the coroutine/generator optional parameters to a coro::attributes class could simplify the interface std::size_t size = ctx::default_stacksize(), flag_unwind_t do_unwind = stack_unwind, bool preserve_fpu = true, * The lib shouldn't throw when preconditions are not satisfied, assert should instead. * It is a shame that the library can not support completely move semantics for the coroutine parameters, as the used boost::tuple don't support it yet. I would like this point be addressed before the first release so that there is no break in the interface when this will be solved either using boost::tuple, boost::fusion::tuple or std::tuple. At a last resort the library could either define a macro that allows to parameterize the tuple implementation, or alternatively it could implement a wrapper that forwards to the best implementation. * As others have noted, providing a view of a generator as an output iterator will be welcome. Viewing it as a range will be also appreciated. BTW, I don't like the alternative using optional as the result of a generator. Following the output iterator concept the access is defined only if the generator has not finished. - What is your evaluation of the implementation? I have not a deep opinion as I have not found the time to inspect it. At first glance, it seems that the inheritance hierarchy is deeper than needed and the use of the pre-processor to manage with variadic templates hides a possible good design (as it is usual in those cases). Maybe now that most of the c++ compilers support them, using the preprocessor is less imperative. - What is your evaluation of the documentation? I find the documentation a little bit sparse and contain a lot or typos and minor errors. I would appreciate if the original Boost.Coroutine documentation from Giovannii were not lost, at least for Motivation and Tutorial parts. I would appreciate also if the documentation include the rationale to don't include symmetric coroutines and show how the current library can be used to solve the problems the missing features provide, why not as examples. * showing the signature in the documentation will be more informative. template< typename Signature, typename Allocator = ctx::stack_allocator >class coroutine; template< typename R, typename ...ArgTypes, typename Allocator > class coroutine<R(ArgTypes...)> { public: class self_t { public: tuple<ArgTypes...>yield( R); void yield_break(); }; * documentation for the following constructor is missing in the reference template< typename Fn > coroutine( Fn && fn, std::size_t size = ctx::default_stacksize(), flag_unwind_t do_unwind = stack_unwind, bool preserve_fpu = true, Allocator alloc = Allocator() ); *The example typedef boost::coro::coroutine< void(int) > coro_t; void f( coro_t::self_t & self, int i) { ... self.yield(); ... } coro_t c( boost::bind( f, _1) ); c( 7); doesn't compiles. It should be something like coro_t c( boost::bind( f, _1, _2) ); BTW, I don't see the need to use boost::bind in this case, as coro_t c( f ); works as well. The superfluous uses of bind in the documentation should be removed: - What is your evaluation of the potential usefulness of the library? Very useful. coroutines and generators are some useful constructions that are missing in the language. - Did you try to use the library? With what compiler? Did you have any problems? Yes. I used gcc-4.2.1,4.6.0, 4.7.0,clang2.9 andclang-3.0 on darwin. I had no problem running the provided examples and tests. I have written some examples. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I have read the documentations of Oliver and Giovanii libraries, followed the review and used the library. - Are you knowledgeable about the problem domain? From the theoretical point of view, yes. Never used in practice. Finally, my vote is YES. Even if the current interface has some drawbacks that should be mentioned in the documentation, I think I Boost.Coroutine is already useful and should be accepted into Boost. Best, Vicente P.S. Maybe I have forgotten to include some of the remarks I did on preceding posts.

4 11

[optional] using gdb to inspect optional value
by Pedro Larroy 13 Sep '12

13 Sep '12

Hi Is there a way to inspect an optional with gdb? I had to remove the usage if boost::optional as it caused me trouble to inspect the value. Thanks. Pedro.

2 1

[asio] New feature: timeout for poll()
by Max Che 13 Sep '12

13 Sep '12

Hello. My previous letter contained errors. Here is another letter. I want to use win_iocp_io_service::poll() with timeout. poll() + timeout => poll() functional and free waitable timer! GetQueuedCompletionStatus() (and epoll(), kqueue()) allows to use that. Can anyone add (restore) this feature?

1 0

[shared_ptr] Patch adding weak_use_count and weak_from_this
by Brent Lewis 12 Sep '12

12 Sep '12

These are useful for debugging, similarly to shared_ptr::use_count. Specifically, you can check for dangling pointers by replacing ordinary pointers with weak pointers, and checking the count inside a destructor. The patch is for boost 1.49 and is attached.

1 0

[build] 1.49 unable to bootstrap boost
by yuri kilochek 12 Sep '12

12 Sep '12

Not sure if this goes here. On Windows 7, when I try to do bootstrap on a freshly unzipped boost 1.49 at the root directory, I get the following output: Building Boost.Build engine But that is as far as it gets before os terminates whatever it is doing with this (roughly translated from russian): **** STACK SIZE EXCEEDED **** **** WHILE PERFORMING RECURSION IN BATCH MODE **** Recursion depth=654, Stack usage=90 percent. **** BATCH PROCESSING ABORTED **** Is there a way to build boost bypassing this?

4 3

[context] Linux x64 / printf
by Daniel Larimer 12 Sep '12

12 Sep '12

I modified the 'jump.cpp' example and added the line marked CRASH in f1() #include <cstdlib> #include <cstring> #include <iostream> #include <vector> #include <boost/assert.hpp> #include <boost/context/all.hpp> namespace ctx = boost::ctx; ctx::fcontext_t fcm, fc1, fc2; void f1( intptr_t) { std::cout<<"hello "<<0; // WORKS printf( "hello %d", 0 ); // <<< CRASH std::cout << "f1: entered" << std::endl; std::cout << "f1: call jump_fcontext( & fc1, & fc2, 0)" << std::endl; ctx::jump_fcontext( & fc1, & fc2, 0); std::cout << "f1: return" << std::endl; ctx::jump_fcontext( & fc1, & fcm, 0); } void f2( intptr_t) { std::cout << "f2: entered" << std::endl; std::cout << "f2: call jump_fcontext( & fc2, & fc1, 0)" << std::endl; ctx::jump_fcontext( & fc2, & fc1, 0); BOOST_ASSERT( false && ! "f2: never returns"); } int main( int argc, char * argv[]) { ctx::stack_allocator alloc1, alloc2; fc1.fc_stack.base = alloc1.allocate(ctx::minimum_stacksize()); fc1.fc_stack.limit = static_cast< char * >( fc1.fc_stack.base) - ctx::minimum_stacksize(); ctx::make_fcontext( & fc1, f1); fc2.fc_stack.base = alloc2.allocate(ctx::minimum_stacksize()); fc2.fc_stack.limit = static_cast< char * >( fc2.fc_stack.base) - ctx::minimum_stacksize(); ctx::make_fcontext( & fc2, f2); std::cout << "main: call start_fcontext( & fcm, & fc1, 0)" << std::endl; ctx::jump_fcontext( & fcm, & fc1, 0); std::cout << "main: done" << std::endl; return EXIT_SUCCESS; }

4 9

[mpi] scatterv, gatherv and Boost.MPI status
by Alain O Miniussi 11 Sep '12

11 Sep '12

Hi, Despite the fact that https://svn.boost.org/trac/boost/ticket/5292 has been sitting there for some time, the documentations still states that MPI_Allgatherv => most uses supported by all_gather (from 1.51.1). It seems the ticket wasn't commited nor refused. Is there a reason why a c++ MPI_gatherv equivalent is useless in Boost.MPI ? Overall, there seems to be a few other tickets in the same situation in the mpi lib. Which raises another question: what is the exact status of Boost.MPI ? is it still maintained ? is it worth submitting tickets or proposing patches to it or is it safer to move back to the C API ? Best regards Alain

1 0

FW: [Review] Coroutine review starts today, September 3rd, ends September 12th
by Hartmut Kaiser 11 Sep '12

11 Sep '12

This is just a reminder that the review of Oliver's Boost.Coroutine is ending tomorrow (see below for the initial announcement). Please get your reviews in as soon as possible. If you need more time, please let me know. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu > -----Original Message----- > From: Hartmut Kaiser [mailto:hartmut.kaiser@gmail.com] > Sent: Monday, September 03, 2012 6:46 AM > To: boost(a)lists.boost.org > Subject: {Review] Coroutine reviewstarts today, September 3rd > > > Hi all, > > The review of Oliver Kowalke's Boost.Coroutine library starts today, > September 3rd 2012, and will end on September 12th. > I really hope to see your vote and your participation in the discussions > on the Boost mailing lists! > > ----------------------------------------------------- > > About the library: > > Boost.Coroutine provides templates for generalized subroutines > (coroutines) which allow multiple entry points for suspending and resuming > execution at certain locations. It preserves local state/data and allows > re-entering subroutines more than once (useful if state must be kept > across function calls). Coroutines can be viewed as a language-level > construct providing a special kind of control flow. > > You can download the library and the view documentation here: > > docs: http://ok73.ok.funpic.de/boost/libs/coroutine/doc/html/ > src: http://ok73.ok.funpic.de/boost.coroutine.zip > > --------------------------------------------------- > > Please always state in your review, whether you think the library should > be accepted as a Boost library! > > Additionally please consider giving feedback on the following general > topics: > > - What is your evaluation of the design? > - What is your evaluation of the implementation? > - What is your evaluation of the documentation? > - What is your evaluation of the potential usefulness of the library? > - Did you try to use the library? With what compiler? Did you have any > problems? > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? > - Are you knowledgeable about the problem domain? > > Regards Hartmut > Review Manager

1 0

[thread] std::this_thread reference in docs
by Lars Viklund 11 Sep '12

11 Sep '12

Hi list. Since 1.50.0, the Boost.Thread documentation has started making references to std::this_thread::get_id() like in [1]. This is a bit strange, considering that the Thead library itself to my knowledge does not require C++11 (yet). Is this an accidental change? Should one read this as that the error condition is not achievable on C++03? 1.49: Preconditions: this->get_id()!=boost::this_thread::get_id() 1.50 (and 1.51): Preconditions: the thread is joinable. Error Conditions: resource_deadlock_would_occur: if deadlock is detected or this->get_id() == std::this_thread::get_id(). [1] http://www.boost.org/doc/libs/1_51_0/doc/html/thread/thread_management.html… [2] http://www.boost.org/doc/libs/1_49_0/doc/html/thread/thread_management.html… -- Lars Viklund | zao(a)acc.umu.se

2 1

[context] Trying to compile Coroutine on trunk
by Vicente J. Botet Escriba 11 Sep '12

11 Sep '12

Hi, I don't reach to compile Boost.Coroutine under Mac using trunk ../../../boost/coroutine/coroutine.hpp:14:45: error: boost/context/stack_allocator.hpp: No such file or directory ../../../boost/coroutine/coroutine.hpp:15:41: error: boost/context/stack_utils.hpp: No such file or directory Are you changing the interface of Boost.Context? Best, Vicente

4 4

[log] library status?
by Igor R 11 Sep '12

11 Sep '12

Hello, Is Boost.Log expected to enter one the Boost version soon? I see that its last update on sourceforge took place about a year ago... Thanks.

3 2

quest for member ‘read_some’ in ‘socket’, which is of non-class type ‘boost::asio::ip::tcp::socket* {aka boost::asio::basic_stream_socket<boost::asio::ip::tcp>*}
by neha_mysql 11 Sep '12

11 Sep '12

Hii, i am trying to execute a code and im getting error in this part of the code(in line no 3) for(;;) char buf[4]; size_t len = socket.read_some(boost::asio::buffer(buf,4)); if(error == boost::asio::error::eof) break; else if(error) throw boost::system::system_error(error); std::cout << "[!]"; std::cout.write(buf.data(), len); } The error is *" quest for member ‘read_some’ in ‘socket’, which is of non-class type ‘boost::asio::ip::tcp::socket* {aka boost::asio::basic_stream_socket<boost::asio::ip::tcp>*}"* -- View this message in context: http://boost.2283326.n4.nabble.com/quest-for-member-read-some-in-socket-whi… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[Review.Coroutine] More comments, questions and suggestions
by Vicente J. Botet Escriba 11 Sep '12

11 Sep '12

Hi, I understand Oliver that you are busy as all of us and that it is better to provide first the minimal scope you are confident with. I expect however that you will add symmetric coroutines based on the work done by Giovanni in a near future. BTW, adding a link to the Giovanni documentation will be welcome. I have more questions concerning the interface before finishing my review: * How the library behaves when the coroutine parameters are const& typedef boost::coro::coroutine< int( AType const& ) > coro_t; int fn( coro_t::self_t & self, AType const& v) { ???j = self.yield( v.get_int() ); /// ... } What should be the type (???) of j? Does AType const& works? * Have you tested with other kind of parameters? arrays, pointers, ... It would be great if the documentation includes some examples, with the different types that can be used. * The way the parameters of the coroutine call are retrieved the second time is a little bit disturbing at a first glance, but once you understand how this works, it is not so complex (This applies to the library under review and the original one, as both share the same design). I don't know if the the self object couldn't store the parameter binding, so that the user will not be concerned by the yield result type. typedef boost::coro::coroutine< int( int) > coro_t; int fn( coro_t::self_t & self, int i) { // binds current parameters to the self object. Done only once. self.bind(i); // *** std::cout << "fn(): local variable i ==" << i << std::endl; // save current coroutine context // transfer execution control back to caller // no need to assign the result. It is up to yield to fill the binded parameters. self.yield(i); // OTHERS *** // i == 10 because c( 10) in main() and i has been bound in self. std::cout << "fn(): local variable i ==" << i<< std::endl; return i; // LAST } I don't know this bind design introduce more problems that it could solve. I don't know neither if this could degrade the performances. * In the preceding example there is an asymmetry between the value returned the last time and the others. self.yield( i); // OTHERS return i; // LAST What about forcing the coroutine function return void, as it is the case now for the generator? voidfn( coro_t::self_t & self, int i) { self.bind(i); std::cout << "fn(): local variable i ==" << i << std::endl; self.yield(i); std::cout << "fn(): local variable i ==" << i<< std::endl; self.yield(i); } This should help to simplify user code, isn't it? * I don't know if you have reached to make the StackAllocator standard compliant, but if this is the case you could add also a specializations of the use_allocator template so that Boost.Container can take it in account. Best, Vicente

5 13

[Review.Coroutine] Lifetime of coroutine parameters
by Vicente J. Botet Escriba 11 Sep '12

11 Sep '12

Hi, I have some concerns about the lifetime of the coroutine parameters. Surprisingly (well not really), the following example doesn't fails at *1*. This is because the coroutine have access to its coroutine parameters *2*, which has a sens only for the first time the coroutine is called. Once the first call to yield return, the memory these parameter *3* can point to trash, as the example shows. typedef int TT; typedef boost::coro::coroutine< void(TT&) > coro_TT; void lifetime( coro_TT::self_t & self, TT& i ) // *2* { i=1; TT& j = self.yield(); std::cout << i << j << std::endl; i=2; // *3* UNSAFE access to i self.yield(); } void test_lifetime() { coro_TT c( boost::bind( lifetime, _1, _2) ); { int k = 0; c( k ); BOOST_CHECK(k = 1); } { int k = 0; int i = 0; c( i ); BOOST_CHECK(k = 2); // *1* std::cout << i << k << std::endl; } } This could hide errors that are difficult to catch. In addition to merit to be mentioned in the documentation as a limitation of the current library interface I really think that it merits to see if this can be solved. Best, Vicente

3 3

[Variant] C++11 variadic template implementation
by Florian Goujeon 11 Sep '12

11 Sep '12

Hi Boosters, I'd like to know if anybody were working on a C++11 version (using variadic templates) of Boost.Variant. I currently use the 'classic' version in my project, but since I need more-than-20-type variants, the compilation take a lot of time (extending the number of types that variant can support forces you to disable the use of precompiled headers). Plus, I'll need to use 70 type variants (MPL lists are physically limited to 50 types). If nobody has started to implement such a version yet, I'd be pleased to contribute. I've written an implementation. It's incomplete and far from perfect, but it could (hopefully) be a viable working basis.

6 16

[HELP] fatal error LNK1120: 5 unresolved externals
by Seow Hui, Saw 10 Sep '12

10 Sep '12

Dear Sir/ Madam, A very good day to you. I installed boost 1.50 installer (32-bit) which downloaded from http://www.boostpro.com/download/ and did the appropriate settings (including CGAL) in Microsoft Visual Studio 2010. I would like to run the following sample code: #include <iostream> #include <CGAL\Exact_predicates_inexact_constructions_kernel.h> #include <CGAL\convex_hull_2.h> typedef CGAL::Exact_predicates_inexact_constructions_kernel K; typedef K::Point_2 Point_2; int main() { Point_2 points[5] = { Point_2(0, 0), Point_2(10, 0), Point_2(10, 10), Point_2(6, 5), Point_2(4, 1) }; Point_2 result[5]; Point_2 *ptr = CGAL::convex_hull_2( points, points+5, result ); std::cout << ptr - result << " points on the convex hull" << std::endl; return 0; } There are no errors during compilation but there are errors during the build as shown below: 1>------ Build started: Project: Cgal_Hello, Configuration: Debug Win32 ------ 1>libboost_system-vc100-mt-gd-1_50.lib(error_code.obj) : error LNK2005: "public: __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (??0?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@ABV01@@Z) already defined in msvcprtd.lib(MSVCP90D.dll) 1>libboost_system-vc100-mt-gd-1_50.lib(error_code.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) void __cdecl std::_Xout_of_range(char const *)" (__imp_?_Xout_of_range@std@@YAXPBD@Z) referenced in function "public: void __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::_Xran(void)const " (?_Xran@?$basic_string@DU ?$char_traits@D@std@@V?$allocator@D@2@@std@@QBEXXZ) 1>D:\Cgal_Hello\Debug\Cgal_Hello.exe : fatal error LNK1120: 5 unresolved externals Can anyone please help me with this issues? desperately need help... In addition, if I have installed the installer, do I still have to use bjam.exe to build the libraries? Hope to hear from you soon. Thank you very much. -- Best Regards, Saw

2 1

[program_option] Better compiler checks?
by Klaim - Joël Lamotte 10 Sep '12

10 Sep '12

Hi I was adding program_option to my prorgam when I discovered a related leak. Fortunately it was false positive, but it pointed a hidden problem. I used: - Visual Studio 2012 - Boost 1.51.0 - Visual Leak Detector to detect the leak This, generate the leak: {{{ #include <boost/program_options.hpp> int main() { namespace bpo = boost::program_options; bpo::options_description options( "Options" ); options.add_options() ( "test" , "Test." ) , ( "value" , bpo::value<int>(), "Value." ) ; } }}} The second option is leaking. The reason is because of the comma in the beginning of the line. I first added it by reflex when using function arguments so it took me some time to find what was leaking. Part of the time I spend was figuring out why it don't leak if you don't set a value type: {{{ #include <boost/program_options.hpp> int main() { namespace bpo = boost::program_options; bpo::options_description options( "Options" ); options.add_options() ( "test" , "Test." ) , ( "value" , "Value." ) // no leak but still wrong! ; } }}} The main problem I see with this is that it is compiled without any problem nor warning. So here is my question: Would it be possible to forbid comma operator with options_description_easy_init? I added a ticket for this, #7361 : https://svn.boost.org/trac/boost/ticket/7361 Joel Lamotte

1 0

Forward declaration headers
by Jens Auer 10 Sep '12

10 Sep '12

Hi, we often have to provide forward declarations of boost types by hand when we write interfaces. This is kind of dangerous because we will have to change the forward declarations when the boost libraries change and impossible for typedefs. Shouldn't there be a standard forward declaration headers in each of the boost libraries? Best regards, Jens

2 1

Sizes, signed and unsigned integers, MPL and Fusion
by Mathias Gaunard 10 Sep '12

10 Sep '12

Hi folks, I am writing this message to bring to your attention ticket #7304 <https://svn.boost.org/trac/boost/ticket/7304> Sizes of fusion sequences are of type 'int', because it mimics MPL. However, sizes of standard containers, some of which are fusion sequences, are of type std::size_t, which is unsigned. This seems a bit inconsistent, and can lead to unexpected signed/unsigned mismatch warnings in certain scenarios. Should both MPL and Fusion be modified to use unsigned size types? I think it is best to discuss this with the whole of Boost.

2 1

Making use of extern template
by Jens Auer 10 Sep '12

10 Sep '12

Hi, I tried to use C++11 extern template mechanism to reduce the turn-around time for our main project, but it turns out that the way people write template code in libraries is not suited well for that purpose. I tried to explicitly instantiate the template base class of boost::posix_time_ptime, date_time::base_time<ptime, posix_time_system>, because ptime is a value class which is used quite often in our project. The base class is then instantiated in every translation unit and later removed by the linker (we use MS Visual C++ 2010. The linker is single threaded and dead slow). The problem with extern template and the boost library is that inline template code is still instantiated in every translation unit even when using extern template, so it basically has no effect with the current boost code: $14.7.2.10: "Except for inline functions and class template specializations, explicit instantiation declarations have the effect of suppressing the implicit instantiation of the entity to which they refer." I would like to have a discussion of how boost could support extern template to reduce built times, maybe by changing the coding style to not write template code inline and use extern template in the library to automatically suppress instantiation of library instantiations such as the base class of ptime. Best regards, Jens

1 0

[atomic, 1.52] adoption & merge request
by Tim Blechmann 09 Sep '12

09 Sep '12

hi all, boost.atomic has been accepted as boost library and has been in trunk for a few months. however there are some issues and pending patches and helge bahmann, the original author, did not comment on any of them. therefore, hartmut and me would like to adopt the library temporarily to support helge, and merge these pending patches. we also like to add the library into the release branch, so that it will make it into 1.52. any objections? thanks, tim

3 2

[atomic] ia32/cmpxchg8b fix
by Tim Blechmann 09 Sep '12

09 Sep '12

one of my users reported an issue with atomic on gcc/ia32, related to const-correctness. ok to commit this fix? thanks, tim Index: boost/atomic/detail/gcc-x86.hpp =================================================================== --- boost/atomic/detail/gcc-x86.hpp (revision 80433) +++ boost/atomic/detail/gcc-x86.hpp (working copy) @@ -1556,11 +1556,11 @@ template<typename T> T -platform_load64(volatile T * ptr) +platform_load64(const volatile T * ptr) { T expected = *ptr; do { - } while (!platform_cmpxchg64_strong(expected, expected, ptr)); + } while (!platform_cmpxchg64_strong(expected, expected, const_cast<volatile T*>(ptr))); return expected; }

2 1

Re: [boost] C++ Boost library - passing Shared pointer to a function
by abhishek goswami 09 Sep '12

09 Sep '12

I am looking for a project which is converting c malloc/realloc to shared_ptr. During my Analysis, I found the issue Can anyone provide me some input how to fix below issue typedef boost::shared_ptr<Employee_t> srdpointer; srdpointer ptr((Employee_t*)malloc(sizeof(Employee_t)),std::ptr_fun(free)); I need to pass the shared pointer which will allocate memory Pointed by the ptr. Something like this. void allocateBlocks(int **ptr, int *cnt) { *ptr = (int*)malloc(sizeof(int) * 10); *cnt = 10; /*do something*/ } int main() { int *p = NULL; int count = 0; allocateBlocks(&p, &count); /*do something*/ free(p); } How can I achieve the similar functionality using shared ptr as shown in above code

2 1

[intrusive] patch to resolve compiler error for WinCE
by David Deakins 09 Sep '12

09 Sep '12

Hi Ion, I had a little bit of time to look into the compile error mentioned in ticket 6841 and determine a patch from detail/mpl.hpp that I think should resolve it. The patch is attached to that Trac ticket, although I could also just go ahead and apply it if you like. Thanks, -Dave

2 1

[Review.Coroutine] Some comments
by Vicente J. Botet Escriba 09 Sep '12

09 Sep '12

Hi, thanks Oliver to move the Coroutine library to a Boost review ready proposal. Before doing a formal review, I have some comments, suggestions and questions after a quick reading. Design ==== * I don't know if showing the signature in the documentation will be more informative. This will avoid, in particular, the be forced to explain what T and R and in the the current declaration. Could you replace template< typename Signature, typename Allocator = ctx::stack_allocator > class coroutine { public: class self_t { public: T yield( R); void yield_break(); }; by template< typename Signature, typename Allocator = ctx::stack_allocator >class coroutine; template< typename R, typename ...ArgTypes, typename Allocator > class coroutine<R(ArgTypes...)> { public: class self_t { public: tuple<ArgTypes...>yield( R); void yield_break(); }; * Could you add the following noexcept specifier? class coroutine { // ... coroutine() BOOST_NOEXCEPT; coroutine( coroutine && other) BOOST_NOEXCEPT; coroutine & operator=( coroutine && other) BOOST_NOEXCEPT; explicitoperator bool() const BOOST_NOEXCEPT; bool is_complete() const BOOST_NOEXCEPT; //... }; void swap( coroutine & l, coroutine & r) BOOST_NOEXCEPT; The same applies to generator. * As the template class Allocator is not used to allocate internal memory of the coroutine class. Could the Allocator parameter be renamed StackAllocator? * Could you add an standard Allocator parameter as e.g. the one of packaged_task? 0. template <class F, class Allocator> explicit packaged_task(allocator_arg_t, const Allocator& a, F&& f); C++ International Standard * I understand that the Boost.Context Allocator parameter is part od the class, as context is a low-level class, but coroutine is more high level. Is there a possibility to type erase the StackAllocator (and preceding Allocator) template parameter, as packaged_task do? This will allow to store coroutines (and generators) with the same signature in a container even if they don't share the Allocator. template<typename>class coroutine; template< typename R, typename ...ArgTypes > class coroutine<R(ArgTypes...)> { public: //... template< typename Fn,typename Allocator> generator( Fn fn, std::size_t size = ctx::default_stacksize(), flag_unwind_t do_unwind = stack_unwind, bool preserve_fpu = true, Allocator alloc = Allocator() ); //... }; * Parameters and move semantics. Could the signature parameters be rvalue references? R operator()(A0 a0, ..., A9 a9); I'm asking this because I think that Boost.Tuple has not implemented yet move semantics. * What about moving some of the coroutine/generator optional parameters to a coro::attributes class std::size_t size = ctx::default_stacksize(), flag_unwind_t do_unwind = stack_unwind, bool preserve_fpu = true, * Usually (at least in the C++ standard) a function doesn't throws because of its preconditions are not satisfied. Preconditions: |size| > ctx::minimum_stacksize(), |size| < ctx::maximum_stacksize() when ! ctx::is_stack_unbound(). Effects: Creates a generator which will execute |fn|. If |do_unwind| is |stack_unwind| the destructor of |*this| unwinds the stack before destructing it. If |preserve_fpu| is |true| the floating-point registers are preserved between context switches. Throws: /invalid_argument/ if a precondition is not satisfied. Should the function throw in this case? This should be coherent with |Result operator()()| <http://ok73.ok.funpic.de/boost/libs/coroutine/doc/html/coroutine/generator/…> Preconditions: |*this| is not a /not-a-generator/, |! is_complete()|. which doesn't throws any specific exception if the preconditions are not satisfied. . Documentation ========= coroutine.html s/it can migrated between threads/it can migrate between threads/ s/yield_return/yield_break/ * documentation for the following constructor is missing in the reference template< typename Fn > coroutine( Fn && fn, std::size_t size = ctx::default_stacksize(), flag_unwind_t do_unwind = stack_unwind, bool preserve_fpu = true, Allocator alloc = Allocator() ); Best, Vicente

4 12

Re: [boost] [Boost-users] boost 1.51.0 bz2 archive observations
by Daniel James 08 Sep '12

08 Sep '12

>From the user list: On 31 August 2012 16:39, Aras Vaichas <aras.vaichas(a)gmail.com> wrote: > > There is a slight difference between the 1.51.0 and 1.50.0 boost bz2 files. > > e.g. > \boost_1_50_0.tar.bz2\boost_1_50_0.tar\boost_1_50_0\ > \boost_1_51_0.tar.bz2\boost_1_51_0.tar\.\boost_1_51_0\ This is causing problems for some people's build scripts. The attached patch should fix this.

2 1

boost::assign::map_list_of and references?
by David Hagood 08 Sep '12

08 Sep '12

I was trying to initialize a map using map_list_of, and ran into what I consider an undesirable behavior: class stooge { public: stooge(); stooge(const stooge &); stooge &operator =(const stooge &); }; typedef std::map<std::string,const stooge &> MyMap_t; extern const stooge larry,moe,curly; MyMap_t mymap = boost::assign::map_list_of ("larry",larry) ("moe",moe) ("curly",curly); The above leaves mymap full of bogus references - it seems map_list_of is creating temporary copies of the objects, rather than taking their references, and then the map takes references to those temporaries, and blooley! Changing the assignment to: MyMap_t mymap = boost::assign::map_list_of<std::string, const stooge &> doesn't change anything. (and for various reasons, making stooge noncopyable is not an option). This is under gcc 4.5 i686 target. Am I "doing it wrong" or is this an issue with map_list_of?

1 0

[config] [result_of] Now VC++11 selects decltype-based result_of by default
by Michel Morin 08 Sep '12

08 Sep '12

On VC++11, result_of (on trunk) uses decltype-based implementation by default from r80453: https://svn.boost.org/trac/boost/changeset/80453 Note that VC++11 does not have a C++03/C++11 compiler switch and it always runs in a C++11 mode. Regards, Michel

1 0

[result_of] Usage guidelines
by Andrey Semashev 08 Sep '12

08 Sep '12

Hi, I wonder what is the correct way of declaring polymorphic function object result types and how to use result_of template with regard to argument types. If a function object receives arguments by reference, should its member result<> template be specialized for reference types as well? Also, should result_of<> for this function be instantiated with reference argument types? struct my_foo { template< typename > struct result; // Is this correct? template< typename ArgT > struct result< my_foo(ArgT) > { typedef ArgT type; }; // Or is this correct? template< typename ArgT > struct result< my_foo(ArgT const&) > { typedef ArgT type; }; template< typename ArgT > ArgT operator() (ArgT const& arg) const { return arg; } }; I realize that I can provide both result<> specializations and it will work either way. But when there are more than one argument the specializations begin to pile quickly. Consider also rvalue references and const and non-const qualified my_foo. Another question I have is how to use result_of<> when my_foo is external (i.e. provided by a third party library)? // Which one is the right way? typedef result_of< my_foo(int) >::type result_type1; typedef result_of< my_foo(int const&) >::type result_type2; I cannot know what result<> specializations are provided by my_foo, so probably there isn't an ultimate answer. But perhaps there are some guidelines or best practices? I've looked at result_of docs but there are no recommendations on this.

5 11

Interest in UDL suffixes for built-in and some standard library types?
by Peter Sommerlad 08 Sep '12

08 Sep '12

Dear boost members, I am preparing a paper for the next C++ standardization meeting for providing user-defined-literals for some standard types. b (and a variety of derivations lik bULL) for binary integer literals as in 101b s for std::string as "hello, world!"s s, h, min, etc. for std::chrono::duration literals such as 0xfh for 15 hours i, r for creating std::complex literals see http://wiki.hsr.ch/PeterSommerlad/wiki.cgi?LiteralsForBinaryStringComplexDu… for the paper draft. It also includes machinery to parse integers using the template version of a user-defined literal, because using constexpr operator"" foo(unsigned long long bar); overload loses the ability to treat the number bar as a compile-time constant, e.g., to use as template argument further on. Some people told me, such a facility would be nice in its own way, to be used by other authors of UDL constexpr overloads. I wonder if there is interest to provide standard conforming versions of my implementation (including the required _ prefix) for boost (which would require to clean up things a bit beforehand). Such a boost.suffixes library would only work with C++11 capable compilers that actually implement UDL and constexpr in combination (for some uses the constexpr is not required). gcc4.7.1 is fine, for example, my version of clang didn't do constexpr yet (that might have changed). Feedback, encouragement and thoughts are welcome. TIA and Best Regards Peter. -- Prof. Peter Sommerlad Institut für Software: Bessere Software - Einfach, Schneller! HSR Hochschule für Technik Rapperswil Oberseestr 10, Postfach 1475, CH-8640 Rapperswil http://ifs.hsr.ch http://cute-test.com http://linticator.com http://includator.com tel:+41 55 222 49 84 == mobile:+41 79 432 23 32 fax:+41 55 222 46 29 == mailto:peter.sommerlad@hsr.ch

2 1

Newbie question: Can't see my own posts
by Peter Sommerlad 07 Sep '12

07 Sep '12

Hi, it seems to me that I cannot see my own posts. For one containing a hyperlink I got a post confirmation but it never reached me: > Your message entitled > > Interest in UDL suffixes for built-in and some standard library types? > > was successfully received by the Boost mailing list. Did anybody see that message? Regards and thanks for your help Peter. -- Prof. Peter Sommerlad Institut für Software: Bessere Software - Einfach, Schneller! HSR Hochschule für Technik Rapperswil Oberseestr 10, Postfach 1475, CH-8640 Rapperswil http://ifs.hsr.ch http://cute-test.com http://linticator.com http://includator.com tel:+41 55 222 49 84 == mobile:+41 79 432 23 32 fax:+41 55 222 46 29 == mailto:peter.sommerlad@hsr.ch

2 1

[heap] typedef T gets prevalence over template parameter
by Alex Hagen-Zanker 07 Sep '12

07 Sep '12

Hi, The d_ary_heap does not compile (in VS2010) when the Comparison class contains a typedef T. The typedef takes prevalence over the template parameter T when the heap is derived from the Comparison class. I.e. the following pattern occurs: template<class T, class Cmp> struct heap_base : Cmp { typedef T value_type; // value_type = Cmp::T } I don't know if this is a bug, a user issue, or a compiler issue. But it caused me a lot of headache when I was trying to apply Jeremiah's indirect_cmp with Boost.Heap. See below for a complete failing example. Kind regards, Alex #include <boost/heap/d_ary_heap.hpp> struct less { typedef int T; bool operator()(const int& a, const int& b) const { return a < b; } }; int main() { boost::heap::d_ary_heap<int, boost::heap::compare<less>, boost::heap::arity<4> > my_heap; return 0; }

3 5

[Review] Coroutine : Christopher's Review
by Christopher Kormanyos 07 Sep '12

07 Sep '12

(I lost the initial review announcement.) Yes, I vote that Coroutine should be accepted into Boost! General impression of the library: Coroutine offers enormous potential for programming regimes such as communications software and embedded systems design. For example, a lightweight event/alarm-based cooperative multitasking scheduler for embedded systems can be readily implemented usingCoroutine combined with a timer resource. Oliver has selected a sensible granularity for Coroutine. It includes Boost.Context, Coroutine and the proposed Boost.Fiber. This granularity allows for fine-tuning the implementations of cooperative scheduling mechanisms while avoiding the prohibitively heavy weight of preemptive scheduling that is found in POSIX and often in implementations of the C++11 thread support library. The documentation is terse, yet complete and informative. The examples are good. The design of Coroutine is clearly thought through. In particular, the separation of Coroutine from Context allows for porting to other systems with minimal effort and maximum reliability and code re-use. How long did I work with Coroutine? I worked for about 1 week with Coroutine. In particular, I worked very intensively with Coroutine for 2 days straight. I used Coroutine with VS2010, VS2012-RC and several GNU compilers. I spent a lot of time deeply embedding Coroutine in a hard real-time system. This experience has led to the comments and suggestions shown below. Am I familiar with the regime of Coroutine? Yes. I am absolutely familiar with the regime of Coroutine. I have authored many cooperative multitasking schedulers for a variety of CPU architectures and shipped them in tens of millions of devices. Suggestions for Coroutine: I have several suggestions for Coroutine, none of which stand in the way of immediate acceptance into Boost. 1) The code may potentially benefit from some clean-up. In particular, there is a mixture of tabs and spaces in the code, possibly resulting from programming over two or more time epochs with different styles. A simple reformat will clean this up. Coroutine is desperately needed in the embedded systems community. Along these lines, I suggests some extensions. 2) There should be, let's say, a *lightweight* version (or configuration) of Coroutine for embedded systems 3) The lightweight version can not use the non-placement version of new(). The internal details of a coroutine are stored in the class as a pointer created with non-placement new(). The lightweight version could add a parameter for user-supplied memory and create the coroutine implementation details with placement-new(). 4) Furthermore, the lightweight version should not not use any exceptions whatsoever. I spent two solid hours removing all traces of exceptions while embedding Coroutine. The result was a lightweight mechanism that only costed a few kilobytes of program code. 5) We need to work together to create more contexts for different CPU architectures. The ARM(R) context that is present in Boost.Context uses several ASM operations that my ARM(R) Cortex(R)-M3 does not support. For this reason, I could not complete my benchmark. We can work on this in the future. Thank you for your efforts and good luck! Best regards, Chris.

3 2

[rational] Over/underflow checked update ready for comments
by Dan Searles 07 Sep '12

07 Sep '12

Le 06/09/12 04:28, Dan Searles a ?crit :>Le 06/09/12 04:28, Dan Searles a ?crit : >>>> For those interested in the rational number class, see: >>>> https://svn.boost.org/svn/boost/sandbox/rational >>>> >>>> Requesting comments on the code, and review for >>>> inclusion in the next release. >>>> >>>> >>> Hi, >>> >>> the enum type could follow the one defined in >>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html >>> "When an overflow does occur, the desirable behavior depends on the >>> application, so programmers may specify the overflow mode with a value >>> of type |enum class overflow|. The possible values are: >>> >>> |impossible| >>> Programmer analysis of the program has determined that overflow >>> cannot occur. Uses of this mode should be accompanied by an argument >>> supporting the conclusion. >>> |undefined| >>> Programmers are willing to accept undefined behavior in the event of >>> an overflow. >>> |modulus| >>> The assigned value is the dynamic value mod the range of the >>> variable. This mode makes sense only with unsigned numbers. It is >>> useful for angular measures. >>> |saturate| >>> If the dynamic value exceeds the range of the variable, assign the >>> nearest representable value. >>> |exception| >>> If the dynamic value exceeds the range of the variable, throw an >>> exception of type |std::overflow_error|. >> 'impossible' and 'undefined' are effectively the same thing, and >> equivalent to the 'no check' currently implemented. >Yes and not. Maybe from the point of view of the library, but this is a >useful information from the user point of view. So for the 'impossible' case, what should the library do when there is an over/underflow? >>> 'modulus' makes >>> more sense for the fixed point class that it's being described for >>> than rational numbers. I'm not sure a useful definition can even be >>> made for rationals. >>You are right. modulus for rational has not a clear sense. >> 'Saturate' sounds like it might be useful, but gets problematic >> quickly when there is under/overflow within the largest/smallest >> range limits. >Could you clarify? 'Saturate' implies returning the max value when the computed result is larger than can be represented, and returning the min value when the computed is smaller (more negative) than can be represented, but rationals can underflow between those extremes. For example, what is 1/2 * 1/maxint? >> The point is that if a result of a calculation is not >> exactly representable, you will get an exception to notify you. And of >> course 'exception' is in the new implementation for just that purpose. >A user can be interested in overflow check without exceptions. The >saturate policy should be a good replacement in context where exceptions >are not allowed. I can't quite see a point for there being 3 possible results when there is an overflow: exception, undefined, and ???. Maybe if '???' is a wrong value, but as close as possible? If you don't need the exact answers, float or double would probably be better. Returning zero for ??? might work. >Anyway, you should replace the CamelCase use in the definition of this >new enumeration. I think that basing your definition on the preceding >one could be acceptable. Which ones? Please suggest the names you think would be appropriate. (I tried to pick names that had a low probability of ever being used anywhere else. Common single dictionary words are probably not good.) >>> >>>> BTW, I have no access to the link for the examples and the test. >>> I have not changed those files. The existing examples and test >>> are still valid for the original non-checked case. For the checked >>> case, I have tests which run for hours. The tests for rational >>> instantiated with signed char is exhaustive (there are only so >>> many normalized values. Pairing up each value with every >>> other value on the binary operators doesn't result in much more >>> that 2**32 combinations). For short/int/long long, sets of interesting >>> values are created, and each value is paired up with every other >>> value in the set. I can provide the test drivers if anyone is >>> interested. >>I was interested by the examples and test using the new facility. Could >>you commit them in the sandbox, please? Uploaded the test driver to: https://svn.boost.org/svn/boost/sandbox/rational/Test_Rationals > >Best, >Vicente Thanks Dan Searles

2 1

[Review:Contract] Andrzej's review
by Andrzej Krzemienski 06 Sep '12

06 Sep '12

Hi, First, my vote is "YES": Contract should be accepted into Boost. Now for some details... === MOST IMPORTANT THINGS === (1) Let me start from the most important arguments. "Contract" enables us to use DbC design and tools in C++. This is the only library in C++ that I am aware of that takes DbC seriously, in every detail. In particular, unlike any "simple contract library," it observes that: (a) function pre- and post-conditions need to be part of declaration rather than function implementation, (b) a precondition is something different than a postcondition, (c) It is the execution of destructors of automatic objects that may (re)establish invariants or satisfy postconditions (thus, they need to be checked after destructors have been executed). "Contract" deals with things more detailed than my above list; but even this list is not always addressed in "simple contract libraries". This already gives me the confidence that Lorenzo has a very good understanding of the domain. I believe the community needs BbC framework: it is necessary in order to be able to program consciously. If the responsibilities and expectations are expressed clearly not only is it faster to track bugs, but also programmers would not plant (I think) some bugs from the outset. Of course, contract framework should ideally be provided as language extension; but in the absence of such support we are left with the attempts to implement it via a (possibly too clever) library. "Contract" may also enable and/or speed up the adoption of DbC as language feature in C++, as it will be possible to have a real-world implementation of the framework that people can play with, experiment and assess its usability. (2) An obvious and serious issue with the library is the burdensome syntax you have to use. Given the ambitious task of wrapping each function call with with tests executed before and after, and still leaving the bodies intact, I realize this is not avoidable. In fact I believe Lorenzo made the impossible to make the EDSL as close to normal declaration syntax as possible. Yet, all this may not be enough to call the interface "acceptable". There is a number of issues with it: you have to learn yet another language; compile times increase; if you mis-spell something you have horrible error messages; you cannot use some C++ constructs that you would otherwise use; your IDE and the debugger may be confused (if your contract fails, the bug may be either in your code or in the testing code). I cannot imagine telling my coworkers "from today on we are using Boost.Contract; start learning the new EDSL". I believe that it is not possible to significantly improve the current interface; its limitation is the natural consequence of the nature of the problem. The cost cannot be reduced any more, so the library can only offer even more value. And this is what it does, by (for instance) simplifying the integration with Boost.Concept or adding virtual specifiers. (3) I see it as a useful tool for personal projects, experimentation, learning, validation of usefulness of DbC, a proof of concept for proposal N1962. But the question is, should "Concept" be included into Boost. "Contract" needs inclusion into Boost to gain visibility and some sort of "attestation" and "certification". Only proposing "Contract" for addition to Boost brought attention to DbC: at least it prompted me to learn more. But does Boost need "Contract"? Similar questions have been asked during the review of Boost.LocalFunction. I am not aware of any objective criteria that would help decide in this case. Is this library of "high quality"? Can library with such interface be called "high quality"? But there is no other way to implement DbC in C++ (I believe)? But is it strong enough the argument? Perhaps we should treat some problems as "not implementable" and not include libraries only because there is no cleaner way to implement the tool. The decision to vote "yes" is not easily made. This is a subjective weighing between the offered value and the imposed cost. Personally, I would like to have this library available whenever I download Boost. === GENERAL OBSERVATIONS === (4) The library has very vast and very thorough documentation. It contains tutorials that teach you step by step how to use the library, the introduction into DbC, very detailed rationale, good reference, lots of examples. It is a good "reference documentation". (5) In order to define concept the library defines EDSL for declaring (and defining) classes and functions. This framework as the potential to do other useful things: enable support for concept definition and checking, base class aliases (see N2881), override control, named parameters, noexcept, simplified enable_if (or static if), etc... In fact, perhaps it could be used as a more general EDSL for declarations. This is my loose suggestion to change macro names from BOOST_CONCEPT_CLASS to BOOST_DECL_CLASS, etc, in case someone wants to use the framework for purposes other than contract enforcements. === ISSUES === Here I list a couple of random issues. I do not consider them critical for decision whether to adopt "Contract" to Boost or not. (6) Static assertions: is there any value in providing them, given that we already have this ability in Boost? I see that N1962 decided to abandon them; I am pretty sure the reason was that static_assert was already there. They somehow do not fit conceptually into the model of preconditions, postconditions and invariants. Precondition, for instance tries to detect a run-time condition occurring immediately before a function is called this time. Static assertion is not even executed then. What point is there in putting such assertion into the precondition? Documentation says " static assertions can be selectively disabled depending on where they are specified [...] so it is still important to logically associate them with preconditions, postconditions, etc." -- technically this sentence makes logical sense, but can you think of a single example where this selective disabling of assertions would be useful? What is the point in disabling such assertions at all, if they cost you nothing in run-time? I propose to remove them and give a sort of recommendation that software quality is assured by using a number of fairly independent tools: DbC, concepts, static assertions. (7) Loop variants: They are definitely a good thing to have (and I started using them immediately I learned about them in your documentation!). But they seem to have little to do with "contracts". A contract is (by definition -- I think) something that involves two parties. For instance, precondition implies two parties: one ensures something, the other expects something. Invariants are harder to explain this way, but to me they are like "automated postconditions" (I explain this later on). However with loop variants the situation is different: they are put inside the the code, so no-one expect function author knows about them. The programmer guarantees something only to himself. It is more like assertion (in the sense of C macro assert()), perhaps with better configuration. I only want to make an observation here that this could be proposed irrespectively of contracts (pre-, post-conditions, invariants and subcontracting) -- but I am not proposing this. (8) Block invariants: Same remark as above: they appear to be separate from contracts. Another question is, what is the difference between block invariant and an assertion (like C-style macro assert())? I know, I know: conditional assertion, requirements, selectively disabling them, customizing run-time behavior... But if this is superior to BOOST_ASSERT, would it be correct to say that with Boost.Contract BOOST_ASSERT is no longer needed (except for backward compatibility)? (9) Class invariants: I have an observation, not about yuor library but the way invariants are handled in DbC methodology. As a "contract" (involving two parties) they make sense when checked after any (public) function call: they are a sort of postcondition that is the same for every function: class implementer "ensures" and class user "expects". But when checked before any function execution they are more like a C-assert: the function "expects", but who is supposed to "ensure"? Only any other public function of that class -- but this is already verified by checking postconditions. Somehow checking invariants before function execution is checking the same thing twice. If you find my reasoning even a bit convincing, perhaps it is worth considering adding another config macro: CONTRACT_CONFIG_NO_CLASS_INVARIANTS_ON_FUNCTION_ENTRY, that would disable invariant checking before function or destructor call, but still check them after function or constructor call? (10) It looks that when I include header <contract/class.hpp>, I also include <boost/concept/requires.hpp> even if I do not intend to use concepts. Would it be possible to avoid this somehow? (An additional header that also allows me to use macros: like CONTRACT_FUNCTION, but does not include <contract/class.hpp>, and if I use keyword "requires" the compilation fails). (11) The library supports almost all of C++03's declaration syntax, but I suppose it may not support some essential declarations from C++11, e.g.: noexcept(condition) or trailing return types. I hope it is doable in the future? (12) In the documentation (Introduction) we read that "This library is implemented for the C++03 <http://en.wikipedia.org/wiki/C%2B%2B> standard and it does not require C++11 <http://en.wikipedia.org/wiki/C%2B%2B11>." I think it is a bit imprecise, because many examples in the docs silently assume that variadic macros, which are not part of C++03, are available. I believe something like this would be more accurate "This library is designed to work on C++03 compilers that support variadic macros; no other C++11 support is necessary. Additionally, if variadic macros are not supported, this library works in >>strict C++03<< mode with slightly different syntax." (13) The documentation says that you can use protected and private members in contracts because "C++ provides programmers ways around access level restrictions (e.g., friend and function pointers)". Next, we read that "only public member functions shall check class invariants. Private and protected member functions are allowed to brake class invariants because private and protected member are part of the class implementation and not of its specification". To me, these two statements appear incompatible: either we say that only public members constitute class'es interface, or even protected and private members constitute class interface, e.g. for befriended functions. And either we both contract-check only public functions and allow only public members in contracts, or we both contract-check all functions and allow all members in contract. I prefer the former. Or am I missing something? If there are some technical obstacles in checking member access in assertions, then I accept such library limitation, but the current argumentation in the docs appears inconsistent. (14) The docs say that in order to make disabling of nested assertions thread-safe in multi-threaded programs, the library needs to use a global lock. Sorry if I am talking nonsense now (I have no intuition of using DbC in multi-threaded apps), but is it not possible to use thread_local storage for this purpose? Is it possible that executing an assertion in one thread would cause the execution of another (nested) assertion in another thread? (15) Unfortunately, I will not have time to check it, so I will only ask you: are any special considerations required in contract-checking classes that inherit virtually (e.g. class hierarchies with diamond inheritance structure). Order of object layout and construction is very particular in those classes, perhaps the order of contract verification and subcontracting should be special a well? (16) Functions like set_precondition_broken() are defined with dynamic exception specification: throw(). Is this necessary? throw() is known to be causing problems, adds little value, and some compilers do not support it; some other issue warnings on dynamic exception specifications; and they are deprecated. (17) According to docs, the framework checks invariants on destructor throw. This is already tracked: https://sourceforge.net/apps/trac/contractpp/ticket/66 (18) "Duplicated globals" problem may cause failure to register custom contract failure handler. This is already tracked: https://sourceforge.net/apps/trac/contractpp/ticket/60 (19) Documentation sometimes uses name "Contract Programming" as though it was a framework. For instance, "This library implements Contract Programming" or "Contract Programing checks them". I think it is incorrect. I understand that "Contract Programming" is a philosophy or a paradigm, whereas what you mean should be called "Contract Programming Framework" or similar. (20) In "Contract Programming Overview" -> "Benefits", in the note we read, "However, the probability that programmers make a mistake twice (in both the body *and* the contract) is lower than the probability that the mistake is made just once (in either the body or the contract)". This implies that we write contracts in order that the code be duplicated because this reduces the probability of the bug. I believe that the mechanism of testing in general is somewhat different (contract-checking is similar to unit testing in this respect, I think): you want the tests to be much simpler then the code they test. Therefore when some test fails you know (although not for sure) that it is the code that is broken rather than the test. For instance: double sqrt(double v) postcondition{ close(return * return = v); }; Testing almost the same thing as function body makes sense because multiplication is conceptually much simpler than the logic to find the square root. Conversely, writing this: bool invert(bool b) postcondition{ b == !return; }; Would be of little practical value, and I believe if there is a chance I will implement such function incorrectly, duplicating the logic in the precondition does not in practice reduce by half the probability of leaving the bug in the code. (21) Contract failure handlers will likely be customized inside function main(). This means that it will be difficult (although not impossible) to customize these actions for contracts of constructors of global objects. This is a very small problem and N1962 also seems to suffer from it and in fact even C++ suffers from it, when it comes to installing terminate handler with set_terminate. (22) Some random type-os in the docs. (apologies that I bluntly paste my notes without editing them, but I am too tired to do it): * " In addition, the library implements" -- don't mention it in the first sentence. * " and increasing overall software quality" -- no meaning * "trailing column symbol :" -> "trailing colon symbol :" * "First, the class invariants and the function preconditions are checked." -> "First, the class invariants are checked, then the function preconditions are checked. "(split it) * "Differences with C++ Syntax" -> "differences from"?<http://contractpp.svn.sourceforge.net/viewvc/contractpp/releases/contractpp…> * "postconditions and class invariants cannot be weaken. " -> weakened * "This library implement this feature however" -> "This library implements this feature, however" * "A *free function* [8<http://contractpp.svn.sourceforge.net/viewvc/contractpp/releases/contractpp…> ] call executes the following steps: " -- mention throw * "Preconditions cannot access the object" -- "you shouldn't" or "it is not possible"? * "to ontract" in destructor tutorial === STANDARD REVIEW QUESTIONS === * What is your evaluation of the design? * What is your evaluation of the implementation? Unfortunately, the macro tricks are beyond my mental powers, so I am unable to evaluate the design and implementation. I could only try to break it or test if it behaves as documented on examples. I can see that the framework is customizable (broken contract handlers, disabling the compilation of handlers). One design flaw I can see is that it is a header-only library while it requires some globals to store the handlers. But this is already recorded as a confirmed bug: http://sourceforge.net/apps/trac/contractpp/ticket/60 * What is your evaluation of the documentation? Very, very good: easy intro for the beginners, very detailed, describes not only the library but also the problem domain, lots of examples. * What is your evaluation of the potential usefulness of the library? It may be disqualified from production code by many parties due to the unusual syntax. But it is definitely useful for learning DbC, experiments, personal projects (where you need not convince others to use the interface they do not like) * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I played with the library for three evenings, running basic tests and trying to break it. I read the documentation. I also had some conversations with Lorenzo as he was developing the library, and reviewed previous versions of the docs. I am using VisualStudio 2010. * Are you knowledgeable about the problem domain? I know Contract Programming from Meyer's book and ISO C++ proposals (N1613, N1669, N1773, N1866, N1962) and Lorenzo's documentation. I haven't used it in practice on a dig scale. === FINALLY === The work Lorenzo did for this library is incredible. He already contributed to the knowledge of the limits and the power of the preprocessor. Supporting contracts in C++ without language extensions appeared (at least to me) impossible. It is a great piece of work. Regards, &rzej

3 9

[Review] Boost.Contract Review Period Extended
by Dave Abrahams 06 Sep '12

06 Sep '12

We've had lots of good discussion, and gotten three votes so far, but for a library of this scope I would like to see more. Therefore, we're extending the review period through Sept 7th. Please take the time to look at it, and *please vote for or against acceptance*. As noted below, everyone who looks at the library is qualified to vote, and every vote is valuable. Thanks, Dave ,----[ Important Notes ] | - Please post your review to the Boost Developers' list | (http://lists.boost.org/mailman/listinfo.cgi/boost) | - Please begin your review's subject line with "[Review:Contract]" | - Please do not post your review or discussion as a reply to this | message. | - Please feel free to note any individual issues in the issue | tracker at https://sourceforge.net/apps/trac/contractpp/report/3 | (you'll need to log in at Sourceforge to add a ticket) and make | reference to them from your review. | - Please see below for *further* important notes `---- THE LIBRARY Boost.Contract implements Contract Programming (a.k.a., Design by Contracts) for C++. In addition, the library implements virtual specifiers, concept checking, and named parameters. Documentation: http://contractpp.sourceforge.net Source: http://sourceforge.net/projects/contractpp/files/latest/download All N1962 requirements and Eiffel features are supported by the library, among others: 1) Support for preconditions, postconditions, class invariants, block invariants, and loop variants. 2) Subcontract derived classes (with support for pure virtual functions and multiple inheritance). 3) Access expression old values and function return value in postconditions. 4) Optional compilation and checking of preconditions, postconditions, class invariants, block invariants, and loop variants. 5) Customizable actions on contract assertion failure (terminate by default but it can throw, exit, etc). This library is implemented for C++03 and it does not require C++11. Obviously, if the library is accepted, all macros will be prefixed by BOOST_... and other symbols will go under the boost::... namespace. Potential Interactions with Existing Boost Libraries ==================================================== This submission potentially interacts with the following existing Boost libraries: * parameter - http://boost.org/libs/parameter * static_assert - http://www.boost.org/libs/static_assert * MPL - http://www.boost.org/libs/mpl * Concept - http://www.boost.org/libs/concept_check Reviewers should consider these potential interactions. What to include in Review Comments ================================== - Keep your criticism constructive. Constructive criticism usually comes with specific suggestions for improvement. - If you identify problems along the way, please note if they are minor, serious, or showstoppers. - Please *do* vote on whether the library should be accepted. Everyone who takes the time to look at the library is qualified to vote, and every vote is valuable. - Other questions you might want to answer in your review: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

3 4

[asio]New feature: timeout for poll()
by Max Che 06 Sep '12

06 Sep '12

Hello. I want to use win_iocp_io_service::poll() with timeout. poll() + timeout = poll() functional and free waitable timer! GetQueuedCompletionStatus() (and epoll(), kqueue()) allows to use that. Somebody can add this feature?

1 0

[rational] Over/underflow checked update ready for comments
by Dan Searles 06 Sep '12

06 Sep '12

>> For those interested in the rational number class, see: >> https://svn.boost.org/svn/boost/sandbox/rational >> >> Requesting comments on the code, and review for >> inclusion in the next release. >> >> > >Hi, > >the enum type could follow the one defined in >http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html >"When an overflow does occur, the desirable behavior depends on the >application, so programmers may specify the overflow mode with a value >of type |enum class overflow|. The possible values are: > >|impossible| > Programmer analysis of the program has determined that overflow > cannot occur. Uses of this mode should be accompanied by an argument > supporting the conclusion. >|undefined| > Programmers are willing to accept undefined behavior in the event of > an overflow. >|modulus| > The assigned value is the dynamic value mod the range of the > variable. This mode makes sense only with unsigned numbers. It is > useful for angular measures. >|saturate| > If the dynamic value exceeds the range of the variable, assign the > nearest representable value. >|exception| > If the dynamic value exceeds the range of the variable, throw an > exception of type |std::overflow_error|. 'impossible' and 'undefined' are effectively the same thing, and equivalent to the 'no check' currently implemented. 'modulus' makes more sense for the fixed point class that it's being described for than rational numbers. I'm not sure a useful definition can even be made for rationals. 'Saturate' sounds like it might be useful, but gets problematic quickly when there is under/overflow within the largest/smallest range limits. The point is that if a result of a calculation is not exactly representable, you will get an exception to notify you. And of course 'exception' is in the new implementation for just that purpose. > >BTW, I have no access to the link for the examples and the test. I have not changed those files. The existing examples and test are still valid for the original non-checked case. For the checked case, I have tests which run for hours. The tests for rational instantiated with signed char is exhaustive (there are only so many normalized values. Pairing up each value with every other value on the binary operators doesn't result in much more that 2**32 combinations). For short/int/long long, sets of interesting values are created, and each value is paired up with every other value in the set. I can provide the test drivers if anyone is interested. > >Could you update the History section? The history section is missing about 6 earlier updates. It also has the problem that it's written in the 1st person by the original author. It might be best to leave that section alone, and just update the main doc body and the revision history of the header file (already done). > >In order to avoid breaking the existing interface, you could define a >class basic_rational that has the new template and define the current >rational using this basic_rational. > >template <typename Integer, overflow Ov> class basic_rational; > >template <typename Integer> class rational : >basic_rational<Integer,overflow::undefined> {...} The new implementation doesn't break the existing interface of the original rational class/header. > >Best, >Vicente Thanks > >P.S A link to a standard proposal >* http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3363.html. There are some interesting things in there to consider... My current goal, however, is to add over/underflow checking to the original implementation, rather than add new capabilities beyond that. Comments?

2 1

[coroutine] new location
by Oliver Kowalke 05 Sep '12

05 Sep '12

Hi, because some of the community members have had some problems to access the archive I've uploaded the library to a new location. docu: http://ok73.ok.funpic.de/boost/libs/coroutine/doc/html/ src: http://ok73.ok.funpic.de/boost.coroutine.zip I'd like to remember that the review starts at September 3, 2012. The library contains one example using boost.asio together with a stream reading from a socket (without blocking the application if newline was not received). regards, Oliver

7 15

[context] Why does boost::ctx::minimum_stacksize() on Windows return 65536
by Hartmut Kaiser 05 Sep '12

05 Sep '12

Hey all, Why is the minimally possible stack size in Boost.Context on Windows set to be 64k? This seems to be way too high for applications where only a minimal amount of stack is required. I assume, that since Boost.Context allocates the stack using VirtualAlloc the minimum possible value should be equal to the page size (see http://msdn.microsoft.com/en-us/library/windows/desktop/aa366887(v=vs.85).as px). Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

4 18

Mail moderated?
by Klaim - Joël Lamotte 05 Sep '12

05 Sep '12

Hi I sent an email to this list this morning that apparently got into moderation because it contained some text files with logs. I'm just not sure it's been noticed by moderators, as it might have been marked spam or something? Joel Lamotte

2 1

Re: [boost] [Review.Coroutine] Some comments
by Oliver Kowalke 05 Sep '12

05 Sep '12

> * I don't know if showing the signature in the documentation will be > more informative. OK > * Could you add the following noexcept specifier? OK > * As the template class Allocator is not used to allocate internal > memory of the coroutine class. Could the Allocator parameter be renamed > StackAllocator? OK > * Could you add an standard Allocator parameter as e.g. the one of > packaged_task? > > C++ International Standard > > * I understand that the Boost.Context Allocator parameter is part od the > class, as context is a low-level class, but coroutine is more high > level. Is there a possibility to type erase the StackAllocator (and > preceding Allocator) template parameter, as packaged_task do? This will > allow to store coroutines (and generators) with the same signature in a > container even if they don't share the Allocator. You mean coroutine would have two allocators - one for allocating internal memory and one for allocating the stack? Removing the StackAllocator from the template arguments of coroutine should not that problem (would require an internal pointer to an internal interface - maybe detail::context_exec is a candidate). I've some concerns about having two allocator objects in coroutine's ctor . > * Parameters and move semantics. Could the signature parameters be > rvalue references? > > R operator()(A0 a0, ..., A9 a9); Hmmm - this would require a second version of opertor() and all arguments are moveable?! R operator()(BOOST_RV_REF( A0) a0, ..., BOOST_RV_REF( A)) a9); > I'm asking this because I think that Boost.Tuple has not implemented yet > move semantics. don't know - would that be an issue > * What about moving some of the coroutine/generator optional parameters > to a coro::attributes class > > std::size_t size = ctx::default_stacksize(), > flag_unwind_t do_unwind = stack_unwind, > bool preserve_fpu = true, instead of passing those threee params as args to coroutine ctor? good point > * Usually (at least in the C++ standard) a function doesn't throws > because of its preconditions are not satisfied. then assert? pre-conditions should be checked but how should I react if I get garbage from the user? > This should be coherent with > > > |Result operator()()| > > Preconditions: > > |*this| is not a /not-a-generator/, |! is_complete()|. > > which doesn't throws any specific exception if the preconditions are not > satisfied. does an assert - OK the I'll replace throwing excpetions be assertions > Documentation > ========= > > coroutine.html > > s/it can migrated between threads/it can migrate between threads/ OK > s/yield_return/yield_break/ > > * documentation for the following constructor is missing in the reference > > template< typename Fn > > coroutine( Fn && fn, > std::size_t size = ctx::default_stacksize(), > flag_unwind_t do_unwind = stack_unwind, > bool preserve_fpu = true, > Allocator alloc = Allocator() ); OK I think it will be easy to incorporate your suggestions - but during the boost.context review I was told not to modify the reviewd library (if the review is still on-going). regards, Oliver

2 1

[rational] Over/underflow checked update ready for comments
by Dan Searles 05 Sep '12

05 Sep '12

>>> Quick overview of the update: the original usage and >>> code of the template class remains mostly as before, ie >>> boost::rational<int> RationalVar; should work as >>> in the original version. Adding 'true' as a second >>> template parameter, however, allows an exception to >>> be raised if an operation with a class variable results >>> in a value that can't accurately be represented >>I haven't looked at anything else, but I dislike using true/false as the template argument. I'd prefer meaningful names. _____ >>Rob Stewart robert.stewart(a)sig.com >>Software Engineer using std::disclaimer; >>Dev Tools & Components >>Susquehanna International Group, LLP http://www.sig.com >Replaced the bool template parameter with an enum: >enum RationalChecktype {RationalNoChecking, RationalCheckforOverflow}; For those interested in the rational number class, see: https://svn.boost.org/svn/boost/sandbox/rational Requesting comments on the code, and review for inclusion in the next release. Dan Searles

2 1

very simple implementation of Andrei Alexandrescu's ScopeGuard idiom
by Sergey Radionov 04 Sep '12

04 Sep '12

https://github.com/RSATom/finally_execute/blob/master/finally_execute.h based on http://www.drdobbs.com/cpp/generic-change-the-way-you-write-excepti/1844037… I know about http://sourceforge.net/projects/loki-lib/ but with boost::bind this can be much simpler: https://github.com/RSATom/finally_execute/blob/master/README I've used this in many of my projects, and found it very usefull.... don't understand, why this simple solution does not contributed already to Boost by someone else... :)

7 19

[graph] property_value no longer valid for bgl_named_parameters
by Alex Hagen-Zanker 04 Sep '12

04 Sep '12

The transition from Boost 1.49 to 1.51 gave me a breaking change in the graph library: Originally I used the property_value struct to get the type of a named parameter, like this: property_value<bgl_params, Tag>::type; This no longer works and the current use seems to be: get_param_type<Tag, bgl_params>::type; Is this a regression? Or was I just using the library in the wrong way? Thanks, Alex

2 1

Enum Conversion
by Roland Bock 04 Sep '12

04 Sep '12

Hi, In a lot of projects in the company I work for we use Ice middleware which allows to define nice interfaces for services. The IDL also allows to define enums, but I cannot set specific values for the enum items. We also need to store some of these values in databases. We use int to represent the enumerations. Since we might feel the need to add more items to an enum or delete an unused one, we cannot just cast enum to int and vice versa when writing to or reading from the database. We need methods that translate enum to int and back in a stable way that won't change for an individual enum item, even if its position in the enum changes. I found a way to do this, which provides enum<->int and enum<->string. It is used like this: typedef enum { Alpha, Beta, Gamma, Delta, Epsilon } Greek; CREATE_CONVERTER_METHODS(Greek, (Alpha, 5), (Beta, 3), (Gamma, 7), (Delta, 1), (Epsilon, 6)); std::cout << GreekToString(IntToGreek(1)) << std::endl; std::cout << GreekToString(IntToGreek(6)) << std::endl; std::cout << GreekToInt(Alpha) << std::endl; std::cout << GreekToString(Alpha) << std::endl; std::cout << IntToGreek(17) << std::endl; ------ $ ./a.out Delta Epsilon 5 Alpha terminate called after throwing an instance of 'std::invalid_argument' what(): unexpected Greek value My questions are: a) Is this something that might be interesting for others as well? (Or does boost even offer something like that already?) b) I'd really like to be able to write this instead: CREATE_CONVERTER_METHODS(Greek, Alpha = 5, Beta = 3, Gamma = 7, Delta = 1, Epsilon = 6); Obviously, if I could use the preprocessor to translate Alpha = 5 -> (Alpha, 5) I'd be done. But I have no idea how to do that. Any suggestions? Thanks and regards, Roland

4 11

[Contract] noexcept and custom contract violation handlers
by Andrzej Krzemienski 04 Sep '12

04 Sep '12

Hi, I have just realized that there is an interesting interaction between "noexcept" and Contract Programming framework. Not only Lorenzo's library, but even if contracts were a language feature. N3248 ("noexcept prevents library validation", http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3248.pdf) recommends that functions with any preconditions should not be declared noexcept(true) in case someone wants to report precondition failures via exceptions. If preconditions become part of declaration syntax, declaring both precondition and noexcept(true) could (and should?) be recognized as compile-time error. But now also invariants and postconditions come into play: if a function declares a postcondition, or our class defines an invariant, should we be allowed to declare our function noexcept? What if someone wants to report an invariant or postcondition failure via special exception? (I do not have a good answer for it.) Regards, &rzej

4 5

[contract] invariant checking after destructor throw
by Andrzej Krzemienski 04 Sep '12

04 Sep '12

I have found a potential issue while reading the documentation. (The documentation is very good BTW). It says that the non-static invariant is still checked if object's destructor throws an exception. Am I reading it right? If so, I believe this is not correct. I have two problems with it: 1. According to the standard, an object is considered destroyed (its life-time has ended) when its destructor *starts*. Even if it throws an exception, it is considered destroyed, so accessing its members (in order to check for the invariant) may be illegal (an undefined behavior). 2. Why such an object (that threw on destruction) would need to preserve the invariant? You cannot access it or use it or even destroy it the second time, because it has already been destroyed. No-one will notice it anyway. Or am I missing something? Regards, &rzej

3 4

[Review:Contract] Late review
by Steven Watanabe 03 Sep '12

03 Sep '12

AMDG First of all, *Yes, Contract should be accepted into Boost* I've only really looked at part of the documentation so far. Here's my comments from that. I may have more later depending on how much time I have. index.html: - "Contract Programming (CP) allows to specify" Use a gerund (specifying) instead of an infinitive. An infinitive here needs a subject. - "... allowing to find bugs ..." Same problem, although it can't be fixed in the same way, since the participle + gerund would sound awkward. It could be handled with a passive infinitive. (allowing bugs to be found) - "and it was first introduced by the Eiffel programming language " You can leave out the "it." It sounds awkward to me. - "Eiffel programming language" Using this repeatedly sounds a bit pedantic. You can just say "Eiffel" after the first occurance. - The side by side code in the example gets a bit wide. This will definitely be a problem if you want the documentation to be generated as a PDF. - I don't understand why the library needs to deal with access control. Why can't the user just use public: private: protected: as usual? - CONTRACT_OLDOF kind of sticks out at me. I don't really like the way it looks having it a macro when everything else is keywords that are parsed by the top level macros. - "...if there is a bug in the function caller for which push_back is called when size is equal to max_size ..." This clause is somewhat confusing. - "...with the assertion number to uniquely identity..." s/identity/identify/. Also don't split infinitives. - "This library suffers of two limitations" s/of/from/ getting_started.html: - "This section explains how to setup..." "set up" should be two words. "setup" as one word is a noun. - "... failure of the checked condition does not abort the program, instead ..." Run on sentence. - "The implementation of this library uses..., templates with partial specializations and function pointers (similarly to Boost.Function), ..." I don't understand the connection between partial specialization and function pointers. Why are they grouped together? contract_programming_overview.html: - "It is assumed that programmes" s/programmes/programmers/ - "...to formally program specifications". Don't split the infinitive. "to program specifications formally" - "Then, this library aims to be ..." "Then" doesn't sound right here. "Then" is usually used for conditions ("if... then") or sequences (e.g. First.... Then...), but there's nothing for it to connect to here. - "Contract Programming is characterized by the following type of assertion mechanisms." s/type/types/ - "before the body execution." I think it would sound better to use the possesive "body's execution" or "execution of the body". rather than apposition. - "Preconditions cannot be strengthen, postconditions and class invariants cannot be weaken. " s/strengthen/strengthened/, s/weaken/weakened/ - I'm not sure that I would consider Subcontracting to be an assertion mechanism. - "Block Invariants | These are logical conditions that programmers except ..." s/except/expect/ - "...while a contract assertions is ..." s/assertions/assertion/ - "This library implement this feature however it should be noted ..." Run on sentence. - "protect such a global variable from racing conditions " It's called a "race condition." - "but that will effectively introduce a global lock in the program" This seems like a classic use case for thread specific storage. - "Furhtermore," s/Furhtermore/Furthermore/ - "Contracts are part of the source code, they are..." Run on sentence (comma splice) - "detailed error messages that greatly helps debugging" "helps" needs to agree with "messages." - "Contract Programming benefits come to the cost of performance " "to" is the wrong preposition. Try "at." - "The run-time performances are negatively ..." "performance" should be singular. Plural doesn't really make sense for abstract nouns like this. - "1. The extra processing required to check the assertions. 2. The extra processing required by the additional function calls (additional functions are invoked to check preconditions, postconditions, class invariants, etc)." How is (2) different from (1)? - "checking function arguments using postconditions " I think you mean /pre/conditions. - "so that these initializations can relay" s/relay/rely/ - "C++ object construction mechanism ..." You need an article. "The C++..." - "Check the non-static class invariants, but only if the body threw an exception." This could use a rationale. Destructors are generally not supposed to throw at all. - "Contracts are only responsible to check the " "for checking" instead of "to check." - "...to only use public members, Eiffel instead ..." Split infinitive, run-on sentence. - "...are allowed to brake class invariants..." s/brake/break/ - "Arbitrary code in contracts | No, assertions only." This is a bit misleading, since assertions can execute arbitrary code. tutorial.html: - "complete guide on this library syntax" s/library/library's/ - result == oldof valule s/valule/value/ - "int const" IIRC, you can't have a const rvalue of a built-in type. - "parameter names can instead by omitted " s/by/be/ - params_postinc You didn't update the pre/post conditions when you copied this from the last example. - "Function and array types cannot be directly used as function parameter types within the contract macros but extra typedef declarations can be used to workaround this limitation " This workaround doesn't work in function templates where the array element or dimension is deduced. - "the maximum number of supported array dimensions is specified by the CONTRACT_CONFIG_ARRAY_DIMENSION_MAX macro" I don't understand the reason for this limitation. - "...evaluates all contract conditions in constant-correct context" Add an article "a" before "const-correct." - "the type of value type" Delete the second "type." - ConstantCopyConstructible You're definitition of CopyConstructible is wrong. A type that only defines T(T&) is not CopyConstructible. - "However, it is still necessary to ontract" s/ontract/contract/ - unique_identifiers I think it's worth pointing out that the postcondition can't assume that the precondition was true in the face of subcontracting. I did a double take when I saw old_found. - "Wakened inherited preconditions ..." s/Wakened/Weakened/ oldof.hpp: The definition of CONCEPT_OLDOF is a bit dangerous. It can't safely be passed as a macro argument. What do you think of this bit of PP magic: #define TEST_EXPAND_EXPAND_OLDOF(x) CONTRACT_OLDOF #define TEST_EXPAND_NOTHING(x) oldof #define TEST_EXPAND_I(x) TEST_EXPAND_ ## x #define TEST_EXPAND(x) TEST_EXPAND_I(x) #define oldof TEST_EXPAND(EXPAND_OLDOF(NOTHING(z))) #define EXPAND_OLDOF(expr) expr oldof -> expands to itself EXPAND_OLDOF(random text oldof more random text) -> expands to random text CONTRACT_OLDOF more random text General: - Are ellipsis parameters allowed? - Just say "parentheses," not "round parentheses." Parentheses without any qualification always means (). In Christ, Steven Watanabe

2 3