- Boost - lists.preview.boost.org

Which compilers are not supported for 1.48 ?
by Antony Polukhin 20 Jul '11

20 Jul '11

Are really old and broken compilers still supported? Do we need them? For example VC++6. It gives thousands of warnings on type_traits and boost PP headers. Tests for VC++6 do not compile. Nobody tested boost libraries on that compiler for years. May be we shall get rid of compilers, that do not support template partitial specialization, ADL or SFINAE? If not, shall we try to make the tests pass (or at least compile) for them? Best regards, Antony Polukhin

15 16

[Boost.bcp] Runtime error while parsing regular expression
by Jakub Skowron 20 Jul '11

20 Jul '11

Boost 1.47.0 file: \tools\bcp\licence_info.cpp function: std::string format_authors_name(const std::string& name) In regex literal (^)?[^-(<a-zA-Z�-�]+(([(<].*)?$)? there are some characters from unknown character set (byte value above 127). This causes runtime error while running "bcp shared_ptr foo": "boost Found a closing ) with no corresponding openening parenthesis. The error occured while parsing the regular expression fragment:" I am using English version of Windnows XP, but locale are Korean (Control Panel->Regional and Language Options->Advanced->Language for non-Unicode programs). Default toolset was used to build boost (that is msvc). I have Microsoft Visual Studio 2005 installed.

1 0

[TTI] Review for The Type Traits Introspection library by Edward Diener **extended**
by Joel Falcou 20 Jul '11

20 Jul '11

The Type Traits Introspection library by Edward Diener started friday 1st have been *extended* to july 17. Comments and reviews are welcome. =========== What is it? =========== The TTI library, which is an abbreviation for the 'Type Traits Introspection' library, allows a programmer to introspect at compile time the inner elements of a C++ type. The introspection process depends on specifying the name of the inner element by different macros for different types of elements, and then using a generated metafunction to determine whether that element exists within the enclosing type. The inner elements which can be introspected are type, class template, member data, member function, static member data, and static member function. The TTI library is based on the type_traits_ext portion of the Concept Traits Library, with improvements and additions, and also reproduces functionality ( without changing existing code ), for the purposes of completeness, from Boost.MPL regarding introspection of types and templates. The purpose of the library is to provide a consistent set of interfaces for doing compile-time introspection of a type, which other template metaprogrammers can use in their code. If you are at all interested in compile-time introspection of types, please take a look at the functionality of this library. =================== Getting the library =================== The library is available at http://svn.boost.org/svn/boost/sandbox/tti/. The HTML documentation is available at http://svn.boost.org/svn/boost/sandbox/tti/libs/tti/doc/html/index.html and the PDF documentation is available at http://svn.boost.org/svn/boost/sandbox/tti/libs/tti/doc/TypeTraitsIntrospec…. =================== Writing a Review =================== The reviews and all comments should be submitted to the developers list, and the email should have "[TTI] Review" at the beginning of the subject line to make sure it's not missed. Please explicitly state in your review whether the library should be accepted. The general review checklist: - 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? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion.

6 30

[accumulator] median absolute deviation
by Phil Bouchard 20 Jul '11

20 Jul '11

Hi, I see the median absolute deviation (MAD) is not provided by the accumulator library. Perhaps this is a feature that could be added. Thanks, -Phil

2 2

[contract] oldof failure not in N1962?
by lcaminiti 20 Jul '11

20 Jul '11

Hello all (and especially N1962 authors), As far as I can see, N1962 does not say what to do in case of a failure while evaluating and copying an oldof expression. For example, what shall Contract Programming do if there is a memory error while taking a copy of size() to later check the following postcondition? size() == oldof size() + 1 Given that oldof copies are taken just after preconditions are checked and before the body is executed, I am tempted to treat the oldof failure as a precondition failure and call the precondition_broken handler. An alternative would be to to treat the oldof failure as if it happened within the body. However, in this case the body will raise more errors (e.g., throw more exceptions) that it will raise without the oldof contracts so I don't think this is a good approach. In summary: 1) oldof expressions belong to the contract therefore I think oldof failures should result in calling one of the contract failure handlers (precondition_broken or postcondition_broken). 2) Given that eventual oldof failures happen before the body is executed (and just after the preconditions are checked), I think precondition_broken should be called (instead of postcondition_broken) in case of an oldof failure. The counter argument is that precondition failures indicate a bug in the caller. However, oldof failures indicate a system-level exception in the code that programs the program-- oldof failures are not bugs in neither the caller (precondition_broken) nor in the body implementation (postcondition_broken)... but if you follow this argument, you need to give up 1)... What do you think? Thank you. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-contract-oldof-failure-not-in-N196… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 9

[Boost] [GSoC] Checks project - prototype hesitation
by Pierre Talbot 20 Jul '11

20 Jul '11

Hello community. I'm a GSoC student who is assigned to the checks library. I currently design the prototype of a function and I would like to have your opinions. Description. --------------- The function must return true or false if the number is correct (or not). This leads me to this prototype : template <typename mod10_iter> bool check_mod10 ( const mod10_iter &begin, const mod10_iter &end, unsigned int nbr_digits = 0) ; But each digits in the functions may have a weight. So I must passed a sequence of unsigned int to the function. template <typename mod10_iter> bool check_mod10 ( const mod10_iter &begin, const mod10_iter &end, const boost::array<unsigned int> &weight, unsigned int nbr_digits = 0) ; The parameter "weight" should be optional, if the size is equal to 0, the algorithm will consider a weight of 1 for all the digits. The const of weight is a problem if the size is equal to 0, we should make a copy of this argument. Do you have any ideas, suggestions about this prototype ? Thank you very much. Pierre Talbot.

3 4

lockfree download
by Sean Farrow 19 Jul '11

19 Jul '11

Hi: I'm looking at reviewing lockfree but the url given on the boost announce list givens an http404, can someone give me a link please? Cheers Sean.

2 1

[qvm] few q's for emil
by Jeffrey Lee Hellrung, Jr. 19 Jul '11

19 Jul '11

Emil, I have a few quick and random questions concerning (proposed) Boost.QVM, which I notice is still in the review queue without a review manager (I may be able to help in that regard if things go well with Lorenzo's (proposed) Boost.Local review). I might be able to utilize this in some of my future work, so I'm interested. First, a very general question. Can you explain where QVM fit within the large collection of linear algebra libraries? What additional value is QVM providing that you feel other solutions are lacking? Now, I've barely scratched the documentation and I already have some questions :/ First, it doesn't look like you support read-only or write-only structures, or structures for which writing is effected through a proxy reference. E.g., v_traits<V>::r<I>(v) and v_traits<V>::w<I>(v) must always be supported, and v_traits<V>::w<I>(v) must return a reference-to-non-const. It seems like, in particular, read-only structures could be useful (e.g., a stateless standard basis vector or identity matrix), as could proxy structures (c*v could be a proxy vector where w<0>(c*v) = 1 is equivalent to w<0>(v) = 1/c). Comment? Why do you require the dimension of vectors (and, likely, matrices; I haven't checked) to be strictly greater than 0? Sometimes a 0-dimensional vector is convenient to have when writing dimension-independent code. I noticed that among the vector operations is a cross product for 3-vectors, but no cross product for vectors of other dimensions. Such a construct is useful for computing normals to hyperplanes in D-dimensional space. I can help you add it if you think it fits. What algorithm do you use for computing determinants? I think a signed volume function would fit in well with the matrix operations. I can help you add this, too. Hmmm...how do you compute the magnitude of a vector given the scalar requirements defined at http://www.revergestudios.com/boost-qvm/scalar_requirements.html ? Seems like you would need a square root function, and possibly even a conjugation function if you want to support complex scalar types... Okay that's it for now, - Jeff

2 7

[TTI] Review
by Gregory Crosswhite 19 Jul '11

19 Jul '11

Are you knowledgeable about the problem domain? ----------------------------------------------- I have done some metaprogramming and made some use of SFINAE, but my knowledge of the program domain is not extensive. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? -------------------------------------------------------------------------------------------- I have glanced over the documentation a few times over the last few days in order to give myself a chance to ponder it subconsciously, but I have probably only spent about an hour or two in total actively examining and thinking about the library, plus about an hour writing this review. Do you think the library should be accepted as a Boost library? --------------------------------------------------------------- I would say yes from what I have seen and understand about the library, but based on my relative lack of knowledge in the program domain and the relatively small amount of time I have spent looking at the library my vote should be weighted accordingly. What is your evaluation of the design? -------------------------------------- 1) I agree with others that it makes more sense to inject the metafunctions at the current scope rather at the absolute scope boost::tti. 2) I strongly think that "CREATE_METAFUNCTION_FOR" (or something similar) should be inserted into all of the macro names because otherwise they strike me as being misleading. If I were not familiar with this library and I saw the macro BOOST_TTI_HAS_TYPE(X) in someone else's code, I would be confused because the name of the macro makes it sound like it is asking if X has some type even though the result doesn't seem to be used. By contrast, if I saw the macro BOOST_TTI_CREATE_METAFUNCTION_FOR_HAS_TYPE(X), it would be immediately clear to me that the purpose of this macro is to create a metafunction. I say this based in part on my own experience. When I was learning how this library worked I started by skimming through the documentation to get a feel for what was going on, and the macro names confused me because I couldn't tell what they were actually doing. I did eventually figure this out when I read through the documentation more closely, but if they had names following the convention I am recommending then I would have immediately understood what they were doing. Although my proposed change would require additional typing (though unlikely not much, since I suspect most people are like me and just copy and paste from a template), I think that the benefit of improving the clarity would be well worth it. 3) I wonder if it would be better to instead of giving the metafunctions names such as has_type_X, it would make more sense to put them in their own namespace so they they would be referred to as for example has_type::X. This would save use from having to use macro pasting to compute the metafunction names, and would also have the advantage of addressing Lorenzo's concern that a double-underscore might inadvertently be put in a type name. However, I do not have enough experience here to get a full sense of the design implications of choosing this convention over the current convention. Another possibility is to hide the actual name of the metafunction by using a macro to access it. If my recommendation to insert "CREATE_METAFUNCTION_FOR" in all of the macro names is followed, it would free up the current macro names to be used to refer to the metafunction. That is, rather than code looking like BOOST_TTI_HAS_TYPE(X) boost::tti::has_type_X<T>::... it would look like BOOST_TTI_DECLARE_METAFUNCTION_FOR_HAS_TYPE(X) BOOST_TTI_HAS_TYPE(X,T)::... which would have the advantage of hiding the exact name and location of the metafunction as an implementation detail. To be clear, point #3 is just me pondering other possibilities to invite discussion, and should not be considered a necessary change that needs to be made. What is your evaluation of the implementation? ---------------------------------------------- I glanced at the code and it looked reasonable on the surface but I am not an expert in metaprogramming so I did not look at it closely. What is your evaluation of the documentation? --------------------------------------------- As others have pointed out, the documentation desperately needs more examples. In particular, unless I missed something I do not believe that there are any examples of actually using the library to accomplish something; all of the examples only show which macros should be used to create the metafunctions and what the resulting metafunction is called. In no example did I see an example where the metafunction was actually applied to accomplish something, such as disabling a function using SFINAE. I suspect that the author assumed that such in-depth examples would not be necessary since anyone reading the documentation would probably be very experienced with metaprogramming and so would already know what to do once they had the introspection metafunctions available to them, but not everyone thinking about using this library will be so experienced at metaprogramming (myself being one member of this ignorant group) and so some examples of how the library could be used to accomplish goals would be incredibly useful to us so that we could get a better sense of exactly how this library works and how we can leverage it to solve practical problems. What is your evaluation of the potential usefulness of the library? ------------------------------------------------------------------- It seems like this library could be incredibly useful to those who need introspection functionality, but since I do not generally do the type of metaprogramming that this library facilitates this should be considered as just my speculation. Did you try to use the library? With what compiler? Did you have any problem? ----------------------------------------------------------------------------- I played with it a little bit and compiled a random selection of the examples successfully. I used gcc version 4.2.1 on OSX. Cheers, Greg

3 7

[TTI] Review
by Lorenzo Caminiti 19 Jul '11

19 Jul '11

Review of Boost.TTI 2011-07-10 (Lorenzo Caminiti) ================================================= Do you think the library should be accepted as a Boost library? --------------------------------------------------------------- Yes, in my opinion Boost.TTI should be accepted as a Boost library. Key points are: 1) I would essentially found this library useful as is. 2) The library should not expand its macros into the boost::tti namespace (I give a few reasons and suggest alternatives below). 3) The library uses too many macros to provide essentially the same functionality (with minor variations). This is confusing and the library macro API should be simplified (I suggest a possible simplification below). My comments are all numbered and marked as follow: [MUST] If these comments are not addressed, I would no longer recommend to add this library into Boost. [WANT] I would like to see these comments addressed but I would still recommend to add this library into Boost even if these comments are not addressed. [NOTE] I do not feel strongly about these comments and the authors can ignore these comments if they wish to do so. What is your evaluation of the design? -------------------------------------- 1. [MUST] The library provides too many macros (with very similar functionality) which make the interface difficult to grasp. The authors should take some time to try to redesign and simply the library interface ideally reducing the number of macros. [WANT] I would reduce the macro API to the following 5 macros (no more, as I explain in the rest of the comments below): HAS_TYPE(has_mytype, mytype) HAS_TEMPLATE(has_mytpl, [template(...) {class|struct}] mytpl) HAS_MEMBER_VARIABLE(has_myvar, [static] myvar) HAS_MEMBER_FUNCTION(has_myfunc, [static] myfunc) MEMBER_TYPE(trait, name) 2. [MUST] Expanding the metafunctions within the boost::tti namespace presents a number of serious issues: a) If multiple part of the program (possibly independent libraries) use the TTI library to introspect the same name, the metafunction names will clash. b) The library macros can only be used at namespace scope. However, it should be possible to use the macros also at class scope so to define the introspection metafunctions as inner classes, etc (this is critical for example in my application for Boost.TTI where I use it to implement Boost.Contract and all Boost.Contract macros expand at class scope). The authors should address these issues. [WANT] To address these issues, I would suggest to simply define the metafunctions within the enclosing scope. It will be the user's responsibility to use the macros within the correct scope (namespace, class, etc). For example: template< class T > struct OurTemplateClass { BOOST_TTI_HAS_TYPE(has_mytype, _mytype) // also at class scope void f() { std::cout << has_mytype<T>::value << std::endl; } }; This should also allow to remove all the GEN/GEN_BASE macros. 3. [MUST] The library macros prefix the specified name with _ but this can create a symbol with double underscores __ which is reserved by C++ (e.g., HAS_TYPE(_my_type) creates a metafunction named boost::tti::has_type__my_type which is a reserved symbol). The authors should address this issue. [WANT] To address this issue (and also to reduce the number of macros eliminating the need for separate TRAIT macros), I would suggest to always ask the user to specify both the trait and the introspected name (not just the introspected name) and then use the trait to name the metafunction (as always, it is the user's responsibility to not use reserved names). For example: HAS_TYPE(has_mytype, _mytype) // generates metafunc has_my_type This should also allow to remove all the TRAIT macros. 4. [WANT] I really think that mixing () and <> parenthesis is confusing: HAS_TEMPLATE_CHECK_PARAMS(MoreParameters, (class) (class) (int) (short) (class) (template <class)(int> class InnerTemplate) // confusing :( (class) ) IMO, this would be more readable as the following: HAS_TEMPLATE_CHECK_PARAMS(MoreParameters, (class) (class) (int) (short) (class) (template( (class) (int) ) class InnerTemplate) // ok :) (class) ) 5. [NOTE] There is no real need to use another macro ..._CHECK_PARAMS because HAS_TEMPLATE can be reused. This would reduce the number of macros. For example, with template parameters: HAS_TEMPLATE( template( // gives the parameters (optional) (class) (class) (int) (short) (class) (template( (class) (int) ) class InnerTemplate) (class) ) struct MoreParameters // struct or class can be used here ) And the same macro without template parameters: HAS_TEMPLATE(MoreParameters) 6. [NOTE] The same macros can accept both pp-sequences and variadic pp-tuples (when variadic macros are supported). This eliminates the VM macros reducing the number of different macros in the library API. For example: HAS_TEMPLATE( template( class, class, int, short, class, template( class, int ) class InnerTemplate, // variadic commas class ) struct MoreParameters ) I know this uses template( class, int ) instead of template< class, int > but this way the syntaxes with and without variadics are unified and consistent (and more readable IMO). Alternatively, you can probably program the macro with variadic to be: HAS_TEMPLATE( template< // template< > here class, class, int, short, class, template< class, int > class InnerTemplate, // template< > here class > struct MoreParameters ) But still keep the following syntax without variadics: HAS_TEMPLATE( template( // template( ) here (class) (class) (int) (short) (class) (template( (class) (int) ) class InnerTemplate) // template( ) here (class) ) struct MoreParameters ) 7. [WANT] Can the authors explain why the inner template parameter name InnerTemplate is needed while all other template parameter names are not needed? Is it really needed? Why I cannot do: HAS_TEMPLATE( template( class, class, int, short, class, template( class, int ) class, // no name InnerTemplate class ) struct MoreParameters ) 8. [NOTE] There is no need to use a different set of macros for static because the keyword static can be used to have the pp detect this case. This will reduce the number of different macros. For example: HAS_STATIC_MEMBER_FUNCTION(has_static_f, f) Can be replaced by: HAS_MEMBER_FUNCTION(has_static_f, static f) 9. [WANT] Why can't we always use the composite function syntax R (C::*)(A0, A1, ...)? This is similar to the preferred notation for Boost.Function so if possible it should be used instead of the other notation. As I understand it, some compilers have troubles supporting the composite syntax. However, these compilers might not be able to support the TTI library all together. Unless there is evidence of compilers that can support TTI but not the composite function syntax, I think only the composite function notation should be provided. This should also allow to remove all the COMP macros. 10. [NOTE] I think "member variable" is a more accepted name that "member data"-- isn't it? If so, I'd rename MEMBER_DATA to MEMBER_VARIABLE. 11. [WANT] Is it possible to have some sort of composite syntax for member variables? I remember reading something about this for overloading the operator ->* to access member variables (as well as calling member functions) but I can't double check right now... can the authors look into this? For example: HAS_MEMBER_VARIABLE(has_number, number) has_number<T::short> // composite form for member variable? If there exists a composite form for member variables, I would like the generated metafunctions to use it instead of the plain form (so to be consistent with the MEMBER_FUNCTION macros-- see comment above). 12. [WANT] Are the metafunction MTFC macros really needed? The docs say they reduce compile-time (compared to using MPL placeholders) but no evidence is shown to support that... Extra macros complicate the library API so if they are provided for reducing compile-time there should be some benchmarking showing their benefits. If not, these macros should be removed. [NOTE] If these macros are shown to be beneficial, I'd rename them with a METAFUNC postfix because I find it more readable. For example: HAS_TYPE_METAFUNC HAS_MEMBER_FUNCTION_METAFUNC 13. [WANT] Are the nullary metafunctions really needed? The docs say they simplify the syntax but no side-by-side example comparing the syntax with and without the nullary type metafunctiosn is provided... Unless their benefit is clearly shown, the nullary metafunctions should be remove to simplify the library API. 14. [NOTE] I'd fully spell the header file names to improve readability and be consistent with the macro names (which are correctly fully spelled). For example, "member_function.hpp" instead of "mem_fun.hpp". 15. [NOTE] I'd rather use an actual name for the library instead of the cryptic acronym TTI (but I personally don't like the widely used MPL neither so maybe it's just me). Maybe "intro" (for introspection), or "mirror" (look at yourself), or "soul" (look into your soul), or "psycho" (look into your person) ;) would be better names... What is your evaluation of the implementation? ---------------------------------------------- 16. I did not look at the implementation. What is your evaluation of the documentation? --------------------------------------------- 17. [WANT] I'd add a "Motivating Example" in the Introduction section to very briefly illustrate the library functionality (probably right after the bullet list on the library functionalities). I had to go all the way into the Nested Types section to start seeing some code... (I was motivated just because I knew what the library does and I've used MPL_XXX macros with SFINAE before). 18. [NOTE] I don't think you need a space before "?" in English (see "Why the TTI Library ?", etc). 19. [WANT] Typo in "depending on how many parameters are bring passed". What is your evaluation of the potential usefulness of the library? ------------------------------------------------------------------- 20. [NOTE] The library is very useful as is. For example, I use a similar introspection technique in Boost.Contract as part of a mechanism to check if a base class has a virtual function that is being overridden so to automatically subcontract from such a base class function. 21. [WANT] I think the docs should add an annex with a complete list of all traits that would ideally be introspected even if they cannot actually be introspected. For example, a table could list all traits that would be good to introspect and then for each trait say "introspected by this library", or "cannot be introspected in C++ because...", etc. For example, Boost.Contract could use the ability to check if a function is public, protected, or private to simplify its macro syntax (because only public functions shall check class invariants). Possible traits for introspection I can think of are: is public, is protected, is private, is template, has these template parameters, is explicit, is inline, is extern, is static, is virtual, is const member, is volatile member, has these exception specifications (throw), any more? 22. [WANT] I'd add an annex to the docs to compare this library with other libraries (e.g., the "mirror" library?) that exist out there for introspection (i.e., some sort of literature review). I would also comment on possible C++ standard extensions or compiler specific support for introspection. Did you try to use the library? With what compiler? Did you have any problem? ----------------------------------------------------------------------------- 23. Yes, I compiled all the examples from the docs and played around with the library a bit more. I have used GCC 4.3.4 on CygWin and I had no issue. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? -------------------------------------------------------------------------------------------- 24. I'd say in between a quick reading and an in-depth study. I spent about 12 hours total reading the docs, trying the examples, and writing this review. Are you knowledgeable about the problem domain? ----------------------------------------------- 25. I have used SFINAE before to introspect if a class has a given inner class to implement subcontracting for Boost.Contract. Furthermore, I have used template metaprogramming in a number of occasions. Overall, I'd say that I am familiar with the problem domain but I am not an expert. --Lorenzo

