November 2009 - Boost - lists.boost.org

[Review] GGL review starts today, November 5th
by Hartmut Kaiser 07 Dec '09

07 Dec '09

Hi all, The formal review of the Generic Geometry Library (GGL) starts today, November 5, 2009 and will finish November 15, 2009. GGL is being developed by Barend Gehrels, Bruno Lalande and Mateusz Loskot, with substantial input from this Boost mailing list. ------------------------------------------------ About the library: GGL defines concepts for geometries and implements some algorithms on such geometries. GGL is header-only, and can be applied in all software where geometry plays a small or a larger role. Users of the library can use just only one function, such as distance: int a[2] = {1,1}; int b[2] = {2,3}; double d = ggl::distance(a, b); Library users can also use the library in combination with std::vector, boost::tuple's and boost::ranges, such as: std::vector<boost::tuple<double, double, double> > line; line.push_back(boost::make_tuple(1, 2, 3)); line.push_back(boost::make_tuple(4, 5, 6)); line.push_back(boost::make_tuple(7, 8, 9)); double length = ggl::length(line); GGL can also be used in combination with custom or legacy geometries, adapting them to the library specializing traits classes or using registration macro's. Formally, GGL contains a dimension-agnostic, coordinate-system-agnostic and scalable kernel, based on concepts, meta-functions and tag-dispatching. On top of that kernel, algorithms are built: area, length, perimeter, centroid, convex hull, intersection (clipping), within (point in polygon), distance, envelope (bounding box), simplify, transform, convert, and more. The library is also designed to support high precision arithmetic numbers, such as GMP. The GGL might be used in all domains where geometry plays a role: mapping and GIS, gaming, computer graphics and widgets, robotics, astronomy... The core is designed to be as generic as possible and support those domains. However, for now the development has been mostly GIS-oriented. The GGL team proposes an extension model, very similar to what is used by GIL. The proposal as it is in the Boost Sandbox included three extensions: - SVG because it is used in the samples and to generate the documentation - WKT because it is used in the tests - The geographic coordinate system because it is used in some of the examples, also showing how other coordinate systems can be implemented There are more extensions, not included now, a.o.: - Spatial index - Map projections The proposed GGL has seen four previews, many discussions and many changes in design and implementation, based on those discussions. Previews were published on this list January '08, March'08, October'08 and February'09. GGL can be found in the sandbox https://svn.boost.org/svn/boost/sandbox/ggl/formal_review, including source code, examples, unit tests and documentation. Documentation can also be found online: http://geometrylibrary.geodan.nl/formal_review ------------------------------------------------------- Everybody on this list is invited to participate in this formal review. I hope to see your review of this library, including your vote, and I welcome your participation in the discussions on the Boost mailing list. Please always state in your review, whether you think the library should be accepted as a Boost library. Additionally, please consider giving feedback on the following general topics: - 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? Regards Hartmut Review Manager ------------------- Meet me at BoostCon http://boostcon.com

20 78

[chrono] type_traits/common_type and integer/ratio
by Vicente Botet Escriba 06 Dec '09

06 Dec '09

Hi, I'm looking on how to continue with the Boost.Chrono library and I would like to know if * Boost.TypeTraits could take care of the common_type class template. * Boost.Integer could take care of the ratio class template. In this way Boost.Chrono will contain only the time related facilities, duration, time_point and Clocks. In order to minimize the task and been able to purpose as soon as possible the library for review I would like to concentrate on the implementation of the standard proposal and let for a future release the facilities Beman added as * Class template timer, with typedefs: * `system_timer` * `monotonic_timer` * `high_resolution_timer` * Process clocks and timers: * `process_clock`, capturing real, user-CPU, and system-CPU times. * `process_timer`, capturing elapsed real, user-CPU, and system-CPU times. * `run_timer`, convenient reporting of process_timer results. What do you think about this approach? Best, Vicente -- View this message in context: http://old.nabble.com/-chrono--type_traits-common_type-and-integer-ratio-tp… Sent from the Boost - Dev mailing list archive at Nabble.com.

6 19

Notice: Boost.Atomic (atomic operations library)
by Helge Bahmann 05 Dec '09

05 Dec '09

Hello, as promised I have started extracting an atomic operations library. Current state is available at: http://www.chaoticmind.net/~hcb/projcets/boost.atomic It implements boost::atomic<TYPE> which faithfully mimics std::atomic<TYPE> as specified in the C++0x draft standard. As allowed by the standard, operations transparently fall back to locking when the underlying architecture does not support the requested operation, so the library already contains a "fallback" implementation that works an all platforms (using mutex from boost::thread). It currently natively supports gcc/x86, gcc/powerpc and gcc/alpha (I can vouch for the correctness of the implementations on these targets). It contains some entirely untested support for building implementations from CAS operations on other systems (e.g. _InterlockedCompareExchange on win), so I would greatly appreciate any feedback if it works/doesn't on any particular platform. There is some preliminary documentation, but not in boostdoc format -- after unsuccessfully struggling with bjam/boostbook & friends for a few hours I simply gave up and reverted to trusty old doxygen :( Is there any step-by-step guide on how to create, build and document a new library? I could really use that as the boost build and documentation system is pretty alien to an autotools-accustomed guy like me. Best regards Helge

