January 2015 - Boost - lists.boost.org

[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

[bpm] Option to skip test dependencies?
by Beman Dawes 09 Jan '15

09 Jan '15

In looking at the Boost Package Manager [bpm] options, there is one omission I suspect users will ask for right away: an option to skip dependencies created by tests and perhaps examples. Is it possible to experiment with some simple strategy, like skipping the dependency check for "test" libraries to see what effect this has? Thanks, --Beman

2 1

ATTN library maintainers: libraries missing metadata files
by Peter Dimov 08 Jan '15

08 Jan '15

The following libraries are currently missing the metadata file meta/libraries.json, which describes the library: libs/algorithm/meta/libraries.json does not exist libs/assign/meta/libraries.json does not exist libs/bimap/meta/libraries.json does not exist libs/compatibility/meta/libraries.json does not exist libs/detail/meta/libraries.json does not exist libs/disjoint_sets/meta/libraries.json does not exist libs/function_types/meta/libraries.json does not exist libs/graph_parallel/meta/libraries.json does not exist libs/icl/meta/libraries.json does not exist libs/iostreams/meta/libraries.json does not exist libs/locale/meta/libraries.json does not exist libs/local_function/meta/libraries.json does not exist libs/numeric/meta/libraries.json does not exist libs/parameter/meta/libraries.json does not exist libs/ptr_container/meta/libraries.json does not exist libs/python/meta/libraries.json does not exist libs/random/meta/libraries.json does not exist libs/range/meta/libraries.json does not exist libs/rational/meta/libraries.json does not exist libs/scope_exit/meta/libraries.json does not exist libs/serialization/meta/libraries.json does not exist libs/statechart/meta/libraries.json does not exist libs/sync/meta/libraries.json does not exist libs/typeof/meta/libraries.json does not exist libs/type_erasure/meta/libraries.json does not exist libs/uuid/meta/libraries.json does not exist libs/winapi/meta/libraries.json does not exist Many of those libraries already have pull requests that contain the file. Please accept them and then merge them to master as well. :-) The file format is documented here: http://www.boost.org/development/library_metadata.html

2 3

Boost.Sort library hierarchy and namespacing
by Steven Ross 08 Jan '15

08 Jan '15

For the Boost.Sort library, I'm planning to add these (non-detail) files: boost/sort/sort.hpp boost/sort/spreadsort/spreadsort.hpp boost/sort/spreadsort/integer_sort.hpp boost/sort/spreadsort/float_sort.hpp boost/sort/spreadsort/string_sort.hpp Should all of these be in the boost::sort namespace? It seems silly to have a boost::sort::spreadsort namespace when there are only 5 publicly-visible functions in it. I actually can't imagine how of these names will conflict with names in other boost libraries, but using a boost::sort namespace appears conventional. Are there any objections or concerns based on this? Once this is done, I'd like to integrate this library into the boost build and testing system for the next appropriate release (I test it currently with modular boost).

2 2

Directory structure not quite right yet?
by Peter Dimov 08 Jan '15

08 Jan '15

Typically, when some library is installed in, say, $LIB, its headers reside in $LIB/include and its .a/.lib files in $LIB/lib. Our libraries, when built, go to $BOOST/stage/lib, which is close enough. But our header directory is just $BOOST, which doesn't seem right, as the whole of Boost is accessible through it. It makes sense, at least to me, to have the headers in $BOOST/include/boost, instead of just $BOOST/boost. The transition to Git would have been a good time to switch to that - there were enough other changes to the structure. I'm not saying that we should switch right away or something like that, but am I the only one to whom such a switch (at some unspecified time in the future) seems a good idea?

12 41

Is TypeOf library maintained?
by Adam Wulkiewicz 08 Jan '15

08 Jan '15

Hi, I'm asking because the most recent change in develop was done in 2013 and the last merge to master (or rather SVN release) was done in 2011. Would it be possible to along with the metadata PR have this trivial fix merged: https://github.com/boostorg/typeof/pull/1 ? It hangs there more than a half year. Thanks, Adam

2 1

New dependency report
by Peter Dimov 08 Jan '15

08 Jan '15

Here: http://www.pdimov.com/tmp/report-develop-3b5a9f4/module-overview.html http://www.pdimov.com/tmp/report-develop-3b5a9f4/module-levels.html and (new) here: http://www.pdimov.com/tmp/report-develop-3b5a9f4/module-weights.html "Weight" is on how many other modules a module depends, both directly and indirectly.

1 0