11 56

[tti] review
by Gordon Woodhull 19 Jul '11

19 Jul '11

Hi Eddie, Joel, all, I apologize that this is a very short review. I believe the library should be accepted. The only interesting thing I have to add to the discussion is that a comparison with concepts should be made at least here, and perhaps in the documentation. This library provides functionality that will also be achievable using concepts, e.g. with Matt Calabrese's Generic library. I surmise that TTI presents a slightly messier low-level way of figuring out what a type is capable of than concepts and concept-based overloading. So I figure that as usual in such situations, TTI would be more powerful and more concise for checking individual things, and more confusing and verbose for checking the entire interface of a type. I think it's good to have both a low-level and an abstract way of doing things. TTI and Generic probably share some techniques and could learn from each other. A few superficial comments below. I agree with Jeff's suggestion that the matching metafunction should take a metafunction that defaults to is_same rather than always testing for type equality (and now I see why he was also suggesting that in the Type Traits Extension review :). Personally I would use the placeholder expressions and not the metafunction classes, because I find it clearer, unless I really thought it would help with performance. I think I would prefer a smaller set of more clever macros as Lorenzo was suggesting, but this wouldn't affect my decision to use the library unless there were two that did the same thing. I was alarmed (yes, alarmed! frightened!) by template <class)(int> class InnerTemplate but IIUC this would only happen without variadic macros, so I don't care. Otherwise it would probably crash my emacs. Cheers, Gordon

4 9

seeking review assistant for Conversion
by Gordon Woodhull 18 Jul '11

18 Jul '11

Hi All, I'm looking for someone to assist in managing the Conversion review at the end of August. This is a great way for people who are new to Boost to learn how the review process works. I especially recommend that prospective library authors try this experience in order to understand how consensus is forged during reviews. I believe that having multiple people managing the review will also help provide a more thorough report, keeping topics from being overlooked or discounted. Responsibilities: - read all reviews and discussion - participate in the review to ensure that discussion comes to some resolution - prepare notes which I will edit and submit as the final review report To be sure, I will not leave all the work to you! We'll either write separate reports and then merge them, or work together on the report more interactively. If the message volume is large, we may split up the topics. If you're interested, please write to me privately. Of course, any public discussion of the review process is also appreciated! Thanks, Gordon P.S. In addition to being a great experience and service to the community, this is something that might look good on your CV. :-)

1 0

Re: [boost] [contract] oldof failure not in N1962?
by Andrzej Krzemienski 18 Jul '11

18 Jul '11

> As far as I can see, N1962 does not say what to do in case of a failure > while evaluating and copying an oldof expression. For example, what shall > Contract Programming do if there is a memory error while taking a copy of > size() to later check the following postcondition? Hi Lorenzo, If we could agree that throwing an exception indicates that the system that hosts the program is in the state where it cannot execute our program anymore (lack of memory, threads), you could just let the thrown exception fly out of your function, as though it was the function that threw it. The function leaves objectsin the correct state: precondition was checked and held, function execution has not yet started. The downside of this solution is that it throws something that the caller might not haave expected. Another valid solution would be "if you cannot check the correctness, at least let the function work". That is, you swallow the exception and abandon checking the postcondition. On the other hand, one may want something opposite: do not let my program run unless you are absolutely sure all checks have succeeded. In this case you might want to signal it, but since it is neither precondition nor postcondition violation, perhaps you need an another callback: "on_inability_to_validate". Then anyone could do what they think is best: 1. Pass the exception 2. Skip postcondition 3. terminate Regards, &rzej

1 0

[type traits extension] test for const volatile& as return type
by Frédéric Bron 18 Jul '11

18 Jul '11

I am still working on the extension of the type trait library to operator detection. I was pretty happy having now all my tests passing with g++, in particular for all possible combinations of const, volatile and reference. I have now some troubles with the intel compiler. The following program reproduces a part of the internal implementation of the operator traits (with T defined below): #include <iostream> void g(T) { std::cout<<"g(T)\n"; } void g(...) { std::cout<<"g(...)\n"; } int main() { int i(0); g(i--); return 0; } This is what I get with g++ 4.6.0 for different values of T: - int&: g(...) - const int&: g(T) - volatile int&: g(...) - const volatile int&: g(...) This is what I get with intel 11.1: - int&: g(...) - const int&: g(T) - volatile int&: g(...) - const volatile int&: error: initial value of reference to const volatile must be an lvalue g++ is just fine for what I want to do but intel issues an error if T is "const volatile&" so that the program cannot compile and the g(...) is not chosen. Does anybody understands if this is the right behaviour according to the standard or if g++ is right chosing g(...)? Cheers, Frédéric

7 21

logging
by Jeff Graham 18 Jul '11

18 Jul '11

Hello, Does anyone know when we can expect a blessed logging facility to make it into an official release of boost? There seem to be 2 logging candidates: 1) one by Andrey Semashev (provisionally accepted 16 months ago in March 2010). 2)one by John Torjo that seems to have finished development 3 years ago at version 0.22.7 in Feb 2008. On John's blog it says it was up for review then. Then a post in May 2008 at http://boost.2283326.n4.nabble.com/what-s-up-with-the-logging-libraries- td2579613.html seems to indicate there will be another version with "quite a rewrite" and implying that may be the version to be reviewed. Can someone give any update on either logger, and if there is any plan for getting them into boost? Thanks

