February 2010 - Boost - lists.boost.org

[geometry] Documentation prototype for review
by Mateusz Loskot 22 Feb '10

22 Feb '10

Hi, I'm working on documentation of Boost Geometry based on Quickbook and I've prepared a prototype: http://mateusz.loskot.net/tmp/ggl/qbk/ What I'm doing is manually porting the content from Doxygen-based (http://geometrylibrary.geodan.nl/) plus restructuring, reformatting and completing it with missing details. I'd like to ask everyone who is interested in Boost Geometry library for comments, impressions and suggestions of improvements. Note, nodes marked with (?) are not finished and empty, but included to give impression about the overall structure. I'd be especially interested comments about the structure, if it's accessible to new users and usable for advanced users at the same time. The Reference is one of the most important section I'd like to master, so please share your comments on the form and completeness of the concepts specification, for example: http://mateusz.loskot.net/tmp/ggl/qbk/geometry/reference/geometries/concept… types description, for example: http://mateusz.loskot.net/tmp/ggl/qbk/geometry/reference/geometries/types/p… and functions description: http://mateusz.loskot.net/tmp/ggl/qbk/geometry/reference/arithmetic/add_poi… Thanks in advance for your feedback. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

3 4

[build] summary at end
by Vladimir Prus 22 Feb '10

22 Feb '10

FYI, Previously, I've made the build process to print information as to where the headers and libraries are to be found. However, that was printed at the start of the build, and many used missed that. I've now checked in a patch to print the message at the end of the build (if there are no errors). You need trunk bjam for this to work. Older bjam will not print that message but otherwise work. The sample wording is as follows: The Boost C++ Libraries were successfully built! The following directory should be added to compiler include paths: /home/ghost/Work/Boost/boost-svn The following directory should be added to linker library paths: /home/ghost/Work/Boost/boost-svn/stage/lib Comments are appreciated, -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build: http://boost.org/boost-build2

1 0

[exception][msvc-7.1] regression and use of member template friends
by JOAQUIN M. LOPEZ MUÑOZ 22 Feb '10

22 Feb '10

Hi, In its current state in trunk, boost/exception/exception.hpp is generating regressions with MSVC 7.1 as shown in: http://tinyurl.com/yckdxrc The problem has to do with some (correct) member template friends declarations that MSVC 7.1 is not able to handle. Lines 222 and ff. of boost/exception/exception.hpp read: #if defined(__MWERKS__) && __MWERKS__<=0x3207 public: #else private: template <class E> friend E const & exception_detail::set_info( E const &, throw_function const & ); [...] To solve the problem the nicest solution would be to replace this by: #if defined(BOOST_NO_MEMBER_TEMPLATE_FRIENDS) public: #else private: template <class E> friend E const & exception_detail::set_info( E const &, throw_function const & ); [...] But exception.hpp, presumably to speed up compilation times, does not include any other header, so seems like including <boost/config.hpp> just to get this macro could be unacceptable. If this is the case, I suggest that the code be changed so as to simply go public and omit the member template friend declarations altogether. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Status of Boost.Polygon
by Anders Dalvander 22 Feb '10

22 Feb '10

