August 2014 - Boost - lists.preview.boost.org

Problem with BOOST_NO_CXX11_VARIADIC_TEMPLATES in gcc.hpp
by Richard Hadsell 30 Aug '14

30 Aug '14

I think I found a problem in config/compiler/gcc.hpp in Boost 1.56.0. I was trying to come up with a workaround for a bug having to do with variadic templates, when compiling with g++ 4.5.1 (on Linux Fedora 14). Modifying line 160 to turn on BOOST_NO_CXX11_VARIADIC_TEMPLATES for g++ versions earlier than 4.7 had not effect. I discovered that the version test in line 160 has no effect, because it is in a block (lines 153-164) that only pertains to g++ 4.2 or earlier, if compiled with -std=c++0x. The block for versions 4.3 and later (lines 145-151) always define BOOST_HAS_VARIADIC_TMPL and never BOOST_NO_CXX11_VARIADIC_TEMPLATES. I think that is a mistake, at least partially, because proposal N2555 is only supported in version 4.4. At any rate, someone should look at these lines and make some sense of them. The GCC support table shows general support for variadic templates in 4.3 and support for N2555 (with a long name) in 4.4. Furthermore, the bug that produces a message like this: "sorry, unimplemented: cannot expand 'Args ...' into a fixed-length argument list" was only fixed in g++ 4.7.0 (according to a bug report). That issue could also use a guard macro, as was done in one of the boost libraries ( BOOST_CONTAINER_UNIMPLEMENTED_PACK_EXPANSION_TO_FIXED_LIST). -- Dick Hadsell 203-992-6320 Fax: 203-992-6001 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studioshttp://www.blueskystudios.com 1 American Lane, Greenwich, CT 06831-2560

4 8

[exception] Demangling support not merged to master?
by Andrey Semashev 30 Aug '14

30 Aug '14

Hi, Sadly, I discovered that the support for type name demangling in Boost.Exception did not make it into 1.56. It's still not merged to master. The tests look green, could this change be merged to master?

2 3

[move] boost::move incorrect documentation?
by Mostafa 30 Aug '14

30 Aug '14

Here http://www.boost.org/doc/libs/1_56_0/doc/html/boost/move_idp159681920.html it states: "This function provides a way to convert a reference into a rvalue reference in compilers with rvalue references. For other compilers converts T & into ::boost::rv<T> & so that move emulation is activated." But in <boost/move/utility.hpp> I see: template <class T> inline typename ::boost::move_detail::enable_if_c < enable_move_utility_emulation<T>::value && !has_move_emulation_enabled<T>::value, T&>::type move(T& x) { return x; } Therefore shouldn't the above be: "This function provides a way to convert a reference into a rvalue reference in compilers with rvalue references. For other compilers if T is Boost.Move enabled type then it converts T & into ::boost::rv<T> & so that move emulation is activated, else it returns T &."

2 1

Boost Build and -Wall
by Emil Dotchevski 29 Aug '14

29 Aug '14

I see that in Boost Build <warnings>on translates to -Wall. What value do I specify for <warnings> to get the compiler-default warnings level? -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

3 4

Boost Build Qt5 support on MACOSX?
by Emil Dotchevski 29 Aug '14

29 Aug '14

Hello, I downloaded Qt and installed it into its default location on mac os x, then tried to initialize it with: using qt5 : /users/<user_name>/Qt/5.3/clang_64 ; I don't know if the above is the correct way to initialize the qt5 support, but I get bad include directories, e.g. #include <QtGui/QWindow> won't work. Searching the Qt directories reveals that the file QWindow is found under Qt/5.3/clang_64/lib/QtGui.framework/Versions/5/Headers. So what is the right way to do this? -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

1 0