9 15

date_time: second_clock::local_time() results in free in a different heap, vs2008
by Mike Vasiljevs 18 Jul '11

18 Jul '11

When using *Visual Studio 2008, x64, windows 7 *boost release 1.45 *Debug DLL (linked against static C runtime, /MTd) loaded/unloaded by Host application using release C runtime (debug version not avaiable!). *calling "second_clock::local_time()", as in date_time examples Deallocation problems occur when dll is unloaded. Most likely release runtime tries to free debug heap block (as far as i can tell at first inspection). The problem also occurs by calling localtime on its own: time_t tnow; time(&tnow); struct tm *time_local= localtime(&tnow); // use time_local... the following code, where "tm" is stored in local data segment, so no problem occurs, unfortunately highly unportable code: static __time64_t tnow; _time64(&tnow); static struct tm time_local; _localtime64_s(&time_local, &tnow); // use time_local... greetings mike

1 0

[mpi] Unresolved external
by Nils van der Struis 18 Jul '11

18 Jul '11

Hi all, I installed the boostpro libraries version 1.46.1. Then I got the openmpi 1.4.3 sources and successfully built them with cmake/VS2008. Now I'm trying to run some example code: #include <boost/mpi.hpp> #include <iostream> #include <string> #include <boost/serialization/string.hpp> namespace mpi = boost::mpi; int main(int argc, char* argv[]) { mpi::environment env(argc, argv); mpi::communicator world; if (world.rank() == 0) { world.send(1, 0, std::string("Hello")); std::string msg; world.recv(1, 1, msg); std::cout << msg << "!" << std::endl; } else { std::string msg; world.recv(0, 0, msg); std::cout << msg << ", "; std::cout.flush(); world.send(0, 1, std::string("world")); } return 0; } This keeps giving me the linker error below. My dependencies are libmpi.lib, libmpi_cxx.lib, boost_mpi-vc90-mt-1_46_1.lib, libboost_mpi-vc90-mt-1_46_1.lib. I also tried with the pre built openmpi version 1.5.3 library files, this didn't help. Error 1 error LNK2019: unresolved external symbol "public: __thiscall boost::mpi::communicator::operator struct ompi_communicator_t *(void)const " (??Bcommunicator@mpi@boost@@QBEPAUompi_communicator_t@@XZ) referenced in function "protected: void __thiscall boost::mpi::communicator::send_impl<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > >(int,int,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,struct boost::mpl::bool_<0>)const " (??$send_impl@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@communicator@mpi@boost@@IBEXHHABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@U?$bool_@$0A@@mpl@2@@Z) MPITest.obj MPITest I suppose this is caused by the boost.org libraries?! Could somebody help me out here?Thanks