According to the announcement (http://comments.gmane.org/gmane.comp.lib.boost.announce/240) Boost.Polygon library was accepted into Boost on 5 November, provided some of the most critical concerns are addressed first. I cannot find it in the 1.42 release of Boost. When can I expect it to exist in a Boost release? Regards, Anders Dalvander

2 1

[getting started] mention boost.build options for abi tages
by Vladimir Prus 21 Feb '10

21 Feb '10

Often, users are asking how they can get "boost_whatever... mt-s ...", or something like that. The attached patch augments with ABI tags table in the getting started guide with corresponding Boost.Build options. Note that I have more suggested changed (in particular to say that naming on Unix is now different), but wanted to split into individual patches for easier review. I've also dropped stlport iostream option, since it's deprecated and in my understanding nobody uses it any longer. OK to commit? Thanks, -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build: http://boost.org/boost-build2

2 1

sp_convertible<> on MSVC10
by Zachary Turner 20 Feb '10

20 Feb '10

I'm using 1.42, not trunk, so I don't know if this has already been addressed, but sp_convertible fails with some errors for me. 2>C:\dev\boost\1.42.0\boost/smart_ptr/detail/sp_convertible.hpp(49): error C2070: 'void': illegal sizeof operand 2> C:\dev\boost\1.42.0\boost/smart_ptr/detail/sp_convertible.hpp(68) : see reference to class template instantiation 'boost::detail::sp_convertible<Y,T>' being compiled 2> with 2> [ 2> Y=error_info_tag_t, 2> T=boost::exception_detail::error_info_base 2> ] 2> C:\dev\boost\1.42.0\boost/exception/info.hpp(159) : see reference to class template instantiation 'boost::detail::sp_enable_if_convertible<Y,T>' being compiled 2> with 2> [ 2> Y=error_info_tag_t, 2> T=boost::exception_detail::error_info_base 2> ] 2> C:\dev\boost\1.42.0\boost/exception/detail/exception_ptr.hpp(170) : see reference to function template instantiation 'const E &boost::operator <<<boost::unknown_exception,boost::tag_original_exception_type,const type_info*>(const E &,const boost::error_info<Tag,T> &)' being compiled 2> with 2> [ 2> E=boost::unknown_exception, 2> Tag=boost::tag_original_exception_type, 2> T=const type_info * 2> ] 2> C:\dev\boost\1.42.0\boost/exception/detail/exception_ptr.hpp(137) : see reference to function template instantiation 'void boost::unknown_exception::add_original_type<std::exception>(const E &)' being compiled 2> with 2> [ 2> E=std::exception 2> ] 2>C:\dev\boost\1.42.0\boost/exception/info.hpp(159): error C2664: 'boost::exception_detail::error_info_container::set' : cannot convert parameter 1 from 'boost::shared_ptr<T>' to 'const boost::shared_ptr<T> &' 2> with 2> [ 2> T=error_info_tag_t 2> ] 2> and 2> [ 2> T=boost::exception_detail::error_info_base 2> ] 2> Reason: cannot convert from 'boost::shared_ptr<T>' to 'const boost::shared_ptr<T>' 2> with 2> [ 2> T=error_info_tag_t 2> ] 2> and 2> [ 2> T=boost::exception_detail::error_info_base 2> ] 2> No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called The line it's pointing to is this: enum _vt { value = sizeof( f( static_cast<Y*>(0) ) ) == sizeof(yes) }; and in particular it's having a problem determining the return type of f( static_cast<Y*>(0) ). It's thinking that whatever overload it's finding for f() here returns type void. Which doesn't make sense neither one returns void. Any ideas? Zach

5 8

Re: [boost] [contract] Contract Programming Library
by Andrzej Krzemienski 20 Feb '10

20 Feb '10

> > The documentation lists the following sequence for executing a constructor: > > > > 1. Initialize member variables via the constructor member > > initialization list (if such a list is specified). > > 2. Check preconditions (but not invariants). > > 3. Execute constructor body. > > 4. Check invariants. > > 5. Check postconditions. > > > > I believe, one of the reasons for validating arguments of a constuctor > > is to not allow the incorrect values to initialize objest's > > sub-objects (members). I believe the sequence of the first two items > > should be inverse. Am I wrong? > The library follows Eiffel semantics for constructor which is {Default > AND Pre}Body{Post AND Inv} where Default is default initialization of > members (similar to C++ member initialization list). That said, it > would be difficult to implement a different semantics (like the one > you suggest) in C++ because of the lack of delegating constructors. The sole fact that other language implements it this way is not sufficient an argument. I can think of the situation when "Eiffel order" may cause damage that the inverse order might have prevented: Type::Type( int & counter ) precondition{ counter < MAX; } : handle( irreversibleChange(int--) ) { ; } Suppose the constructor of Type is called, and the value of counter is MAX. This value is invalid, but by the time the precondition is checked, the irreversibleChange is executed, and the value of counter is reduced, so the assertion concludes that everything is fine. Now, the argument that it is difficult to implement is convincing; it may be that it is impossible at all. But I would call not having the {Pre->Init} order a limitation of the library. Let me be clear: one tiny limitation in the great library, because out of many attempts to provide contract programming to C++ I have seen, this is the only one that really looks good. Regards, &rzej

2 1

[mpi] Documentation patch
by Number Cruncher 19 Feb '10

19 Feb '10

Attached is a patch (against 1.42) to fix a couple of minor errors with the Doxygen documentation for some headers in the boost/mpi library. The errors relate to Doxygen usage, not content. Simon.

1 0

Re: [boost] [contract] Contract Programming Library
by Andrzej Krzemienski 19 Feb '10

19 Feb '10

Hi, two other questions that came to my mind, regarding the library design. (1) Sometimes the assertions execute longer than the function itself. For example: iterator find( iterator begin, iterator end, value v ) precondition { is_sorted( begin, end ); } { return find_sorted( begin, end, v ); } find_sorted has logarithmic complexity, whereas is_sorted has linear one. If I use function find like this: sort( begin, end ); process( find(begin, end, A) ); // call is_sorted process( find(begin, end, B) ); // call is_sorted process( find(begin, end, C) ); // call is_sorted is_sorted is called many a time. Even if I am in debugging mode but use a medium size range, the performance can kill me. I would like to disable checking of this assertion, but at the same time there is no reason to disable others. Would you consider providing a way to selectively disable asserts? some assertion level? (2). Usually public member functions would be used to express DbC assertions. Do you disable assertions in public functions that are called only to evaluate other assertions in order to avoid recursive calls? Regards, &rzej

2 1

Re: [boost] [contract] Contract Programming Library
by Andrzej Krzemienski 19 Feb '10

19 Feb '10

> I am thinking to submit a library for Contract Programming (a.k.a. > Design By Contract (TM) ) for C++. > I have drafted some of the library documentation in Boost-like format: > http://dbcpp.sourceforge.net/boost/libs/contract/doc/html/ > Comments? Hi, I have a couple of questions/suggestions regarding the documentation of the library. (1) Does it execute postconditions when the function body ends with a thrown exception? Obviously it shouldn't. I can see one lie saying It is possible to describe the function postconditions. These are logical conditions that programmers expect to be true when the function has ended **normally**. So I guess it doesn't, but I believe this fact deserves some more room in the documentation, like "public member function is not required to satisfy the postcondition if it ends with exception." (2) Obviously, the expressions in assertions shouldn't change the behaviour of the program when executed. This requirement is stronger than having no side effects. You protect the object itself by allowing only const member functions. Are the function arguments (those passed by mutable reference also protected?). Is it allowed/recommended to refer to global or static data in the assertions? If you are using clever macros, perhaps there is a way to block the references to these. In C++0x lambdas you can specify a list of objects you want to refer to: [this, &max_value, &count, &cache]( int fact1, int fact2 ) {...} perhaps there is a way to do it with current C++ macros. (3) In a similar manner, what happens if one of postcondition's assertions throws an exception? I have troubles answering this question myself (I do not know what should ideally happen), but whatever your answer is, I believe it should be clearly documented. (Note that this is not only the issue of DbC; simple C-assertions also leave this question unanswered). (4) Do the assertions have access to objet's private/protected interfaces? (I believe they shouldn't). (5) Does the library allow defining preand postconditions for "free" functions or static member functions? The examples are so focused on objects/classes that I cannot tell the answer. (6) Similarly, does the library allow defining block invariants? (7) The documentation lists the following sequence for executing a constructor: 1. Initialize member variables via the constructor member initialization list (if such a list is specified). 2. Check preconditions (but not invariants). 3. Execute constructor body. 4. Check invariants. 5. Check postconditions. I believe, one of the reasons for validating arguments of a constuctor is to not allow the incorrect values to initialize objest's sub-objects (members). I believe the sequence of the first two items should be inverse. Am I wrong? (8) Since library usses macros that make the syntax a bit difficult to read/parse, perhaps it would be useful to augment every example with another one that would say how the same thing would be acomplished with fictitious "DbC C++" syntax if we had one. This was done for Boost Interface library (under construction, http://www.cdiggins.com/bil.html) and I think it helps a lot. Regards, &rzej

2 1