October 2010 - Boost - lists.boost.org

[geometry]
by Paul Blampspied 13 Oct '10

13 Oct '10

I have been looking at the advance version of [boost][geometry]. I think it is very useful and very well worked out. I have a question. Does [geometry] support the idea of a frame of reference ? I believe not, but it may be that I have missed some way of achieving this. By reference frame I mean that some points are not directly comparable if they are in different frames of reference. This is distinct from different coordinate systems (I think). For example we could have two geographic coordinate systems, one referring to lat./long. on earth and another to Mars. the points on these two reference frames should not be comparable and should give a compile error. Can this be done in [geometry] ? More interestingly we could use two distinct reference frames for convenience, even though there is a known relation between them. It would be nice if point conversions between the two frames could be carried out (possibly implicitly). For example, I would like to do something like this: ShiftAndRotateTransform<EgocentricFrame, WorldFrame> EgoFrame_WorldFrame_Transform(10, 20, 90); //Shift by [10,20] and rotate 90deg. WorldFrame Test() { WorldFrame p1 = EgoFrame(0,0); EgocentricFrame p2 = WorldFrame(p1); return p2; //IMPORTANT - p2 is implicitly transformed to WorldFrame when returned from Test function. } I have managed to implement a very simple scheme which allows this to compile and work successfully, but I am not completely satisfied with my homebrew scheme. In particular, I am forced to declare the WorldFrame and EgoFrame classes and provide all the constructors for them. It is necessary to explicitly provide constructors for all the reference frames which can be converted - implying that this is known at the time the class is written. It is more flexible to use overloaded functions, because these can be added as required e.g. //The second argument is the output point which is modified. ChangeReferenceFrame(WorldFrame &p1, EgocentricFrame &p2); ChangeReferenceFrame(EgocentricFrame &p1, WorldFrame &p2); ChangeReferenceFrame(EgocentricFrame &p1, SomeNewFrameType &p2); However the syntactic convenience and possibility of implicit conversion is lost. I wonder if some sleight of template magic could allow the extensibility of the second approach with the usability of the first. The starting point would be to allow a class representing the transform between the two frames of reference to be declared. This should attempt to define as much of the machinery as possible. It seems to me that these facilities have no impact on the existing design of [geometry], but concern an extension to allow reference frames to be defined and related.

2 3

License question
by David Bellot 13 Oct '10

13 Oct '10

Hi guys, I'm working on a new library for some specific A.I and machine learning problems and I will release it as a Free Software of course. However, I wonder if you guys can enlighten me regarding license. This library will be template-based for some parts and compiled for other parts. I don't want to restrict users in what they're doing with the library, I mean they can use it for open-source or closed-source products. However, I want to decently protect my work and because it's template-based and can be used in commercial products, I don't want someone to do closed-source fork of it and all those kind of things... I selected to candidates: Boost and LGPL. So question: - do I have to use a Boost license or a LGPL license ? - and why not using GPL directly or is it too restrictive ? Thanks for your help, David (also boost::ublas maintainer when not doing statistics ;-) ) -- David Bellot, PhD david.bellot(a)gmail.com http://david.bellot.free.fr

5 5

Re: [boost] [function] function wrapping with no exception safety guarantee
by Dave Abrahams 12 Oct '10

12 Oct '10

On Tuesday, October 12, 2010, Emil Dotchevski <emil(a)revergestudios.com> wrote: > On Tue, Oct 12, 2010 at 4:04 PM, Daniel Walker > <daniel.j.walker(a)gmail.com> wrote: >> Formally, boost::function invocation has strong exception safety if >> invoking the target function has strong exception safety. > > This makes no sense at all. Invoking boost::function always has strong > exception safety guarantee. In no way it can make the state of the > boost::function object inconsistent, because it does not modify its > state. Sounds like you're talking about the basic guarantee here. > _____________________________________________ -- Dave Abrahams BoostPro Computing http://www.boostpro.com

2 1

Nightly tests failed with filesystem problem
by Belcourt, Kenneth 12 Oct '10

12 Oct '10

Hi, Tests failed last night for a problem with v3/src/operations.cpp. gcc.compile.c++ /scratch/boost/boost/bin.v2/libs/filesystem/build/ gcc-4.1.2/release/link-static/v3/src/operations.o "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall - DBOOST_ALL_NO_LIB=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -I"/scratch/ boost/ boost" -c -o "/scratch/boost/boost/bin.v2/libs/filesystem/build/ gcc-4.1.2/release/link-static/v3/src/operations.o" "/scratch/boost/ boost/libs/filesystem/v3/src/operations.cpp" /scratch/boost/boost/libs/filesystem/v3/src/operations.cpp: In function ‘boost::filesystem3::file_type<unnamed>::query_file_type(const boost::filesystem3::path&, boost::system::error_code*)’: /scratch/boost/boost/libs/filesystem/v3/src/operations.cpp:467: error: no matching function for call to ‘symlink_status(const boost::filesystem3::path&, boost::system::error_code*&)’ /scratch/boost/boost/boost/filesystem/v3/operations.hpp:209: note: candidates are: boost::filesystem3::file_status boost::filesystem3::symlink_status(const boost::filesystem3::path&) /scratch/boost/boost/boost/filesystem/v3/operations.hpp:211: note: boost::filesystem3::file_status boost::filesystem3::symlink_status(const boost::filesystem3::path&, boost::system::error_code&) Can someone please take a look? Thanks. -- Noel