1 0

[local] Review request
by Lorenzo Caminiti 18 Jul '11

18 Jul '11

Hello all, I happy to announce that I have released Boost.Local 0.2.0 incorporating the many valuable suggestions that I have received from this mailing list. I would like to request to add Boost.Local to the review schedule and for any volunteer to be the review manager. Thank you! Boost.Local supports local functions, local blocks, and local exits for C++. For example: #include <boost/local/function.hpp> #include <boost/local/block.hpp> #include <boost/local/exit.hpp> #include <algorithm> #include <iostream> #include <cassert> int main() { double sum = 0.0; int factor = 10; void BOOST_LOCAL_FUNCTION_PARAMS(double num, const bind factor, bind& sum) { sum += factor * num; std::cout << "Summed: " << sum << std::endl; } BOOST_LOCAL_FUNCTION_NAME(add) add(100.0); size_t size = 2; double* nums = new double[size]; BOOST_LOCAL_EXIT(const bind& size, bind nums) { if (size && nums) delete[] nums; std::cout << "Freed array: " << nums << std::endl; } BOOST_LOCAL_EXIT_END nums[0] = 90.5; nums[1] = 7.0; std::for_each(nums, nums + size, add); // `add` as template parameter BOOST_LOCAL_BLOCK(const bind& sum) { assert(sum == 1975.0); // so far `sum` is 10*100+10*90.5+10*7=1975 std::cout << "Asserted summation: " << sum << std::endl; } BOOST_LOCAL_BLOCK_END return 0; } Documentation: http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/index.html Source code: http://svn.boost.org/svn/boost/sandbox/local/ Release Notes for Version 0.2.0 (2011-05-14) 1. Replaced parenthesized syntax with variadic and sequencing macro syntaxes. 2. Profiled library performances against other approaches. 3. Replaced virtual functor trick with casting functor trick (for smaller run-time). 4. Optimized library run-time (rearranging code and not using casting functor trick on compilers that accept local classes as template parameters). 5. Added BOOST_LOCAL_FUNCTION_NAME(inline ...) and BOOST_LOCAL_FUNCTION_NAME(recursive ...). 6. Added BOOST_LOCAL_TYPEOF. 7. Added bind(type) to specify bind type explicitly (skipping Boost.Typeof type deduction). 8. Removed boost::local::function (use boost::function instead). 9. Added boost::local::function::overload to overload local functions (and functors in general). 10. Implemented support for nesting local functions, blocks, and exits into one another. Boost.Local was used by Gregory Crosswhite in one of his project: https://github.com/gcross/CodeSearch -- Lorenzo

