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

[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

mpi compile bug
by 陈立红 03 Sep '12

03 Sep '12

Hi guys, I have installed the OpenMPI_v1.6.1 and want to make use of boost mpi. But I cannot compile it with msvc10.0 successfully. The error message is like below. I found similar bug Ticket #5465 (new Bugs), but there's no one comment on it. Please help. E:\soft\boost_1_49_0>bjam stage --toolset=msvc-9.0 --with-mpi --stagedir="E:\sof t\boost_1_49_0\Debug\lib10" link=static runtime-link=shared runtime-link=static ָ��줿�ѥ��Ҋ�Ĥ��ޤ�� ָ��줿�ѥ��Ҋ�Ĥ��ޤ�� ָ��줿�ѥ��Ҋ�Ĥ��ޤ�� ָ��줿�ѥ��Ҋ�Ĥ��ޤ�� MPI auto-detection failed: unknown wrapper compiler mpic++ Please report this error to the Boost mailing list: http://www.boost.org You will need to manually configure MPI support. warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. Component configuration: - chrono : not building - date_time : not building - exception : not building - filesystem : not building - graph : not building - graph_parallel : not building - iostreams : not building - locale : not building - math : not building - mpi : building - program_options : not building - python : not building - random : not building - regex : not building - serialization : not building - signals : not building - system : not building - test : not building - thread : not building - timer : not building - wave : not building ...found 1 target... Regards, Lihong Chen

1 0

[trac] Library components: ATTENTION LIBRARY AUTHORS
by Rene Rivera 03 Sep '12

03 Sep '12

If you are the author of an accepted library please remember to ask to add the library to the trac bug system. It's important that others have a component to assign to bugs. In order to add the library component we need to know the trac *account* name you are using. Please check in trac to see if your library has a component (with this report <https://svn.boost.org/trac/boost/report/15>). If not, or if there are errors, please reply here with the new, or corrected, information. And if you don't happen to have a trac account please ask for one (<https://svn.boost.org/trac/boost/wiki#GettingaTracSVNUserid>). Thank you. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

2 2

[lockfree] Faulty (?) static assert
by Hartmut Kaiser 03 Sep '12

03 Sep '12

Hey, The lockfree::queue constructors raise a static assert if no capacity is specified. This contradicts the member initialization code close to the assert, for instance: queue(void): head_(tagged_node_handle(0, 0)), tail_(tagged_node_handle(0, 0)), pool(node_allocator(), has_capacity ? capacity : 0) { BOOST_STATIC_ASSERT(has_capacity); initialize(); } which implies that 'has_capacity' is allowed to be false. From what I can see 'has_capacity' could be false, indeed, in particular if the queue is not bounded in size. Would changing this to queue(void): head_(tagged_node_handle(0, 0)), tail_(tagged_node_handle(0, 0)), pool(node_allocator(), has_capacity ? capacity : 0) { BOOST_STATIC_ASSERT(has_capacity || capacity); initialize(); } reflect the actual intention? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

2 8

[lockfree] Type conversion warnings
by Hartmut Kaiser 03 Sep '12

03 Sep '12

Hey all, The attached patch fixes a couple of warnings about possible loss of precision caused by integral type conversions for MSVC. Ok to commit? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

2 1

[lockfree] freelist_stack::allocate and freelist_stack::deallocate should not be private
by Hartmut Kaiser 03 Sep '12

03 Sep '12

Hey all, Currently, the allocate/deallocate functions et.al. in lockfree::detail::freelist_stack are private. This inhibits reusing this class for implementing other lock-free datastructures as it's not possible to allocate anything which has not a constructor taking 0, 1, or 2 arguments (those are supported explicitly by exposing overloads for freelist_stack::construct). Would it be possible to make the mentioned functions 'protected' instead? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

2 3

Please create a category for atomic, context, and lockfree in trac
by Hartmut Kaiser 02 Sep '12

02 Sep '12

Please create a category for atomic, context, and lockfree in trac. Thanks! Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

3 4

[Review:Contract] Some questions
by Vicente J. Botet Escriba 02 Sep '12

02 Sep '12

Hi, First of all, thanks Lorenzo for your work on pre-processor programming. With this library, you have showed to me how far the pre-processing can go in terms of expressiveness. I have some questions before doing a complete the review: = C++11 compatibility = * Does the library use c++11 features when available? I was thinking e.g. on the emulated virtual specifiers. BTW, I think the "new" virtual specifier was removed from the standard, but maybe I'm wrong. * I think the library don't allow to declare C++11 specific classes/function. E.g * variadic templates * noexcept functions * constexpr functions * class/function attributes BTW, I have not see any example using exception specifications using 'throws'. Does the library support them? Could you confirm? and if not, could you tell us if you have a plan to support them? = Postconditions result = "Postconditions can access the function return value by declaring a variable of type |auto| and assigning it to the |return| keyword (the variable name is arbitrary but |result| is often used)." What prevent the library to the use of return instead of an auto variable postcondition( // Postconditions. auto old_value = CONTRACT_OLDOF value, // Old value(s). value == old_value + 1, // Assertion(s)... return == old_value ) instead of postcondition( // Postconditions. auto result = return, // Result value. auto old_value = CONTRACT_OLDOF value, // Old value(s). value == old_value + 1, // Assertion(s)... result == old_value ) =Constant assertions = I would expect that the old are always const so the following postcondition( auto old_even = CONTRACT_OLDOF even, auto old_odd = CONTRACT_OLDOF odd, // `[old_]even` and `[old_]odd` all `const&` within assertions. const( even, old_even ) even == old_even + 2, const( odd, old_odd ) odd == old_odd + 2 ) should be rewritten without loss of semantics as postcondition( auto old_even = CONTRACT_OLDOF even, auto old_odd = CONTRACT_OLDOF odd, // `[old_]even` and `[old_]odd` all `const&` within assertions. const( even ) even == old_even + 2, const( odd ) odd == old_odd + 2 ) = Oldof = As the old of value must be declared using a variable, using a specif oldof keyword that will replace auto old_size = CONTRACT_OLDOF size(), by oldofold_size = size(), could simplify the syntax. What do you think? Some minor points: * Why do you use( void ) instead of () in the functions without parameters? e.g. public: bool empty ( void ) const { return vector_.empty(); } Some suggestions: * Use 2 spaces indentation instead of 4 could reduce the width of the page, in particular when you use several columns. * The use of'int const' as return type is verbose and could be replaced by just int. Best, Vicente

2 21

[context] Recent changes (rev. 80363) break compilation
by Hartmut Kaiser 02 Sep '12

02 Sep '12

Hey all, The latest commit to trunk (rev. 80363) breaks compilation of Boost.Context on Windows. I'm attaching a patch fixing the issue. Ok to commit? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

2 2

[Review:Contract] Base class preconditions not checked
by Steven Watanabe 02 Sep '12

02 Sep '12

AMDG Test case attached. The problem is that the precondition test is executed when initializing a virtual base. Virtual bases are always initialized by the most derived class, so the preconditions of base class constructors are never checked. In Christ, Steven Watanabe

2 1

[lockfree] Inconsistent typedef tag_t in tagged_ptr
by Hartmut Kaiser 02 Sep '12

02 Sep '12

Hey all, The embedded typedef <...> tag_t has inconsistent visibility in the two implementations of tagged_ptr. In tagged_ptr.hpp this typedef is 'public', while in the file tagged_ptr_ptrcompression.hpp this typedef is 'private'. Would it be possible to make it public in both cases (patch attached)? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

2 2

[context] Windows ctx::maximum_stacksize() runtime asserts
by Hartmut Kaiser 02 Sep '12

02 Sep '12

Hey all, The Windows implementation of boost::ctx::maximum_stacksize() does always assert: std::size_t maximum_stacksize() { BOOST_ASSERT( ! is_stack_unbound() ); static std::size_t stacksize = 8 * 1024 * 1024; return stacksize; } That is because is_stack_unbound() will unconditionally return true. Patch is attached - ok to commit? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

2 2

MPI maintainer?
by Ralf Grosse-Kunstleve 02 Sep '12

02 Sep '12

Who is currently maintaining Boost MPI? We have two trac items I'd like to assign to the MPI maintainer. The first one has been sitting there for a long time already. https://svn.boost.org/trac/boost/ticket/6123 https://svn.boost.org/trac/boost/ticket/7316 Ralf

1 0

[test] Boost.Test unreleased since November 2009 ?
by Mathieu Champlon 02 Sep '12

02 Sep '12

Hi, I've noticed that no merge has been made from trunk to the release branch for Boost.Test since November 2009, meaning that a lot of bug fixes and features have remained unreleased. Is it on purpose ? Thanks, MAT.

2 1

[test] Where should I put replacement functions for WinCE?
by Jan Hudec 02 Sep '12

02 Sep '12

Hello Folks, Windows CE don't have time and clock functions, getenv function and errno.h (though they seem to have _errno function). I needed to define these things to get Boost.Test to build for WinCE. Now it would be nice to have this work by default. I can provide the definitions (they are quite simple), but I am not sure where would be correct place for them. Should I add them to config/platform/win32.hpp, create config/platform/wince.hpp or put them just in test? Thanks, Jan -- Jan 'Bulb' Hudec <bulb(a)ucw.cz>

2 1

[test] sigaltstack does not work on older Android
by Jan Hudec 02 Sep '12

02 Sep '12

Hello Folks, Android NDK contains several "platforms", depending on which release one desires to be compatible with. Boost test compiles fine with android-8 and newer, but the older versions have incomplete definition of sigaltstack (they define the structure, but not the function), causing compilation error in boost/test/detail/impl/execution_monitor.ipp. I have fixed it locally by adjusting the condition for defining BOOST_TEST_USE_ALT_STACK, but I am not sure which level of fix would be best suited for integrating in boost. I see 3 options: 1. Leaving it as is and simply saying android is only supported from API level 8 (that's 2.2; we are still compiling for 2.1 (which has no changes in native since 2.0)) 2. Simply disabling BOOST_TEST_USE_ALT_STACK in Android; it's not necessary after all. 3. Being really precise and reading the API version, but that requires including extra header. It would be nice, but I am not sure what is the correct place to include it. Here is a simple patch that just disables sigaltstack for Android: --- a/boost/test/impl/execution_monitor.ipp +++ b/boost/test/impl/execution_monitor.ipp @@ -173,7 +173,7 @@ namespace { void _set_se_translator( void* ) {} } # endif # endif -# if !defined(__CYGWIN__) && !defined(__QNXNTO__) +# if !defined(__CYGWIN__) && !defined(__QNXNTO__) && !defined(__ANDROID__) # define BOOST_TEST_USE_ALT_STACK # endif And here is a more complex patch that on android (the __ANDROID__ macro is predefined by the compiler in Android NDK) reads the api-level and uses it to decide: --- a/boost/test/impl/execution_monitor.ipp +++ b/boost/test/impl/execution_monitor.ipp @@ -173,7 +173,11 @@ namespace { void _set_se_translator( void* ) {} } # endif # endif -# if !defined(__CYGWIN__) && !defined(__QNXNTO__) +# if defined(__ANDROID__) +# include <android/api-level.h> +# endif + +# if !defined(__CYGWIN__) && !defined(__QNXNTO__) && (!defined(__ANDROID__) || __ANDROID_API__ >= 8) # define BOOST_TEST_USE_ALT_STACK # endif -- Jan 'Bulb' Hudec <bulb(a)ucw.cz>

2 1

[test] Fix WinCE workaround
by Jan Hudec 02 Sep '12

02 Sep '12

Hello Folks, boost/test/impl/execution_monitor.ipp has workaround for older MSVC++ and assumes WinCE version need it too. However the WinCE compiler caught up in next version. Here is a proposed patch: --- a/boost/test/impl/execution_monitor.ipp +++ b/boost/test/impl/execution_monitor.ipp @@ -84,7 +84,7 @@ using std::va_list; typedef unsigned uintptr_t; # endif -# if BOOST_WORKAROUND(_MSC_VER, < 1300 ) || defined(UNDER_CE) +# if BOOST_WORKAROUND(_MSC_VER, < 1300 ) || (defined(UNDER_CE) && BOOST_WORKAROUND(_MSC_VER, < 1500 )) typedef void* uintptr_t; # endif -- Jan 'Bulb' Hudec <bulb(a)ucw.cz>

2 1

[test] Interest in gtest-like output?
by Jared Grubb 02 Sep '12

02 Sep '12

I really like the Boost.Test framework, however, I cant help but have a bit of envy over how great the output from googletest looks. I've been playing around with writing a formatter/outputter that emulates the output style of googletest, and I am willing to spend some time to pretty it up and generate a patch if there's interest. Does anyone think this would be a worthy submission to boost? For an example of what the output looks like, this site has some great examples: http://www.ibm.com/developerworks/aix/library/au-googletestingframework.html (just to clarify: I'm not suggesting changing any BOOST_TEST syntax, just adding a new optional way to format the test progress and results to stdout) Jared

3 2

Re: [boost] [lockfree] Faulty (?) static assert
by Hartmut Kaiser 01 Sep '12

01 Sep '12

> The lockfree::queue constructors raise a static assert if no capacity is > specified. This contradicts the member initialization code close to the > assert, for instance: > > queue(void): > head_(tagged_node_handle(0, 0)), > tail_(tagged_node_handle(0, 0)), > pool(node_allocator(), has_capacity ? capacity : 0) > { > BOOST_STATIC_ASSERT(has_capacity); > initialize(); > } > > which implies that 'has_capacity' is allowed to be false. From what I can > see 'has_capacity' could be false, indeed, in particular if the queue is > not bounded in size. > > Would changing this to > > queue(void): > head_(tagged_node_handle(0, 0)), > tail_(tagged_node_handle(0, 0)), > pool(node_allocator(), has_capacity ? capacity : 0) > { > BOOST_STATIC_ASSERT(has_capacity || capacity); > initialize(); > } > > reflect the actual intention? Sorry, I meant: > BOOST_STATIC_ASSERT(has_capacity || !capacity); Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu > > Regards Hartmut > --------------- > http://boost-spirit.com > http://stellar.cct.lsu.edu > >

1 0

[atomic] Windows autolinking and longlong patches
by Hartmut Kaiser 01 Sep '12

01 Sep '12

Hey, Please find attached two patches for Boost.Atomic (trunk, rev. 80334) adding auto-linking for MSVC, fixing symbol visibility, and fixing a long long problem. Ok to commit? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

2 2