- Boost - lists.preview.boost.org

[regression] new runner missing in master results
by Ion Gaztañaga 08 Oct '15

08 Oct '15

Hi, Since MSVC-7.1 is (in theory) supported by Boost and we had no regressions on that platform, I've set up an old computer to do the job. I've executed regression tests several times and results appear in develop branch's result page but they are always missing in master branch. Logs indicate that executions and uploading were correct. Eg.: Runner "igaztanaga" present in develop: http://www.boost.org/development/tests/develop/developer/move.html Runner "igaztanaga" missing in develop: http://www.boost.org/development/tests/master/developer/move.html Any hint on what could be the problem? Ion

3 6

Boost.test failures in develop
by Aparna Kumta 08 Oct '15

08 Oct '15

Compiling with Oracle Solaris Studio on sparc-S2 platform with -library=stlport4, I see the following failure in the develop branch: "CC" -library=stlport4 -xO4 -mt -erroff=%none -m32 -KPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_TEST_DYN_LINK=1 -DBOOST_TIMER_DYN_LINK=1 -DNDEBUG -D__typeof__=__typeof__ -I".." -c -o "/export/home/b_dev/results/boost/bin.v2/libs/test/build/sun/release/stdlib-sun-stlport/threading-multi/unit_test_parameters.o" "../libs/test/src/unit_test_parameters.cpp" "../boost/test/utils/runtime/errors.hpp", line 75: Error: Templates can only declare classes or functions. "../boost/test/utils/runtime/errors.hpp", line 86: Error: Templates can only declare classes or functions. "../boost/test/utils/runtime/errors.hpp", line 124: Error: ")" expected instead of "&&". "../boost/test/utils/runtime/errors.hpp", line 133: Error: ")" expected instead of "&&". "../boost/test/utils/named_params.hpp", line 69: Error: Unexpected type name "Rest" encountered. "../boost/test/utils/named_params.hpp", line 69: Error: Unexpected ":" found. "../boost/test/utils/named_params.hpp", line 205: Error: Unexpected type name "Rest" encountered. "../boost/test/utils/named_params.hpp", line 205: Error: operator, is not defined. "../boost/test/utils/named_params.hpp", line 205: Error: "," expected instead of ";". ... Compilation aborted, too many Error messages. It seems that the code contains rvalue reference and hence the compiler is not able to build it in C++03 mode. This seems to be a recent change preventing building of libboost_unit_test_framework.a and hence causing several tests to fail. Thanks, Aparna

12 33

git reset and force push
by Raffi Enficiaud 08 Oct '15

08 Oct '15

Hi all, Is there any policy wrt. reseting a branch master/develop and force pushing? The side question is to know if the boost git tools (the bot for submodules) can cope with those operations. Thanks, Raffi

9 38

[serialization] static_warning.hpp seems behind boost/config
by Alain Miniussi 07 Oct '15

07 Oct '15

Hi, It seems that BOOST_STATIC_ASSERT_UNUSED_ATTRIBUTE has been replaced by BOOST_ATTRIBUTE_UNUSED in boost config. But static_warning.hpp is still using the old macro on master (while it is fixed on develop). On master: #define BOOST_SERIALIZATION_BSW(B, L) \ typedef boost::serialization::BOOST_SERIALIZATION_SS< \ sizeof( boost::serialization::static_warning_test< B, L > ) \ > BOOST_JOIN(STATIC_WARNING_LINE, L) BOOST_STATIC_ASSERT_UNUSED_ATTRIBUTE; On develop: #define BOOST_SERIALIZATION_BSW(B, L) \ typedef boost::serialization::BOOST_SERIALIZATION_SS< \ sizeof( boost::serialization::static_warning_test< B, L > ) \ > BOOST_JOIN(STATIC_WARNING_LINE, L) BOOST_ATTRIBUTE_UNUSED; Could someone move the fix from develop to master to keep in synch with boost/config ? It is preventing some tests to pass in mpi. Thanks -- --- Alain

2 2

Boost.Filesystem for Universal Windows (windows-api=store)
by Mikael Olenfalk 06 Oct '15

06 Oct '15

Hi, I made a first attempt at getting Boost.Filesystem to run on the Universal Windows Platform (Windows 10). I intend to do more testing of it before it is ready to be merged but I would very much appreciate a quick and dirty review already. If somebody could take a look I would be a very happy guy. https://github.com/boostorg/filesystem/pull/18 I am working on some more libraries in the hopes that I can finish off most libs in the next couple of week, but I cannot promise anything. To compile for windows store, just add "windows-api=store" to your b2 invocation. Regards, /M

3 11

Request for review: Boost.Fit
by paul Fultz 06 Oct '15

06 Oct '15

Hi All, Boost.Fit is a header-only function utility library for C++11. It supports both gcc, clang and visual studio. More info can be found here: https://github.com/pfultz2/Fit I would like to take this time to ask for a review. Vicente Botet has mentioned he could be a review manager. So I would like to move forward in scheduling a formal review. I plan to boostify the library for the formal review. In addition, I would like to ask for an informal review at this time. If anyone has some feedback or questions, that would be greatly appreciated. Thanks, Paul

6 10

Boost.GSL?
by David Sankel 05 Oct '15

05 Oct '15

As you may or may not know, Bjarne Stroustrup, Herb Sutter, and others have announced a new set of C++ guidelines[1] and an accompanying library[2] that supports them. For many folks, it would be difficult to incorporate a new library into their organizations, but there is a strong desire to make use of the guidelines. I floated the idea of including GSL in Boost as a distribution mechanism to Bjarne and he said he doesn't have any objection to the idea in principle, although he is hesitant to having to go through an extensive review process where some of these basic structures would change. What do you all think? Would it be appropriate and/or desirable to have a Boost.GSL library? -- David Sankel [1] https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md [2] https://github.com/Microsoft/GSL

9 16

Re: [boost] boost.test regression or behavior change (was Re: Boost.lockfree)
by Brian Wood 04 Oct '15

04 Oct '15

Bjorn Reese writes >On 10/04/2015 12:18 PM, Gennadiy Rozental wrote: > >> Sooner rather than later we should have this discussion and setup timeline. >> IMO it had very little sense to continue to maintain c++03 workarounds. >> Boost code should be an example how modern c++ libraries should look like. >> And c++03 compatibility is directly in a way of this goal. > > You appear to have missed the many discussions on this topic. > > While Boost started out to design cutting-edge libraries, it has been > caught by its own success. Today there is a large user-base that still > uses C++03, and that are unlikely to upgrade in the foreseeable future. > > Therefore, the current consensus is that existing libraries should not > increase their standards requirements. New libraries are free to decide > their standards requirements (although it will probably be questioned > during a formal review.) > Support for that is dwindling as more projects adopt 2011 or newer versions of C++. I understand Gennadiy and Raffi's desire to discuss this issue again. C++ 2011 is required to use my software. That decision was also based on limited resources and the belief that C++ 2011 had some helpful things for on line code generation. If I had more resources, I could support C++ 2003, but at this point I'm happy to not have to support that. As time goes on, more people are using C++ 2011 or newer. -- Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

1 0

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