6 28

Itanium floating point and negative NaN and changesign function
by Paul A. Bristow 18 Jul '11

18 Jul '11

Antony Polukhin has done some great work on lexical_cast to make it work consistently with nonfinite numbers (infinity and NaNs) without stringstream which required use of a globale C99 facet. // Now try some 'round-tripping', 'reading' "inf" double x = boost::lexical_cast<double>("inf"); // and check we get a floating-point infinity. BOOST_ASSERT(x == std::numeric_limits<double>::infinity()); now does what most people would expect. All lexical_cast tests now pass on the popular platforms - except Itanium platform when parsing -NaN, so lexical_cast<std::basic_string<CharType> > (changesign)(std::numeric_limits<ValType>::quiet_NaN()) ) != -nan \boost-trunk\libs\math\test\test_lexical_cast.cpp I don't access to this platform, or indeed any knowledge of it. The test_sign.cpp which exercises changesign appears to work on this platform. BOOST_CHECK((boost::math::signbit)((boost::math::changesign)(a)) != 0); Can anyone expert on the platform shed any light on this? My reading of some docs only mentions NaN, and never negative ones. Is there anything special about the treatment of negative NaNs? Paul (There are those who believe that negative NaNs should not exist, but I have taken the other view that it is more consistent to permit them, even if their meaning may be uncertain - the *signbit does exist* on most platforms, and so is part of the 'payload' of some 7 (?) bits that the NaN pattern carries. There are similar differences of view on signed zero, but most platforms permit negative zero, mainly because there is a signbit, even for a value of zero.) --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

