- Boost - lists.boost.org

GGL Review
by Michael Caisse 22 Nov '09

22 Nov '09

Let me start by apologizing for the short amount of time I was able to put into this review. I have spent about 5 hours reviewing the documentation, looking at some of the source and trying a few examples of mine own. Clearly an enormous amount of work has gone into this library and I feel like it deserves more of my time than I am able to give right now. Nevertheless, I thought it important to review the most critical portions of the library. Based on the library review announcement, GGL is promoting key concepts for describing geometries. Some algorithms are provided. As such, it seems to me that the interfaces and concepts are key and is what I have devoted my time to looking at. And now for the executive summary spoiler: I believe that this library offers well defined concepts for geometry. The design is sound and the extension capabilities appear to be reasonable based on my short trial. I found the interface and concepts to the library usable and therefore recommend acceptance of this library within Boost. That was a wordy way of saying it has a Yes vote from me. ===== What is your evaluation of the design? ===== I am quite pleased with the use of tag-dispatching and strategies. I was happy to see this approach taken and by looking at the documentation and source code it seems sound. I believe this approach offers the greatest latitude for a generic library. ===== What is your evaluation of the implementation? ===== Very clean. Every file I opened and took a look at was readable and easy to follow. The directory structure is obvious and made exploring the library an easy feat. I would like to see ggl::exception inherit from boost::exception instead of std::exception. I was unable to spend time evaluating the implementations of algorithms in any detail. ===== What is your evaluation of the documentation? ===== I found the "Design rationale" section well written and quite applicable to the problem at hand. According to the review announcement: "GGL defines concepts for geometries and implements some algorithms on such geometries." As such, the concepts are paramount to the review and the design rationale provides more than tidbits about the underlying structure of the library. It provides the requirements for compliance to the concepts promoted by the library. Adding generality step-by-step while using a basic concept such as distance allows the reader to follow the logic behind the tag-dispatching and quickly see how extensions and modifications could be incorporated. I am not typically a fan of Doxygen generated docs for generic libraries. Much has already been said about this by other reviewers; however, I did not find the documentation as lacking as some have described. I think the current state is adequate for using the library and did not encounter any problems using the docs while writing my own small tests. I can see that some of the descriptions are a little terse and if I was trying to implement something more complex I might have questions. A few specific comments on the docs......................... design.html section "Return type" typename Strategy::return_type distance <http://geometrylibrary.geodan.nl/formal%5Freview/group__distance.html#g22a6…>( G1 const& G1 , G2 const& G2 , S const& strategy) -- should be -- typename Strategy::return_type distance <http://geometrylibrary.geodan.nl/formal%5Freview/group__distance.html#g22a6…>( G1 const& g1 , G2 const& g2 , S const& strategy) and inline typename distance_result<G1, G2>::type distance <http://geometrylibrary.geodan.nl/formal%5Freview/group__distance.html#g22a6…>(G1 const& G1, G2 const& G2) -- should be -- inline typename distance_result<G1, G2>::type distance <http://geometrylibrary.geodan.nl/formal%5Freview/group__distance.html#g22a6…>(G1 const& g1, G2 const& g2) design.html section "Multi" The comments at first confused me. They are correct but by the end of reading a whole page on type traits my eyes were getting tired. Perhaps something like this for clarification: struct distance <http://geometrylibrary.geodan.nl/formal%5Freview/group__distance.html#g22a6…> < GeometryTag1, GeometryTag2, G1, G2, Strategy, false, // G1 is_multi result true // G2 is_multi result > ===== What is your evaluation of the potential usefulness of the library? ===== I think a library implementing generic geometry concepts is extremely useful in many domains. I think this library provides usable concepts for a geometry library with a design and implementation that allows extension to user types and algorithms. ===== Did you try to use the library? With what compiler? Did you have any problems? ===== I found that the examples did not compile using the normal method. I was using the boost_1_41_0 release. cd libs/ggl/example bjam release Changing the Jamfile include requirement to <include>../../.. makes it work fine. I compiled with VC8, gcc-4.3.3, and gcc-4.3.2 m68k-elf cross-compile. The cross-compiler is for a device without FPU and I will continue looking at this library for integer only calculations next week. gcc-4.3.3 spat a bunch of warnings about "use of C99 long long integer constant" from boost/integer_traits.hpp. Not a GGL issue. The 03_polygon_example.cpp tickles some uninitialized warnings with gcc-4.3.3 that originate from intersection.hpp. ===== How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? ===== I spent about 5 hours reviewing the library with a careful read of the Main Page, Design rationale, Spatial set-theoretic operations, and Relation to Boost and std libraries. I also looked over the source code, examples and implemented my own small test cases. ===== Are you knowledgeable about the problem domain? ===== Somewhat. I spent almost 10-years working with GDS-II and other semiconductor mask formats. I worked on transforming data at the "server" level and writing microcode for very accurate and high speed rendering on custom hardware. I have about a year experience working with GIS data sets. I can appreciate the integer versus floating point discussion that has been going on. Different domains have very different requirements. Those who promote the idea that integer only is pointless or floating point is THE solution haven't worked in the other domains. One is not more important than the other; however, concepts described by a library should be able to adapt to either. This library obviously performs in the FP realms and I have no problem envisioning how to adapt types and algorithms to work with it for integer only problems. I hope to explore this domain further in the coming weeks with GGL. Thank you GGL team for your hard work. Thank you Hartmut for your willingness to manage this review. Best regards - michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

