- Boost - lists.boost.org

Core libraries should separated from experimental libraries
by Tom Brinkman 22 Nov '09

22 Nov '09

Continued from "Shouldn't both logging proposals be reviewed in the same formal review" Vladimir Batov said: > People will eventually start asking to distribute boost in parts, where > the "core" libraries are separated from the "experimental" libraries. >>> Isn't it already the case? Just put yourself into the shoes of a project >>> manager facing overruns, deadlines, etc. I -- an excited s/w eng. -- come >>> over and say -- there is a library that does what we want. Your first >>> questions will be 1) quality? 2) will the lib. around long enough? 3) will >>> the interface be stable enough? 4) etc. >>> In that setting I suspect you'll steer clear from anything >>> "inspirational-only". > For boost to remain popular and successful, this issue will eventually > have to be addressed. Fortunately, it probably does not need to be > addressed for a few years. >>> I'll probably have to disagree. I'd be more likely leaning towards >>> "addressed now". I'm actually sympothetic with your point of view and you've certainly made some strong points. My experience has been similar. Nevertheless, no matter how much you wish boost was something different, Boost's mission statement is pretty clear. I dont see that changing anytime soon. You should know that my favorite development library is Gnome (GLIB). http://library.gnome.org/devel/glib/2.22/ Its a very different library, its mission statement clearly states different priorities. Granted its a 'C' library, but its the library that my teams turns to for most of our programming needs. Its not community based like boost is. Not much original thinking is done their, its all about being practical, minimilistic and writing tight code. Boost is different. The libraries here reach for the moon -- some succeed. Boost is where I come for inspiration and there has been some absolutly brillant successes. However, for practical day to day developer needs, I discourage doing too much advanced C++. Neverthless, boost needs to keep on pushing the envelope. Functional programming is the future and boost is where you come to see whats possible in that domain. I would hate to see that change. If boost's focus is switched to addressing the needs of day to day "average" programmers, I would loose interest. I want boost developers to continue to reach for the stars. If "average" developers happen to find boost useful, of course they can use it, but they need to appreciate where boost priorities have been and use it appropriately.

10 14

[thread] Bug sprint #3097 throwing destructor
by Vicente Botet Escriba 22 Nov '09

22 Nov '09

Ticket Description: thread::detach() and thread::~thread() could throw thread_resource_error while locking thread_info_mutex. Currently it is on windows only. Hi Anthony, A simple reading of the current code let me think that this bug has been solved. thread::~thread() { detach(); } void thread::detach() { release_handle(); } void thread::release_handle() { lock_guard<mutex> l1(thread_info_mutex); thread_info=0; } Do you agree? Best, Vicente -- View this message in context: http://old.nabble.com/-thread--Bug-sprint--3097-throwing-destructor-tp26467… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[Review] GGL Review ends today, November 22nd
by Hartmut Kaiser 22 Nov '09

22 Nov '09

Hi all, The review of the Generic Geometry Library officially ends today, November 22nd. Please send in your reviews if you have not done so yet. If you need more time for your review, please get in contact directly with me to work out some individual schedule. Regards Hartmut GGL Review Manager ------------------- Meet me at BoostCon http://boostcon.com

1 0

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