1 0

updating history in beta site
by Vladimir Prus 18 Jul '11

18 Jul '11

I've tried to add some item to 1.47 history in the beta site. I've edited .qbk file, and then went to site_tools directory. According to: http://www.boost.org/development/website_updating.html I am supposed to run 'site-tools.py update' there, but there's no such script, and running 'update.py' results in an error. On the 'live' site, I was able to do that, and in fact, I see new content on: http://www.boost.org/users/history/version_1_47_0.html So, it looks like this functionality is not working just in beta site? Thanks, -- Vladimir Prus CodeSourcery / Mentor Graphics +7 (812) 677-68-40

2 3

[locale] Documentation correction
by Beman Dawes 18 Jul '11

18 Jul '11

The last bullet item on page libs/locale/doc/html/index.html says: Many standard libraries provide only the C and POSIX locales, thus GCC supports localization only under Linux. On all other platforms, attempting to create locales other than "C" or "POSIX" would fail. Actually, locale("") works on most platforms, including PC-BSD and Open Solaris, so needs to be added to the above list of locales that do work. Look at the trunk filesystem regression first test, "locale_info", and click on the Pass link to see the output. locale("") is working pretty much across the board, even on the Darwin tests. Mac OS X is of particular interest because by default locale("") does fall, and the Apple folks have said in the past that they won't fix it. It fails on my Mac mini in the default configuration. Presumably the Darwin regression test machine has something beyond the default configuration. Also, would it be possible to use locales from the Apache library? See http://stdcxx.apache.org/doc/stdlibref/locale.html#Table%C2%A021 --Beman

