October 2015 - Boost - lists.preview.boost.org

Boost perf tests?
by Stephan T. Lavavej 03 Oct '15

03 Oct '15

Hi Boost devs, Does Boost have any runtime perf tests? We (MSVC) are looking for something that uses modern C++, which would reveal areas where our optimizer and libraries could be improved. I looked around briefly, but didn't find anything. Thanks, STL

6 6

[optional] Specializing optional to save space
by David Stone 03 Oct '15

03 Oct '15

Andrzej posted another thread about creating a new compact_optional class. The goal of this class is to make it easy to create a new optional type with a special sentinel value. This allows easy customization per instance of an optional value. This post is about the opposite approach: making it easier to specialize optional to provide special behavior for all instances of a given optional type. When I bring this up, people often compare it to the vector<bool> specialization, but this is a completely different issue. The problem of vector<bool> is that it does not actually store a bool anywhere, so it cannot return a reference to one. This would still store a T somewhere. For the rest of the discussion, I will be assuming a typical standard library implementation on a 64-bit system. Whenever I talk about specific sizes of objects, mentally insert "on most common systems". The principles apply generally. Consider the case of optional<std::string>. Using the naive implementation, this object is 8 bytes larger than std::string, due to alignment requirements. However, there are certain representations of std::string that are not actually possible. For instance, for common implementations of std::string you cannot have std::string::size() == std::numeric_limits<std::string::size_type>::max() *. We can take advantage of this if our std::string implementation stores the capacity as an integer value, rather than a pointer to the end of the storage. Therefore, we could have implementations that look something like this: class string { friend optional<string>; }; template<> class optional<std::string> { optional(none_t) { // Use friendship to just set capacity to sentinel value } explicit operator bool() const { return m_data.capacity() == std::numeric_limits<std::string::size_type>::max(); } }; optional<std::string> still stores std::string in it, so operator*() works just fine. The initialized check is still just comparing a field against a compile-time constant. This makes this purely a space optimization that cannot be detected by the user, unless they use sizeof(optional<std::string>). I believe all of this is possible today with the current specification of boost::optional (and would definitely be allowed for the proposed std::experimental::optional). However, this requires the creator of each specialization to implement the full optional interface. What's more, it is especially tricky to specialize optional for a class template when you only want to specialize on certain specializations of the class template. My use case for this is my bounded::integer library. This library lets you specify the bounds of your integer as template parameters. If your bounded::integer has a narrower range than its underlying integer, you can take advantage of this to make a more space-efficient optional. If, however, the bounded::integer min and max are equal to that of the underlying type, there is no extra space and we want the default optional implementation. With the current specialization approach, it is the responsibility of the specializer to reimplement all of optional. A better approach to easily support this space optimization is as follows: optional contains an instance of optional_storage<value_type>. optional_storage has a much narrower interface: * optional_storage() leaves it uninitialized * optional_storage(in_place_t, T && ...) constructs the value directly with the variadic arguments * emplace(T && ...) constructs an object when there may be one in existence already * reset() destroys the contained object and sets the storage to uninitialized * is_initialized() says whether the contained object is initialized. This could be replaced with explicit operator bool(); I have no preference. * value() returns a reference to the value We need both the constructor and the emplace function to allow literal optional types. This is because for the general case, emplace calls placement new, which is not allowed in a constexpr function. This solves the problem of specializers having to implement the entire interface of optional just to change how the uninitialized state is stored. However, it still does not solve the problem I mentioned earlier about allowing easy use of the default storage policy for some specializations of your own class template. To solve that, we need one more class: default_optional_storage. default_optional_storage<T> is a literal type if T is a literal type (in practice, std::is_trivially_destructible<T>::value is all you really need to test). It implements the same interface as optional_storage<T>. The default implementation of optional_storage<T> is template<typename T> struct optional_storage : default_optional_storage<T> { private: using base = default_optional_storage<T>; public: using base::base; }; This means that the optional library would have at least three classes in its public interface: * optional * optional_storage * default_optional_storage To see a working example of this (including a specialization for bounded::integer), see https://bitbucket.org/davidstone/bounded_integer/src/2defec41add2079ba023c2… https://bitbucket.org/davidstone/bounded_integer/src/2defec41add2079ba023c2… * The reason is that std::string::size_type is a typedef for std::size_t, which is equivalent in range to std::uint64_t. However, std::iterator_traits<std::string::iterator>::difference_type is std::ptrdiff_t, which is equivalent in range to std::int64_t. This means that for the largest std::string, std::distance(begin(), end()) cannot be more than std::numeric_limits<std::ptrdiff_t>::max(), which is less than std::numeric_limits<std::size_t>::max().

6 15

[type_traits] common_type errors with Oracle compiler
by Andrey Semashev 03 Oct '15

03 Oct '15

Hi, Both oracle-intel-S2-next-cpp11 and oracle-sparc-S2-next-stlport4 testers fail to compile common_type as it is being used in Boost.Chrono. This in turn affects compilation of Boost.Thread and multiple other library tests. The error can be seen here: http://www.boost.org/development/tests/develop/developer/output/oracle-inte… Just in case if the test results go down, I'm copying the error inline below. Could it be fixed? "CC" -std=c++11 -temp=/tmp/bn -xO4 -mt -erroff=%none -m32 -KPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_DLL=1 -DNDEBUG -D__typeof__=__typeof__ -I".." -c -o "/export/home/sstrunk-tester/boost_regression/boost_regression_develop/boost_intel-S2_cpp11/results/boost/bin.v2/libs/atomic/test/atomicity.test/sun-next_cpp11/release/threading-multi/atomicity.o" "../libs/atomic/test/atomicity.cpp" "../boost/chrono/duration.hpp", line 405: Error: type is not a member of boost::common_type<long long, long long>. "../boost/thread/pthread/timespec.hpp", line 52: Where: While specializing "boost::common_type<boost::chrono::duration<long long, boost::ratio<1, 1000000000>>, boost::chrono::duration<long long, boost::ratio<1, 1>>>". "../boost/thread/pthread/timespec.hpp", line 52: Where: Instantiated from boost::chrono::operator-<Rep1, Period1, Rep2, Period2>(const duration<Rep1, Period1>&, const duration<Rep2, Period2>&). "../boost/thread/pthread/timespec.hpp", line 52: Where: Instantiated from non-template code. "../boost/chrono/duration.hpp", line 406: Error: A declaration does not specify a tag or an identifier. "../boost/thread/pthread/timespec.hpp", line 52: Where: While specializing "boost::common_type<boost::chrono::duration<long long, boost::ratio<1, 1000000000>>, boost::chrono::duration<long long, boost::ratio<1, 1>>>". "../boost/thread/pthread/timespec.hpp", line 52: Where: Instantiated from boost::chrono::operator-<Rep1, Period1, Rep2, Period2>(const duration<Rep1, Period1>&, const duration<Rep2, Period2>&). "../boost/thread/pthread/timespec.hpp", line 52: Where: Instantiated from non-template code. "../boost/chrono/duration.hpp", line 406: Error: Use ";" to terminate declarations. "../boost/thread/pthread/timespec.hpp", line 52: Where: While specializing "boost::common_type<boost::chrono::duration<long long, boost::ratio<1, 1000000000>>, boost::chrono::duration<long long, boost::ratio<1, 1>>>". "../boost/thread/pthread/timespec.hpp", line 52: Where: Instantiated from boost::chrono::operator-<Rep1, Period1, Rep2, Period2>(const duration<Rep1, Period1>&, const duration<Rep2, Period2>&). "../boost/thread/pthread/timespec.hpp", line 52: Where: Instantiated from non-template code. "../boost/chrono/duration.hpp", line 406: Error: "}" expected instead of ">". "../boost/thread/pthread/timespec.hpp", line 52: Where: While specializing "boost::common_type<boost::chrono::duration<long long, boost::ratio<1, 1000000000>>, boost::chrono::duration<long long, boost::ratio<1, 1>>>". "../boost/thread/pthread/timespec.hpp", line 52: Where: Instantiated from boost::chrono::operator-<Rep1, Period1, Rep2, Period2>(const duration<Rep1, Period1>&, const duration<Rep2, Period2>&). "../boost/thread/pthread/timespec.hpp", line 52: Where: Instantiated from non-template code. "../boost/thread/pthread/timespec.hpp", line 52: Error: The operation "const boost::chrono::duration<long long, boost::ratio<1, 1000000000>> - boost::chrono::duration<long long, boost::ratio<1, 1>>" is illegal. 5 Error(s) detected.

3 4

Compiler warnings after boost update
by Auer, Jens 03 Oct '15

03 Oct '15

Hi, we compile with high compiler warnings setting (-Wall, -Wpedantic), and treat compiler warnings as errors. Recently, I had to upgrade the boost library version from 1.53 to at least 1.55. Since there was no package available, I compiled it by hand from the source code. With 1.53, everything compiled fine, but with the newer version my builds now break because the boost library generates a lot of warnings, e.g. /cots/boost-1.55/include/boost/iterator/iterator_concepts.hpp: At global scope: /cots/boost-1.55/include/boost/mpl/assert.hpp:288:54: error: use of old-style cast [-Werror=old-style-cast] boost::mpl::assert_arg( (void (*) pred)0, 1 ) \ ^ /cots/boost-1.55/include/boost/mpl/assert.hpp:59:58: note: in definition of macro ‘BOOST_MPL_AUX_ASSERT_CONSTANT’ # define BOOST_MPL_AUX_ASSERT_CONSTANT(T, expr) enum { expr } /cots/boost-1.55/include/boost/range/algorithm/equal.hpp: In function ‘bool boost::range::equal(const SinglePassRange1&, const SinglePassRange2&, BinaryPredicate)’: /cots/boost-1.55/include/boost/concept/detail/general.hpp:71:20: error: typedef ‘boost_concept_check185’ locally defined but not used [-Werror=unused-local-typedefs] BOOST_PP_CAT(boost_concept_check,__LINE__) /cots/boost-1.55/include/boost/property_tree/xml_parser.hpp:52:59: required from ‘void boost::property_tree::xml_parser::read_xml(std::basic_istream<typename Ptree::key_type::value_type>&, Ptree&, int) [with Ptree = boost::property_tree::basic_ptree<std::basic_string<char>, std::basic_string<char> >; typename Ptree::key_type::value_type = char; typename Ptree::key_type::value_type = char]’ /home/auerj/MDAF/src/commons/src/crypto/KeyFileReader.cpp:43:34: required from here /cots/boost-1.55/include/boost/property_tree/detail/rapidxml.hpp:1204:33: error: zero as null pointer constant [-Werror=zero-as-null-pointer-constant] if (first_attribute()) ^ /cots/boost-1.55/include/boost/property_tree/detail/rapidxml.hpp:1204:33: error: zero as null pointer constant [-Werror=zero-as-null-pointer-constant] /cots/boost-1.55/include/boost/property_tree/detail/rapidxml.hpp:1211:45: error: zero as null pointer constant [-Werror=zero-as-null-pointer-constant] These are just some examples, there are literally hundreds of warnings. It is enough to just include ptree.hpp, but other headers have the same issue. I am wondering why this came up after the update. Is it a configuration problem during the build of the boost libraries, or is it an issue in the boost libraries? I find it hard to believe that the code quality changed so much between the versions. What is the policy of the boost project concerning compiler warnings in installation headers? I would assume that the libraries should compile without warnings on supported compilers, either because there are no issues, or because warnings are disabled in the boost headers. Best wishes, Jens -- Jens Auer | CGI | Software-Engineer CGI (Germany) GmbH & Co. KG Rheinstraße 95 | 64295 Darmstadt | Germany T: +49 6151 36860 154 jens.auer(a)cgi.com<mailto:jens.auer@cgi.com> Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter de.cgi.com/pflichtangaben<http://de.cgi.com/pflichtangaben>. CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to CGI Group Inc. and its affiliates may be contained in this message. If you are not a recipient indicated or intended in this message (or responsible for delivery of this message to such person), or you think for any reason that this message may have been addressed to you in error, you may not use or copy or deliver this message to anyone else. In such case, you should destroy this message and are asked to notify the sender by reply e-mail.

10 14

[build][regression] Problems when trying to run automated regression tests for MSVC-7.1
by Ion Gaztañaga 03 Oct '15

03 Oct '15

Hi, Since Boost 1.55 minimum requirements include Visual C++ 2003. Since currently there is no regression report for this compiler, I'm trying to follow the steps detailed here and try to fill the gap: http://www.boost.org/development/running_regression_tests.html All the source code is downloaded, my user-config.jam only contains "using msvc ;" but it seems that Boost.Build continues to be broken for MSVC-7.1: <output> notice: Loading user-config configuration file 'user-config.jam' from 'C:/Users/igaztanaga'. notice: [msvc-cfg] msvc-7.1 detected, command: 'C:\Program Files (x86)\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe' notice: will use 'C:\Program Files (x86)\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe' for msvc, condition <toolset>msvc-7.1 C:/boost/develop/boost_bb/src/tools\msvc.jam:1072: in configure-really *** argument error * rule generate-setup-cmd ( version : command : parent : options * : cpu : global-setup : default-global-setup-options : default-setup ) * called with: ( 7.1 : C:\Program Files (x86)\Microsoft Visual Studio .NET 2003\Vc7\bin : C:\Program Files (x86)\Microsoft Visual Studio .NET 2003\Vc7 : <command>C:\Program Files (x86)\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe : i386 : : x86 : vcvars32.bat ) * missing argument global-setup C:/boost/develop/boost_bb/src/tools\msvc.jam:798:see definition of rule 'generate-setup-cmd' being called C:/boost/develop/boost_bb/src/tools\msvc.jam:201: in configure C:/boost/develop/boost_bb/src/tools\msvc.jam:153: in msvc.init C:/boost/develop/boost_bb/src/build\toolset.jam:43: in using C:\Users\igaztanaga\user-config.jam:49: in modules.load c:/boost/develop/boost_bb/src\build-system.jam:249: in load-config c:/boost/develop/boost_bb/src\build-system.jam:389: in load-configuration-files c:/boost/develop/boost_bb/src\build-system.jam:524: in load C:\boost\develop\boost_bb\src/kernel\modules.jam:295: in import C:\boost\develop\boost_bb\src/kernel/bootstrap.jam:139: in boost-build C:\boost\develop\boost_regression\boost-build.jam:57: in module scope </output> I can't figure out what's wrong in msvc.jam. Comments on that file suggest that MSVC-7.1 should be supported although it seems that since MSVC-8.0 the configuration script architecture changed. I'd be glad if any Boost.Build expert could have a look at this issue. Many thanks, Ion PS: Full output for command... python run.py --runner=igaztanaga --toolsets=msvc-7.1 --tag=develop --incremental --libraries=move --have-source > output.txt ...attached.

2 4

compact_optional -- prompting interest
by Andrzej Krzemienski 02 Oct '15

02 Oct '15

Hi Everyone, I would like to inquire if there would be an interest in Boost in another library for storing optional objects, but working under different design goals. Compact optional T has (or can have) the same sizeof as T. It uses one indicated value of T to represent the "empty" (or "singular") value. You can declare it like this: compact_optional<evp_int<int, -1>> oi; This reads: we have an optional int, with type int inside, where -1 represents the empty value. It can never have a genuine (non-empty value -1). This can be used, for instance, to wrap the std::string::npos into: compact_optional<evp_int<string::size_type, string::npos>> With the same memory layout as std::string::size_type, but with the special syntax for managing the singular value. It is not meant to be an alternative to Boost.Optional: it targets a different application space. The (single-header) implementation is at: https://github.com/akrzemi1/compact_optional The documentation is at: https://github.com/akrzemi1/compact_optional/blob/master/documentation.md For the motivation and design rationale see this article: https://akrzemi1.wordpress.com/2015/07/15/efficient-optional-values/ Any feedback is welcome. Regards, &rzej

17 43

[build] Issue with -- argument
by Gennadiy Rozental 01 Oct '15

01 Oct '15

Hi, Due to the change in Boost.Test parameter handling I needed update Boost.Test Jamfile, since I was passing baseline pattern file names as arguments to the test module. Here is snippet from my Jamfile: return [ $(test-rule) $(source_files) ../build//$(usage-variant) $(extra-libs) : -- <============= Note: I added '--' : $(pattern_file) ... Unfortunately -- disappears for some reason from command line. I found that the following works: return [ $(test-rule) $(source_files) ../build//$(usage-variant) $(extra-libs) : -- "" <============= Note "" : $(pattern_file) ... Can we fix it so that "" is not required? Is there a different workaround? Gennadiy

1 0