[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 27 Aug '14

27 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 27 Aug '14

27 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 27 Aug '14

27 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

[endian][build] Boost build broken
by Marcel Raad 27 Aug '14

27 Aug '14

Hi, as mentioned on the Boost user mailing list a week ago (http://thread.gmane.org/gmane.comp.lib.boost.user/82429) I cannot build Boost from develop anymore. I just noticed that I can still build individual libraries, only the combination of Boost.System + Boost.Endian (and thus building all of Boost by just running "b2") is broken. "b2 --without-endian" works, "b2 --without- system" doesn't. Does anyone have any idea what the problem could be? The output of "b2 --with-system --with-endian" is: K:/boost/tools/build/src/build\virtual-target.jam:1099: in virtual- target.register-actual-name from module virtual-target error: Duplicate name of actual target: <pstage\lib>libboost_system-vc140- mt-gd-1_57.lib error: previous virtual target { common%common.copy-libboost_system-vc140- mt-gd-1_57.lib.STATIC_LIB { msvc%msvc.archive-libboost_system-vc140-mt-gd -1_57.lib.STATIC_LIB { msvc%msvc.compile.c++-error_code.obj.OBJ { error_code.cpp.CPP } } } } error: created from ./stage-proper error: another virtual target { common%common.copy-libboost_system-vc140-mt- gd-1_57.lib.STATIC_LIB { msvc%msvc.archive-libboost_system-vc140-mt-gd- 1_57.lib.STATIC_LIB { msvc%msvc.compile.c++-error_code.obj.OBJ { error_code.cpp.CPP } } } } error: created from ./stage-proper error: added properties: <asynch-exceptions>off <warnings>on error: removed properties: <asynch-exceptions>on <warnings>all K:/boost/tools/build/src/build\virtual-target.jam:484: in actualize-no- scanner from module object(file-target)@3811 K:/boost/tools/build/src/build\virtual-target.jam:134: in class@virtual- target.actualize from module object(file-target)@3811 K:/boost/tools/build/src\build-system.jam:720: in load from module build- system K:\boost\tools\build\src/kernel\modules.jam:289: in import from module modules K:\boost\tools\build\src/kernel/bootstrap.jam:139: in boost-build from module K:\boost\boost-build.jam:17: in module scope from module

2 4

[Graph] 'traverse' event in DFS visitor concept?
by Jeremy Murphy 27 Aug '14

27 Aug '14

I have been trying to figure out how to use the dfs_visitor to do something every time a vertex is 'traversed', which would be (num_children(v) + 1) times for any given vertex v, for a total of (2n - 1) traversals on a graph of size n. (I have been working on rooted trees, so the application to general graphs may be a bit rough.) The use case is calculation of Eulerian paths, which I occasionally see people asking how to do. So although the dfs_visitor doesn't support this notion of 'traverse', I have been able to simulate it using tree_edge and finish_vertex and some post-processing. If you let "result" be an output iterator in a dfs visitor class with these member functions: template <typename Edge, typename Graph> void tree_edge(Edge const &e, Graph const &g) { *result++ = boost::source(e, g); *result++ = boost::target(e, g); } template <typename Vertex, typename Graph> void finish_vertex(Vertex const &v, Graph const &) { *result++ = v; } Then apply std::unique to the resulting sequence to remove adjacent duplicates, the result is an Eulerian circuit (if one is possible). (Alternatively you could check for duplicate values at time of traversal.) So apart from showing a simple way to calculate Eulerian path/circuit, I wanted to suggest: is it worth adding a 'traverse/visit' event to dfs (or bfs) visitor concept for this kind of use case? It would sure reduce the computation (though not the complexity) required in this case. Cheers. Jeremy

2 3

[graph] strong_components & depth_first_visit feature proposal
by Alexander Lauser 27 Aug '14

27 Aug '14

Hi all, I am writing two minor extensions for Boost.Graph, making strong_components and depth_first_visit more generic. This mail is to assess interest in publishing these features. * Question 1: What about extending strong_components to allow the user to (optionally) hook into DFS-events? The rationale for that is that when computing strong components, one may also be interested in connecting paths between any two distinct vertices in a component. With the ability to hook into the events, the paths can be traced, using tree_edge and back_edge to store paths to/fro the root of the component. One may possibly even allow additional events with respect to the discovery and finishing of components as well as the adding of vertices. What do you think about that? A technical question w.r.t the implementation of such a visitor: Why is the name dispatching for the named parameters of strong_components done "by hand" and not using the same facilities as depth_first_search? (I'm quite new to Boost and most of its notions like named parameters, so I may have missed something trivial. If so I beg to forgive the question.) * Question 2: What about introducing a new (optional) event for finish_tree_edge during a depth_first_visit? This event would be called when backtracking a tree_edge. Even though I cannot give a specific application where such an event would be essential, I still think it's a event during a depth-first-search that is natural enough to allow the user to hook in. (N.b. that similar events finish_back_edge and finish_forward_or_cross_edge would not make sense as they get always called immediately after back_edge and forward_or_cross_edge, respectively.) * Another minor question: Why are not all events of a DFS-visitor optional (like finish_edge is)? I think this would make implementing a partial DFS-visitors easier (by not having to derive from dfs_visitor in order to provide events that one is not interested in). A problem in the implementation of this would be that there is currently a bug (ticket 10231) with the current implementation that makes finish_edge optional. - Alex

2 2

[build] Running b2 with particular toolset invokes other toolsets in user-config.jam
by Edward Diener 27 Aug '14

27 Aug '14

I brought up this issue on the Boost build mailing list and it was eventually ignored, so I will bring it up here again. If I run "b2 toolset=sometoolset" Boost Build ends up invoking other toolsets in my user-config.jam along with "sometoolset" to do the build. This invoking of other toolsets seems not only a waste of time and unnecessary but also wrong in the sense that the invoking of some other toolset in user-config.jam may produce an error. I do not understand the necessity for invoking other toolsets in user-config.jam when I have specified the toolset I want. The practical situation for me which is causing problems with Boost Build behavior, because of the actions described above, is that I have a local setup under Windows where I can run many different versions of gcc/mingw or gcc/mingw64. In order to do this I using a changing symbolic link, on my PATH, to point to any one of many versions of gcc in different directories. I have a file running appropriate commands that switches between the versions. I have also built clang on Windows with a particular gcc version and therefore any invocation of clang looks for the run-time system of that particular version when clang is invoked. So if I "switch" gcc to a version which is not the one wih which i built clang, and then invoke Boost Build with that gcc toolset, clang also gets invoked as explained in the beginning remarks above, and this gives an error from the clang invocation. It is true that Boost Build continues, even after the error message coming from clang, in executing the appropriate jamfile with the particular version of gcc as the toolset. But it is annoying nonetheless to see this error for a toolset I am not even invoking. Cannot something be done in Boost Build so that if I am invoking toolset=x there should be no reason to be trying toolset=y unless it is actually needed for something when using toolset=x ? As for instance when the bjam files specifies some other tool ( doxygen, fop, xsl ) which have to be used.

2 4

[documentation] Incorrect link in prebuilt Win binaries.
by Mostafa 26 Aug '14

26 Aug '14

1) Download and install boost_1_56_0-msvc-8.0-64 2) Open libs/libraries.htm 3) Click the link for static_assert 4) Wrong 2nd link in the following message: Automatic redirection failed, please go to ../../doc/html/boost_staticassert.html or view the online version at http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/boost_stati…