3 3

[trac] trouble uploading a patch to a ticket
by Jeffrey Lee Hellrung, Jr. 18 Jul '11

18 Jul '11

I'm trying to upload a patch to https://svn.boost.org/trac/boost/ticket/5697 but every time I try for this particular patch I get --------------- Trac Error Submission rejected as potential spam (Akismet says content is spam, External links in post found) --------------- Sometimes I get a captcha thingy, and I enter in the word-things and hit "enter" (cause there's no "Submit" button or something like that), and it just goes to a page that says "Error". I have uploaded other patches to this ticket, so...what gives? Okay, yes, there's some http:// link in the patch, but it's in a comment and I'm not adding it (it's already in the file-to-be-patched). Plus, I don't think it goes anywhere, I tried :/ And I don't see why that would be grounds to reject an attachment. And why the captcha thing doesn't work. For reference, I have attached the patch in this email (and I've also sent it to Dave personally, so I'm not worried (yet) about it getting forgotten). - Jeff

2 2

Boost with Clang via MinGW-w64
by Joshua Boyce 17 Jul '11

17 Jul '11

Hey all, Ruben over at the MinGW-w64 project has started providing a Clang toolchain built upon MinGW-w64. http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-July/016005.html I just tried compiling Boost trunk r72754 with it, and figured I'd post the output here so work can commence bringing it in line with GCC via MinGW-w64. 90% of the errors seem to be a result of a 'call to deleted constructor' which seems to be caused by the shared_ptr library (or its usage)... Then the remaining 5% seem to be quite similar in nature, so it doesn't look like stuff will be too horrible to fix, but I don't know enough about the implementation of shared_ptr to fix it at the moment. One other thing to take into consideration will be the lack of a Clang Windows toolset. Currently when you set your toolset to Clang under MinGW, Boost treats it as Clang-Linux. I'm not sure what exactly that will affect... The script I used and the resulting output is available here: http://www.raptorfactor.com/code/Boost-Clang-MinGW-Output-20110708a.zip Thanks..