1 0

[proto] Writing a transform to get at an inner constant of a transform result type
by Sebastian Redl 12 Oct '10

12 Oct '10

Hi, The subject is probably very confusing. I'm back to playing with a proto-based library for vector types. I have a basic underlying vector template, simd_impl: template <typename T> struct simd_impl { static const size_t size = VECTOR_BYTES / sizeof(T); // data }; And I have a grammar, Simd struct Simd : proto::or_< SimdLiteral, SimdUnary, SimdVectorBinary, SimdMixedBinary > {}; where SimdLiteral is an enumeration of proto::terminal<simd_impl<T>> where T are various underlying types, SimdUnary are unary operations, SimdVectorBinary are combinations of two vectors, and SimdMixedBinary are combinations of vectors with scalars. SimdVectorBinary is currently defined approximately like this: struct SimdVectorBinary : proto::or_< proto::when<proto::plus<Simd, Simd>, exec::simd_plus(Simd(_left), Simd(_right))>, // more operators here > {}; Now I want to validate, in the grammar, that you only add two vectors of the same arity together. That is, I'm fine with adding simd_impl<long> and simd_impl<int> together if they have the same size, because both have the same number of elements, but adding simd_impl<short> and simd_impl<int> together doesn't work, as one has twice the number of elements as the other. But I can't figure out how to write a grammar that validates this. I've started something like this: struct VSizeMatches : proto::if_<mpl::equal_to<Arity(proto::_left), Arity(proto::right)>()> {}; but I think that's wrong, and I can't figure out how to write Arity anyway. Basically, I have to find the simd_impl<T> type that the result of my Simd transform has and then access the size member. But I'm kinda afraid that this will get me into a world of trouble with prematurely instantiated templates. Any advice? Sebastian

2 2

Re: [boost] [Review] Formal Review of Proposed Boost.RatioLibrary IS UNDERWAY
by Tan, Tom (Shanghai) 12 Oct '10

12 Oct '10

Hi, Here my review. ----- Original Message ----- From: "Anthony Williams" <anthony.ajw(a)gmail.com> Subject: [boost] Reminder: [Review] Formal Review of Proposed Boost.RatioLibrary IS UNDERWAY >> Here are some questions you might want to answer in your review: >> >> - What is your evaluation of the design? As others already mentioned, it follows the C++ Standards Committee's current Working Paper. That's good. >> - What is your evaluation of the implementation? - Code is clear and easy to read and understood. - BOOST_INTMAX_C is the only macro that's defined in ratio.hpp but not staring with BOOST_RATIO_. As the name suggests, it'll be better 1) if placed in boost/cstdint.hpp, or 2)be named as BOOST_RATIO_INTMAX_C indicating that it's used for boost.ratio only, I personally prefer option 1). - I would expect the comments are better cleaned up and the style unified. Right now, //, //-, //~, /**/ are all used, which seems confusing. I personally like the style adopted in boost.asio. >> - What is your evaluation of the documentation? - It's always a pleasure to read documents generated with BoostBook Documentation Format, - In the tutorial section, it'll be great if more examples are appended so that one example for each supported arithmetic and comparison operations, considering boost.ratio is a small one, doing so won't explode the tutorial section but gives a more complete picture of the lib. >> - What is your evaluation of the potential usefulness of the library? I can think of two scenarios: 1) It could quite useful in physical measurement of time, length, weight and the like where values of different units are being calculated. 2) It could be useful in expressing large rational number (Can anyone please let me know whether ratio is short for rational or a complete word itself? It seems either is OK, though I still wonder) >> - Did you try to use the library? With what compiler? Did you have any problems? Yes, indirectly through using boost.chrono, which is based on boost.ratio. VC10 on Windows 7, GCC4.4 w/ mingwin on widows 7. GCC4.4 on Ubuntu 10.4 No problem with the latest version from boost sandbox. >> - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I did have some in-depth reading of previous versions of the code & documentation while I was started using boost.chrono, though not line by line. I also did a deep reading of C++ Standards Committee's current Working Paper (n2661in order to understand the why and how of ratio class then. While doing this review, I had a thorough reading of the code and documentation, which costs about half a day (including expressing my comments in English). >> - Are you knowledgeable about the problem domain? Intermediate. >> - Do you think the library should be accepted as a Boost library? Yes.

3 2

construe_cast, call for interest and feedback
by Jeroen Habraken 11 Oct '10

11 Oct '10