1 0

Building boost on osx 10.9 mavericks
by Jerome Laurens 26 Aug '14

26 Aug '14

Hi I could build boost 1.56 on macosx 10.9 for 10.9 but I do not manage to build boost on macosx 10.9 targeting macosx 10.8. It seems that darwin.jam does not recognize the installed SDKs such that I cannot use macosx-version feature. Now the developer resources are no longer in the /Developer folder but in /Applications/.../Xcode.app/Contents/Developer I tried to symlink this folder from /, I also tried a root=... argument to no avail. Any hint ? Tia Jérôme LAURENS

1 0

Movable but not copyable bug?
by Mostafa 26 Aug '14

26 Aug '14

I had posted this on the user's list but I think this should be brought to the attention of the developers. The following code contains a templated copy constructible Boost.Move enabled class (Bar) with a single non-copy constructible Boost.Enabled member (Foo). If Bar's copy constructor is not explicitly defined then the code compiles with both g++ 4.8.2 and VS2005, else if it's explicitly defined then it fails to compile on g++ 4.8.2 I think this is due to the fact that g++ 4.8.2 erroneously instantiates Bar's default copy constructor in the latter case. Is this a Boost.Move bug or a gcc bug? #include <boost/move/core.hpp> #include <boost/move/utility.hpp> struct Foo { Foo(int x, int y) {} Foo(BOOST_RV_REF(Foo) rhs) {} private: //Purposefully declared and not defined. Foo & operator=(Foo); private: BOOST_MOVABLE_BUT_NOT_COPYABLE(Foo) }; template <typename T> struct Bar { Bar() : f(0, 1) {} // (1) //Bar(Bar const & rhs) //: f(rhs.f) //{} Bar(BOOST_RV_REF(Bar) rhs) : f(::boost::move(rhs.f)) {} private: //Purposefully declared and not defined. Bar & operator=(Bar); private: BOOST_COPYABLE_AND_MOVABLE(Bar) private: T f; }; Foo f1() { return Foo(0, 1); } Bar<Foo> f2() { return Bar<Foo>(); } int main() { // Foo f( f1() ); Bar<Foo> b(( Bar<Foo>() )); // Bar<Foo> b1; // Bar<Foo> b2(b1); return 0; }

