- Boost - lists.preview.boost.org

[build] Test marked as compile-fail is now reported as a failure.
by Adam Wulkiewicz 12 Jan '15

12 Jan '15

Hi, Since yesterday one test marked as compile-fail is now reported as a failure on the regression tests page. It's the test: rtree_values_invalid on the page: http://www.boost.org/development/tests/develop/developer/geometry-index.html Surprisingly other tests aren't. see e.g.: geographic_custom_point_with_wrong_units on the page: http://www.boost.org/development/tests/develop/developer/geometry.html They seem to be defined the same way in the Jamfile: https://github.com/boostorg/geometry/blob/develop/index/test/rtree/Jamfile.… https://github.com/boostorg/geometry/blob/develop/test/point_concept/Jamfil… AFAIS the oldest run when it failed was of the runner: teeks99-03c-Ubuntu12.04-64 on Sat, 10 Jan 2015 02:05:44. On Fri, 09 Jan 2015 18:36:55 (teeks99-08b-win2012R2-64on64) everything was ok. Furthermore when run locally it's also reported as a failure. Some time ago of course "(failed-as-expected)" message was printed instead. Do you have any idea what may be wrong? Regards, Adam

2 1

[filesystem] Problems with UTF-8 paths in GIT.
by Rene Rivera 12 Jan '15

12 Jan '15

This commit < https://github.com/boostorg/filesystem/commit/785d521b54140763dd23ef091a18d…> is causing me some problems with some git clients. In particular the git client in Eclipse errors out with some unsupported / invalid messages. I know why those dir names are the way they are.. But we still are supposed to follow the naming rules we agreed to < http://www.boost.org/development/requirements.html#Directory_structure>. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 1

About a Ratio/MPL submodule and removing dependencies from Ratio/Chrono on MPL.
by Vicente J. Botet Escriba 10 Jan '15

10 Jan '15

Hi, Boost.Ratio has a logical submodule providing an extension to the standard see boost::ratio as an MPL type adding struct rational_c_tag : int_<10> {}; This submodule could be moved to the subdirectory of libs/ratio/mpl so that the users of boost::ratio, shouldn't depend on MPL. Boost.Chrono depends already on MPL, but the dependencies are really minor - see below (and can be replaced by StaticAssert and TypeTraits, so that this dependency could be removed also. Do you think removing the dependencies of Boost.Ratio and Boost.Chrono on Boost MPL has value? Best, Vicente P.S. I know that currently TypeTraits depends on MPL, but we expect to resolve this dependency already. |<boost/mpl/assert.hpp>| * from |<boost/chrono/detail/static_assert.hpp>| |<boost/mpl/bool.hpp>| * from |<boost/chrono/detail/static_assert.hpp>| |<boost/mpl/if.hpp>| * from |<boost/chrono/io/duration_get.hpp>| * from |<boost/chrono/io_v1/chrono_io.hpp>| |<boost/mpl/logical.hpp>| * from |<boost/chrono/detail/is_evenly_divisible_by.hpp>| * from |<boost/chrono/duration.hpp>|

3 2

[variant] match()
by Eelis 10 Jan '15

10 Jan '15

Boost.Variant provides access through get() and visitors, but in C++11 we can do so much better! :) For a boost::variant<A,B,C>, the attached small utility function match() lets you write: match(v, [](A & a){ cout << "it's a A!"; } [](B & b){ cout << "oh, a B!"; } [](C & c){ cout << "ah yes, a C!"; }); Return values are supported. I think this really belongs in Boost. It makes variants much more usable. Regards, Eelis P.S. I have not attempted a C++98 implementation. P.S.2. Right after finishing my implementation, I discovered another, /vastly/ more complex implementation of the same thing: https://github.com/exclipy/inline_variant_visitor I'm not sure its complexity gives that implementation any advantages.

9 26

Moving files around
by John Maddock 10 Jan '15

10 Jan '15

