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

[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

[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

[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

[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

[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: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

[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

[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] 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

[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

[type_eraseure]Why not make default concept_interface a metafunction returning Base?
by Larry Evans 31 Aug '12

31 Aug '12

Since the unspecialized concept_iterface definition: template<class Concept, class Base, class ID, class Enable = void> struct concept_interface : Base {}; does nothing, and it's used to compose the any base class heirarchy in: template<class Derived, class Concept, class T> struct compute_bases { typedef typename ::boost::mpl::fold< typename ::boost::type_erasure::detail::collect_concepts< Concept >::type, ::boost::type_erasure::any_base<Derived>, ::boost::type_erasure::concept_interface< ::boost::mpl::_2, ::boost::mpl::_1, T > >::type type; }; why not eliminate the empty concept_interfaces by redefining the unspecialized concept_interface to: template<class Concept, class Base, class ID, class Enable = void> struct concept_interface : Base { //The following enables mpl::fold, when using //this as the binary operator, to skip this //empty interface. typedef Base type; }; I believe that would work since mpl::fold uses the nested type if it's available, IIUC. Although it would not change the behaviour of any code, it would make the intent of the code clearer. Also, while trying to understand what the code is doing by using a type name demangler, I found all those empty concept_interfaces are just noise. -regards, Larry

1 0

[Review:Contract] Contract Broken Handlers , BOOST_NO_EXCEPT and noexcept
by Vicente J. Botet Escriba 31 Aug '12

31 Aug '12

Hi, I would like to know if Boost.Contract could work when BOOST_NO_EXCEPT is defined. I suspect that it can not at present, as the user needs to re-throw the exception to know the broken nature. Maybe the handler could have the an exception/error object as parameter instead. In order to be able to use contracts in C++11 functions declared noexcept I would need that the contract handler are declared noexcept also, in particular when the contract is broken from a destructor, which is often declared noexcept in C++11. Maybe the library can provide some specific set handlers that expect a noexcept handler for the destructor context. BTW, could the ALL CAPITAL |FROM_CONSTRUCTOR, ... enumeration literal|s be renamed to lower case from_constructor, ...? Best, Vicente

2 3

Question about release branches
by Pedro Larroy 30 Aug '12

30 Aug '12

Hi I'm not able to find some fixes such as (78513) in tags/release/Boost_1_51_0/ nor tags/release/Boost_1_50_0/ Why some fixes that are in trunk didn't made it to the release branches? Thanks. Pedro.

2 1

[range] Missing include in boost/range/algorithm/for_each.hpp
by Sergiu Dotenco 30 Aug '12

30 Aug '12

There is an issue with boost/range/algorithm/for_each.hpp which is missing an include. The problem seems to have been fixed in trunk two months ago (https://svn.boost.org/trac/boost/changeset/79180) but the changeset hasn't been applied to the release branch yet. Could this be done for the 1.52 release?

2 1

[fusion] undocumented sequence requirement: convert
by Eric Niebler 30 Aug '12

30 Aug '12

Say I have a valid fusion sequence. I want to use an mpl algorithm on it. I include boost/fusion/mpl.hpp and put a nested tag type in my sequence that is an alias for fusion::fusion_sequence_tag. So far, so good. Then I try to call mpl::pop_back on this sequence, and I find that, despite fulfilling all the documented requirements for Fusion ForwardSequence, the code fails to compile. That's because of this in boost/fusion/mpl/pop_back.hpp: template <> struct pop_back_impl<fusion::fusion_sequence_tag> { template <typename Sequence> struct apply { typedef typename fusion::result_of::pop_back<Sequence>::type result; typedef typename fusion::result_of::convert< typename fusion::detail::tag_of<Sequence>::type, result>::type type; }; }; My code doesn't compile because I haven't implemented the fusion::convert customization point. Where is that documented and what does it do? -- Eric Niebler BoostPro Computing http://www.boostpro.com

4 12

[type_erasure]bug in computed_bases?
by Larry Evans 29 Aug '12

29 Aug '12

Based on the output of the test code(compute_bases.cpp) in the 1st attachment, the compute_bases metafunction defined in any.hpp is producing something like: concept_interface < concepts , concept_interface < mpl::at_c<concepts,1>::type , concept_interface < mpl::at_c<concepts,2>::type , ID , Enable > , ID , Enable > , ID , Enable > where concepts is the Concept argument to any. When the test code is run with: //#define OVERLOAD_SIMPLE the output is what should be expected with a_any.simple(); calling the simple<.>::apply static method. The output for this case is shown in the compute_bases.not_overload_simple.out. OTOH, when the test code is run with: #define OVERLOAD_SIMPLE the code in the concept_interface<typename requirements<C>::type,...>::simple is run. The output for this case is shown in the compute_bases.yes_overload_simple.out. This output shows that the concept_interface<C,...> CTOR is called where C == mpl::vector<...>. Is this the intended behaviour? If so, where is this spelled out in the documentation? The documentation here: http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… certainly doesn't suggest anything of that sort, and the doc here: http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… says: 1. typename Concept The concept that we're specializing concept_interface for. which uses the singular Concept instead of the plural Concepts, suggesting the Concept is not an mpl::vector<> of any sort. -regards, Larry

2 4

Review Request: odeint
by Mario Mulansky 29 Aug '12

29 Aug '12

Hi, after getting some good amount of positive feedback on our talk at boostcon we are now asking for a formal review process of the odeint library, currently hosted on github: https://github.com/headmyshoulder/odeint-v2 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 The code is hosted on github: https://github.com/headmyshoulder/odeint-v2 Documentation/Tutorial: http://headmyshoulder.github.com/odeint-v2/doc/index.html We are, of course, looking for a review manager as well. Thanks! Karsten and Mario

4 3

[type_erasure][docs]conceptdef.html terms
by Larry Evans 29 Aug '12

29 Aug '12

The doc: http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… states: When a concept is instantiated with a specific set of type bindings, each placeholder is bound to a cv-unqualified non-reference type. After replacing each placeholder in the template argument list with the type that it binds to, the following must hold. * The number of arguments of apply in the bound concept must be the same as the number of arguments in the unbound concept. * The arguments and return type of apply in the bound concept can be derived from the corresponding arguments and the return type in the unbound concept as follows: If the argument in the unbound concept is a placeholder with optional cv and reference qualifiers, then the argument in the bound concept can be found by replacing the placeholder. Otherwise, the argument in the unbound concept must be the same as the argument in the bound concept. However, there is no apply in the builtin concept's: same_type (in same_type.hpp) null_construct (in constructible.hpp) destructible (in builtin.hpp) so, shouldn't the paragraph qualify the word concept with the word primitive, to make clear it's talking about item 3 in the list: There are three kinds of concepts. 1. The library defines a number of predefined concepts. 2. Any MPL Forward Sequence whose elements are concepts is also a concept. 3. Users can define their own primitive concepts. from the 2nd paragraph of conceptdef.html? IOW, rephrase the 1st sentence to: When a *primitive* concept is instantiated with a specific set of type bindings, I guess one could infer from the sentence 2 paragraphs up: Each primitive concept defines a single operation. that the word concept in subsequent paragraphs means primitive concept, but not every reader (in particular, this reader) would make that inference unless he'd actually looked at the definition of some of the predefined concepts. BTW, the same_type doc uses the term 'built in concept'; however, the conceptdef.html doc uses the term 'predefined concept'. It would be helpful if the same term were used everywhere. HTH. -regards, Larry

1 0

Re: [boost] a (useful?) crtp trick
by Gottlob Frege 29 Aug '12

29 Aug '12

declaration is crystal clean (read: self documenting), no need to use enable_if, etc. -- Pavel P.S. if you notice a grammar mistake or weird phrasing in my message please point it out Crystal clear, not crystal clean. Tony

1 0

[type_erasure]tests fail_any_cast_pointer_to_val fails compile
by Larry Evans 29 Aug '12

29 Aug '12

When running bjam, I get: compilation; default-directory: "~/prog_dev/boost-svn/ro/boost_1_49_0/sandbox/ro/type_erasure/type_erasure/libs/type_erasure/test/" -*- Compilation started at Tue Aug 28 21:33:51 bjam sh: icpc: not found ...patience... ...patience... ...found 2363 targets... ...updating 171 targets... gcc.compile.c++ bin/test_binding.test/gcc-4.8n/debug/test_binding.o gcc.link bin/test_binding.test/gcc-4.8n/debug/test_binding . . . gcc.compile.c++ bin/test_null.test/gcc-4.8n/debug/test_null.o gcc.link bin/test_null.test/gcc-4.8n/debug/test_null testing.capture-output bin/test_null.test/gcc-4.8n/debug/test_null.run **passed** bin/test_null.test/gcc-4.8n/debug/test_null.test gcc.compile.c++ bin/fail_default_construct.test/gcc-4.8n/debug/fail_default_construct.o In file included from fail_default_construct.cpp:11:0: ../../../boost/type_erasure/any.hpp: In instantiation of 'boost::type_erasure::any<Concept, T>::any() [with Concept = boost::type_erasure::copy_constructible<>; T = boost::type_erasure::_self]': fail_default_construct.cpp:18:32: required from here ../../../boost/type_erasure/any.hpp:157:9: error: no matching function for call to 'assertion_failed(mpl_::failed************ boost::type_erasure::is_relaxed<boost::type_erasure::copy_constructible<> >::************)' BOOST_MPL_ASSERT((::boost::type_erasure::is_relaxed<Concept>)); ^ ../../../boost/type_erasure/any.hpp:157:9: note: candidate is: BOOST_MPL_ASSERT((::boost::type_erasure::is_relaxed<Concept>)); ^ svn update shows: ~/prog_dev/boost-svn/ro/boost_1_49_0/sandbox/ro/type_erasure/type_erasure $ svn update At revision 80297. svn diff shows: ~/prog_dev/boost-svn/ro/boost_1_49_0/sandbox/ro/type_erasure/type_erasure $ svn diff|filterdiff --exclude=\*bjam.normal\* Index: boost/type_erasure/detail/normalize.hpp =================================================================== --- boost/type_erasure/detail/normalize.hpp (revision 80297) +++ boost/type_erasure/detail/normalize.hpp (working copy) @@ -353,7 +353,14 @@ struct collect_concepts ::boost::type_erasure::detail::substitution_map<Map> >::type transformed; typedef typename ::boost::mpl::eval_if< + #if 0 + ::boost::mpl::or_ + < ::boost::is_same<transformed, void> + , ::boost::mpl::is_sequence<Concept> + >, + #else ::boost::is_same<transformed, void>, + #endif ::boost::mpl::identity<Out>, ::boost::mpl::insert< Out, Index: libs/type_erasure/test/bjam.normalize_no_is_seq.out =================================================================== ~/prog_dev/boost-svn/ro/boost_1_49_0/sandbox/ro/type_erasure/type_erasure $ Anyone else seeing this? -regards, Larry

2 1