2 1

[serialization][1.41] export.hpp should #include extended_type_info.hpp
by Marco Jez 22 Nov '09

22 Nov '09

Hi everyone. Header file <boost/serialization/export.hpp> has a dependency to <boost/serialization/extended_type_info.hpp>, because it defines the macro BOOST_CLASS_EXPORT_KEY2 which specializes the class template guid_defined<> which, in turn, is defined in extended_type_info.hpp. Perhaps export.hpp should #include extended_type_info.hpp? Regards, Marco

1 0

[build] Performance tests
by vicente.botet 22 Nov '09

22 Nov '09

Hi, I would like to execute some performance test with Boost.Build. Is there a way to force the execution of the tests without building the executables? Are there some examples of performance tests for some Boost libraries? Thanks, Vicente _____________________ Vicente Juan Botet Escribá

3 6

[property_tree]bug in serialization of json, when it process UTF8 encoding string with std::string.
by Qiu Yuzhou 22 Nov '09

22 Nov '09

Hi, Because char is singed in msvc, the ptree serialization code will truncate the value when it greater than 127. Patch for boost_1_41_0\boost\property_tree\detail\json_parser_write.hpp: 21a22,33 > template<typename Ch> > unsigned long to_unsigned( Ch ch ) > { > return static_cast<unsigned long>( ch ); > } > template<> > inline unsigned long to_unsigned<char>( char ch ) > { > unsigned char* p = reinterpret_cast<unsigned char*>( &ch ); > return *p; > } > 46c58 < unsigned long u = (std::min)(static_cast<unsigned long>(*b), 0xFFFFul); --- > unsigned long u = (std::min)(to_unsigned<Ch>(*b), 0xFFFFul); Patch for boost_1_41_0\boost\property_tree\detail\json_parser_read.hpp 141a142 > template<typename CH_T> 148,149c149,150 < u = (std::min)(u, static_cast<unsigned long>((std::numeric_limits<Ch>::max)())); < c.string += Ch(u); --- > u = (std::min)(u, static_cast<unsigned long>((std::numeric_limits<CH_T>::max)())); > c.string += CH_T(u); 152a154,165 > template<> > struct a_unicode<char> > { > context &c; > a_unicode(context &c): c(c) { } > void operator()(unsigned long u) const > { > u = (std::min)(u, static_cast<unsigned long>((std::numeric_limits<unsigned char>::max)())); > c.string += char(u); > } > }; > 250c263 < | 'u' >> uint_parser<unsigned long, 16, 4, 4>()[typename Context::a_unicode(self.c)] --- > | 'u' >> uint_parser<unsigned long, 16, 4, 4>()[typename Context::a_unicode<Context::Ch>(self.c)] Best, Qiu Yuzhou

1 0

ACCU 2010 - Boost folks there ?
by Alp Mestan 22 Nov '09

22 Nov '09

Hi, I'm currently wondering whether I'll go to ACCU 2010 or not. But I just would like to know if any Boost folk will be there, and if there will be some talk or whatever, about Boost ? Thanks. -- Alp Mestan http://alpmestan.wordpress.com/ http://alp.developpez.com/

2 3

[fiber] version 0.1.1 available (incl. docs)
by Oliver Kowalke 21 Nov '09

21 Nov '09

I've uploaded a new version of boost.fiber - it contains the docs as requested. http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Concu… kind regards, Oliver

1 0

Boost.Python question about converters and make_getter
by John Wiegley 21 Nov '09

21 Nov '09

I have a converter registered for a boost::optional<amount_t> object. If I use it as follows, my code works just fine: boost::optional<amount_t> py_price(annotation_t& ann) { return ann.price; } class_< annotation_t > ("Annotation") .add_property("price", py_price) ; However, if I dispense with the intermediary and use make_getter, I get an exception stating that no conversion exists for optional<amount_t>: class_< annotation_t > ("Annotation") .add_property("price", make_getter(&annotation_t::price)) ; The attached file demonstrates this bug using Boost 1.40 and Python 2.6.1. I'm running it on OS X 10.6.2 with g++ 4.4.2. My steps were: g++-mp-4.4 -I/usr/include/python2.6 -I/usr/local/include/boost-1_40 -o bug.so bug.cc -L/usr/local/lib -lboost_python-xgcc44-d-1_40 -lpython -shared $ python >>> import bug >>> x = bug.Annotation() >>> x.price2 # This works just fine >>> x.price # This causes an abort() due to terminate() John