Can I just fire a shot across the bows before we all get too carried away moving files around here there and everywhere? *The move has to make logical sense* - reducing dependencies is a worthy goal, but not if it makes stuff harder to maintain and/or harder for the user to find what they're looking for. Let me give you a trivial example: boost/utility/declval.hpp was moved into the type_traits repository to reduce dependencies on utility. OK fair enough. But I see no tests or docs, and the docs at the very least are still in "utility". So now we have a situation where maintenance of that functionality is split over two repositories each with different maintenance teams. That's not good. Perhaps more to the point, if I'm a user and I'm looking for boost/something/whatever.hpp, it had better darn well be in package "something" or I'm going to be pretty annoyed. This applies equally to folks wanting to use "whatever.hpp" as to folks wanting to submit pull requests. In fact if the above doesn't hold I suspect that a) Folks will give up and reinvent smaller utilities for themselves. b) Use an older version of Boost ("I new where everything was there"). c) Not submit bug reports or pull requests cause they can't figure out where they should go. I guess what I'm saying is that while re-factoring is a good idea, it needs a vision to improve "discover-ability" and make Boost's structure more logical, not merely easier for a package manager. Now please do carry on as you were ;) John.

3 2

[functional] How to avoid a dependency on functional?
by Beman Dawes 10 Jan '15

10 Jan '15

Filesystem has a dependency on <boost/functional/hash_fwd.hpp> in order to supply this: inline std::size_t hash_value(const path& x) { # ifdef BOOST_WINDOWS_API std::size_t seed = 0; for(const path::value_type* it = x.c_str(); *it; ++it) hash_combine(seed, *it == '/' ? L'\\' : *it); return seed; # else // BOOST_POSIX_API return hash_range(x.native().begin(), x.native().end()); # endif } The problem with this is that functional is a heavy-weight dependency for such relatively minor feature. See http://www.pdimov.com/tmp/report-develop-3b5a9f4/module-weights.html Is there any recommended way to avoid the functional dependency? Thanks, --Beman

5 14

[Boost.Filesystem] unique_path uses a random number generator from the OS, correct?
by Ben Fritz 09 Jan '15

09 Jan '15

The reference docs for unique_path state: Remarks: Implementations are encouraged to obtain the required randomness via a cryptographically secure pseudo-random number generator, such as one provided by the operating system. I'm confused by the "implementations are encouraged to" text. Isn't Boost.Filesystem the implementation of unique_path? Specifically, it *looks like* this is provided in unique_path.cpp which will use either CryptGenRandom from the Windows API; or /dev/urandom or /dev/random on POSIX systems. This means the random number comes from system/OS utilities, and not Boost itself, correct? -- Ben Fritz

2 1

A proposal for the creation of a new module, Core Type Traits
by Peter Dimov 09 Jan '15

09 Jan '15

This is a more formal statement of the same suggestion I've already given in other threads. Currently, library developers who need type traits functionality face a choice: either to use the TypeTraits library, and make their libraries dependent on MPL, Preprocessor, TypeOf and Utility, or to duplicate its functionality locally. Similarly, developers who want to specialize a type trait on a type of theirs, even a trivial empty struct, need to include the TypeTraits headers for the traits to be specialized, which brings in MPL and Preprocessor on a header-level, and makes their module dependent on TypeTraits and its dependencies listed above. Local replication, as in Boost.Move, rightly attracts charges of code duplication, with the associated potential maintenance problems when the implementations diverge. These two problems could be avoided if we were to have core type traits whose interface consisted solely of a member integral constant called "value", without any other required members or base classes, and which were only allowed to depend on Config or StaticAssert. This solves the second problem because it will then be possible for a developer to specialize a trait, such as is_pod, by using a forward declaration of the form template< class T > struct is_pod; in the appropriate namespace, like boost::core_type_traits, and then adding his specializations: template<> struct is_pod< blank > { BOOST_STATIC_CONSTANT( bool, value = true ); }; without including ANY additional headers. If we look at the current implementation of Boost.TypeTraits, for example is_pointer, we see this: template< typename T > struct is_pointer_impl { BOOST_STATIC_CONSTANT(bool, value = (::boost::type_traits::ice_and< ::boost::detail::is_pointer_helper<typename remove_cv<T>::type>::value , ::boost::type_traits::ice_not< ::boost::is_member_pointer<T>::value >::value >::value) ); }; in namespace detail, and then this: BOOST_TT_AUX_BOOL_TRAIT_DEF1(is_pointer,T,::boost::detail::is_pointer_impl<T>::value) which takes care of everything else. Note that is_pointer_impl is EXACTLY what we need! It is the core implementation of the trait and exposes only ::value and nothing else. The full-featured boost::is_pointer is built on top of that. If detail::is_pointer_impl was called core_type_traits::is_pointer, this would immediately take care of the two problems at the top of this post, while not affecting the users of Boost.TypeTraits in any way. In particular, note that if a developer specializes detail::is_pointer_impl, is_pointer automatically picks up this specialization. Therefore, I propose that a new module, libs/core_type_traits, is created, which: - provides core type traits that only expose a member integral constant called "value" as part of its documented interface and nothing else; - allows these traits to be forward declared, without requiring header inclusion; - is not allowed to depend on anything except Config or StaticAssert; - is the place to which TypeTraits's is_pointer_impls gradually migrate, along with their tests. This - solves the dependency problems some of us are facing, - avoids unnecessary code duplication, - still allows type trait specialization, with clients of both libraries automatically picking up the specialization, - is backward compatible with respect to existing uses of Boost.TypeTraits because the new library will contain the same code and the same tests. Thank you for your attention. :-)

