November 2009 - Boost - lists.preview.boost.org

[test] Boost.Test broken in Trunk
by John Maddock 23 Nov '09

23 Nov '09

Folks, Boost.Test is currently completely broken in Trunk for msvc: compile-c-c++ ..\..\..\bin.v2\libs\test\build\msvc-9.0\debug\asynch-exceptions-on\threading-multi\exception_safety.obj exception_safety.cpp d:\data\boost\trunk\boost/test/detail/unit_test_parameters.hpp(54) : error C2059 : syntax error : '__declspec(dllexport)' d:\data\boost\trunk\boost/test/detail/unit_test_parameters.hpp(55) : error C2059 : syntax error : '__declspec(dllexport)' and: d:\data\boost\trunk\boost/test/impl/progress_monitor.ipp(44) : error C2039: 'log_sink' : is not a member of 'boost::unit_test::runtime_config' d:\data\boost\trunk\boost/test/impl/progress_monitor.ipp(44) : error C3861: 'log_sink': identifier not found Obviously this completely breaks regression testing for msvc as well :-( Strangely, I can't see how any of the recent fixes could have caused this either? John.

2 2

Does anyone use the IBM pSeries?
by Marshall Clow 23 Nov '09

23 Nov '09

We've got a really old bug (#583) with patches to support V8 of this compiler. Looking for someone to apply these patches to a local boost install, and report back on the results.... https://svn.boost.org/trac/boost/ticket/583 -- Marshall

1 0

Using units prefix dynamically to get the appropriate prefix for the size of the value?
by Paul A. Bristow 23 Nov '09

23 Nov '09

I'd like to use the units library prefix (k, M, G ...) system, but I'd really like to determine the prefix dynamically (automatically) depending on the value. For example, if I have a length of 12300 m I'd like an output of "12.3 km" but if my length is 0.0123 m, I'd like an output of "12.3 mm". I can't see how to do this (and including the correct length unit of m or meter of course). Suggestions? Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com

2 3

Possible regression in Boost.Test
by Ian Emmons 23 Nov '09

23 Nov '09

A previously reported issue in Boost.Test, which the bug tracking system indicates as fixed, is still present in the 1.41.0 release. The issue I am speaking of is entitled "Boost:Test pointer error with g++ 64-bit on Mac OS X 10.6 Snow Leopard", discussed here: https://svn.boost.org/trac/boost/ticket/3432 It looks to me like one of two things happened here. Either the bug was fixed on a branch but the branch was never merged into the release, or a merge conflict overwrote the change before it was ever released. In 1.38.0 and 1.39.0 the method in question looked like this: void clear() { while( !m_test_units.empty() ) { test_unit_store::value_type const& tu = *m_test_units.begin(); // the delete will erase this element from map if( test_id_2_unit_type( tu.second->p_id ) == tut_suite ) delete (test_suite const*)tu.second; else delete (test_case const*)tu.second; } } The ticket claims to have fixed the bug like so: void clear() { while( !m_test_units.empty() ) { test_unit_store::value_type const& tu = *m_test_units.begin(); // the delete will erase this element from map if( test_id_2_unit_type( tu.second->p_id ) == tut_suite ) { test_suite const* p = (test_suite const*)tu.second; delete p; } else { test_case const* p = (test_case const*)tu.second; delete p; } } } But in 1.40.0 and 1.41.0 the method looks like this: void clear() { while( !m_test_units.empty() ) { test_unit_store::value_type const& tu = *m_test_units.begin(); // the delete will erase this element from map if( ut_detail::test_id_2_unit_type( tu.second->p_id ) == tut_suite ) delete static_cast<test_suite const*>(tu.second); else delete static_cast<test_case const*>(tu.second); } } Perhaps whoever switched the C-style cast to static_cast removed the local pointer variable and reintroduced the bug? In any case, the bug needs to be re-fixed, in the next release, and I would suggest adding a comment so that a future maintainer doesn't eliminate the apparently pointless local pointer variable, like so: void clear() { while( !m_test_units.empty() ) { test_unit_store::value_type const& tu = *m_test_units.begin(); // the delete will erase this element from map // Important: The pointer MUST be copied to local // storage in order to avoid the issue described in // https://svn.boost.org/trac/boost/ticket/3432 if( ut_detail::test_id_2_unit_type( tu.second->p_id ) == tut_suite ) { test_suite const* p = static_cast<test_suite const*>(tu.second); delete p; } else { test_case const* p = static_cast<test_case const*>(tu.second); delete p; } } }

2 1

[thread] unlock on multiple lockables
by Vicente Botet Escriba 23 Nov '09

23 Nov '09

Hi, I don't know if I have already requested that but ... Is there any deep reason to don't provide the equivalent of the free functions lock, try_lock Non-member function lock(Lockable1,Lockable2,...) Non-member function lock(begin,end) Non-member function try_lock(Lockable1,Lockable2,...) Non-member function try_lock(begin,end) to unlock multiple lockables? Non-member function unlock(Lockable1,Lockable2,...) Non-member function unlock(begin,end) Thanks, Vicente -- View this message in context: http://old.nabble.com/-thread--unlock-on-multiple-lockables-tp26471789p2647… Sent from the Boost - Dev mailing list archive at Nabble.com.

5 5

Re: [boost] Meta State Machine library review starts Monday
by Christophe Henry 23 Nov '09

23 Nov '09

>Is there any direct link for an online documentation? Yes, in the Sandbox, which will also be more up to date than the one in the Vault: http://svn.boost.org/svn/boost/sandbox/msm/libs/msm/doc/index.htm

1 0

[1.41.0] [integer] integer.hpp does not compile in MSVC 8.0 with /Za option on
by Adam Badura 23 Nov '09

23 Nov '09

An empty CPP file containing only inclusion of <boost/integer.hpp>: --------------- #include <boost/integer.hpp> --------------- does not compile in MS Visual Studio 8.0 Standard when /Za option ("Disable Language Extensions") is used. The output is following: --------------- D:\Libraries\boost_1_41_0\boost/integer_fwd.hpp(70) : error C2039: 'long_long_type' : is not a member of 'boost' D:\Libraries\boost_1_41_0\boost/integer_fwd.hpp(70) : error C2065: 'long_long_type' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer_fwd.hpp(70) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_fwd.hpp(73) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(67) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(73) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(79) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(85) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(119) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(126) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(132) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(138) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(144) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(150) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(156) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer.hpp(88) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(94) : see reference to class template instantiation 'boost::int_max_value_t<MaxValue>' being compiled D:\Libraries\boost_1_41_0\boost/integer.hpp(89) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(90) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(91) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(101) : error C2065: 'const_min' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(107) : see reference to class template instantiation 'boost::int_min_value_t<MinValue>' being compiled D:\Libraries\boost_1_41_0\boost/integer.hpp(102) : error C2065: 'const_min' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(103) : error C2065: 'const_min' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(104) : error C2065: 'const_min' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(116) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(122) : see reference to class template instantiation 'boost::uint_value_t<Value>' being compiled D:\Libraries\boost_1_41_0\boost/integer.hpp(117) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(118) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(119) : error C2065: 'const_max' : undeclared identifier --------------- I suppose this happens to other editions as well. Also it seems that the same happens with 2005 version. 1.40 version had the same problem and I reported it but it seems no one cared about it. Adam Badura

6 13

Re: [boost] [Review] GGL review starts today, November 5th
by Christophe Henry 23 Nov '09

23 Nov '09

Steven Watanabe wrote: >FWIW, non-virtual destructors are the norm in Boost. >I strongly dislike the idea of having a policy enabling >virtual destructors. I understand this in many cases. OTOH, the geometry types seem to me to be begging for usage the OO way. A small note in the documentation seems to be better than hours of debugging and cannot hurt anyway. The policy was simply a suggestion as it proved a useful solution in my own experience.

1 0

Meta State Machine library review starts Monday
by Christophe Henry 23 Nov '09

23 Nov '09

>I remember hearing alot about UML years ago, but I have not heard very >much about it lately (last 5 years). >Any sense who popular UML is these days. It seems to me it was once >greatly touted as the cure to most of project management and >prototyping needs. >Does anyone have any experience using it? >Where is it primarily used, what kind of projects can benefit from it? I personally try to design my projects with UML, eventhough I mostly use only a few diagrams. It helps quite a bit for documentation and Model-Driven development. But I wouldn't want to start a big discussion about UML. Msm is implementing only a small part of it, the state machine chapter. There were state machines long before UML. The biggest advantage of following the standard whenever possible is that at least there is a standard and it is formally defined, so that you know what you get. If your question was about where to use state machines, this would need a longer answer. Common cases include GUI development, implementation of communication protocols or whenever you might be tempted to define some flags to define the state of a given class (those who never defined a dirty flag, raise your hand ;-) ). In these cases, state machines help you abstract away implementation details and allow someone else understand your code more easily. I also found them a huge help during development as thinking in terms of a model made a problem much easier to solve. HTH, Christophe

1 0

[iostream] closing filtering_ostream
by Vladimir Prus 23 Nov '09

23 Nov '09

Hello, I must be missing something basic, but I cannot find that in Boost.Iostream documentation. Suppose I am writing into filtering_ostream, and I'm done. I wish to close the ostream, flushing whatever remaining data and reporting whatever I/O errors arise to user. However: base64.cpp:17: error: ‘class boost::iostreams::filtering_ostream’ has no member named ‘close’ The documentation say: By default, if the Device at the end of the chain is popped or if the filtering_stream is complete when it is destroyed, all the filters and devices in the chain are closed using the function close. So I assume something is closed in destructor, but what if I don't want the destructor to potentially throw, and instead what to close the stream explicitly? - Volodya P.S. Actually, I'm sure there's a Trac issue saying that potentially throwing destructor is not good.

2 1

Meta State Machine library review starts Monday
by Tom Brinkman 23 Nov '09

23 Nov '09

I remember hearing alot about UML years ago, but I have not heard very much about it lately (last 5 years). Any sense who popular UML is these days. It seems to me it was once greatly touted as the cure to most of project management and prototyping needs. Does anyone have any experience using it? Where is it primarily used, what kind of projects can benefit from it?

1 0

Preliminary submission: generic linear algebra algorithms library Boost LA
by Emil Dotchevski 23 Nov '09

23 Nov '09

I remember some past discussions on this mailing list about the need for similar library in Boost, so I hope it is OK to skip the interest query and request a preliminary review for Boost LA. Boost LA provides a set of generic linear algebra algorithms, primarily for working with vectors and matrices of static size. The library also defines vector and matrix data types, however it allows users to introduce their own types by specializing the vector_traits and matrix_traits templates. Documentation and source code available at http://www.revergestudios.com/boost-la, released under the Boost Software License. Thanks, Emil Dotchevski

9 25

[GGL] Is this a bug, or undocumented behavior?
by Jonathan Franklin 23 Nov '09

23 Nov '09

I have been running some of my own polygon union test cases on the union_inserter. The union_inserter doesn't appear to return a minimal set. E.g. if the start point of a polygon appears in the union, it will appear twice (consecutively). Is this expected behavior? If so, it should probably be documented. I have some other algorithms which expect a sequence of unique points, so I would need to pre-process the result of this function call. Thanks, Jon

2 2

Re: [boost] Core libraries should separated from experimental libraries
by Thomas Klimpel 22 Nov '09

22 Nov '09

Stefan Seefeld wrote: > Wait. You'd like to have releases bundle both, and you don't want to > provide distinct guarantees. What's the point in this split, then ? 1) To make the life of package maintainers (e.g. debian, ubuntu) easier. 2) To make adoption of boost in corporate environments easier, by offering the option to only use the "core" package, potentially cherry-picking only a few of the other libraries from the "complete" package. 3) Have a first step in the direction you want to go, but sufficiently similar to the existing release mode that it may still be possible to reach agreement. 4) Guarantees and what actually works are two different things. Even now, Boost.MPI and Boost.Phyton are probably tested on fewer systems than other Boost libraries without external dependencies. But with respect to your question, the "core" packages would probably actually be quite stable, but without an explicit guarantee for this. Regards, Thomas

2 3

[1.41] Are docs on the website updated?
by Andrey Semashev 22 Nov '09

22 Nov '09

I'm looking at Boost.DateTime changelog page: http://www.boost.org/doc/libs/1_41_0/doc/html/date_time/details.html#date_t… It looks like it has not been updated since the previous release. The source documentation in SVN (release branch) includes changes between 1.40 and 1.41. Is this a known issue?

2 2

new library boost.fiber in vault
by Oliver Kowalke 22 Nov '09

22 Nov '09

I've re factored boost.fiber (-> boost vault http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Concu…) The library provides a so called lightweight thread of execution (also known as user-space thread or fiber on WIN32). The API is modeled after boost.thread. Beside a scheduler (currently simple round-robin) for the fibers the library provides sync. primitives like mutex, condition- and event-variables (auto-reset, manual-reset, count-down). Message can be passed between fibers via bounded-/unbounded-fifo. Some feedback would be nice. regards, Oliver

5 15

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

22 Nov '09

Thomas Klimpel said: >> I don't know whether I understand your concerns. >> I'm just not sure that it >> will be easy to agree on a set of core >> libraries. If it were just the official boost libraries >> themselves, it would at least be easy to figure out >> which library must necessarily be considered as >> "core". But you will never know exactly which boost >> libraries are used by closely boost related projects, >> like the libraries in the sandbox. For them, the >> official release boost libraries present the "core" >> libraries, and the other sandbox libraries are the >> experimental ones (and as Glas shows, it is quite >> possible that there is even a dependence to another >> experimental library). My major concern is about how to encourage continued innovation. Having potential libraries languish in the review queue for many many months, in some cases, years, can't be a good thing for getting people to want participate in boost. Think about all the people behind the scenes that see the review queue and say, why bother, its too cumbersome. There are alot of good ideas out there, but they need a place to get some exposure, and to flush them out. Debian has demonstrated that a stable and a non-stable branch can be quite successful. Boost should adopt a similar approach.

2 1

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