August 2014 - Boost - lists.boost.org

[units] Interest in UDLs (e.g. _kg) for units?
by Curdeius Curdeius 28 Aug '14

28 Aug '14

Hi all, I was wondering if there is any interest in adding User-Defined Literals (UDLs) to Boost.Units. IMO, it could simplify some code and improve code readability in some cases. For example instead of writing (it's a somehow artificial example) 5.34 * si::milli * si::kilogram; 1234 * si::kilogram; one would write 5.34_g; 1234_kg; I propose to add this feature for compatible compilers (where BOOST_NO_CXX11_USER_DEFINED_LITERALS is not defined). The user would have to pull corresponding namespace (let's call it `udl`) to use it, for example using namespace boost::units::systems::si::udl; // bring _kg, _km, ... into scope What are your feelings about it? In the first place, I would go for `operator ""` taking as arguments `unsigned long long` and `long double`. Later, one could think about the one taking a `const char *` argument which would provide a quantity with an underlying type of arbitrary precision (like boost::multiprecision::cpp_int). Regards, Marek Kurdej -- Ph.D. candidate

5 5

Re: [boost] [units] Interest in UDLs (e.g. _kg) for units?
by Marek Kurdej 28 Aug '14

28 Aug '14

Looks much nicer! > Will reduce the user resistance to using Boost.Units - it's a bit verbose > for mere engineers and scientist's taste ;-) > But have you implemented it yet? > (and are there any hidden gotchas? - the proposed C++ time literals > suffixes proved to be a can of worms :-( > Paul I have a partial implementation for mass and length units. You can have a look at it : https://github.com/mkurdej/units/tree/feature/user-defined-literals You guess right, there are some problems to solve with output of quantities created with literals. See lines with FIXME in test/test_literals.cpp For those who were sceptic about "megagrams" and so on: that was just an example. Actually, I implemented tonnes (t), kilotonnes (kt), Gt and so on. Still, someone could possibly use Mg, Gg for uniformity... (but I haven't found such a person yet). Marek Kurdej -- Ph.D. candidate

1 0

Compiling with MPI support on Linux using clang and libc++
by Gonzalo BG 28 Aug '14

28 Aug '14

Dear boost users/devs, has anyone had any luck compiling the latest boost from source with mpi support on linux using clang and libc++? I'm trying to set up a project on travis-ci and am running into ABI issues (cxxabi files not found,etc). I could try to use libstdc++ instead but would prefer to keep on using libc++. If anyone has been successful on setting this up on travis-ci and has a .travis.yml that I could have a look at I would be really grateful. Bests, Gonzalo

1 0

[move] Implicit conversion to rvalues and move ctors.
by Mostafa 28 Aug '14

28 Aug '14

Here's another use case that fails to compile in C++03 but compiles successfully in C++11. (Note, it fails to compile in VS2005 and g++ 4.8.2 -std=c++98, and compiles successfully with g++ 4.8.2 -std=c++11) MOC is a BOOST_MOVABLE_BUT_NOT_COPYABLE type. Foo is an empty with an implicit conversion function to MOC. "MOC m(Foo());" compiles successfully but "MOC m2(makeFoo());" fails to compile. Is this a bug or a limitation of Boost.Move in C++03? //---------- //Start Code //---------- #include <boost/move/core.hpp> #include <boost/move/utility.hpp> struct MOC { MOC() : value(121) {} MOC(BOOST_RV_REF(MOC) rhs) : value(rhs.value) {} int value; private: BOOST_MOVABLE_BUT_NOT_COPYABLE(MOC) }; struct Foo { operator MOC () { return MOC(); } }; Foo makeFoo() { return Foo(); } int main() { // (1) Successfully Compiles. MOC m(Foo()); // (2) Fails to Compile. MOC m2(makeFoo()); return 0; } //-------- //End Code //-------- //-------------------- //Start Error Messages //-------------------- boost_move_implicit_conversion_to_rvalue.cc: In function ‘int main()’: boost_move_implicit_conversion_to_rvalue.cc:32:19: error: no matching function for call to ‘MOC::MOC(Foo)’ MOC m2(makeFoo()); ^ boost_move_implicit_conversion_to_rvalue.cc:32:19: note: candidates are: boost_move_implicit_conversion_to_rvalue.cc:10:3: note: MOC::MOC(MOC&) BOOST_MOVABLE_BUT_NOT_COPYABLE(MOC) ^ boost_move_implicit_conversion_to_rvalue.cc:10:3: note: no known conversion for argument 1 from ‘Foo’ to ‘MOC&’ boost_move_implicit_conversion_to_rvalue.cc:7:3: note: MOC::MOC(boost::rv<MOC>&) MOC(BOOST_RV_REF(MOC) rhs) : value(rhs.value) {} ^ boost_move_implicit_conversion_to_rvalue.cc:7:3: note: no known conversion for argument 1 from ‘Foo’ to ‘boost::rv<MOC>&’ boost_move_implicit_conversion_to_rvalue.cc:6:3: note: MOC::MOC() MOC() : value(121) {} ^ boost_move_implicit_conversion_to_rvalue.cc:6:3: note: candidate expects 0 arguments, 1 provided //------------------ //End Error Messages //------------------

2 3

[review] Formal review period for VMD library begins today, Aug 21, and ends Sat, Aug 30
by Steven Watanabe 28 Aug '14

28 Aug '14

AMDG The formal review of the VMD library by Edward Diener starts today, Aug 21st and is scheduled to continue until Aug 30th. About VMD =============== The Variadic Macro Data library is a library of variadic macros which enhance the functionality in the Boost preprocessor library ( Boost PP ). The main focus of the library is the parsing/identifying of a subset of C++ preprocessor data types and of all Boost PP data types. This allows enhanced preprocessor metaprogramming based on the type of macro input. The library may also be seen as a repository for future enhancements to the Boost PP library functionality using variadic macros. Where to get it =============== The library is available on github at https://github.com/eldiener/variadic_macro_data Review guidelines ================= Reviews should be submitted to the developer list (boost(a)lists.boost.org) with '[vmd]' in the subject. Or if you don't wish to for some reason, you can send them privately to me. If so, please let me know whether or not you'd like your review to be forwarded to the list. For your review you may wish to consider the following questions: - 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. In Christ, Steven Watanabe

10 35

[Http] Request for comments
by Vinícius dos Santos Oliveira 28 Aug '14

28 Aug '14

I just finished an initial version of the documentation and I'd like to receive your feedback on the library design. The documentation is available online at github[1] and it was generated using Quickbook/Boostbook. This initial version contains everything but the reference. The reference documentation is unavailable at the moment because I was unable to convert Doxygen output into Quickbook output smoothly. I'll do the conversion of current documented entities by hand and proceed to complete missing documentation shortly. I'll send another email when this extra piece is complete. Even with this lacking piece, I feel the current documentation is already useful and I might be able to receive useful feedback from interested ones. The latest version of the library itself is also available at github[2]. [1] http://vinipsmaker.github.io/asiohttpserver/ [2] https://github.com/BoostGSoC14/boost.http -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker

2 5

Re: [boost] poly_collection (was sentinels vs iterators)
by Brian Wood 28 Aug '14

28 Aug '14

Ion Gazta?aga <igaztanaga <at> gmail.com> writes: > > El 23/08/2014 20:53, Joaquin M Lopez Munoz escribi?: >> A container that is not a sequence, unordered but not associative. >> unordered_collection might be an alternative name. Oy vey. > This name misses the critical feature that elements are polymorphic. Why use collection rather than container? poly_container. >> An interesting addition to Boost.Container? > If I had the time :-/ I' ve been considering working a little more on > this to turn the initial sketch into something resembling a full-fledged > container, but it'd take me some days' work I don't have. I couldn't sleep for a while last night and my thoughts turned to this subject. I had thought this was an interesting (birds of a feather) idea and then realized it would also be helpful from a serialization perspective. Rather than having to marshal a type identifier before each instance, you could (iiuc) marshal a type identifier and how many instances will follow. Something like Derived_1_type_id 50 Derived_2_type_id 77 So it would reduce the serialization overhead compared to other containers. I think it's a good idea and look forward to seeing it developed further. -- Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

2 1

Re: [boost] [units] Pull request and RFC: information unit definitions for Boost.Units
by Curdeius Curdeius 27 Aug '14

27 Aug '14

Hi all, I have created a pull request building on top of Erik's proposal. It adds missing zebi and yobi prefixes as defined by IEC. I have also added tests for these prefixes. The only thing is that zebi (2^70) and yobi (2*80) are too large for *long long int*, so I test them with boost::multiprecision::int128_t. Link to PR: https://github.com/boostorg/units/pull/6 Description: I have added zebi and yobi IEC prefixes and corresponding tests for completeness taking Erik's pull request as a base. I am not sure if creating a new PR is a good solution or if there is any way to add a commit directly to the existing one. If you know a better way, I would appreciate any information. Regards, Marek Kurdej I would love to pass the responsibility for ongoing maintenance of > Boost.Units on to a new torchbearer. My time to dedicate to this project > has dwindled to essentially zero, and I believe it would be best for all > involved to enlist some fresh blood, ideally someone who is using the > library on a regular basis... Any volunteers? > As far as Erik's request, I don't have any objections to adding these to > the library, though I have not had time myself to verify that they are > correct. > Matthias > > > > > > ----- Original Message ----- > >> Link to PR: https://github.com/boostorg/units/pull/3 > >> > >> Description: > >> Adds unit definitions for standard units of information: bit, byte, > nat, > >> hartley, shannon. Defines a new unit system boost::units::information > for > >> convenient manipulation. Also includes IEC binary prefixes: kibi, mebi, > >> gibi, tebi, pebi, exbi > >> > >> Example code: > >> > https://github.com/erikerlandson/units/blob/info_units/example/information.… > > >> > >> Unit testing code: > >> > https://github.com/erikerlandson/units/blob/info_units/test/test_informatio… > > > > > > > > > I've been unable to raise a response from either Steven Watanabe or > Matthias Schabel, either on- or off-list. It would be nice to get a thumbs > up or thumbs down so I can make a decision on how to proceed with my other > project. >

5 7

Compile Time String in C++14
by TONGARI J 27 Aug '14

27 Aug '14

Hi all, I found a way to make CT strings in C++14, with the help of generic lambda. FYI, Ábel Sinkovics has presented a c++11 CT string in his mpllibs::metaparse[1] lib before, but it requires some PP trick which has a predefined limit MPLLIBS_LIMIT_STRING_SIZE. The new trick doesn't suffer from the limitation, but it assumes a null-terminated string. It's fairly simple, see below: ```c++ template<char...> struct str {}; template<char c> struct ch {}; template<int n> using idx = std::integral_constant<int, n>; template<class S, char c, char... cs> auto accum(S s, ch<c>, str<cs...>) { return accum(s, s(idx<sizeof...(cs) + 1>()), str<cs..., c>()); } template<class S, char... cs> auto accum(S, ch<0>, str<cs...> ret) { return ret; } template<class S> auto make_str(S s) { return accum(s, s(idx<0>()), str<>()); } #define LIT(s) make_str([](auto idx) { return ch<s[idx.value]>(); }) ``` Then you can use `doSomething(LIT("abc"))` in your code. What do you think? [1] http://abel.web.elte.hu/mpllibs/metaparse/

6 14

Re: [boost] [units] Interest in UDLs (e.g. _kg) for units?
by Marek Kurdej 27 Aug '14

27 Aug '14

> > From: Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> > To: boost(a)lists.boost.org > Date: Mon, 25 Aug 2014 17:16:21 +0200 > Subject: Re: [boost] [units] Interest in UDLs (e.g. _kg) for units? > On 25/08/14 16:03, Sebastian Redl wrote: > > > > > > On 25 Aug 2014, at 13:24, Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> > wrote: > > > >> On 22/08/14 10:08, Curdeius Curdeius wrote: > >>> > >>> Hi all, > >>> > >>> I was wondering if there is any interest in adding User-Defined > Literals > >>> (UDLs) to Boost.Units. > >>> > >>> IMO, it could simplify some code and improve code readability in some > cases. > >>> For example instead of writing (it's a somehow artificial example) > >>> 5.34 * si::milli * si::kilogram; > >>> 1234 * si::kilogram; > >>> one would write > >>> 5.34_g; > >>> 1234_kg; > >> > >> > >> Did you mean to write > >> 5.34_g * si::milli; > >> or > >> 5.34_mg; > >> ? > > > > > > No, to get grams you need si::milli * si::kilogram. I assume the > intention is that the _g suffix already includes that scaling - otherwise > it’d be broken. > > Sorry, I read that too fast. > In any case the idea would be to get suffixes that include all prefix > variants as well. Yes, the idea is to include all the prefix variants as well, so for the mass, we will have: ..., _ng, _ug (?), _mg, _g, _kg, _Mg,_Gg, _Tg, ... And, the fact is, writing si::milli * si::kilogram is counterintuitive as you have just experienced on your own. Marek Kurdej -- Ph.D. candidate

4 4