10 33

[explore] Library Proposal: Container Streaming
by Jeffrey Faust 03 Dec '09

03 Dec '09

Jared McIntyre, Danny Havenith, and myself, with support from Jeff Garland have developed a library to stream standard containers to output streams. We would like to submit this for review. The requirements for this library were gathered at the BoostCon 2007 Library in a Week sessions. An initial review was held and further requirements were gathered at BoostCon 2008. Everything can be found in the boost vault <http://www.boostpro.com/vault/> . Here is a direct link to explore.zip <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=ex plore.zip&directory=&> . Some quick examples: #include <boost/explore.hpp> # include ... // simple vector example std::vector<int> vi; vi.push_back(1); vi.push_back(2); vi.push_back(3); std::cout << vi; // prints [1, 2, 3] // lets do some containers in containers std::vector<std::vector<int> > vvi; vvi.push_back(vi); vvi.push_back(vi); std::cout << vvi; // prints [[1, 2, 3], [1, 2, 3]] // associative containers std::map<std::string, int> si_map; si_map["hello"] = 1; si_map["world"] = 2; std::cout << si_map; // prints [hello:1, world:2] // containers of complex types std::list<date> dl; // date from boost::gregorian dl.push_back(date(2007, Jan, 1)); dl.push_back(date(2007, Jan, 3)); std::cout << dl; // prints [2007-Jan-1, 2007-Jan-3] // how about some boost container types: boost::array<std::string, 2> sa2; sa2[0] = "one"; sa2[1] = "two"; std::cout << sa2; // prints [one, two] Jeffrey Faust

27 56

Re: [boost] Formal Review Request: Boost.String.Convert
by Vladimir.Batov＠wrsa.com.au 02 Dec '09

02 Dec '09

I understand we'll never manage to please everyone. Apologies. For now I am settling on the boost::convert interface as I very much agree with the arguments Robert's put forward for it and I feel there is the least disagreement around this interface. Surely boost::convert() has issues of its own. However, I feel the path (convert::to_string->convert::to->convert) how I myself arrived to this logical (IMHO) conclusion seemed reasonable. More so, despite its subtle (to some) directionality the interface has proven to work (as it is essentially the same interface as for lexical_cast). You cannot deny that I made considerable sacrifices (my pets "string" namespace and "to/from" are gone, something I was ready to die :-) for yesterday...). I am hoping the others could make some concessions as well and we would settle on boost::convert()... for now. If some other issues pop up that we missed so far, we'll revisit the issue. It is because I would very much like to move forward and start looking at the functionality and implementation. Do you think it is possible or I am rushing things again? I somewhat cleaned up the implementation (removed to/from, etc.). However, before going forward I'd like to discuss one important thing that's been bugging me since Scott brought it up. Namely, all conversions are now implemented as discriminated functions like // string-to-type conversion template<class TypeOut, class StringIn> typename boost::enable_if_c< !is_string<TypeOut>::value && is_string<StringIn>::value, detail::from_string<StringIn, TypeOut> >::type convert(StringIn const& from_str, TypeOut const& default_value =TypeOut()) { return detail::from_string<StringIn, TypeOut>(from_str, default_value); } However, Scott mentioned that and I feel that might be cleaner if we could implement it as namespace boost { template<class TypeOut, class TypeIn, class Enable =void> class convert; } Then for every conversion we'll be able to encapsulate *complete* implementation in the respective specialization class. Like for string-to-type template< class TypeOut, class StringIn, typename boost::enable_if_c< !is_string<TypeOut>::value && is_string<StringIn>::value, void>::type> class convert { convert(StringIn const& from_str, TypeOut const& default_value =TypeOut()); }; The reason I like it is that it eliminates other support/intermediate classes (like something used-to-called boost::string::value<...> and detail::from_string) and we can do int i = convert(str, -1); // Nothing changed. a 'convert' instance created on the stack and converted to 'int'. convert<int, string> checked(str, -1); // named 'convert' is created. convert<int, string> checked = convert(str, -1); // the same but some might like this syntax better. if (checked.good()) success // we can check the success as ussed to with boost::string::value It feels that approach gives us considerably more room for expansion as some special conversions will be able to have methods only specific to that particular conversion. For this approach to work with algorithms we'll need class convert { static TypeOut apply(TypeIn const&); }; and then std::transform( ints.begin(), ints.end(), std::back_inserter(strings), convert<string, int>::apply); Thanks, Vladimir.

9 63

[fiber] new version in vault
by Oliver Kowalke 01 Dec '09

01 Dec '09

I've uploaded a new version of boost.fiber - main features are: - multiple schedulers can be used in one thread - user can provide its own scheduler implementation as template argument to class scheduler - classes disable_interruption and restore_interruption moved into namespace boost::this_fiber regards, Oliver

6 29

BOOST_MSVC vs. _MSC_VER wrt #pragma warning
by Emil Dotchevski 01 Dec '09

01 Dec '09