4 14

[Range] compilation error with mfc-iteration-support
by Tobias Loew 26 Aug '14

26 Aug '14

Hi, moving parts of range_const_iterator to the namespace range_detail in file boost/range/const_iterator.hpp leads to ambiguity in /range/detail/mfc.hpp line 747: 25>..\src\libs\boost\boost\boost/range/mfc.hpp(747): error C2872: 'range_const_iterator' : ambiguous symbol 25> could be '..\src\libs\boost\boost\boost/range/const_iterator.hpp(67) : boost::range_const_iterator' 25> or '..\src\libs\boost\boost\boost/range/const_iterator.hpp(40) : boost::range_detail::range_const_iterator' 25> ..\src\libs\boost\boost\boost/range/detail/microsoft.hpp(135) : see reference to class template instantiation 'boost::range_detail_microsoft::customization<Tag>::meta<X>' being compiled 25> with 25> [ 25> Tag=CEbsValueArray::mfc_range_base_type, 25> X=CTypedPtrArray<CObArray,EbsValue *> 25> ] 25> ..\src\libs\boost\boost\boost/range/begin.hpp(111) : see reference to class template instantiation 'boost::range_detail_microsoft::const_iterator_of<T>' being compiled 25> with 25> [ 25> T=CTypedPtrArray<CObArray,EbsValue *> 25> ] ... changing the name of boost::range_detail::range_const_iterator to boost::range_detail::range_const_iterator_helper resolves the problem. I expect other begin/end adapters to run into the same problem. Tobias -- View this message in context: http://boost.2283326.n4.nabble.com/Range-compilation-error-with-mfc-iterati… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

[endian] Boost.Endian library added for 1.57.0
by Beman Dawes 26 Aug '14

26 Aug '14

The library provides integer and floating point types and conversion functions for portable byte ordering regardless of processor endianness. Although the primary uses are for file or network I/O, it is also useful for unaligned integers or floats, or for 3, 5, 6, and 7 byte integers. The library's predecessors have been in use for thirty years and developed independently multiple times. The repository is https://github.com/boostorg/endian The documentation is online at https://boostorg.github.io/endian/ See https://boostorg.github.io/endian/index.html#Release-history for changes since the Formal Review. No need to report "Inspection Report" problems; those will be cleaned up before 1.57.0 ships. Please do report any other problems or concerns, since the time between now and when the 1.57.0 beta ships in effect acts a mini-review period. If anyone has access to a big-endian platform with a modern C++ compiler, please, please run the endian test suite and report the results. All testing and use in recent years has been on little-endian platforms, so big-endian platform testing is a worry. Thanks for you patience, --Beman

7 9

Align and TypeIndex are missing in components list
by Antony Polukhin 25 Aug '14

25 Aug '14

Hi, It is impossible to create a ticket for TypeIndex or Align libraries in track (https://svn.boost.org/trac/boost/newticket) -- Best regards, Antony Polukhin

2 1