Hi, I'm proud to say I've tagged a version 0.2 of construe_cast some minutes ago. For those unfamiliar with the library (it's the first time I'm posting this to the boost mailinglist), it's a library which builds upon boost.spirit to create a cast-like operator aiming to provide an alternative to lexical_cast providing greater speed and flexibility. The current code can be found at http://github.com/VeXocide/construe_cast and should be compatible with boost version 1.42.0 and up. What can it do, in short, boost::construe_cast<int>("23") and boost::construe_cast<std::string>(23); (and a lot of other types, basically the ones boost.spirit supports). Secondly, since this release, boost::construe_cast<std::string, tag::bin>(23) resulting in a std::string("10111") and visa versa. The user has the ability to add functionality here by implementing extra tags, by default tag::bin, tag::oct and tag::hex are implemented, with more to follow. What I'm hoping to add the coming weeks: - Documentation, I'm somewhat ashamed to say this hasn't been written yet, however, this will be tackled shortly. - Support for different encodings, it currently uses standard (ASCII) and standard_wide for wchar_t, with more to follow. - A nothow version, like lexical_cast it currently throws when it encounters a run-time, an interface returning false or a default value will be included (the exact interface hasn't been decided upon yet). Performance, now this is where it gets hard. I've done some basic benchmarking and it's somewhere between one and five times as fast as lexical_cast, depending on what you're casting. Good compilers (I've notices this with gcc 4.4 and up for example) are actually capable of optimizing boost::construe_cast<int>("23") to the integer 23 at compile-time which makes it tricky to benchmark. If anyone with more benchmarking experience is willing to look into this, please do. Again, thanks to everyone who helped me get this far, and Hartmut in particular. There seems to be little to add at the moment, I'm looking forward to your opinions and insights. Regards, Jeroen Habraken P.S. I've had a few responses about the name, construe is an english word (http://www.thefreedictionary.com/construe) and I'm using construe_cast as a working name. If people are ever going to consider this for inclusion with boost, changing the name will surely be the least of my worries.

11 20

[units] missing merge of autoprefix to release
by Jürgen Hunold 11 Oct '10

11 Oct '10

Hi ! I was quite surprised that the "autoprefix" feature is not available in the current release branch. I found that the merge from the development branch to trunk was done in r62532. The issue is https://svn.boost.org/trac/boost/ticket/3660 Any chance this can be merged to release ? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 3

[Review] Formal Review of Proposed Boost.Ratio Library FINAL DAY
by Anthony Williams 11 Oct '10

11 Oct '10

Hi everyone, Today is the FINAL DAY for the review of Vicente Botet' Ratio library. If you haven't already posted a review, please do so today. What is it? ======== Portable implementation of the C++0x Standard Library's compile-time rational arithmetic working on C++03 and C++0x compilers. See the current C++0x working draft at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3126.pdf Boost.Ratio provides: * A class template, ratio, for specifying compile time rational constants such as 1/3 of a nanosecond or the number of inches per meter. ratio represents a compile time ratio of compile time constants with support for compile time arithmetic with overflow and division by zero protection * It provides a textual representation of boost::ratio<N, D> in the form of a std::basic_string. Other types such as boost::duration can use these strings to aid in their I/O. This library is header-only and is designed to be generic and useful in a lot of areas of math and numerics C++ programming, in particular it is absolutely needed for the proposed Boost.Chrono and Boost.Stopwatches libraries which are currently in the review queue. Getting the library ============= The latest version of this library may be downloaded from vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=ratio.… SVN: http://svn.boost.org/svn/boost/sandbox/chrono (directories boost/ratio and libs/ratio) and the docs may be viewed here html: http://svn.boost.org/svn/boost/sandbox/chrono/libs/ratio/doc/html/index.html pdf: http://svn.boost.org/svn/boost/sandbox/chrono/libs/ratio/doc/ratio.pdf You can get all these information also (which should avoid some long links) from http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Ratio It is worth noting that the tests included in the zip file are relatively sparse. Vicente has an extensive suite of tests licensed under the LLVM license. He has posted a message on the Boost Developers mailing list regarding the license requirements for tests (See http://thread.gmane.org/gmane.comp.lib.boost.devel/208978) and is awaiting the outcome of that discussion before making the tests available. Writing a review ================ If you feel this is an interesting library, then please submit your review to the developer list (preferably), or to the review manager. Here are some questions you might want to answer in your review: - 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? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Anthony Review Manager for the proposed Boost.Ratio library -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

2 1

Boost Evolution
by Robert Ramey 11 Oct '10

11 Oct '10

Boost is getting bigger and bigger. This is a good thing. The Boost header directory and boost namespace is also getting bigger and bigger. This is starting to become a problem. I would like to see: a) new libraries not add headers to boost directory or namespace. - with the possible exception - of "convenience headers" which include all the other headers for a library. Personally I don't like these, but since one doesn't have to use them its not a huge deal. b) authors of existing libraries which are implemented in boost directory/namespace would be encouraged to migrate them to a lower level. c) a couple of "catch all" namespaces/headers would be required such as "utility" for small libraries. I'm somewhat confused about "detail". If it's an implemenation detail of a particular library it should be in that library. If its a useful function which is shared by several libraries, it should be in something like: "unreviewed". And of course these should have thier test and documenations in the corresponding "lib" subdirectory. As boost get's bigger and bigger, it gets harder and harder to install just a part of it. But installing just a part of it is what users need to become confident about it. I realize that we've been circling around this topic for a while, I just want to keep it alive. Robert Ramey

9 16