2 2

Re: [boost] Core libraries should separated from experimental libraries
by Tom Brinkman 21 Nov '09

21 Nov '09

C++ is an for expert system and "boost" is a place for the most advanced users of c++ to share experiences. If you don't agree with that basic statement, we don't have much to talk about. I know that calling some one "average" at a particular skill is a loaded statement. It implies a sense of superiority that is uncomfortable to some. However, "average" only comes with a great deal of practice and hard work. Most of us, only ever become average at a handful of things in our life, if we are lucky. Actually, calling someone average at something is highly complimentary. If you are uncomfortable with the term "average", take your sensibilities elsewhere. No back to the issue at hand: Boost needs to separate out the core libraries from the experimental libraries. The libraries within boost that have stable api's should separated from those that don't. Boost needs a system similar to debains. People need to know what parts of boost are backwards compatible. At the same time, we need to allow for complete interface changes to the experimental libraries, to encourage and nurture those libraries that are still in active development, but still very usable. I don't see this as a difficult issue to comprehend at all. Its quite surprising to me that it gets so much push back. This is the single reason why so many people are so resistant to using boost. Hopefully somebody will take up this issue, as I fear without it, boost will become trivialized after the next release of the c++ standard. I'm just saying what people are thinking in the trenches. >From my perspective, as the former review wizard, and long time follower of boost, the current situation of having a dozen libraries in the queue, and probably a dozen more waiting behind the scenes is unacceptable. If we distributed those libraries currently waiting to be reviewed as part of the non-stable part of boost, we could be much more liberal about what libraries get accepted. The important review would then be determining when a library is going to be switched from the non-stable to the stable portion of boost. Tom Brinkman

2 1

[ANN] Elements of Programming study group
by David Abrahams 21 Nov '09

21 Nov '09

FYI, over at http://cpp-next.com we're running a study group on the new book by Alex Stepanov & Paul McJones that might be of interest to generic library authors and users.

2 1

[Ticket #3548] Comeau C++ reports global scope has no int64_t
by Mateusz Loskot 21 Nov '09

21 Nov '09

Hi, I've been trying to diagnose and fix the problem with missing definition of int64_t and uint64_t when using Comeau C/C++ frontend on Linux 32-bit with GCC 4.x. I submitted all details to the Trac: https://svn.boost.org/trac/boost/ticket/3548 Shortly, the problem is that if <sys/types.h> header is included then <boost/cstdint.hpp> can't import uint64_t/int64_t types. However, if <stdint.h> is used, everything works. 1) Does compile with Comeau + GCC #include <boost/cstdint.hpp> int main() { boost::int64_t a(0); } 2) 1) Does compile with Comeau + GCC as well #include <stdint.h> #include <boost/cstdint.hpp> int main() { boost::int64_t a(0); } 3) Does not compile with Comeau + GCC #include <sys/types.h> #include <boost/cstdint.hpp> int main() { boost::int64_t a(0); } What I found is that there are slight differences, in GNU C Library, in how those integer types are defined: 1) <sys/types.h> # elif __GLIBC_HAVE_LONG_LONG __extension__ typedef long long int int64_t; # endif 2) <stdint.h> # else __extension__ typedef long long int int64_t; # endif More details are in the #3548 ticket report. Shortly, sys/types.h vs stdint.h are somewhat competing and seem to confuse <boost/cstdint.hpp> definitions. Both headers define __int8_t what disables the other definitions, thus depending on which header goes first, that one wins but with different effect regarding int64_t type. I exchanged a few e-mails with Comeau team about it and, as for this moment, we've concluded this slight differences between the two headers seem a bit odd and competing indeed. Comeau team has been very helpful and they are willing to make further investigation of this problem. In the meantime, I decided to report this issue to GNU C Library bugzilla (I should send to their mailing list first, my mistake): http://sourceware.org/bugzilla/show_bug.cgi?id=10990 Ulrich Drepper confirmed that this is not GNU C Library issue: "stdint.h is a C99 header and C99 demands the implementation of long long. The headers are correct." Fair enough. However, it makes it more difficult to me to understand where fixes should go. So, I'd like to ask the Community here for help in diagnosing this problem. My thought for now is that if Boost Integer is used with Comeau C/C++ frontend with GCC, Boost configuration could detect if <sys/types.h> was included first and try to disable its effects, like undefine __int8_t and only let int64_t and uint64_t definitions from <stdint.h> header. I believe that solving this problem is quite important to make Boost compilable with Comeau C/C++ frontend, because, as far as I've tested, it mostly leaks when compiling Boost.Test and tests of Boost libraries. I'd be thankful for any thoughts on this. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

1 0