4 8

bpm added to tools/bpm on develop
by Peter Dimov 09 Jan '15

09 Jan '15

I've added bpm, the Boost Package Manager, to tools/bpm on develop. To build it, do b2 tools/bpm/build//install at the Boost root and b2 will build bpm with the default toolset and place it in dist/bin. To try it out, first you might want to review the fs_remove_all function in fs.cpp, or use a drive or filesystem that does not hold valuable files, :-) then make an empty directory, copy bpm(.exe) there, make a text file bpm.conf with the following line: package_path=http://www.pdimov.com/tmp/pkg-develop-1612497/ then do f.ex. "bpm install filesystem". pkg-develop-1612497 is just a sample "release" that I made by running tools\bpm\scripts\package.bat at the root of my source tree, which happened to be at revision 1612497 of develop. It therefore contains Windows line endings (and b2.exe), so it will generally not be suited for installation on non-Windows systems. A POSIX release would need to be prepared from a POSIX source tree and will probably need to install bootstrap.sh instead of b2.exe, with bpm then issuing a message that ./bootstrap.sh needs to be run. I've done my development on Windows so far and have not had time to test on POSIX.

2 3

Road to low-quality-code is paved with good intentions of dropping dependencies
by Antony Polukhin 09 Jan '15

09 Jan '15

Hi all, I've been looking through the latest changes to drop dependencies. Stuff that I saw is very frightening. For example: https://github.com/boostorg/move/blob/develop/include/boost/move/detail/typ… . Every boost release some issues are fixed in intrinsics of TypeTraits and is_move_* is_nothrow_* traits. Copy-pasting code from TypeTraits feels like loading a gun and pointing it on own foot. Another example is a sad story of boost::swap. We can not use Boost.Move here because it will add "a lot of dependencies" to Boost.Core. This leads us to nonoptimal implementation, which is sad. The Solution Almost *all* of the Boost libraries depend on TypeTraits, MPL, Core, Assert, StringRef. Language emulation features implemented in Exception, Move, StaticAssert, TypeIndex should be also widely used. hash_fwd.hpp must be used by almost all the containers and structures. So may be we should think of those libraries as of "base" libraries! I do not mean that they must be moved in a single "base" folder. I'm talking only about dependency reports: those libraries must be treated by the dependency tool as a single one and must have the level 1. Those libraries are "base", because they are the very common part of Boost framework. Not using them is more like a bad decision, reimplementing parts of them is an afwull decision. Threating them as base/common/core/main part of Boost seems reasonable. -- Best regards, Antony Polukhin

15 34