4 5

[context] Floating Point Exception
by Daniel Larimer 17 Jul '11

17 Jul '11

Attempting to use the latest Boost.Context implementation on Mac OS X and everything was going fine except for a few small issues: 1) fcontext_x86_64_sysv_macho_gas.S fails to compile because: fcontext_x86_64_sysv_macho_gas.S:50:Unknown pseudo-op: .type fcontext_x86_64_sysv_macho_gas.S:50:Rest of line ignored. 1st junk character valued 95 (_). fcontext_x86_64_sysv_macho_gas.S:51:Alignment too large: 15. assumed. 2) I can fix those errors by commenting out the .type line and changing to .balign 16 or .align 8 3) Compiled with: gcc-4.5.0 -o fcontext_x86_64_sysv_macho_gas.S.o -c fcontext_x86_64_sysv_macho_gas.S 4) protected_stack() cannot map /dev/zero - solutions were to mkfile -n 1m /tmp/zero and then open that - use ::mmap( 0, size__, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0); instead of specifying any file. After getting all of those things "working" I attempted to print out a floating point number and it dies deep inside __ntoa(), but I could get it to crash by doing any floating point operations from within the contexts stack. I noticed that none of the examples test for floating point ops. You might want to include that as part of your standard testing. Dan

2 5

[Pool] Attention all Pool users....
by John Maddock 17 Jul '11

17 Jul '11

Folks, I'm planning on merging the all new and shiny version of Boost.Pool in the sandbox under https://svn.boost.org/svn/boost/sandbox/guild/pool/ into Trunk pretty soon unless anyone objects. There are a lot of bug fixes in this version, plus updated docs (see https://svn.boost.org/svn/boost/sandbox/guild/pool/libs/pool/doc/pool.pdf) Please let me know if you spot any issues, or if there's something that needs addressing that hasn't been (no promises on that one though!). Regards, John.

2 2