I understand that BOOST_MSVC is needed to detect MSVC because other compilers besides MSVC define _MSC_VER. But what about #ifdefing #pragma warning, should it use _MSC_VER or BOOST_MSVC? The reason why the ifdefing is needed is to prevent GCC and other compilers issuing a warning about #pragma warning, but presumably compilers that have _MSC_VER defined wouldn't warn about that, would they? -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

2 1

[1.42.0] Release branch open for merges
by Beman Dawes 01 Dec '09

01 Dec '09

The release branch (https://svn.boost.org/svn/boost/branches/release) is open for merging all stable changes from trunk, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging *does not* require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: http://www.boost.org/development/index.html Release schedule explanation: http://svn.boost.org/trac/boost/wiki/ReleaseSchedule Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices -- The Release Managers, Beman Dawes Daniel James Eric Niebler Rene Rivera Vladimir Prus

3 3

[msm] Review
by Christophe Henry 01 Dec '09

01 Dec '09

Hi Juraj, First of all, thank you for being the first one to write a review. I imagine it's not an easy thing. Thank you also for bringing a few very interesting points to the discussion. I'm happy to build on them and hope to finally start some discussion. >MSM does lack some of the SC functionality. >There is no state-local storage in SC sense, as all states are >constructed when main state machine is constructed. This can be easily >worked around though. As this point is being brought for the second time, I'd like to spend some time on it. You already have state local storage with msm, just not like with SC. Like SC, msm defines states as classes, meaning they can have data. There is however one important difference with SC. Msm builds all the states upon state machine creation. States are not destroyed until state machine destruction. This has advantages and disadvantages: - states must be default-constructible - you might need to heap allocate the state data if you cannot initialize it at state construction. + speed: states don't need to be constructed again and again. Constructing a state (and its attributes) each time it becomes active can be costly, even if memory allocation can be optimized. + your state data is always available. In my experience, state data is not only needed in the entry or when the next event is processed, but during a transition or even at some time after a transition. This means, that you have, during a transition, access to data from the source or the target state. + combined with the visitor, you can at any time access data from the currently active state and build a generic way to do something with state data. + you can build examples like the iPodSearch where states keep iterators to some container, thus keeping information from an iteration to the next one. + you avoid having data released inside a destructor. Knowing that destructors should not throw, it makes your life easier. + on_entry is templatized, giving you more leeway to add event-specific handling. + your event data is not lost upon state entry Msm's handling is hard to emulate with SC, on the other hand, SC's handling is easy to emulate with Msm. It has its drawbacks but all considered, I think it is a superior solution. >It is impossible to stop event from propagation (SCs discard_event()) >without actually changing state. It is true. At the moment you cannot. Actually, I don't think UML foresees this possibility. OTOH, I think it is an interesting one and will be happy to borrow it from SC. I think that using the transition table is one of Msm's biggest strengths so I offer to add a row or a functor allowing event propagation to be stopped. You could even give it a guard, thus allowing fine-grained transition conflict resolution. > You cannot conditionally defer an event. Again you're right. I think UML doesn't foresee this either, but I also like it and will also borrow it from SC. You offered the idea of a d_row (deferred row) or dg_row (the same with a guard). I think it is the best possibility with the simplest front-end and makes deferred events a first-class citizen, being in the transition table and coming into play during conflict resolution. For the functor and eUML front-ends I think it could be done as an execution row. Something like: State1() + Event1() / defer_() Seems an interesting starting point. >There seem to be some differences on how event deferral is handled when > composite states are used. This part is a still bit mysterious to me. I will add a part about the dispatch algorithm to the documentation. >Aesthetically - I'm not a great fan of one big fat html documentation > and would prefer to have it broken down and cross-referenced as most > boost libraries docs are organized, but this is just a minor issue. If Msm is accepted into Boost, I'd probably move to BoostBook anyway, so this will be done at this time. > The author seems masochistic enough to try to tackle this. :) Sure :) and I don't mind the term at all :) Thanks for the review and the very good points you brought during the last weeks! Regards, Christophe

3 2

Re: [boost] [msm] Review
by Christophe Henry 30 Nov '09

30 Nov '09

Hi Sebastian, > I know nothing about MSM and very little about state machines in > general, but if all states are constructed at SM instantiation time, > would it be possible to pass the SM constructor a tuple of constructed > states that are copied/moved into the internal states? In theory it'd be possible because MSM stores the states in a fusion::set, which can be constructed from a forward sequence. And according to the fusion doc, a tuple can be adapted to a forward sequence. So I suppose it'd work. The problem would be to find an acceptable syntax because a msm::back::state_machine already has a templated constructor used to pass arguments to the front-end, for example: struct player_ : public msm::front::state_machine_def<player_> { player_(int some_value){…} } typedef msm::back::state_machine<player_ > player; player p(3); So we'd need to pass the tuple as extra argument, the first or the last one and add a bit of SFINAE to check if this argument is a tuple. > Would it be worth the effort? I don't know. It has never been requested so it's hard to know, but I find the idea quite interesting. Let's make a quick poll (which I'll shamelessly use as a way to make the review slightly more alive). Would someone make use of this feature? Christophe

1 0