- Boost - lists.preview.boost.org

[modularization] LocalFunction and ScopedExit cycle
by Vicente J. Botet Escriba 06 Oct '14

06 Oct '14

2 3

[move] Macro for initializing base classes in move ctors.
by Mostafa 04 Oct '14

04 Oct '14

Initializing base classes in move constructors involves some boiler-plate code. Is there a reason why a macro is not provided for it? Something like: #define BOOST_MOVE_INITBASEMOVECTOR(baseclassname, rhs) \ baseclassname(::boost::move(static_cast<baseclassname &>(rhs)))

2 3

[mpl] struct definition and mpl sequence in one shot?
by Adam Romanek 03 Oct '14

03 Oct '14

Hi! This is a re-post from the boost-users mailing list. I have a problem and I'm not sure how to approach it. Currently my code looks like this: struct Definition { typedef boost::mpl::int_<5> A; typedef boost::mpl::int_<3> B; typedef boost::mpl::int_<6> C; typedef boost::mpl::int_<1> D; typedef boost::mpl::vector<A, B, C, D> Seq; }; Here, the number N in mpl::int_< N > denotes some arbitrary decimal number. Then some other code calculates the sum of these numbers up to the type defined by "key", e.g. for Definition::D, the sum is 5 + 3 + 6 (A + B + C). This needs to be done at compile-time. That's why I use mpl::vector and some appropriate meta-programming. I'm wondering whether it would be possible to provide such struct definition without the need to repeat type names in the mpl::vector for Seq type. In other words, I'd probably need a bunch of macros which would allow me to write code like this: struct Definition { FIELD(A, 5); FIELD(B, 3); FIELD(C, 6); FIELD(D, 1); GEN_SEQ() // if needed }; And then Definition::A would still refer to boost::mpl::int_<5>, or would at least allow me to access the boost::mpl::int_<5> somehow, and Definition::Seq would give me the appropriate MPL sequence. Of couse this is just my imagination. The code might look different, I'm just looking for options. Thanks in advance. Adam Romanek

1 0

[Boost] [DateTime] dividing a time_period in N time_periods
by Pablo Madoery 02 Oct '14

02 Oct '14

Hi, I want to make a method which divides a time_period in N time periods, something like this: list<time_period> splitTimePeriod(time_period timePeriod, int n); I actually have made it and although it seems to work it results very inefficient regarding the time it took to divide a large time_period. The method I did is this: list<time_period> splitTimePeriod(time_period timePeriod, int n) { double secsTime = dateTime::diffSeconds(timePeriod.end(), timePeriod.begin()); // tiempo en segundos de cada período de tiempo double ti = secsTime / n; list<time_period> timePeriods; // tiempo de comienzo del primer período de tiempo ptime tpBegin = timePeriod.begin(); // tiempo de fin del último período de tiempo ptime tpLastEnd = timePeriod.end(); for (int i = 0; i < n; i++) { int tUnits = ti * time_duration::ticks_per_second(); // tiempo de comienzo del siguiente período de tiempo ptime tpNextBegin = dateTime::increment(tpBegin, tUnits); // tiempo de fin del período de tiempo ptime tpEnd; if (i == n - 1) { tpEnd = tpLastEnd; } else { tpEnd = dateTime::decrement(tpNextBegin, 1); // guarda para evitar que por cuestiones // de redondeo, el tiempo final de un período // sea mayor que el pasado inicialmente // como argumento de entrada if (tpEnd > tpLastEnd) { tpEnd = tpLastEnd; } } time_period p(tpBegin, tpEnd); // se inserta período de tiempo en la lista timePeriods.push_back(p); // se actualiza el comienzo del siguiente período de tiempo tpBegin = tpNextBegin; } return timePeriods; } Other methods I use are these: double diffSeconds(const ptime &dateA, const ptime &dateB) { time_duration diff = dateA - dateB; return diff.total_seconds(); } ptime increment(const ptime &date, int n) { time_iterator it(date, dateTime::unit); for (int i = 0; i < n; i++) { ++it; } return *it; } ptime decrement(const ptime &date, int n) { time_iterator it(date, dateTime::unit); for (int i = 0; i < n; i++) { --it; } return *it; } const time_duration unit = microseconds(1); ################################################# The question is: is there a better way to accomplish this?

1 0

[static_if] Is there interest in a `static if` emulation library?
by Lorenzo Caminiti 01 Oct '14

01 Oct '14

Hello all, With C++14 generic lambdas, it is possible to implement a sort of `static if` (see also N3613): template< typename T > void assign ( T& x, T const& y ) { x = y; static_if<boost::has_equal_to<T>::value>( std::bind([] ( auto x, auto y ) { assert(x == y); std::cout << "asserted for: " << typeid(T).name() << std::endl; }, x, y) ).else_( [] ( ) { std::cout << "cannot assert for: " << typeid(T).name() << std::endl; } ); } The bind around the generic lambda is a bit verbose... but this code compiles, asserts when called on int, and does not assert when called on x_t (tested on clang 3.4.2): int i = 1; struct x_t { } x; assign(i, i); // asserts assign(x, x); // does not assert I have attached a reference implementation. Thank you. --Lorenzo P.S. I didn't do much background research... sorry if this topic has already been considered and discussed in Boost.

17 43

[uuid] Issue 9407: help required to merge fix
by Antony Polukhin 01 Oct '14

01 Oct '14

There is an issue with long history https://svn.boost.org/trac/boost/ticket/9407 That issue is annoying and can be easily fixed. There's even a pull request to fix that issue (https://github.com/boostorg/uuid/pull/2) Could someone take a look at the pull request, comment it and even merge to develop branch? -- Best regards, Antony Polukhin

1 0

Licensing issue (TestCmd.py)
by Polhodzik Peter (ext) 01 Oct '14

01 Oct '14

Hi all, Could anyone tell me, why the \boost_1_38_0\tools\build\v2\test\TestCmd.py (TestCmd version 0.02) file in Boost 1.38.0<http://www.boost.org/users/history/version_1_38_0.html> has Steven Knight's Python license reference, this: # Copyright 2000 Steven Knight # This module is free software, and you may redistribute it and/or modify # it under the same terms as Python itself, so long as this copyright message # and disclaimer are retained in their original form. # # IN NO EVENT SHALL THE AUTHOR BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, # SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OF # THIS CODE, EVEN IF THE AUTHOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH # DAMAGE. # # THE AUTHOR SPECIFICALLY DISCLAIMS ANY WARRANTIES, INCLUDING, BUT NOT # LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A # PARTICULAR PURPOSE. THE CODE PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, # AND THERE IS NO OBLIGATION WHATSOEVER TO PROVIDE MAINTENANCE, # SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS. __author__ = "Steven Knight <knight(a)baldmt.com<mailto:knight@baldmt.com>>" __revision__ = "TestCmd.py 0.D002 2001/08/31 14:56:12 software" __version__ = "0.02" while the original TestCmd 0.02<http://baldmt.com/Test-Cmd/Archive/Test-Cmd-0.02.tar.gz> is Perl licensed, this way: COPYRIGHT Copyright 1999-2000 Steven Knight. All rights reserved. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. ? It is also unclear which Python or Perl license it refers to ,since there are more licenses versions for both. I know 1.38.0 is an old release, but now I definitely need to have the information about this one. Updating to 1.56.0 is NOT an option to solve the problem this time. Thank you!! Üdvözlettel / Best Regards, Péter POLHODZIK OSS Expert [cid:image001.jpg@01CFDD70.90958F30] Phone: +36 (46) 5-17894 Fax: +36 (46) 5-17801 Peter.Polhodzik.ext(a)evosoft.com<mailto:Peter.Polhodzik.ext@evosoft.com> evosoft Hungary Kft. Arany János tér 1. H-3508 Miskolc www.evosoft.com<http://www.evosoft.com/> ---------------------------------------------------

2 1

[move] Build failures in develop
by Andrey Semashev 01 Oct '14

01 Oct '14

Hi, I'm seeing lots of build errors that originate from Boost.Move, such as: In file included from ../libs/log/src/text_file_backend.cpp:41: In file included from ../boost/filesystem/path.hpp:28: In file included from ../boost/iterator/iterator_facade.hpp:12: In file included from ../boost/iterator/interoperable.hpp:11: In file included from ../boost/mpl/or.hpp:23: ../boost/mpl/aux_/nested_type_wknd.hpp:27:10: error: no type named 'type' in 'boost::move_detail::is_rv<boost::rv<boost::log::v2_mt_posix::aux::light_function<void ()> > >' : T::type ~~~^~~~ See the full error logs: http://www.boost.org/development/tests/develop/developer/output/marshall-ma… http://www.boost.org/development/tests/develop/developer/output/teeks99-08b… http://www.boost.org/development/tests/develop/developer/output/teeks99-tes… I didn't change Boost.Log for quite some time, so there seems to have been some breaking change. Could this be fixed?

3 7

[thread] Build failures in develop
by Andrey Semashev 01 Oct '14

01 Oct '14

Hi, Boost.Thread currently fails to build on MSVC, which affects other libraries: http://www.boost.org/development/tests/develop/developer/output/teeks99-08d… Could it be fixed?

4 6

[modularization] request for a new modularization status for develop branch
by Vicente J. Botet Escriba 01 Oct '14

01 Oct '14

Hi Peter, could you upload a new modularization status, as in http://www.pdimov.com/tmp/report-d53f656/module-levels.html ? Best, Vicente

4 7

[Modularization][optional][functional] boost::none - what do we want it to be?
by Andrzej Krzemienski 30 Sep '14

30 Sep '14

Hi Everyone, I know it may be premature to to think about removing every cycle in Boost, but while looking at the cycle reports I found that at least one library is using boost::none, for a purpose different than indicating an uninitialized boost::optional. It is in Boost.Functional: https://github.com/boostorg/functional/blob/master/include/boost/functional… It uses none_t as a default type for a template type parameter Allocator. My question is: what do we want boost::none_t to indicate, at least in Boost? 1. A value-semantic alternative to void, that anyone can use? 2. A tag indicating boost::optional<T> without a value? The answer to this question dictates how we should untie the cycle. I know it is too soon to care about small cycles right now, but my question is more about "the principles". Regards, &rzej

2 2

"Easy Build and Install" fails at bootstrap.sh
by Josh Juran 30 Sep '14

30 Sep '14

I'm building Boost from Git since there's no secured download option, only HTTP. josh@alice:~/src/boost$ git log --oneline -n1 43bb782 Update thread from master. josh@alice:~/src/boost$ ./bootstrap.sh ./bootstrap.sh: 1: ./bootstrap.sh: ./tools/build/src/engine/build.sh: not found Building Boost.Build engine with toolset ... Failed to build Boost.Build build engine Consult 'bootstrap.log' for more details josh@alice:~/src/boost$ cat bootstrap.log ./bootstrap.sh: 218: cd: can't cd to ./tools/build/src/engine Do I need to run git-submodule? It would be helpful if Getting Started covered this. Josh

4 3

[iostreams]Bugs in dual seekable mode
by Jorge Lodos 29 Sep '14

29 Sep '14

Currently there are no tests for dual seekable streams. New tests (dual_seekable_test.cpp in the ticket) uncover the following bugs: 1. The functions test_seekable_in_chars and test_seekable_in_chunks in test/detail/verification.hpp use seekp in several places where seekg should be used. This has no effect when there is a single head but does not work when the stream is dual seekable. 2. indirect_streambuf::seek_impl does not work for dual seeking. The problem is that both heads are modified for both input and output operations. Since the modification is the same (just resetting the pointers) everything works when there is a single head. This is a duplicate of https://svn.boost.org/trac/boost/ticket/7681. 3. The function shared_buffer() does not consider dual_seekable stream buffers as shared. 4. The function init_put_area() does not consider the existing input position. This is a duplicate of https://svn.boost.org/trac/boost/ticket/8572. With the attached (in the ticket) versions of verification.hpp and indirect_streambuf.hpp all previously existing tests passed. I recommend adding the new tests in dual_seekable_test.cpp. I have created the ticket https://svn.boost.org/trac/boost/ticket/10561 Best regards Jorge

1 0

[thread] Specific old move semantics usage
by Vicente J. Botet Escriba 27 Sep '14

27 Sep '14

Hi all, I would like to remove the specific move semantics included in Boost.Thread as it was flawed. This has been replaced by the Boost.Move one long time ago. Is there someone still using it? Could I at least define by the default (even for BOOST_THREAD_VERSION 2) BOOST_THREAD_USES_MOVE for Boost 1.57? Best, Vicente

2 1

[Modularization] Range and Spirit dependencies
by Stephen Kelly 27 Sep '14

27 Sep '14

Hello, Boost 1.55 has been out for some weeks. I repeat my recommendation to remove the Boost.Algorithm dependency from Boost.Range and the Boost.Serialization dependency from Boost.Spirit. http://thread.gmane.org/gmane.comp.lib.boost.devel/251966/focus=252090 http://thread.gmane.org/gmane.comp.lib.boost.devel/251966/focus=251968 http://thread.gmane.org/gmane.comp.lib.boost.devel/252250/focus=252293 Thanks, Steve.

3 7

questions regarding dependency reports(s)
by Robert Ramey 27 Sep '14

27 Sep '14

I've been looking at the question of "dependencies" and I would like to know a little more about how they are generated. I've looked at: a) http://www.pdimov.com/tmp/report-6d1f271/serialization.html b) http://www.steveire.com/boost/2014sept16_serialization.png c) bcp documentation And it doesn't seem that they all produce the same list of dependencies. a) doesn't include any *.cpp files. So I assume that it contains less than the true number of dependencies. That is if a *.cpp file includes a header as part of it's implementation and not it's interface, it wouldn't be included. b) produces a very intimidating graph. I'm not sure what the rules are for it's generation. I'm guessing that it uses dependencies at the library level rather than the *.cpp level which might make things look worse than they are. c) BCP seems pretty exhaustive in that it cans all the code in all the *.cpp libraries, tests, examples etc. For lots of applications - e.g. if I wanted to include a boost library with my application but not all the tests, It would generate a likely much larger subset than I need. But maybe not. If my application includes the boost library.dll then I guess I have to include it all. This raises an interesting question to me. Suppose I want to distribute my app with source and I include a CMake which just doesn't build the libraries but just includes the relevant *.cpp files in the application build itself? This would make my application depend upon the smallest subset of boost possible. What would it take to make a version of BCP which, given an arbitrary group of source files, returns a list of headers and *.cpp files which could be used to build the app? We know from an intuitive basis that we want to give the option of delivering a smaller boost, but we've always thought that that means delivering a library subset. Is this really what we want? What would users do with the smaller subset? (Besides complain that its not small enough?) How about if we tweaked BCP to deliver just a subset of files relevant to the target? Would that make them happier? Would it get us off the hook for trying to "solve" what the dependencies are? Just thinking out loud here. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/questions-regarding-dependency-reports-s… Sent from the Boost - Dev mailing list archive at Nabble.com.

7 8

Re: [boost] Stefanus Du Toit
by Hartmut Kaiser 26 Sep '14

26 Sep '14

http://emlakdanismanlari.com/izvusl/xqwkkozimojmnoisxjsllmsfkjpoaiycejluiocg

1 0

New C++14 config macros - opinions wanted
by John Maddock 25 Sep '14

25 Sep '14

There is a pull request to add new config macros for C++14 features (https://github.com/boostorg/config/pull/39) I have a few questions really, particularly for those more familiar with C++14 than me: * Do we need these? * Are these the correct names? * Are the proposed tests correct? Thanks, John.

8 9

TravisCI and Coverall usage policies in Boost
by Antony Polukhin 25 Sep '14

25 Sep '14

Hi, Motivation. I'd like to show some useful stuff using the Boost.Variant library as an example. Take a look at this link: https://coveralls.io/builds/1224886 It shows tests coverage and has a nice interface to get info about untested things. For example: * if we take a look at this https://coveralls.io/files/293662719 , we'll see that `polymorphic_get` was not tested for extracting type that is not in a variant variable * if we take a look at this https://coveralls.io/files/293662720 we'll see that swapping of recursive wrappers was not tested All that stuff was achieved by adding the https://github.com/apolukhin/variant/blob/travisci/.travis.yml file and turning a switch at coveralls.io site. Now let's take a look at the regression tests of variant: http://www.boost.org/development/tests/master/developer/variant.html . There we can see a indirect_travisci_tests tester. There's nothing special about that tester, except the fact that results are gathered using foreign TravisCI service. We can integrate foreign service to do regression reporting for us. We can even make this separately for each of the Boost libraries, triggering test run on every commit and reporting the results directly to README.md file (for example https://github.com/apolukhin/Boost.DLL#test-results) The problem. A few things make me nervous. First of all, TravisCI requires some access permissions to the repo. I'm not a github expert so I'm not 100% sure that this is safe. Second one, is that there is no policy in Boost about usage of foreign services like TravisCI and Coveralls. The questions. Is is OK to commit to Boost repos .travis.yml files without enabling TravisCI runs? Do we need a license note in .travis.yml file? Can we enable automated testing using TravisCI for a Boost repo? Can we enable automated tests coverage using Coverall for a Boost repo? -- Best regards, Antony Polukhin

5 9

[modularization] Extract xml_archive from serialization
by Stephen Kelly 25 Sep '14

25 Sep '14

Hi there, The biggest single problem of coupling in boost comes from the spirit dependency in the serialization library. This makes serialization itself very (and needlessly) heavy: http://www.steveire.com/boost/2014sept16_serialization.png Spirit is used only by the xml archiving classes. I recommend extracting an xml_archive library from serialization. That way, serialization no longer depends on spirit, which is already an improvement: http://www.steveire.com/boost/2014sept16_serialization-after-extract-xml_ar… Further, the serialization classes for boost::variant and boost::array are in the serialization library. This is not appropriate, as the serialization classes for all other types are in the libraries providing the types. Move the serialization classes to those libraries. mkdir ../variant/include/boost/serialization mv include/boost/serialization/variant.hpp ../variant/include/boost/serialization mkdir ../array/include/boost/serialization mv include/boost/serialization/array.hpp ../array/include/boost/serialization This is a large improvement: http://www.steveire.com/boost/2014sept16_serialization-after-type-move.png There is more that can be done. These things can be done now. I recommend doing them. Thanks, Steve.

8 23

[modularization] Are modular releases a goal or a non-goal?
by Stephen Kelly 25 Sep '14

25 Sep '14

Hello, I can download one monolithic tarball to get Boost 1.56: http://sourceforge.net/projects/boost/files/boost/1.56.0 And I get all of it. There are no separate 'modular Boost' tarballs so that I can download what I want and not what I don't. Compare to Qt which provides both monolithic source tarballs: http://download.qt-project.org/official_releases/qt/5.3/5.3.2/single/ and modular source tarballs: http://download.qt-project.org/official_releases/qt/5.3/5.3.2/submodules/ Is something similar to this a goal or a non-goal for 'Boost modularization'? Thanks, Steve.

10 32

[intrusive] Possible bug in bstree_algorithms.hpp
by Lars Hagström 25 Sep '14

25 Sep '14

Hi, I've just upgraded to boost 1.56 and I've run into a problem. I get an infinite loop inside insert_equal_lower_bound_check(...) in bstree_algorithms.hpp. I'm using that file indirectly through Boost.Interprocess. I've not been able to penetrate exactly what that function does or whether there is indeed a bug in it. But I did look at the version that was in 1.55 (called insert_equal_check_impl(...) there), and to me it looks like there is at least one unexpected change: A ! has been removed on the line where the branches are compared, which to me would mean that we put the wrong branch into x. Again, I don't really understand what is going on in that function, so I might well be completely wrong. Cheers Lars

2 22

[containers] Clarifications on incomplete type support?
by Mikael Persson 24 Sep '14

24 Sep '14

Hi all, I've been using Boost.Containers for some time now. As for many, the primary (and only) reason for using them (over STL ones) is that they support incomplete value types. Since the beginning, I have always assumed that support for incomplete value types meant that I could instantiate the container type and any indirect type, most notably, **iterators**. I cannot stress enough how important it is for data structure designs to be able to instantiate the iterators of containers of incomplete value types! And, in general, there is no inherent reason why, in general, incomplete type support could not extend to iterators as well. This is even more true in light of the SCARY iterator requirements (which boost containers purport to support, which cannot possibly be true given the compilation errors I have seen). So, my main question is this: Is the following code supposed to work when using Boost.Containers? boost::container::some_container<IncompleteType>::iterator it; The documentation only states that "all Boost.Containers containers [..] are designed to support incomplete types". This needs to be clarified when it comes to iterators, at least. If the above code is not guaranteed to work, then may I request that it be added to the requirements? Because in my view, not having iterator support for incomplete types sort of defeats the whole purpose of supporting incomplete types, except for the most trivial use-cases (like those "recursive containers" examples). And moreover, without this support, workarounds are so major that they won't benefit from the container's support for incomplete types any more (and therefore, might as well use the standard ones instead). >From experience, I know that most Boost.Container containers had working iterators for incomplete value types up to and including version 1.54 (and it's a kind of natural consequence of supporting incomplete types for the container itself). But recently, changes to the boost::container::list class have made it impossible to use of boost::container::list iterators for incomplete types (due to some convoluted new iterator scheme that I can barely understand myself). If iterators are supposed to be included in the incomplete type support, then this is a bug in the list container (and btw, boost::unordered_set also has the same problem), and I would also recommend adding this to the container unit-tests. Thanks, Mikael Persson

2 9

[modularization] What is a module? What is a sub-module?
by Vicente J. Botet Escriba 24 Sep '14

24 Sep '14

Hi all, After the long threads concerning the modularization it seems clear to me that we are in an impasse. While I guess breaking dependency cycles is a modularization goal for all of us, it seems that moving files from one module to a sub-module has not be well accepted, worst yet, could have some dramatic consequences (a lot of testers were broken with the MPL split) due to the way we build Boost. I'm wondering if we don't need an alternative definition of module/sub-module. This definition could be temporary, it would just be useful to identify the modules/sub-modules that would be the good ones. We could move the files when needed by some user oriented tools (install). Let me try it. A module or submodule is just a list of files. The first problem is how to identify this list. Currently, the boostdep tool request that a module is associated to the files in the directory include of a repository and a sub-module to the files in the directory include in a subdirectory of a repository. I don't remember which criteria Stephen Kelly is using in his tool. I propose to switch to a less restrictive and more explicit mapping that don't implies any change on how Boost is build/tested. The advantage is that we can change this mapping without any trouble on the regressions tests :) * If a repository don't have this explicit mapping, the module with the same name as the repository is composed of the files in the directory include, src and build of the repository. There could be other implicit modules for test, examples, benchmarks, ..., which are not user oriented. * If a repository has this explicit mapping, the module/sub-modules are the ones described in this mapping. Open points * Do we want/need to be able to define modules containing files in more than one repository? * Where the explicit mapping should be stored? * Should we track the build dependencies? How? * Should we rethink how Boost is build in a modularized world? * Do we want/need to take in account optional dependencies from the beginning? Note that this would not reduce the dependencies at the file level, but at least would help us to break the cycles. Peter, if we agree this is the way to exit from the impasse, would you like to adapt your tool to use an explicit mapping ? Any concrete proposal about how Boost could be installed in a modularized world would be welcome. Open point: Is anyone interested in working on this modular installation? Best, Vicente

8 16

Re: [boost] [Boost.Config] variadic templates availiable with GCC 5 in C++03 mode
by Lars Gullik Bjønnes 24 Sep '14

24 Sep '14

(resent due to missing membership on boost list) On 23 September 2014 22:43, Lars Gullik Bjønnes <larsbj(a)gullik.org> wrote: > Hi, > > It seems that the checking to define BOOST_NO_CXX11_VARIADIC_TEMPLATES or not > is slightly wrong when __GNUC__ > 4 (in this case __GNUC__ == 5) > > This was tried fixed in [SVN r70019], but it looks like the fix was > wrong for __GNUC__ > 4. > > (git 050da29d47ce43b1dca6bed03d54c40d5e3d315e) > > > This is the current code: > > // Variadic templates compiler: > // http://www.generic-programming.org/~dgregor/cpp/variadic-templates.html > # if defined(__VARIADIC_TEMPLATES) || (__GNUC__ > 4) || ((__GNUC__ == > 4) && \ (__GNUC_MINOR__ >= 4) && defined(__GXX_EXPERIMENTAL_CXX0X__)) > # define BOOST_HAS_VARIADIC_TMPL > # else > # define BOOST_NO_CXX11_VARIADIC_TEMPLATES > # endif > #endif > > > This is my proposed fix: > > diff --git a/functional/boost/boost/config/compiler/gcc.hpp > b/functional/boost/boost/config/compiler/gcc.hpp > index ef6b07e..736e8ba 100644 > --- a/functional/boost/boost/config/compiler/gcc.hpp > +++ b/functional/boost/boost/config/compiler/gcc.hpp > @@ -157,7 +157,7 @@ > > // Variadic templates compiler: > // http://www.generic-programming.org/~dgregor/cpp/variadic-templates.html > -# if defined(__VARIADIC_TEMPLATES) || (__GNUC__ > 4) || ((__GNUC__ > == 4) && (__GNUC_MINOR__ >= 4) && defined(__GXX_EXPERIMENTAL_CXX0X__)) > +# if defined(__VARIADIC_TEMPLATES) || ((__GNUC__ > 4 || (__GNUC__ == > 4 && __GNUC_MINOR__ >= 4)) && defined(__GXX_EXPERIMENTAL_CXX0X__)) > # define BOOST_HAS_VARIADIC_TMPL > # else > # define BOOST_NO_CXX11_VARIADIC_TEMPLATES > > > (I'll post a none-damaged diff if wanted.) > > -- > Lgb -- Lgb

3 2

[iterator] Support other tuple implementations with zip_iterator
by Kohei Takahashi 24 Sep '14

24 Sep '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, Here is my proposal [1] for supporting other tuple implementations (e.g. std::tuple) with zip_iterator, which discussed at the issue [2]. This PR will reimplement zip_iterator as a fusion based one, because current implementation is tightly coupled with Boost.Tuple. Of course, Boost.Tuple should be accepted via Boost.Fusion. [1] https://github.com/boostorg/iterator/pull/2 [2] https://svn.boost.org/trac/boost/ticket/7526 Thanks, Kohei Takahashi -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUIi7FAAoJEGGyPxPRp/zof5IQAMFjfB1q3yhXXEvoXOZGedhn 8S6hCWsar0MA42Wn/PIG1cMxgb4oc9cZFv6KBieDAn38QJu44NYDFhxhRlMPDMrs cgNQDbvYROWzakzUX93DstzSwvUwqIjWg4bFFYbE5cmK1MbmCWZODs5TQFKQDxxO KfrUEsttoMlbklFa5Rw9JdM3bP2NMUlmJZ9M/8/rBhAf/AvgLiSK9f7qXjoWoMaZ DwZKEztQB2ZRL+iwtCeNJU0OSJ3/KCsS45xYKY9tsE25RGWU8vdryKEqt/eeHe/d dfVpMWMLKZ3g7PoLc73ntxX+C0B/Zj96rhqurt3Z6gtWmSiYFxct/0oDqfu9JKCn hG4p+g70m1nW47Kfvc8p3ZiWABvOOghPT9CEyyATh4nMzJTYLwawD00uRUtdATT9 siTIH2AeEHUnUuNHMMdbr7kJMq/6aubt0RFz04TgIZJ0EmrkjbuxfeiemoiZhyeN JNE9ubujqMiAcyeLpCWAbnogLWMgn8duvIKYc0pvFlYIkGWKrAMSd46RaCd47g4x alYh7vlLE8nqdmAwe2is5PfFIw8qzJj1zn+Kj+CFkXouJ9eObiOXTbTdQNPhFplT gAxYLdcmz23goQzAQ9xTMySmuGFzHKZn+uTQ3gpzDABC6zGCXhGA/Hu+JER/KmTY 3Ty2EoDqWdsu/bp9mY+/ =wJsr -----END PGP SIGNATURE-----

1 0

Boost.Hana - Type Classes, data types and categories (tags).
by Vicente J. Botet Escriba 23 Sep '14

23 Sep '14

Hi Louis, There is a lot of very good work on your library. I have some comments in relation on how I have implemented Type Classes in my prototype. About datatype<T>. The library proposes type classes and data types. The name datatype_t<> is confusing as the datatype<T> meta-functions must not return one of the defined data types. I see it much more as a category, which is used to map the data type to a category used as parameter of the instantiation TC::Instance<datatype_t<T>>. In addition, I wonder if the category associated shouldn't depend on the type class we want to map. TC::Instance<category_t<T, TC>> About naming: Haskell doesn't have namespaces and all the functions are at the same scope. Your library makes use of a lot of non-member functions, and so name clashing must be avoided. What about moving all the non-member functions of the Type Class to a specific namespace? E.g. struct Monad { ... }; namespace monad { using namespace applicatives; ... bind() }; The use would need to use the type class namespace explicitly auto x = monad::bind(m, f) or introduce the namespace of the type class using namespace monad; auto x = bind(m, f); Best, Vicente

4 10

CMake module for compile-time benchmarks
by Louis Dionne 22 Sep '14

22 Sep '14

Hi, While working on Hana, I have developped a couple of tools to generate compile-time benchmarks. I have now made this easier to use for anyone who wishes to do the same by writing a CMake module which does the dirty work for you. The module is available at [1]. Basically, you drop this in your CMake tree, install a couple of dependencies and then you can create targets to run the compile-time benchmarks. The gist of it is explained in the module, and you can find a lot of examples in [2]. This is still a work in progress. For example, the module still does not support runtime benchmarking even though the documentation says it does. Also, it only works with Clang and GCC for now. There are probably a ton of glitches and ways to improve it; feel free to send pull requests! Regards, Louis [1]: https://github.com/ldionne/hana/blob/master/cmake/Benchmarks.cmake [2]: https://github.com/ldionne/hana/tree/master/benchmark

1 0

Boost.Hana - Maybe and Either data types design
by Vicente J. Botet Escriba 21 Sep '14

21 Sep '14

Hi Louis, I have some concerns with the design of the Maybe and Either data types (maybe the other data types have the same design, I have not taken a look at). There are somethings that I don't understand, sorry I have not changed yet my mind to then new C++ way. If I want to define a function that takes an Either string int, how can I define it? void f(??? p) {} I see that there is a maybe_detail::maybe<bool,class>, however I don't think this is the data type of Maybe, is it? Anyway, I don't see a either_detail::either<bool, class, class>. I have the impression that I must use always auto with lambdas auto f = [](auto p) {...}; But I don't know what I can put in the body. It is to clear neither how can I declare a variable of type Either string int. I see that I can declare a Left string and a Right int BOOST_HANA_CONSTEXPR_LAMBDA auto left_value = left("x"); BOOST_HANA_CONSTEXPR_LAMBDA auto right_value = right(1); I have the impression that the variables are initialized only once and can not be reassigned,or at least we can not assing a Left value to a variable initialized with a Right value. Is this by design? A last concern related to the applicative lift function. I suspect that it corresponds to the Haskell return function and the more general unit Monad function. As there is a lift function in Haskell, this is a little bit confusing. I have named this function make :) In Haskell, the template parameter is a type constructor. This Monad(Applicative) type constructor should be Either E, not Either. Is the type-constructor feature missing from your design? How wan I create an Either string int with a call to auto x =lift<Either>(123); I would expect something like auto x = lift<Either<string>>(123); In my prototype I have auto x = make<expected<holder, string>>(123); where expected<holder, string> is the Monad type constructor for expected<T, string>. Sorry the argument of expected and Either are in interchanged. The string type is the Error. Best, Vicente

2 1

[GSoC] [Boost.Hana] Formal review request
by Louis Dionne 21 Sep '14

21 Sep '14

Dear Boost, It has been a while since I've given news about my GSoC project, Boost.Hana[1]. Things are going very well and I uploaded the library to the Boost Incubator. I think it is time to push the library forward for review. As the author, I know everything that's left to be done and polished before I can be fully satisfied. Still, I believe the library is worthwhile in its current state as it implements a superset of the functionality found in the Boost.MPL and Boost.Fusion. I also think the library will benefit greatly from a larger user base and more feedback. Here are some caveats: - The library requires a full C++14 compiler, so only Clang 3.5 can compile the unit tests right now. However, compilers will eventually catch up. Also, pushing cutting edge libraries forward might motivate compilers to support C++14 ASAP, which is probably a good thing. - The library is not fully stable yet, so interface changes are to be expected. I don't see this as a problem as long as this is documented, especially since I expect Hana to be used mostly for toying around for at least a while. I could be mistaken. So unless someone thinks the library isn't ready or would get rejected right away in its current state for reason X, I am requesting a formal review for Boost.Hana. Regards, Louis [1]: http://github.com/ldionne/hana

22 110

Re: [boost] proposal a movable_initializer_list
by 何子杰Hzj_jie 19 Sep '14

19 Sep '14

No body interests in it? I trust if the initializer_list is movable, it would be great helpful to construct a class with a set of lambda expressions. And we can use these lambda expressions to define a procedure, and provide a better solution for asynchronous programming. .Hzj_jie ________________________________ From: 何子杰Hzj_jie<mailto:hzj_jie@hotmail.com> Sent: ‎16/‎9/‎2014 10:35 To: boost(a)lists.boost.org<mailto:boost@lists.boost.org> Subject: Re: [boost] proposal a movable_initializer_list sorry, my fault of the mistake of for-range usage, you are correct, I am using iterator in my implementation. The efficiency I am taking care is the difference between copy-construction and move-construction. It will be significant if we are using lambda expression. Surely we still have something else to improve, say, provide the size of the vector at construction. The way using movable_initializer_list in the test case is not typical, indeed I am trying another not related issue. <the order of the move-constructions are not expected, i.e. line 46 will throw errors by g++, but no problem by msvc> Usually if a class A accept movable_initializer_list<T> as the parameter of a constructor, we only need A({T(), T()}), i.e. same as initializer_list. You properly would like to have a look at the event class, which is the typical scenario of movable_initializer_list, at https://github.com/Hzj-jie/osi/blob/master/delegates/event.hpp, with a test at https://github.com/Hzj-jie/osi/blob/master/utt_cases/delegates/event_test.h…. briefly it uses movable_initializer_list to avoid a copy of std::function instances, but can provide a way to call constructor with { } syntax. .Hzj_jie From: Sebastian Redl Sent: ‎Monday‎, ‎September‎ ‎15‎, ‎2014 ‎8‎:‎09‎ ‎PM To: boost(a)lists.boost.org On 15 Sep 2014, at 9:39, 何子杰Hzj_jie <hzj_jie(a)hotmail.com> wrote: > hi, all, > > So I proposal a movable_initializer_list, it accepts two ways to construct, with an initializer_list<T*> or initializer_list<T>, the prototype is, > > The implementation of T* overloads is something like > > movable_initializer_list<std::initializer_list<T*> x) > > { > > for(auto it : x) > > { > > assert((*it) != nullptr); > > v.push_back(std::move(**it)); > > delete *it; > > } > } Should be for (auto p : x) { v.push_back(std::move(*p)); delete p; } because of how for-range works. Seems an incomplete manual change from your published source. However, this is highly problematic because: - There is absolutely no way to make this exception-safe. The intended usage is obviously: SomeType st = { new Foo(123), new Foo(456), new Foo(789) }; But if any constructor here throws, a lot of memory is leaked, and destructors are not called. - If efficiency is your goal, I somehow doubt that an additional dynamic allocation per element for the initial list, then building a vector element by element, is the best way to achieve it. - The interface to this is just horrible. Looking at your test case, there is an absurd amount of boilerplate. Here’s what we really want: SomeType st{ Foo(123), Foo(456), Foo(789) }; Here’s what your thing forces me to do: auto pointers = { new Foo(123), new Foo(456), new Foo(789) }; SomeType st(pointers); // Absolute best case: no ambiguity in overload resolution - actually rather doubtful. If you do it that way, you might as well do it this way: Foo[] foos = [ Foo(123), Foo(456), Foo(789) }; // No dynamic allocation SomeType st(make_move_iterator(begin(foos)), make_move_iterator(end(foos))); More efficient, and you could make helpers that combine the make_move_iterator and begin/end calls to reduce boilerplate. > > While the implementation of T overloads is something like > > moveable_initializer_list<std::initializer_list<T> x) > { > > for(auto it : x) v.push_back(move(*it)); > } Again, that’s not how for-range works. What you want is for (auto&& e : x) v.push_back(std::move(e)); But that doesn’t actually work, because a std::initializer_list never gives you non-const access to its elements. I notice that your test case doesn’t test this constructor. Sebastian _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Boost incubator milestone
by Robert Ramey 19 Sep '14

19 Sep '14

The boost library incubator (www.blincubator.com) has received it's first Boost quality review for one of its submitted libraries. See the review here: http://rrsd.com/blincubator.com/reviews/?library_post_id=669 Hopefully this will motivate more people to submit their own reviews in advance of some formal review period. BTW - this review of this library (Compute) is very positive. Hopefully this will motivate other potential users to try out the library and make their own review. If the number of reviews reaches 5 I'll ask that the formal review for this library be expedited since, given such a head start, the review should be much simpler than starting from scratch. So I'm encouraging people who want to get the review process on a faster track to submit their own reviews as soon as they can find time. The Incubator has been progressing more slowly than I would hope. But progress is being made. Hopefully, this will continue to the point where it becomes and "overnight" success. Thanks to Denis Demidov for breaking the ice here. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-incubator-milestone-tp4667761.html Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

Re: [boost] TravisCI and Coverall usage policies in Boost
by Marek Kurdej 19 Sep '14

19 Sep '14

Hi, > If we ever get Windows on Travis, I was surprised how good the MSVC > static analyser has become, and we should have a pass with that too. > FYI, there is a CI similar to Travis running MSVC-12.0, see https://ci.appveyor.com/. I've used it for a personal project, you can have a look at a sample configuration file using Boost libraries at https://github.com/mkurdej/bft/blob/develop/appveyor.yml. The only problem, there is only a 30-day free trial... Cheers, Marek Kurdej -- Ph.D. candidate

1 0

Trac spam report
by Joaquín M Lopez Munoz 19 Sep '14

19 Sep '14

https://svn.boost.org/trac/boost/ticket/10502 Thank you Joaquín M López Muñoz Telefónica

2 1

[regression] Debian-sid
by Suckow, Thomas J 18 Sep '14

18 Sep '14

Someone has been running regression tests on develop with the name “Debian-sid”, I believe they have a space in the path to the regression suite, which is causing it to fail. The job gets run like clockwork, shame that it isn’t uploading any useful results. Either the operator of this builder should change the path so that it does not have a space, or the regression suite should be updated to tolerate it. I tried once to figure out where in the test suite the path got mangled, but was unsuccessful, maybe someone more familiar with it could take a look? - Thomas

2 3

[type_traits] Modularization proposal
by Andrey Semashev 17 Sep '14

17 Sep '14

Hi, Boost.TypeTraits is used in lots of other Boost libraries, and it currently unnecessarily pulls MPL and TypeOf. The dependencies are introduced by just these two public headers: floating_point_promotion.hpp and common_type.hpp. I'd like to avoid these dependencies. I propose to extract common_type.hpp (and its implementation and tests) into a sublib within type_traits (e.g. type_traits/common_type). As for floating_point_promotion.hpp, it is used in promote.hpp, which is using integral_promotion.hpp. I can see two ways of tackling it: 1. Extract all promotion traits into a sublib (e.g. type_traits/promotion). This includes floating_point_promotion.hpp, integral_promotion.hpp and promote.hpp, as well as their tests. 2. Change floating_point_promotion.hpp to not use MPL. MPL is used only to workaround BOOST_NO_CV_SPECIALIZATIONS, which is defined for Borland 5.51 and older and MPW 8.90 and older. The simplest way is to drop the workaround, but at a quick glance it should be possible to retain it. I'm currently leaning towards the option 2, although we obviously don't test those compilers and there is no way of knowing if the code will still work after the change. So I'm interested to know others' opinion, both with regard to the general idea and the way of proceeding with floating_point_promotion.hpp in particular. PS: TypeTraits dependencies can be seen in the report Peter graciously uploaded: http://www.pdimov.com/tmp/report-d5ca5be/type_traits.html After the modularization efforts TypeTraits should only depend on Config, Core, Preprocessor, MPL.Core and StaticAssert. Don't mind that MPL.Core depends on MPL - the pull request fixing it has already been created.

8 23

[mpl] Modularization pull request
by Andrey Semashev 17 Sep '14

17 Sep '14

Hi, I've created this pull request: https://github.com/boostorg/mpl/pull/11 to separate core components of Boost.MPL to a sub-library. The intent of this pull request is to reduce dependencies added by MPL to its dependent libraries, when only the basic MPL components are required. In particular, it should help resolving circular dependency between MPL and TypeTraits. Please, have a look at the list of moved components and let me know if you have any comments.

4 18

[testing] mpl/core tests not visible
by Andrey Semashev 17 Sep '14

17 Sep '14

Hi, I can see a few testers have cycled since MPL.Core was extracted into a sublibrary, but there is no mpl/core page in the test matrix. The sublibs file and core/test directory are present in the mpl submodule. Is there something I should do to make the tests appear?

3 21

[TR1] Reming TR1? [was: Libraries failing across the board.]
by Beman Dawes 16 Sep '14

16 Sep '14

On Wed, Jul 9, 2014 at 8:13 AM, John Maddock <boost.regex(a)virgin.net> wrote: > > > On 08/07/2014 22:07, Beman Dawes wrote: > >> Marshall is just a few days away from being able to put out a beta release >> candidate. (And that is very good news!) >> >> But we still have too many libraries failing across the board on master: >> >> accumulators >> interprocess >> numeric/ublas >> pool >> proto >> spirit/repository >> spirit/test >> tr1 >> > > TR1 is now deprecated, and again hasn't been changed in a long time - the > main failures seem to be caused by changes to Boost.Random (or possibly > std::random) so that it is now no longer TR1 compliant. Someone would have > to rewrite it to use TR1-compatible random number classes perhaps culled > from an old version of Boost, frankly I just don't see the point. The lib > should probably be removed from Boost at some point. > We went back and forth a bit, and decided to remove TR1 after 1.56.0 shipped. What exactly needs to be done? * Remove the .gitmodules entry. * Remove the status/Jamfile.v2 entry. * Remove the libs/maintainer.txt entry. * Update http://www.boost.org/doc/libs/ Anything else? --Beman

5 4

[modularization] mplcore depends on mpl
by Stephen Kelly 16 Sep '14

16 Sep '14

Hi there, libs/mpl/core/include/boost/mpl/aux_/include_preprocessed.hpp from mplcore includes boost/mpl/aux_/config/compiler.hpp which is in mpl. mpl depends on mplcore. This is a circular dependency. I thought the point of the split was to resolve that in part. If so, then I recommend you go ahead and resolve the cycle in the obvious way. Thanks, Steve.

2 1

Re: [boost] proposal a movable_initializer_list
by 何子杰Hzj_jie 16 Sep '14

16 Sep '14

sorry, my fault of the mistake of for-range usage, you are correct, I am using iterator in my implementation. The efficiency I am taking care is the difference between copy-construction and move-construction. It will be significant if we are using lambda expression. Surely we still have something else to improve, say, provide the size of the vector at construction. The way using movable_initializer_list in the test case is not typical, indeed I am trying another not related issue. <the order of the move-constructions are not expected, i.e. line 46 will throw errors by g++, but no problem by msvc> Usually if a class A accept movable_initializer_list<T> as the parameter of a constructor, we only need A({T(), T()}), i.e. same as initializer_list. You properly would like to have a look at the event class, which is the typical scenario of movable_initializer_list, at https://github.com/Hzj-jie/osi/blob/master/delegates/event.hpp, with a test at https://github.com/Hzj-jie/osi/blob/master/utt_cases/delegates/event_test.h…. briefly it uses movable_initializer_list to avoid a copy of std::function instances, but can provide a way to call constructor with { } syntax. .Hzj_jie From: Sebastian Redl Sent: ‎Monday‎, ‎September‎ ‎15‎, ‎2014 ‎8‎:‎09‎ ‎PM To: boost(a)lists.boost.org On 15 Sep 2014, at 9:39, 何子杰Hzj_jie <hzj_jie(a)hotmail.com> wrote: > hi, all, > > So I proposal a movable_initializer_list, it accepts two ways to construct, with an initializer_list<T*> or initializer_list<T>, the prototype is, > > The implementation of T* overloads is something like > > movable_initializer_list<std::initializer_list<T*> x) > > { > > for(auto it : x) > > { > > assert((*it) != nullptr); > > v.push_back(std::move(**it)); > > delete *it; > > } > } Should be for (auto p : x) { v.push_back(std::move(*p)); delete p; } because of how for-range works. Seems an incomplete manual change from your published source. However, this is highly problematic because: - There is absolutely no way to make this exception-safe. The intended usage is obviously: SomeType st = { new Foo(123), new Foo(456), new Foo(789) }; But if any constructor here throws, a lot of memory is leaked, and destructors are not called. - If efficiency is your goal, I somehow doubt that an additional dynamic allocation per element for the initial list, then building a vector element by element, is the best way to achieve it. - The interface to this is just horrible. Looking at your test case, there is an absurd amount of boilerplate. Here’s what we really want: SomeType st{ Foo(123), Foo(456), Foo(789) }; Here’s what your thing forces me to do: auto pointers = { new Foo(123), new Foo(456), new Foo(789) }; SomeType st(pointers); // Absolute best case: no ambiguity in overload resolution - actually rather doubtful. If you do it that way, you might as well do it this way: Foo[] foos = [ Foo(123), Foo(456), Foo(789) }; // No dynamic allocation SomeType st(make_move_iterator(begin(foos)), make_move_iterator(end(foos))); More efficient, and you could make helpers that combine the make_move_iterator and begin/end calls to reduce boilerplate. > > While the implementation of T overloads is something like > > moveable_initializer_list<std::initializer_list<T> x) > { > > for(auto it : x) v.push_back(move(*it)); > } Again, that’s not how for-range works. What you want is for (auto&& e : x) v.push_back(std::move(e)); But that doesn’t actually work, because a std::initializer_list never gives you non-const access to its elements. I notice that your test case doesn’t test this constructor. Sebastian _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Darwin Clang Config failures.
by John Maddock 15 Sep '14

15 Sep '14

Does anyone understand why these all fail: http://www.boost.org/development/tests/develop/developer/output/marshall-ma… Is <functional> really broken on that platform? Surely not? Thanks, John.

4 3

proposal a movable_initializer_list
by 何子杰Hzj_jie 15 Sep '14

15 Sep '14

hi, all, the initializer_list in c++11 does not support the inner objects to be moved, so in some scenarios the performance will be significant impacted. say, an event class, which stores several std::function objects, and execute them later. the prototype is template <typename Args…> class event { private: std::vector<std::function<void(Args…)>> v; public: event(std::initializer_list<std::function<void(Args…)>>); void bind(std::function<void(Args…)>&&); }; When calling the constructor of event with a set of lambda expressions, the std::function objects will be copied instead of moved, and cause performance impact. Though pointer can resolve the issue, the syntax is not friendly, and the user needs to delete the instances manually. So I proposal a movable_initializer_list, it accepts two ways to construct, with an initializer_list<T*> or initializer_list<T>, the prototype is, template <typename T> class movable_initializer_list { private: std::vector<T> v; public: movable_initializer_list(std::initializer_list<T*>); movable_initializer_list(std::initializer_list<T>); // other functions same as initializer_list }; The implementation of T* overloads is something like movable_initializer_list<std::initializer_list<T*> x) { for(auto it : x) { assert((*it) != nullptr); v.push_back(std::move(**it)); delete *it; } } While the implementation of T overloads is something like moveable_initializer_list<std::initializer_list<T> x) { for(auto it : x) v.push_back(move(*it)); } Surely end-users need to aware the implementation of movable_initializer_list will move the objects instead of copy. The full implementation is at https://github.com/Hzj-jie/osi/blob/master/formation/movable_initializer_li…, and the test is at https://github.com/Hzj-jie/osi/blob/master/utt_cases/formation/movable_init…. Please feel free to give me some suggestions about this proposal. Thank you in advanced. .Hzj_jie

2 1

[vmd] Library Review
by Paul Mensonides 15 Sep '14

15 Sep '14

(apologies for the late review) -- Design -- Many of the utility components of the library have decent design. There are, however, a couple of aspects of the design that I dislike, and they touch on a large chunk of the library. These concerns all revolve around the registration, recognition, parsing, and limitations of various "v-types" and "v-sequences". I do not yet see a strong use case for the "v-key"/"v-identifier" recognition scenario, as opposed to just registering a "v-identifier". For example, #define BOOST_VMD_MAP_<v-key><v-identifier> // ... BOOST_VMD_IS_IDENTIFIER(<v-seq>, <tuple-of-v-keys>) Perhaps Edward can enlighten me about the use-cases for which this is ideal. I do see some use-cases, but in most cases it requires dispatch based on what the particular "v-identifier" it is anyway. One could do better for this low-level part with registrations such as (without a BOOST_VMD_ prefix for brevity) #define IDENTIFIER_CIRCLE (CIRCLE), #define IDENTIFIER_SQUARE (SQUARE), #define IDENTIFIER_TRIANGLE (TRIANGLE), #define IDENTIFIER_RECTANGLE (RECTANGLE), These definitions don't allow one to directly test for specific "v-identifiers", but they do allow one to extract registered "v-identifiers" from a "v-sequence". If all such registrations are required to be the same, there is no need for separate per-library prefixes. Macros can be defined multiple times if they are defined the same way. Similarly, the "v-numbers" could be pre-registered by the library as #define NUMBER_0 (0), #define NUMBER_1 (1), #define NUMBER_2 (2), // ... Tests for specific "v-identifiers" can be done via extraction from the above and using macro definitions such as #define COMPARE_CIRCLE_CIRCLE () #define COMPARE_SQUARE_SQUARE () // ... In many cases this sort of comparison is not needed, as one would directly dispatch off of the "v-identifier" itself. In any case, one could "parse" a "v-sequence" into "v-types" without many of the limitations of the current design. The following example uses Chaos, but I do not think there is anything in the design that fundamentally cannot be made to work on (e.g.) VC++. #include <chaos/preprocessor.h> #define NUMBER_1 (1), #define NUMBER_2 (2), #define NUMBER_3 (3), #define NUMBER_4 (4), #define NUMBER_5 (5), // ... // parser implementation... #define PARSE(vseq) PARSE_S(CHAOS_PP_STATE(), vseq) #define PARSE_S(s, vseq) \ CHAOS_PP_SPLIT(0, CHAOS_PP_EXPR_S(s)(CHAOS_PP_WHILE_S( \ s, PARSE_P, PARSE_O,, vseq \ ))) \ /**/ #define PARSE_P(s, seq, vseq) \ CHAOS_PP_COMPL(CHAOS_PP_IS_EMPTY_NON_FUNCTION(vseq)) \ /**/ #define PARSE_O(s, seq, vseq) \ seq CHAOS_PP_IIF(CHAOS_PP_IS_VARIADIC(vseq))( \ PARSE_O_A, PARSE_O_B \ )(vseq) \ /**/ #define PARSE_O_A(vseq) PARSE_O_A_A vseq #define PARSE_O_A_A(...) (3, (__VA_ARGS__)), #define PARSE_O_B(vseq) \ CHAOS_PP_IIF(CHAOS_PP_IS_VARIADIC(NUMBER_ ## vseq))( \ PARSE_O_B_A, \ CHAOS_PP_IIF(CHAOS_PP_IS_VARIADIC(IDENTIFIER_ ## vseq))( \ PARSE_O_B_B, PARSE_O_B_C \ ) \ )(vseq) \ /**/ #define PARSE_O_B_A(vseq) \ (1, CHAOS_PP_REM_CTOR( \ CHAOS_PP_SPLIT(0, NUMBER_ ## vseq) \ )), \ CHAOS_PP_SPLIT(1, NUMBER_ ## vseq) \ /**/ #define PARSE_O_B_B(vseq) \ (2, CHAOS_PP_REM_CTOR( \ CHAOS_PP_SPLIT(0, IDENTIFIER_ ## vseq) \ )), \ CHAOS_PP_SPLIT(1, IDENTIFIER_ ## vseq) \ /**/ #define PARSE_O_B_C(vseq) (0, vseq), // registrations... #define IDENTIFIER_CIRCLE (CIRCLE), #define IDENTIFIER_SQUARE (SQUARE), #define IDENTIFIER_TRIANGLE (TRIANGLE), #define IDENTIFIER_RECTANGLE (RECTANGLE), PARSE( CIRCLE RECTANGLE (a, b, c) TRIANGLE 3 (xyz) UNREGISTERED SQUARE ) (Apologies for any mistakes in the above. I wrote it up quickly.) This particular example results in key-value pairs of the form: (0, <unrecognized>) (1, <v-number>) (2, <registered-identifier>) (3, <tuple>) (2, CIRCLE) (2, RECTANGLE) (3, (a, b, c)) (2, TRIANGLE) (1, 3) (3, (xyz)) (0, UNREGISTERED SQUARE) There are a number of things that could be done instead of producing a binary sequence like this (which Boost.Preprocessor cannot handle). One could fold the results via a user-supplied macro, for example. Aside from the massive amount of clutter introduced by workarounds, many of the pieces of the above are already available either in Boost.Preprocessor or in other parts of the VMD library. For example, BOOST_VMD_IS_EMPTY is essentially CHAOS_PP_IS_EMPTY_NON_FUNCTION. -- Implementation -- I have not looked closely at the implementation, but I do know what a herculean effort it is to get this type of stuff working with VC++ in particular. -- Documentation -- There are few inaccuracies in the documentation related to motivations for various Boost.Preprocessor things, but those could be fixed. The documentation for BOOST_VMD_IS_EMPTY is decent except that essentially any input that ends with a function-like macro name will cause weird results or errors. So much so that the documentation should just disallow input that ends with a function-like macro name across the board. Other than that, the documentation needs some clean-up and organization (particularly of definitions), but does a reasonable job of documenting the library. I do feel that a lot of documentation complexity comes from the way that v-keys/v-identifiers (etc) are handled. -- Usefulness -- There is a definite use-case for many of the utilities in the library, and the fundamental concept v-sequence parsing. -- Testing -- I tested the library with GCC and everything functioned as advertised. -- Effort -- I did a fairly significant study of the design and interface of the library. -- Domain Familiarity -- I had my skull opened up and had "preprocessor metaprogramming" tattooed directly onto my brain. -- There are many good parts of the library--including the herculean effort to make it work on sub-par preprocessors such as VC++. However, at this point I would be hesitant to recommend acceptance based on the design of the v-type recognition and v-sequence parsing part. I am open to argument about why the current design is superior based on use-cases or technical limitations introduced by (e.g.) VC++ or, if it is not superior, a further review at a later date after a redesign because the underlying concept is sound. -- Regards, Paul Mensonides

3 14

Intel C++ Linux non-commercial software development license updated information
by Edward Diener 15 Sep '14

15 Sep '14

Just a quick note to tell anyone interested that evidently Intel has discontinued their free Intel C++ Linux compiler for developers based on their non-commerical software development license. If you look at their non-commercial software development license page at https://software.intel.com/en-us/non-commercial-software-development you will see that it only potentially offers a license for academics and the response I received on their online forum for Intel C++ is that they have discontinued their non-commercial software development license for developers, although they seem loth to make an announcement about it or publicize it. I have some recent versions of Intel C++ Linux with which I can still test but I will not be able to test the latest version(s) of Intel C++ on Linux. The isocpp Get Started page at https://isocpp.org/get-started still mentions the free Intel C++ version, but this evidently is no longer the case.

1 0

[process] [sorting] [singularity] [compute] [others] Who needs review manager?
by Antony Polukhin 14 Sep '14

14 Sep '14

Hi, Library authors that have no review manager and feel ready for review please contact me via this mailing list. -- Best regards, Antony Polukhin

7 14

[serialization] [libstdc++] [detail] utf8_codecvt_facet fixes broke serialization test_array_xml_warchive
by Beman Dawes 13 Sep '14

13 Sep '14

The specific crash message is: *** Error in `../../../bin.v2/libs/serialization/test/test_array_xml_warchive.test/clang-linux-libstdcpp/debug/test_array_xml_warchive': double free or corruption (!prev): 0x00000000015f6f90 *** It occurs for clang, gcc, and intel compilers, using libstdc++. It does not occur with clang using libc++. It does not occur with msvc 10.0, 11.0, or 12.0. None of the other libraries (filesystem, log, program_options, property_tree) that use utf8_codecvt_facet are failing on develop. This is mainly a heads up to let people know that the serialization problem in develop is being worked on, but it may be a day or two before I have a fix. --Beman

4 10

[asio] RFC on new reliable UDP library
by Niall Douglas 12 Sep '14

12 Sep '14

Dear Boost and ASIO users, CC: boost(a)lists.boost.org, asio-users(a)lists.sourceforge.net I am writing to ask for comments on the design of and interest in a generic reliable messaging library based on ASIO. Such a library could bring to ASIO very considerably improved data transfer performance over TCP, plus the ability to ignore NAT firewalls. The design imperatives for such a library are proving tricky to reach consensus upon, so perhaps the community might be able to help. Firstly, what features should such a reliable messaging library have? Here are some for you to consider: * Should it have wire transport backends with an abstraction from wire transports, so a UDT backend could be interchangeable with TCP for example with just a recompile needed? Upper level code need therefore not consider what format the wire transport takes, just that messages are reliably delivered or we are told of the connection failure. Some mechanism for dealing with out of order messages, and message expiry in case congestion control excessively delays outbound messages would also be included. You should be aware that congestion control for a reliable messaging library means one has no choice but to pace message construction (i.e. block/EWOULDBLOCK handing out new message send templates), otherwise one ends up buffering more data for sending than potentially can ever be delivered. This is because we cannot drop reliable messages, nor can we pace writes, so pacing new message construction is the only alternative. * Should it be zero copy for both receipt and send? If so, we'll have to break with the existing ASIO API somewhat - namely that MutableBufferSequence will need to now become MutableFileOffsetBufferSequence so one can supply scatter/gathers of user space buffers and kernel side buffers. We'll also have to templatise the buffer management so client code can supply the virtualisation (e.g. an iterator) which remaps inbound message fragments into apparently contiguous regions. By the time we have done these, the API looks quite different. * Should it be written using C++ 14 idioms instead of the existing 03 idioms ASIO uses? If so, basing read and write handlers on the C++ 17 proposed experimental::expected<T, E> (http://www.hyc.io/boost/expected-proposal.pdf) makes much more sense than the fixed ASIO handler prototype void (*handler)(const boost::system::error_code& ec, std::size_t bytes_transferred) - it is more powerful, more expressive, optionally integrates cleanly with no-alloc future-promise and the rest of the C++ 11/14 STL, and lets handlers use any mix of error reporting mechanism they choose. It also opens the door to a much cleaner and tighter integration of the future C++ 17 Networking TS with Concurrency TS. Equally, especially if combined with the earlier changes, it goes further and further away from the present ASIO design. * How concurrent should it be capable of? Unlike TCP where it makes not much sense to have concurrent writers, UDP allows enormous parallelism, potentially into queue depths of thousands on decent NICs, sufficiently so where a strand based design may simply not scale. We believe that with some effort a completely lock free design which can make full use of the batch datagram send and receive APIs on Linux and Windows is possible - we believe that such a design would scale close to linearly to CPU cores available. Unfortunately, as batch datagram send/receive is not supported by ASIO and on POSIX the main dispatcher appears to be locked by a mutex, this would require a custom code path and i/o service. If combined with all of the above, it starts to look like a rewrite of the core of ASIO which seems very big just to implement reliable messaging. I guess that is good for now for starting discussion. My thanks for your time in advance. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

9 17

[core/noncopyable][test/boost::unit_test::singleton] massive test failures
by Joaquin M Lopez Munoz 11 Sep '14

11 Sep '14

Hi, There's a problem with noncopyable and boost::unit_test::singleton in Intel 13 for Linux in C++11 compatibility mode that's rippling through many Boost libs. To list a few: date_time: http://tinyurl.com/lkeakab geometry: http://tinyurl.com/n3rajyn regex: http://tinyurl.com/kxkqo4c tuple: http://tinyurl.com/oz3vlct The error messages go like protected function "boost::noncopyable_::noncopyable::noncopyable()" [...] is not accessible through a "boost::noncopyable_::noncopyable" pointer or object[...] protected function "boost::unit_test::singleton<Derived>::singleton()" [...] is not accessible through a "boost::unit_test::singleton<boost::unit_test::unit_test_log_t>" pointer or object[...] which are manifestations of the following compiler bug: https://software.intel.com/en-us/forums/topic/404755 The report also indicates a simple workaround consisting of replacing BOOST_CONSTEXPR noncopyable() = default; with noncopyable() {} (seemingly, this would also fix boost::unit_test::singleton automatically.) Maybe the maintainer of boost:noncopyable can try a fix for ICC 13 along these lines? This can potentially clear a ton of yellow cells. I'd volunteer a pull request but alas I don't have local access to that compiler. Thank you, Joaquín M López Muñoz Telefónica

8 38

[build] clang objective c support?
by Emil Dotchevski 11 Sep '14

11 Sep '14

Hello, It seems like building with the clang-darwin toolset silently ignores .m and .mm files What is the status of Objective C support in this toolset? Is this a configuration problem on my part or is it just not supported? -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

3 6

ICL space and running complexity
by Kenneth Adam Miller 11 Sep '14

11 Sep '14

With regards to the ICL data structure, can anybody tell me what the space and time complexity is of the various interval_map types (split and regular)? http://www.boost.org/doc/libs/1_56_0/libs/icl/doc/html/index.html

2 1

[git] Problem after deleting submodule
by Edward Diener 10 Sep '14

10 Sep '14

Git is starting to get to me. I did a git pull from the latest master only to get a bunch of conflicts from the latest align submodule. I have never touched the align submodule locally so having conflict errors with it is absurd. After trying to straighten out the errors via a 'git reset --hard' for the align submodule, and still getting conflicts, I deleted the submodule locally just so I could get the latest master. Now I can't seem to get back the submodule. No matter what I do the submodule is no longer recognized at the top level. What do I do ? Yes git is powerful but it is also a VCS from hell. About the only intelligent thing I have ever heard Linux Torvalds say.

1 1

Trac spam report
by Joaquin M Lopez Munoz 09 Sep '14

09 Sep '14

I got this one: https://svn.boost.org/trac/boost/ticket/10437 Joaquín M López Muñoz Telefónica

5 6

_MSVC_VER - variadic_slot_invoker.hpp
by Anders Dalvander 09 Sep '14

09 Sep '14

There appears to be two predefined macro spelling mistakes in signals2/detail/variadic_slot_invoker.hpp. It says _MSVC_VER where it should say _MSC_VER. #if defined(_MSVC_VER) // <-- Here # pragma warning(push) # pragma warning(disable:4100) // unreferenced formal parameter #endif ... #if defined(_MSVC_VER) // <-- ... and here # pragma warning(pop) #endif Regards, Anders Dalvander

1 0

[range] Interest in range_call function?
by Arthur Rosenstein 09 Sep '14

09 Sep '14

Hi, I'm checking to see if there's interest in a range_call function that makes calling iterator-based algorithms with ranges a little less painful. Simply put, range_call takes a function and an argument list and forwards the arguments to the function while expanding ranges into begin/end iterator pairs. For example: range_call(std::sort, vec, std::greater<int>()); It can also transform the result a la Boost.Range: range_call(std::copy, range_call<return_begin_found>(std::unique, range_call<return_begin_end>(std::sort, vec) ), std::ostream_iterator<int>(std::cout, " ") ); Obviously, Boost.Range provides a cleaner interface for most standard algorithms. range_call, however, works with arbitrary functions and has a smaller surface area. Is there any interest in this (possibly as part of Boost.Range)? -- Cheers, Arthur

1 0

Re: [boost] [process] [sorting] [singularity] [compute] [others] Who needs review manager?
by Antony Polukhin 09 Sep '14

09 Sep '14

2014-09-08 22:52 GMT+04:00 Kyle Lutz <kyle.r.lutz(a)gmail.com>: > On Mon, Sep 8, 2014 at 9:03 AM, Antony Polukhin <antoshkka(a)gmail.com> > wrote: > > Hi, > > > > Library authors that have no review manager and feel ready for review > > please contact me via this mailing list. > > Hi Antony, > > The Boost.Compute library [1] is in need of a review manager. Also, > would it be possible to add it to the review queue listed at [2]? > > Thanks, > Kyle > > [1] https://github.com/kylelutz/compute > [2] http://www.boost.org/community/review_schedule.html > I took a quick glance at the library and it looks really interesting and promising. I'm not an expert in a problem domain, but at least I have some experience with CUDA. I'll need a few weeks to look through the sources and ask questions. If no one objects, after that we could discuss a review date and put it to the schedule. -- Best regards, Antony Polukhin

1 0

How to respond to mailing list
by Kirk Liberty 08 Sep '14

08 Sep '14

Hello, I'm sorry to have to ask this, but I've googled all around and can't figure it out. My email is set up to receive periodic digests of the mailing list. If I want to respond to an email thread, how would I do that? Thanks, Kirk

4 3

NTCTS Iterator [was: Interest in is_iterator type trait?]
by Beman Dawes 08 Sep '14

08 Sep '14

On Tue, Aug 19, 2014 at 1:56 PM, Peter Dimov <lists(a)pdimov.com> wrote: > Beman Dawes wrote: > > Source can be a iterator to a NTCTS or a container. >> > > An iterator to an NTCTS? That's an interesting invention. :-) > See http://beman.github.io/ntcts_iterator/ or https://github.com/Beman/ntcts_iterator --Beman

9 18

[Boost-users] Testers required
by Antony Polukhin 08 Sep '14

08 Sep '14

Hi, There is a big need in testers that have access to exotic platforms(zArch, MIPS) and compilers (Cray, IBM xlc ...). Could you please run `b2` in `boost/libs/type_index/test` and report results. This will help to test Boost.TypeIndex library and other libraries that depend on `demangle.hpp` I'll appreciate any help. Thanks in advance! -- Best regards, Antony Polukhin

2 2

Help identify the conversion bug in MSVC
by Andrzej Krzemienski 08 Sep '14

08 Sep '14

Hi, I found a bug in MSVC 10.0 that causes a bug in Boost.Optional. I will be trying to find a workaround for the compiler. I would like to ask people with the access to MSVC 11.0 and 12.0 to check if the bug also persist in these newer releases. The following code is expected to compile: struct A { A(int) {} A(A &&) {} }; struct B { operator A() { return A(1); } operator int() { return 0; } }; int main() { A t = B(); } The following code is expected *NOT *to compile: struct A { A(int) {} }; struct B { operator int() { return 0; } }; int main() { A t = B(); } Please let me know what your compiler says. Thanks, &rzej

2 2

Re: [boost] Finite state machine
by arcolight 07 Sep '14

07 Sep '14

> Hi, > I don't know if you're using msm or statechart but msm uses no dynamic > memory, except if you choose to use the event queue or deferred events. And > even this can be avoided by providing as template argument you own queue. > If you don't require these features, you can disable them. > > Cheers, > Christophe I'm using MSM. Yes I tried this, but I could not do so. Perhaps, I doing something wrong. Problem in that i've no OS, and even no full C library, I'm using newlib-nano. I was trying to disable everything, that I can, but this didn't help. I understand, that this situation is special and boostmust count on something. May be you can advise me how to use (and, may be,build?)boost with arm-none-eabi compiler.I've read docs and trying to build boost for arm-none-eabi, but compilation fails. Do I understand correctly, that MSM doesn't need to compile something - this is only .hpp files and it doesn't use libs, so I can try to use it without compilation? -- arcolight

2 1

[git][align][litre] git submodule update failure.
by Mostafa 07 Sep '14

07 Sep '14

$ git submodule update libs/align fatal: reference is not a tree: d32353ea7d39c0237202e3e460f3248f226db274 Unable to checkout 'd32353ea7d39c0237202e3e460f3248f226db274' in submodule path 'libs/align' $ git submodule update tools/litre fatal: reference is not a tree: 564d4d8d30b7e03ac5e25d78e14d2c19fa321c83 Unable to checkout '564d4d8d30b7e03ac5e25d78e14d2c19fa321c83' in submodule path 'tools/litre' According to this: http://stackoverflow.com/questions/13425298/git-submodule-update-fatal-erro… , this is most likely a maintainer's bug. From the above: "This is the most common problem with submodules. The commit that you are on in the outer repository has a reference to a commit in the submodule that someone did not push up yet. It's a dependency problem. Always push from the inside-out. This is most likely not something you did wrong, but someone else that's working in the repository. They were sloppy and forgot to issue push on the submodule and just pushed the containing repository. Stuff works on their machine because they made the change and those commits exist there." Is this true?

3 3

Re: [boost] Finite state machine
by arcolight 07 Sep '14

07 Sep '14

> Are you using Statechart or MSM? > -- Michael Caisse ciere consulting ciere.com I tried to use both. -- arcolight

1 0

Re: [boost] Finite state machine (arcolight)
by arcolight 07 Sep '14

07 Sep '14

> This is something that would be very interesting to me, but I wonder if the > memory allocation can be factored out in the current boost library by using > allocators or something. I'm not terrible familiar with the libraries > internals, but I'd be willing to take a look at my next free cycle. To be > clear, is there another state machine lib in boost besides > boost.statechart? That's the only one I'm familiar with from a user > perspective. > > -Greg Yes, custom allocator doesn't solve the problem, especially because current FSM-s includes many other libraries. In any case, I can't afford to use even custom allocator in my project, if I would use it, I must have sufficient size heap, it's risky in embedded system. I already have third-party code, that uses heap, and I couldn't do anything with it. :) Another FSM implementation - Boost.MSM(Meta state machine), I tried to use it in different ways, but i've failed. MSM based on MPL boost library. If you interested in code, I have small repo on github: https://github.com/arcolight/ecl, there are several small classes, one of them, in fsm.hpp - state machine. There are simple test with cd-player like in boost lib.

1 0

Finite state machine
by arcolight 07 Sep '14

07 Sep '14

Hi all. I have a question about participation in boost libraries. In my embedded project I'm using finite state machine and I tried to use one of the boost implementations of FSM, but they are too big and complex. Main disadvantage of them is usage of dynamic memory allocation, that I can't afford on my CPU and many dependencies, that I can't use on my CPU. CPU is ARM Cortex-M4 with 128K memory, I've no operating system in my project. I have write my own FSM implementation without dynamic memory and dependencies, it's more simple, than boost libraries, but, of course, not so powerful. I've used C++11 standard, specifically variadic templates. My question - Is there some interest in such FSM implementation for boost developers? I'll be very grateful for advice. P.S.: I'm sorry for my english, it's not my native language.

4 3

Autolinking broken in master
by Agustín K-ballo Bergé 06 Sep '14

06 Sep '14

There's a report that autolinking is broken for a fresh recursive checkout of master, due to b2 generating 1.57 libraries while boost/version.hpp still reports the version as 1.56. This commit setting BOOST_VERSION in Jamroot made it to master: https://github.com/boostorg/boost/commit/d9cf98c2074cf8a27017170375c5c825e4… While the corresponding commit for boost/version.hpp didn't: https://github.com/boostorg/config/commit/34e1c7416be2ede7d86f3dcc093a84580… Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com

1 0

[iterator] Merge to master
by Andrey Semashev 06 Sep '14

06 Sep '14

Hi, There were lots of changes to Boost.Iterator develop in the last few months. The tests look green for quite some time now. Could these changes be merged to master? I need those changes to merge next/prior in Boost.Utility.

2 1

sqlpp11, 3rd iteration
by Roland Bock 04 Sep '14

04 Sep '14

Dear Boosters, Quite a bit has happened since last I reported about sqlpp11 in this forum [1,2]. I have incorporated a lot of the feedback you gave me, hopefully bringing the library closer to a reviewable state. Source: https://github.com/rbock/sqlpp11 Doku: https://github.com/rbock/sqlpp11/wiki (not at all formal yet) I am hoping for more feedback both here and live at CppCon (http://sched.co/1r4lue3) Here are some noteworthy changes: _Restructuring:_ The code has undergone a major restructuring, leading to a much simpler and thereby much more flexible way to define the structure of SQL statements. As a result, it would now be quite simple to add vendor specific features sqlpp11 connector libraries. Dominique Devienne mentioned array binding for inserts, Johan Baltié mentioned hierarchical searches (both features of Oracle). If you are interested in writing a connector and adding such features, please let me know, I'll walk you through it. _NULL handling:_ Enabled by the restructured code and spurred by the library quince by Michael Shepanski, sqlpp11 can now calculate which result fields can or cannot be NULL. Speaking of which, handling NULL for result values has been discussed a lot. The library now has compile-time configurable behavior, you can choose between an std::optional-like interface and mapping NULL to the trivial value of the result type, e.g. 0 for numbers or "" for strings, see also https://github.com/rbock/sqlpp11/wiki/NULL _Connectors:_ Matthijs wrote a new postgresql connector from scratch, see https://github.com/matthijs/sqlpp11-connector-postgresql The sqlite3 connector received a bunch of corrections, thanks to dirkvdb _Compilers:_ Known to compile with clang>=3.1 and gcc>=4.8. I currently cannot test with MSVC or Intel or others, but if you happen to have the latest top notch version of any of those, I'd be interested in what they have to say about sqlpp11. Cheers, Roland [1]: http://lists.boost.org/Archives/boost/2013/11/208388.php [2]: http://lists.boost.org/Archives/boost/2014/02/211206.php

7 43

[move][unique_ptr] c++14 unique_ptr comes to town
by Ion Gaztañaga 03 Sep '14

03 Sep '14

Hi to all, We've discussed about a boostified version of std::unique_ptr several times in later years. I decided we could not continue with this hole in the Boost toolset and implemented in Boost.Move a unique_ptr that follows the C++14 interface. Commit here: SHA-1: e1da7c5ca1162841f643331af891a9a730eba118 http://github.com/boostorg/move/commit/e1da7c5ca1162841f643331af891a9a730eb… This implementation is also usable from C++03, and apart from the general limitations of the Boost.Move machinery, it should be really uesful for C++03 users. I would like to make this implementation the official boost::unique_ptr implementation, but until the community approves this, it's in boost::movelib namespace (boost::move it's a function so I needed to tweak the namespace name). I would like to thank Howard Hinnant for his great public implementation of the emulated unique_ptr published here: http://home.roadrunner.com/~hinnant/unique_ptr03.html I've ported and refactored Howard's extensive testsuite to implement boost test cases. Really useful to detect many implementation errors and details. I've found unique_ptr much harder to write than I expected. The standard text is really detailed and helps implementors, but things like allowed conversion between pointers and deleters and several ICEs and different SFINAE parties on many compilers made the work quite entertaining. The API is taken from the draft n3797 and the implementation has some differences with the standard. The main reason for this is that I wanted to make unique_ptr as lightweight as possible avoiding external dependencies, as it's interesting to implement idioms like PIMPL. Main attributes and differences with the standard: -> Implemented in two headers: <boost/move/unique_ptr.hpp> and <boost/move/make unique.hpp>. -> <boost/move/unique_ptr.hpp>: Boost.Move is the only heavyweight dependency. Not even that, as unique_ptr.hpp only uses boost/move/utility_core.hpp, that does not depend on any external library excepct BoostConfig and StaticAssert. No TypeTraits, MPL and others. Only Boost.Config, BOOST_STATIC_ASSERT and BOOST_ASSERT are used in the implementation. No standard library headers used (no pointer_traits, memory or other utilities). -> <boost/move/make unique.hpp>: Boost.PP is used in compilers without variadic templates. This is the main reason to have a separate make_unique.hpp header and avoid pulling Boost.PP for c++03 users that only want to have C++11 unique_ptr. -> unique_ptr's "operator <" is implemented as x.get() < y.get() instead of std::less<CT>(). std::less requires <funcional>. std::common_type requires C++11 standard library or some partial emulation based on Boost.TypeOf. I don't think 99,99% of users will notice the difference. For raw pointers, in all our platforms comparisons provide strict weak ordering. If a smart pointer writer specializes std::less for its smart pointer, it should be a law against that. -> It's assignable from literal 0. I found some problems in some compilers trying to write a constructor for that. -> nullptr support is conditional on !defined(BOOST_NO_CXX11_NULLPTR) but I think really should have a Boost nullptr for C++03 compilers. Let's put Meyer's nullptr (http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/nullptr) in Boost for BOOST_NO_CXX11_NULLPTR compilers. -> unique_ptr<T[]> is convertible to other types when conversion is considered safe. This means that unique_ptr<T[]> is convertible to unique_ptr<const volatile T[]>. Conversion from T[] to U[] is considered safe if remove_cv<T> is the same type as remove_cv<U> and unique_ptr<T[]>::pointer is convertible to unique_ptr<U[]>::pointer. This is a feature that might go to C++17 (http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2118) Safe conversions in reset() and constructors from pointers are also implemented in unique_ptr<T[]>. I tested the implementation in GCC{4.4, 4.6, 4.7, 4.8} Clang3.4 and MSVC{7.1, 8.0, 9.0, 10.0, 11.0, 12.0} in 32/64 bits, debug/release and C++03/C++11 modes (where applicable). The class documentation is generated with Boost.Move documentation and the most part of it is taken from the standard. I haven't added a tutorial to Boost.Move but I plan to it based on Howard's c++03 unique_ptr tutorial. I hope you find this addition to Boost.Move useful. If you think the implementation is good enough to be the official boost::unique_ptr implementation living in Boost.SmartPtr, porting should be easy, except for the documentation part. That would require either combining somehow handwritten and Quickbook produced documentation or writing new docs for unique_ptr. Best, Ion

6 30

Default documentation settings
by Glen Fernandes 03 Sep '14

03 Sep '14

What is the value of chunk.section.depth used, for those Boost libraries whose documentation is supplied only in QBK form (not the generated HTML from the QBK)? It appears to be 1, i.e. my sections-within-sections are not broken into separate pages. If so, could we make the default <xsl:param>chunk.section.depth=2? Glen

2 4

Can't file issues on trac with Chrome
by legalize+jeeves＠mail.xmission.com 03 Sep '14

03 Sep '14

[Please do not mail me a copy of your followup] Attempting to file a bug report gives me this message: "Captcha Error Submission rejected as potential spam (StopForumSpam says this is spam (username)) Trac thinks your submission might be Spam. To prove otherwise please provide a response to the following." ...but there is no captcha displayed in Chrome. If I attempt again in IE, then the captcha is displayed and I can enter the number and proceed. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

1 0

[fusion] Help co-maintaining Fusion modules
by Joel de Guzman 03 Sep '14

03 Sep '14

Hi Y'all, I need help in maintaining Fusion modules, especially those that are co-authored by someone else. For example, the Fusion Invoke module was authored by Tobias Schwinger who is unfortunately inactive now. I need help in maintaining the code, for instance, to adapt to C++11 and C++14. Case in point: https://svn.boost.org/trac/boost/ticket/10443 For that matter, I'd also like to take this opportunity to invite folks here to help out in some more aspects of the libraries I am involved with: Spirit, Fusion and Phoenix. If anyone is interested, please email me privately. THANKS! Regards, -- Joel de Guzman http://www.ciere.com http://boost-spirit.com http://www.cycfi.com/

1 0

[spinlock] concurrent_unordered_map is ready for review
by Niall Douglas 02 Sep '14

02 Sep '14

Dear Boost, CC: Howard, Jonathan for N3645 enhancements It has taken me far longer than I expected, however I believe that proposed boost::concurrent_unordered_map is ready for community feedback, with its unit test suite passing all green on the thread sanitiser and 92% coverage including exception safety tests. The main documentation page with the API and a lengthy explanation of the caveats in this design can be viewed at https://ci.nedprod.com/view/Boost%20Thread-Expected-Permit/job/Boost.S pinlock%20Test%20Linux%20GCC%204.8/doxygen/classboost_1_1spinlock_1_1c oncurrent__unordered__map.html Performance improves linearly to CPU cores at a slope of about 0.9. I only have four core hardware available to me, if someone could tell me how it scales to eight cores or more I would be very interested. Source code is at https://github.com/ned14/boost.spinlock. Tested on GCC 4.8, clang 3.4 and VS2013. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

6 13

Unable to find the boost.fsm library and turnstile example
by Aniket Pugaonkar 02 Sep '14

02 Sep '14

Hi, I wanted to implement a simple fsm using boost. i read the boost fsm doc http://boost-extension.redshoelace.com/docs/boost/fsm/doc/state_machine.html http://boost-extension.redshoelace.com/docs/boost/fsm/doc/reference.html but I couldnt locate the header files. Are the fsm library and other template classes located in boost statechart folder ? When I did a find in the subdirectories, I found this: boost version: 1.55 find . -name state_machine.hpp ./boost/msm/back/state_machine.hpp ./boost/spirit/home/support/detail/lexer/state_machine.hpp ./boost/statechart/state_machine.hpp ./libs/mpl/example/fsm/state_machine.hpp (1) Which one should I use to implement a simple FSM? (2) Also I couldnt find the turnstile example which they said is supposed to be in libs/fsm/examples/Turnstile folder. Can anyone please tell me the correct path and location ? [1]: http://boost-extension.redshoelace.com/docs/boost/fsm/doc/state_machine.html Regards Aniket -- Thanks and regards, Aniket Pugaonkar

2 3

Checking interest in DynamicLoad/DLL/DSO/Plugin library
by Antony Polukhin 02 Sep '14

02 Sep '14

Hi, There is a basic implementation of a header only Plugin library: https://github.com/apolukhin/Boost.Plugin Documentation with examples could be found here: http://apolukhin.github.io/Boost.Plugin/index.html Is there an interest in such library in Boost community? What features are missing in the library? Looking forward to hearing from you. Any feedback is more than welcomed. -- Best regards, Antony Polukhin

11 32

Review Wizard Status Report for August 2014
by Ron Garcia 02 Sep '14

02 Sep '14

============================================== Review Wizard Status Report for August 2014 ============================================== News ==== 1. Fiber Accepted Provisionally. January 2014. 2. Align Accepted. April 2014. 3. TypeIndex Accepted. May 2014. 4. Convert Accepted. June 2014. 5. Boost 1.56 Released -- New Libraries: Align, TypeIndex Open Issues =========== The following libraries have review managers, but have not yet been scheduled for review: * Range Extensions - added May 2012; review manager: Neil Groves. The following libraries have been accepted to Boost, but have not yet been integrated into Boost Git: * Contract - accepted September 2012; author: Lorenzo Caminiti. The following libraries have been accepted and submitted to Boost Git, but have not yet appeared in a release: * Convert - accepted June 2014; author: Vladimir Batov. The following libraries have been accepted provisionally to Boost, but have not been submitted for mini-review and full acceptance: * Fiber - accepted provisionally January 2014; author Oliver Kowalke. General Announcements ===================== As always, we need experienced review managers. Please take a look at the list of libraries in need of managers and check out their descriptions. In general review managers are active boost participants, including library contributors, infrastructure contributors, and other mailing list participants with a substantial track record of constructive participation. If you can serve as review manager for any of them, email Ron Garcia or John Phillips, "rxg at cs dot ubc dot ca" and "johnphillipsithica at gmail dot com" respectively. We are also suffering from a lack of reviewers. While we all understand time pressures and the need to complete paying work, the strength of Boost is based on the detailed and informed reviews submitted by you. If you are interested in reviewing a library but won't have time during the review period, you can always prepare your review ahead of time. No rule says you can only work on a review during the review period. A link to this report will be posted to www.boost.org. If you would like us to make any modifications or additions to this report, please email Ron or John. The review schedule is an unordered list of the libraries awaiting review. As such, any library on the schedule can be reviewed once the developer is ready, a review manager has been secured, and the manager, developer, and wizards agree on a date to schedule the review. Review Schedule =============== * Join (M) * Sorting (M) * Quaternions, Vectors, Matrices (M) * Block Pointer (M) * Singularity (M) * Extended Complex Numbers (M) * Metaparse (M) * Boost.Range Extensions * Nowide (M) * Array (M) * STL Extensions (M) * Countertree (M) * Process (M) * Asynchronous File I/O (M) * Application (M) * Edit Distance (M) * Mixin (M) ``(M)`` marks libraries that need review managers. -------------------- Join ---- :Author: Yigong Liu :Review Manager: Needed :Download: http://channel.sourceforge.net/ :Description: Join is an asynchronous, message based C++ concurrency library based on join calculus. It is applicable both to multi-threaded applications and to the orchestration of asynchronous, event-based applications. It follows Comega's design and implementation and builds with Boost facilities. It provides a high level concurrency API with asynchronous methods, synchronous methods, and chords which are "join-patterns" defining the synchronization, asynchrony, and concurrency. Sorting ------- :Author: Steven Ross :Review Manager: Needed :Download: https://github.com/boost-vault/Sorting :Description: A grouping of 3 templated hybrid radix/comparison-based sorting algorithms that provide superior worst-case and average-case performance to std::sort: integer_sort, which sorts fixed-size data types that support a rightshift (default of >>) and a comparison (default of <) operator. float_sort, which sorts standard floating-point numbers by safely casting them to integers. string_sort, which sorts variable-length data types, and is optimized for 8-bit character strings. All 3 algorithms have O(n(k/s + s)) runtime where k is the number of bits in the data type and s is a constant, and limited memory overhead (in the kB for realistic inputs). In testing, integer_sort varies from 35% faster to 2X as fast as std::sort, depending on processor, compiler optimizations, and data distribution. float_sort is roughly 70% faster than std::sort. string_sort is roughly 2X as fast as std::sort. Quaternions, Vectors, Matrices ------------------------------ :Author: Emil Dotchevski :Review Manager: Needed :Download: http://www.revergestudios.com/boost-qvm/ :Description: QVM defines a set of generic functions and operator overloads for working with quaternions, vectors and matrices of static size. The library also defines vector and matrix data types, however it allows users to introduce their own types by specializing the q_traits, v_traits and m_traits templates. Block Pointer ------------- :Author: Phil Bouchard :Review Manager: Needed :Download: https://svn.boost.org/svn/boost/sandbox/block_ptr/ :Description: Deterministic memory manager of constant complexity capable of handling cyclic collections. Singularity ----------- :Author: Ben Robinson :Review Manager: Needed :Download: https://github.com/cppmaven/Singularity :Description: The Singularity Design Pattern allows you to restrict any class to a single instance. Unlike the infamous Singleton, Singularity gives you direct control over the lifetime of the object, does not require you to grant global access to the object, nor does it limit you to the default constructor for that object. Extended Complex Numbers ------------------------ :Author: Matthieu Schaller :Review Manager: Needed :Download: http://code.google.com/p/cpp-imaginary-numbers/ :Description: The library is an extension of the std::complex class addressing two issues: 1. The standard does not guaranty the behaviour of the complex class if instantiated with types other than float/double/long double. 2. Some calculation where pure imaginary numbers (i.e. multiples of sqrt(-1)) appear are unnecessarily slowed down due to the lack of support for these numbers. The code I submit contains two interleaved classes boost::complex and boost::imaginary which can be instantiated with any type T provided T overloads the usual arithmetic operators and some basic (real) mathematical functions depending on which complex function will be used. It is thus an extended version of Thorsten Ottosen's n1869 proposal (http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1869.html) Metaparse --------- :Author: Abel Sinkovics :Review Manager: Needed :Download: http://abel.web.elte.hu/metaparse/metaparse.zip :Description: Metaparse is a library for constructing parsers parsing at compile-time based on template metaprogramming. The parsers built with the library take boost::mpl::strings as input and can produce - types - objects (types with public static members) - callable C++ functions (types with public static method) - template metafunction classes as output (based on the input being parsed). On compilers supporting constexpr the library provides the following syntactic sugar for writing the input of the parsers: BOOST_STRING("this is a string") The library can be used for implementing DSLs in C++, including DSLs making C++ template metaprogramming easier (see examples). Range Extensions ---------------- :Author: Akira Takahashi :Review Manager: Neil Groves :Download: https://github.com/faithandbrave/OvenToBoost :Description: This project adds some features of the Oven Range Library to Boost.Range. Features: - Additional Range Adaptors (taken, taken_while, dropped, dropped_while, elements, elements_key, memoized, outdirected) - Extensions for using Lambda (regular function, regular operator) - Infinite Range (iteration function) - and additional range utilities. Nowide ------ :Author: Artyom Beilis :Review Manager: Needed :Download: http://cppcms.com/files/nowide/ :Description: This library makes cross platform Unicode aware programming easier. It provides an implementation of standard C and C++ library functions, such that their inputs are UTF-8 aware on Windows without requiring to use Wide API. Array ----- :Author: Brian Smith :Review Manager: Needed :Download: https://github.com/BrianJSmith/Array :Description: The array class is a C++11 compatible implementation of static multidimensional arrays. STL Extensions -------------- :Author: Vadim Stadnik :Review Manager: Needed :Download: https://github.com/vstadnik/stl_ext_adv_review :Description: The proposed library [stl_ext_adv] offers augmented array based B+ trees and STL containers that support the interfaces of the C++03 sequences and associative containers. The library offers a number of extensions and performance improvements that are not available in C++03 and C++11 standard containers. Countertree ----------- :Author: Francisco Jose Tapia :Review Manager: Needed :Download: https://dl.dropbox.com/u/8437476/works/countertree_code_doc.zip :Description: This library is an implementation of a binary red-black counter tree. This tree have an additional counter in each leaf. This permit the access to the elements by the position, like in a vector. It is a random access container with random access iterators. COUNTERTREE This kind of trees have an additional counter in each leaf. This permit the access to the elements by the position, like in a vector. It is a random access container with random access iterators. With unordered information we have a vector with the same speed inserting and deleting in any position (O(log N)). With ordered information, we have the classes set, multiset, map and multimap, with identical interface than the STL classes, with the plus of access to the elements by position, like in a vector. The iterators are random access , and you can subtract them. SUBALLOCATOR The suballocator is a layer between the allocator and the data structures, compatible with any allocator with the STL definition. The suballocator replace to the allocator in the allocation of equal size elements. It provides speed, return the unused memory and decrease the memory used by the program and improve the cache performance due to the data locality improvement ( 30% of improvement of speed respect the std::allocator with GCC 4.7) Process ------- :Author: Boris Schaeling :Review Manager: Needed :Download: http://www.highscore.de/boost/process0.5/process.zip :Description: Boost.Process is a library to manage system processes. It can be used to: * create child processes * setup streams for child processes * communicate with child processes through streams (synchronously or asynchronously) * wait for processes to exit (synchronously or asynchronously) * terminate processes Asynchronous File I/O --------------------- :Author: Niall Douglas and Paul Kirth :Review Manager: Needed :Download: https://github.com/BoostGSoC/boost.afio/archive/boost-peer-review.tar.gz :Description: Boost.AFIO is a linear scalable, batch, chainable, asynchronous closure execution engine with an almost wait free implementation extending Boost.ASIO and Boost.Thread specialised as a portable asynchronous file i/o implementation library. Implementation of this first version has been kept as simple as possible (~ 1000 active LOC) at the cost of some performance, though with a good compiler you can expect 25-50% of the performance of using raw Boost.ASIO. Application ----------- :Author: Renato Tegon Forti :Review Manager: Needed :Download: https://github.com/retf/Boost.Application :Documentation: http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/index.html :Description: Application provides an application environment, or start point to any people that want a basic infrastructure to build an system application on Windows or Unix Variants (e.g. Linux, MacOS). Application uses behaviours modeled using 'aspects' concept proposed by 'Vicente J. Botet Escriba', that allow easy extension and customization of library components. The application modes uses these components internally to achieve the user desirable behaviours. Application provide many useful ready-to-use features, e.g: * Run application as Windows Service; * Run application as UNIX/POSIX Daemon; * Plugin extension system; * Process(executable) Single instance Instantiation support; * Application SIGNAL/Callbacks customization; * Windows Service Setup feature; * And many others. Edit Distance ------------- :Author: Erik Erlandson :Review Manager: Needed :Download: https://github.com/erikerlandson/algorithm/tree/edit_distance/sequence :Description: The edit distance is the length of the shortest (or least-cost) edit script from one sequence to another, where an edit script is defined as a sequence of insertion, deletion and (optionally) substitution operations. The function implementing the edit distance is named edit_distance. This function will return the edit distance between two sequences, where sequences may be any valid range object supporting forward iteration. The edit_distance function will also, if requested, return the edit script. Mixin ----- :Author: Borislav Stanimirov :Download: https://github.com/iboB/boost.mixin :Documentation: http://ibob.github.io/boost.mixin/ :Review Manager: Needed :Description: Boost.Mixin is a library that allows the composition and modifications of polymorphic types at run time. Types and objects are constructed out of building blocks called mixins. The library uses the type boost::mixin::object as a placeholder, whose instances can be extended with existing classes (mixins), thus providing a particular instance with the functionality of all those types. Accessing the newly formed type's interface is made through messages: stand-alone functions generated by the library, which can be thought of as methods. This is given while also having full abstraction between the interface and the definition of types. An existing feature in another language similar to Boost.Mixin and also an inspiration for the library are the mixins in Ruby. The library also has similarities with the pattern entity-component-system. Libraries under development =========================== See http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction for a current listing of libraries under development.

2 3

[quickbook] miss-generated headings?
by John Maddock 01 Sep '14

01 Sep '14

I have a problem with quickbook code that has [h6 ...] elements in it - these end up being larger in both html and pdf output than [h5 ] blocks which is not so good :-( From what I can tell, [h5 ] actually produces html <h6> and [h6 ] produces html <h5>. BTW I realise [h6 ] is a lot of nesting, but the current stylesheet make <h6> quite a bit larger than surrounding text, so <h7> seems to be not beyond the realms of possibility? Thanks, John.

3 2

[build] b2 headers don't work for sublibs
by Andrey Semashev 01 Sep '14

01 Sep '14

Hi, I'm trying to move some headers of Boost.MPL to a sublib Boost.MPL.Core. I've reorganized the repository as follows: libs mpl book core include boost <- here and below are core headers test index.html doc example include boost <- here and below are the rest headers meta preprocessed test .git .gitattributes README.md index.html sublibs The problem is when I run 'b2 headers' the command creates a symlink boost/mpl pointing to libs/mpl/include/boost/mpl, which leaves out all headers from libs/mpl/core/include/boost/mpl. How do I instruct Boost.Build to create links to the core headers?

6 12

Re: [boost] [graph] strong_components & depth_first_visit feature proposal
by Jeremiah Willcock 31 Aug '14

31 Aug '14

On Wed, Aug 27, 2014 2:39 AM EDT Alexander Lauser wrote: >> * 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). >> >> Have you tried deriving from default_dfs_visitor? > >Yes, but why only make finish_edge optional? I think it would make >user-code (slightly) clearer if all events were optional. It's no big >deal, of course, and that's why it's a minor question. > >Alex > > >PS: For the background, I'm quite new to Boost and for me it is somewhat >arbitrary that everything is mandatory but finish_edge. The reason, >however, seems to be historical: I recently saw that, at least in Boost >version <= 1.39, there was no finish_edge-event. That is why it is (or at least is trying to be) optional. Visitors from before that event was added would become incorrect if it was not optional, leading to compatibility problems. Making all of the events optional would be possible as long as Boost.TTI could detect all of the signatures that are in use for them currently. -- Jeremiah Willcock

2 1

[vmd] Library review
by Matt Calabrese 31 Aug '14

31 Aug '14

Design: As a set of utility macros, there is not too much to be said. The macros that are presented are generally useful and fill some needs that are encountered when doing preprocessor metaprogramming. Implementation: I admittedly haven't examined the implementation itself too closely, but I have used the library in practice with both clang and gcc without problems on a considerably large preprocessor project (~50k lines preprocessor programming), albeit a few years ago. Documentation: I read through the entirety of the documentation and it is fairly good at describing some of the problems faced when doing preprocessor metaprogramming, such as the lack of truly being able to detect emptiness and the implementation weaknesses of certain non-compliant preprocessors. That said, I feel like it focuses a lot on the hairiness of the preprocessor and not enough on the functionality that the library itself provides. For example, the tuple-related macros (being able to deal with something that is a tuple with more tokens after the tuple, for instance) are very useful in preprocessor metaprogramming, but the documentation doesn't do much to explain why. As well, while what to expect from expansion of the macros is described, examples are absent. To be more specific, take these two bits of the documentation: BOOST_VMD_BEGIN_TUPLE http://htmlpreview.github.io/?https://raw.githubusercontent.com/eldiener/va… BOOST_VMD_AFTER_TUPLE http://htmlpreview.github.io/?https://raw.githubusercontent.com/eldiener/va… Although the macros are described, a set of examples could go a long way. For instance something as simple as the following can go quite a long way: BOOST_VMD_AFTER_TUPLE( (int a, float b, char c) const ) // yields: const The above both more directly shows what you can expect from the macro and also may better explain the usefulness. To people experienced with [ab]using the preprocessor, why you want to use these macros is often obvious, but most people are not very familiar with preprocessor metaprogramming and I think the docs sort of need to be aware of that. Examples and a motivation explaining why the particular set of macros provided is important. Perhaps what might be best is to start the documentation with a tutorial that takes the user through the uses that come up in practice when I.E. designing a simple EDSL through preprocessor metaprogramming. Usage: Years ago I used the VMD library when developing [not a boost lib] Boost.Generic. Prior to VMD being around, I had hand-rolled much of the functionality into Boost.Generic that VMD provides, though I very quickly stopped caring about VC++ support. When VMD was in the boost sandbox, I swapped out everything I could with invocations to VMD's macros and it freed me of the maintenance burden of trying to support noncompliant compilers. Needless to say, VMD "just worked" and I find it likely that other people who use the preprocessor in these ways would find VMD just as useful as I have. For my project I was testing with both GCC and Clang and had no problems with anything that VMD provided. Domain familiarity: I've done an embarrassingly large amount of preprocessor metaprogramming and, again, I find this library useful. ===== Overall, I'd say that this library should make it into boost. The biggest thing that it lacks is motivation in documentation, lack of examples, and a practical tutorial, but these should be able to be added before the library would make it into a release. Other than that, I do think there might be some way to roll this into Boost.Preprocessor, but I have no strong feelings on the matter and it's really up to Paul. So this a +1 from me, as long as the documentation gets some improvement. -- -Matt Calabrese

2 1

[conceptcheck] Document using namespace boost.
by Mostafa 31 Aug '14

31 Aug '14

I'm not unfamiliar with Boost.ConceptCheck, though I've used it very infrequently. So, like all familiar but infrequently used libraries I skip to the examples to jog my memory as to their usage. Invariably, if the examples or the tutorial are not complete then I end up repeating past mistakes. This is the case with Boost.ConceptCheck library. All the examples on this page: http://www.boost.org/doc/libs/1_56_0/libs/concept_check/using_concept_check… (which is the quick 5 minute introduction on how to use ConceptCheck) assume some previous "using namespace boost;" declaration, yet that is not documented on that particular page or any previous page. Can this be fixed to save new and infrequent users of the library unneeded head-scratching and wasted time? (I can open a trac ticket if that helps.) Thanks.

1 0

[config] BOOST_NO_CXX11_HDR_FUNCTIONAL and VC++10
by Edward Diener 31 Aug '14

31 Aug '14

While BOOST_NO_CXX11_HDR_FUNCTIONAL is not defined for VC++10 my tests show that std::ref in VC++10 is broken in a very simple case. Here is the code for that case: // test_vc10_refwrapper.cpp #include <functional> class p_functor_class_char { public: p_functor_class_char() : data('A') {} char operator()() { return data; } private: char data; }; void main() { p_functor_class_char pfcc; std::function<char ()> sf(std::ref(pfcc)); } which for VC++10 gives: > c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\xxcallobj(13) : error C2440: 'return' : cannot convert from 'void' to 'char' > Expressions of type void cannot be converted to other types > c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\xxfunction(65) : see reference to function template instantiation '_Ret std::tr1::_Callable_obj<_Ty>::_ApplyX<_Rx>(void)' being compiled > with > [ > _Ret=char, > _Ty=std::tr1::reference_wrapper<p_functor_class_char>, > _Rx=char > ] > c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\xxfunction(64) : while compiling class template member function 'char std::tr1::_Impl_no_alloc0<_Callable,_Rx>::_Do_call(void)' > with > [ > _Callable=_MyWrapper, > _Rx=char > ] > c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\xxfunction(386) : see reference to class template instantiation 'std::tr1::_Impl_no_alloc0<_Callable,_Rx>' being compiled > with > [ > _Callable=_MyWrapper, > _Rx=char > ] > c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\xxfunction(369) : see reference to function template instantiation 'void std::tr1::_Function_impl0<_Ret>::_Reset0o<_Myimpl,_Fty,std::allocator<_Ty>>(_Fty,_Alloc)' being compiled > with > [ > _Ret=char, > _Fty=std::tr1::reference_wrapper<p_functor_class_char>, > _Ty=std::tr1::_Function_impl0<char>, > _Alloc=std::allocator<std::tr1::_Function_impl0<char>> > ] > c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\functional(126) : see reference to function template instantiation 'void std::tr1::_Function_impl0<_Ret>::_Reset<std::tr1::reference_wrapper<_Ty>>(_Fty)' being compiled > with > [ > _Ret=char, > _Ty=p_functor_class_char, > _Fty=std::tr1::reference_wrapper<p_functor_class_char> > ] > test_vc10_refwrapper.cpp(15) : see reference to function template instantiation 'std::tr1::function<_Fty>::function<p_functor_class_char>(std::tr1::reference_wrapper<_Ty>)' being compiled > with > [ > _Fty=char (void), > _Ty=p_functor_class_char > ] With VC++11 and VC++12 this has been fixed. Using boost::function and boost::ref there are no problems in VC++10. I realize that this might not really be an issue in Boost but I was still wondering if this is a known problem with any Boost developers. I ran into it during tests, where I was letting BOOST_NO_CXX11_HDR_FUNCTIONAL determine whether to use std or boost versions of the functionality in the C++11 <functional> header.

1 0

[review] [vmd] Last day of review period - reviewers needed
by Steven Watanabe 30 Aug '14

30 Aug '14

AMDG The limited amount of feedback has been generally positive, but I haven't seen any full reviews, yet. If anyone is planning to review the library, please let me know. In Christ, Steven Watanabe

3 2

Trac getting spammed
by John Maddock 30 Aug '14

30 Aug '14

We seem to be getting more than the usual amount of spam on the Trac recently, I've deleted quite a few, but I bet there are others I haven't seen. Latest is https://svn.boost.org/trac/boost/ticket/10358 Anyone any ideas for blocking these guys? Thanks, John.

9 13

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

[Serialization] link error in 1.56
by Tobias Loew 25 Aug '14

25 Aug '14

Hi, linking the serialization lib fails in version1.56 with unresolved symbols due to the missing implementation of boost::archive::detail::shared_ptr_helper::shared_ptr_helper(void) boost::archive::detail::shared_ptr_helper::~shared_ptr_helper(void) up to version 1.55 those symbols were defined in libs\serialization\src\shared_ptr_helper.cpp, but now this file is excluded from the build and contains the implementation of a nowhere defined class shared_ptr_helper_base. Is there a replacement for shared_ptr_helper, is it redundant or is serialization broken in 1.56? Tobias -- View this message in context: http://boost.2283326.n4.nabble.com/Serialization-link-error-in-1-56-tp46668… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

[container] New container: why is everybody silent?
by Alexander Kuprijanov 25 Aug '14

25 Aug '14

Hi boost community! Please tell me something about my container, don't be silent. I firmly intend to offer it to boost, because it's much faster than competitors (by a constant factor). It's intended to replace std::vector in cases, when an application requires multiple insertion/deletion. It takes O(log(N)) for insertion/deletion. Docs: http://alexkupri.github.com/array/ Code: https://github.com/alexkupri/array Best regards, Aleksandr Kupriianov

10 22

[move] const rvalue failure.
by Mostafa 25 Aug '14

25 Aug '14

The following fails to compile on both g++ 4.8.2 and VS2005 using Boost 1.56: #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: //Declared and purposefully not defined. MOC & operator=(MOC); private: BOOST_MOVABLE_BUT_NOT_COPYABLE(MOC) }; MOC moveonlyMutableRValue() { return MOC(); } MOC const moveonlyConstRValue() { return MOC(); } int main() { MOC m(moveonlyConstRValue()); return 0; } with g++, I get the following error messages: boost_move_const_rvalue.cc: In function ‘int main()’: boost_move_const_rvalue.cc:28:30: error: invalid user-defined conversion from ‘const MOC’ to ‘boost::rv<MOC>&’ [-fpermissive] MOC m(moveonlyConstRValue()); ^ In file included from boost_move_const_rvalue.cc:1:0: /home/HPC/boost_installed/v1_56_0/include/boost/move/core.hpp:219:7: note: candidate is: MOC::operator boost::rv<MOC>&() <near match> operator ::boost::rv<TYPE>&() \ ^ boost_move_const_rvalue.cc:13:3: note: in expansion of macro ‘BOOST_MOVABLE_BUT_NOT_COPYABLE’ BOOST_MOVABLE_BUT_NOT_COPYABLE(MOC) ^ /home/HPC/boost_installed/v1_56_0/include/boost/move/core.hpp:219:7: note: no known conversion for implicit ‘this’ parameter from ‘const MOC*’ to ‘MOC*’ operator ::boost::rv<TYPE>&() \ ^ boost_move_const_rvalue.cc:13:3: note: in expansion of macro ‘BOOST_MOVABLE_BUT_NOT_COPYABLE’ BOOST_MOVABLE_BUT_NOT_COPYABLE(MOC) ^ boost_move_const_rvalue.cc:28:30: error: passing ‘const MOC’ as ‘this’ argument of ‘MOC::operator boost::rv<MOC>&()’ discards qualifiers [-fpermissive] MOC m(moveonlyConstRValue());

1 2

[serialization] get_helper documentation
by Joaquin M Lopez Munoz 24 Aug '14

24 Aug '14

Hi, I see the Loading and Saving Archive concepts in Boost.Serialization have been augmented with helper support via get_helper<Helper>(). However, this is only explicitly documented for *Loading* Archives, http://www.boost.org/libs/serialization/doc/archives.html when indeed Saving Archives must and do also provide such a member function. Best, Joaquín M López Muñoz Telefónica

1 0

[type_traits] is_character<T> trait
by Antony Polukhin 24 Aug '14

24 Aug '14

Hi, Boost.LexicalCast has a trait boost::detail::is_character<T>, that evaluates to true if T is char, char16_t, wchar_t, unsigned char or any other character type. If this trait looks useful, I can move it to TypeTraits library, add docs and tests. Is there any interest in such trait? -- Best regards, Antony Polukhin

3 2

Re: [boost] [Boost-users] [Chrono] The default BOOST_CHRONO_VERSION is still 1
by Vicente J. Botet Escriba 24 Aug '14

24 Aug '14

Le 24/08/14 01:49, DonM a écrit : > -------- Original Message -------- > Subject: Re: [Boost-users] [Chrono] The default BOOST_CHRONO_VERSION > is still 1 > From: "Vicente J. Botet Escriba" <vicente.botet(a)wanadoo.fr> > Date: 8/23/2014 6:28 AM > To: boost-users(a)lists.boost.org >> >> Le 23/08/14 01:41, DonM a écrit : >>> The docs (boost_1_56_0/doc/html/chrono/reference.html) say: >>> >>> "The default value for BOOST_CHRONO_VERSION will be changed to 2 >>> since Boost 1.55. " >>> >>> However, it still has the value 1 in both 1.55 and 1.56. >>> >>> Not a big deal, I just noticed and figured I'd mention it. >>> >> Hi, >> >> I must remove this comment as as there is a incompatibility this will >> break user code. I planned to do a smooth trarnsition, but there were >> some complains. >> >> Thanks for pointing this issue, >> Vicente > > Are you saying that you never intend to change the default value? That > would be a mistake, in my opinion. Version 2 is much better -- the I/O > stuff works. If users need backwards compatibility, they can define > version 1, but encourage people to use version 2. Just my $0.02. > What others think? Vicente

1 0

[math] pull request for boost::math::round bug in corner cases
by Robin Eckert 24 Aug '14

24 Aug '14

Hello, I found two corner cases in which boost::math::round doesn't round correctly. For double types, these are the numbers directly beneath 0.5: +/- 0.499999999999999944488848768742172978818416595458984375 (which get rounded to 1.0 although their aboslute value is smaller than 0.59) and odd integral numbers on the edge of the mantissa length: +/- 4503599627370497.0 +/- 4503599627370499.0 +/- 4503599627370501.0 ... +/- 9007199254740989.0 +/- 9007199254740991.0 +/- 9007199254740993.0 These get rounded to the next bigger/smaller integral value. For a detailed explanation and a fix, see the description of the pull request on https://github.com/boostorg/math/pull/8 Regards, Robin

1 0

[test] Using BOOST_CHECK_EQUAL with enum
by Edward Diener 23 Aug '14

23 Aug '14

In code I have the expression: BOOST_CHECK_EQUAL(cnew,e_test_third); where 'cnew' is: test_enum cnew; and test_enum is: enum test_enum { e_test_default, e_test_first, e_test_second, e_test_third }; This is giving me the error: ..\..\../boost/test/test_tools.hpp:100:1: error: expected ')' before 'do' do { \ ^ ..\..\../boost/test/test_tools.hpp:169:5: note: in expansion of macro 'BOOST_CHECK_WITH_ARGS_IMPL' BOOST_CHECK_WITH_ARGS_IMPL( ::boost::test_tools::tt_detail::equal_impl_frwd(), "", CHECK, CHECK_EQUAL, (L)(R) ) ^ test_auto_value.cpp:64:4: note: in expansion of macro 'BOOST_CHECK_EQUAL' BOOST_CHECK_EQUAL(cnew,e_test_third); ^ Is Boost Test incapable of checking that an enumeration object equals an enumerated value ? Is this a known problem ? How do I work around it ?

1 1

[iterator] Merge pull request
by Andrey Semashev 23 Aug '14

23 Aug '14

Hi, Some time ago I made this pull request: https://github.com/boostorg/iterator/pull/6 It makes some of the implementation details of Boost.Iterator public. These components are already used in Boost.Range and Boost.Tokenizer and the intent is to further patch these libs to use public interfaces instead of the implementation details. Could this pull request be merged?

2 6

[filesystem] Epoch of trivial_clock
by Bjorn Reese 23 Aug '14

23 Aug '14

The filesystem::trivial_clock type is implementation-defined [1]. That means that the epoch is also implementation-defined. How do we determine the epoch of trivial_clock? For instance, we may need to represent the last_write_time() timestamp to the end-user, or transfer it to another node when we implement a network file system. PS: I am looking at the std::filesystem proposal, but I assume that boost::filesystem will be update accordingly. [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4097.html#8

5 7

GSOC: Boost.Math: hypergeometric functions
by Anton Bikineev 22 Aug '14

22 Aug '14

Hi all, I'm glad to represent my GSoC project work about implementation of hypergeometric functions: https://github.com/BoostGSoC14/boost.math I would like to thank everybody who helped me, essentially my mentor Christopher Kormanyos, my advisors John Maddock, Paul Bristow and, of course, Niall Douglas. The concentration of the project was mostly confluent hypergeometric function 1f1. Some essential algorithms were implemented and research works were done. A few short articles may be read in my blog: http://antoha-bikineev.blogspot.com Of course, it's gonna be updated while researching. The most important thing for me is that this work opened new ideas, ways and approaches for development and investigation of new numerical algorithms. Some of them are intended to reduce probability of cancellation errors in power series and to reduce round-off errors for recurrence relations at unstable directions. So there are plenty of stuff to do and improve.

1 0

[graph] Faster strong_components-implementation
by Alexander Lauser 22 Aug '14

22 Aug '14

Hi all, reimplementing Tarjan's dfs-visitor used in Boost.Graph's algorithm to compute strong components yielded a performance gain of about 15 to 20% (for adjacency_list-graphs). The problem is that due to bug #10231 [1], this implementation does not work with a current vanilla version of Boost. (See below for some details explaining my changes and the reason it is affected by the bug.) Is there interest in the faster implementation? If so, what's the best way to proceed? Wait until the bug is fixed and then incorporate the changes in a pull request? Create a pull request and hope that is not merged before the bug is fixed? Btw, my feeling is that the bug's not too involved and I tried to fix it myself. It seems that it is not even in Boost.Graph itself, but in Boost.TTI (in the macro-depths of which I got lost). Should I file a separate bug for Boost.TTI? For the details: My implementation is a back-to-the-root-approach, following the classical formulations of Tarjan's algorithm more closely. The current implementation somewhat "simulates" edge events upon leaving a vertex by an additional loop over all edges incident to the vertex. This can be avoided by using finish_edge -- which suffers from the above mentioned bug. (In addition to the performance-boost, I think it is also more natural to implement Tarjan's algorithm using finish_edge.) Cheers, Alex [1] https://svn.boost.org/trac/boost/ticket/10231

1 0

ISO C++14 passes final ballot
by Beman Dawes 21 Aug '14

21 Aug '14

All 18 countries voting voted "yes". See http://isocpp.org/blog/2014/08/we-have-cpp14

7 7

[container] variadic template support in g++ 4.5.1
by Richard Hadsell 21 Aug '14

21 Aug '14

I am trying to compile some of our code with Boost 1.56.0 on a Linux (Fedora 14) platform with this compiler: gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) I apologize for using this ancient version of g++, but we're stuck with it for a while longer. I get this error message: In file included from .../boost/circular_buffer/details.hpp:19:0, from .../boost/circular_buffer.hpp:56, from ...: /netDISKS/master/netmt/LINUX_INTF14/cgi/boost/1.56.0/Include/libboost/boost/container/allocator_traits.hpp: In static member function 'static void boost::container::allocator_traits<Alloc>::priv_construct(boost::false_type, Alloc&, T*, const Args& ...)': /netDISKS/master/netmt/LINUX_INTF14/cgi/boost/1.56.0/Include/libboost/boost/container/allocator_traits.hpp:324:43: sorry, unimplemented: cannot expand 'Args ...' into a fixed-length argument list /netDISKS/master/netmt/LINUX_INTF14/cgi/boost/1.56.0/Include/libboost/boost/container/allocator_traits.hpp:325:51: error: 'value' is not a valid template argument for type 'bool' because it is a non-constant expression /netDISKS/master/netmt/LINUX_INTF14/cgi/boost/1.56.0/Include/libboost/boost/container/allocator_traits.hpp:325:57: error: invalid type in declaration before ';' token Line 324 is in a block guarded by: #if !defined(BOOST_NO_CXX11_VARIADIC_TEMPLATES) config/compiler/gcc.hpp defines BOOST_NO_CXX11_VARIADIC_TEMPLATES for g++ earlier than 4.4, which means it believes the code should be valid for 4.5.1. Is there already a fix for this in development? Please, tell me what to do with my copy of 1.56.0. -- Dick Hadsell 203-992-6320 Fax: 203-992-6001 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 1 American Lane, Greenwich, CT 06831-2560

2 4

intrusive_ptr wrapper for C++/CLI
by Stephen Channell 21 Aug '14

21 Aug '14

I do a lot of development using native C++ and managed C++/CLI, and have coded a simple smart pointer wrapper around intrusive_ptr to allow C++/CLI code to use reference counting objects without change. IntrusivePtr takes advantage of the template support engineered for gcroot<T> to implement the smart pointer. It’s a wrapper to support factory functions that return intrusive_ptr. Whilst many would object to putting C++/CLI conditional code into boost, the smart pointer is too small to stand alone and too boost specific for Microsoft. thoughts welcome https://ql.codeplex.com/SourceControl/latest#IntrusivePtr/boost/IntrusivePt…

3 3

Re: [boost] [units] Pull request and RFC: information unit definitions for Boost.Units
by Curdeius Curdeius 21 Aug '14

21 Aug '14

Hi all, From: Jürgen Hunold <jhunold(a)gmx.eu> > > > I'd like to have a definite response on "go/no go" for maintainership > > > before I invest some of my scarce time on this. > > > > Go for it. > > Thanks a lot. > > Done. See https://github.com/boostorg/admin/issues/83 for my request. > > Please bear with me as I want to check the current repository state first. > The > plan is to tackle the simple pull requests afterwards and then come back to > the features. > > Yours, > > Jürgen > Firstly, congratulations Jürgen! Secondly, a few days ago I have proposed myself to be a co-maintainer together with Jürgen (see the cite below), but have still no answer from the community. At least Jürgen is not against. So, I ask for a green light from the community to co-maintain Boost.Units. Hi all, > I considered proposing myself as a maintainer of Boost.Units for some > time, but considered too inexperienced to do it on my own. > Therefore I am happy that Jürgen proposed himself and I would like to help > him by being a co-maintainer if it is possible and needed. > As for me, I have been using the library for at least 3 years now and > would like to contribute to it. > For the moment, I mainly proposed small bug fixes to Boost libraries. > Regards, > Marek Kurdej > -- > Ph.D. candidate Best regards, Marek Kurdej -- Ph.D. candidate

3 2

Boost Hana comments
by Jeremy Maitin-Shepard 21 Aug '14

21 Aug '14

First off, while I haven't thoroughly reviewed the library, I am certainly impressed by a lot of what I see. It is obvious that this library represents a lot of excellent work. Here are my miscellaneous comments: Constant type class: -------------------- Why isn't std::integral_constant an instance? There is no documentation of what the value method actually returns, just that it returns something that is a constexpr. Does value(integral<int,3>)) return int, or does it return integral<int,3> ? Perhaps the Constant type class should be "parameterized" by a type specifying the return type of value. Integral data type: ------------------- It would be better not to duplicate std::integral_constant. However, I recognize that the overloaded operators are useful and you wouldn't be able to do this with std::integral_constant (well, I suppose you still could, but as they wouldn't be found by ADL, they wouldn't be terribly useful). This rationale (assuming it is correct) should be documented though. Logical type class: ------------------- What is really gained by making this a type class at all? It seems that and_ and or_ require that all arguments be of the same "hana datatype", though actually this isn't documented anywhere and this might not even be the precise requirement (but obviously it needs to be documented very explicitly, and this probably applies to almost every method in Hana). Really we really should be able to mix multiple data types in a call to or_ or and_, though. Otherwise the usability is unreasonably limited. Of course there is then the question of return type. However, I would assume most users would be happy getting back either a Hana Integral or a bool, depending on whether it is a compile-time or runtime condition. Certainly this would be better than getting back a compiler error. Another question: how does the performance of and_ and or_ compare to the optimized verions you showed in your MPL11 talk? Pair datatype: -------------- Why duplicate std::pair? Alternatively, why duplicate list? Perhaps list should just define first and second as well? Product type class: ---------------- Why isn't a 2-element List, a 2-element std::tuple, etc. an instance? List type class: ---------------- Just as for Logical, it would be useful to be able to mix datatypes in calls to concat, zip, zip_with. The list function itself shouldn't be documented as part of the type class, since it isn't logically part of it. What about get<N>, get<N,M> accessors? I understand these can be defined in terms of the other methods, but clearly they are useful on their own.

3 4

[Concepts] Definition. Was [GSoC] [Boost.Hana] Formal review request
by Mostafa 21 Aug '14

21 Aug '14

On Thu, 31 Jul 2014 10:54:59 -0700, Robert Ramey <ramey(a)rrsd.com> wrote: > Eric Niebler-4 wrote >> On 07/29/2014 05:14 PM, Niall Douglas wrote: >>> I'm all for Concepts as in compiler enforced ones, and I'll add them >>> to AFIO when and only when C++ gets them. But for documentation they >>> don't help. >> >> Wow, I couldn't disagree more. I can't imagine how the standard >> algorithms would be specified without the use of concepts like >> "RandomAccessIterator", for instance. Clustering requirements into >> meaningful abstractions and assigning them names makes it possible to >> document library interfaces without an explosion of verbosity and >> repetition. > > +10 > > Usage of concepts is greatly: > > a) misunderstood > b) misunderestimated as to their value in design AND documentation > d) The word "concepts" is a big contributor to the problem - substitute > "type requirements" or "type constraints" for concepts. -1 to the above term substitutions for concepts. Type requirements/type constrains are not concepts. The reason concepts are misunderstood is because they have not been well defined. FWIW, here's my take on how they should be defined: Concepts are sets of types whose membership are compile-time determinable. Precisely, a concept is any set expressible in the following form: { T | T is a type and p(T ...) } where p is a (n+1)-ary compile time computable boolean function (a function in the mathematical sense, not an actual C++ function). p is said to be (or to express) the type requirements or type constrains for its associated concept. (Note: just as a set membership predicate is not its set, a type requirement is not its concept. For example, the predicate "there exists a,b and a,b are integers and b != 0 and c = a/b" does not denote the set of rational numbers, the symbol Q does.) A type T is said to model a concept C if T is a member of C. In such a case we also say that "T is a C". A concept B is said to be a refinement of a concept A if B is a subset of A. Why use concepts? Because they are helpful in documenting generic code, especially template type parameter requirements. Examples: 1) DefaultConstructible := { T | T has the method "T()" defined and accessible. } // Requirements: // T is DefaultConstructible. template <typename T> struct FooBar { ... }; std::tuple<int> is DefaultConstructible, therefore FooBar< std::tuple<int> > is well formed. Mostafa

14 57

[Container] Provide more guarantees for flat_multimap
by Vinícius dos Santos Oliveira 21 Aug '14

21 Aug '14

Currently, flat_multimap mirrors C++98's multimap concept. I'd like to propose an update to flat_multimap fulfil the C++11's multimap concept. The part I'm particularly interested are guarantees about preserving the insertion ordering for elements with equivalent keys. On ISO/IEC 14882-2011, 23.2.4 - associative container requirements, pages 741 and 742, you can see the effects for a_eq.emplace and a_eq.insert ends with "If a range containing elements equivalent to t exists in a_eq, t is inserted at the end of that range". I see no similar guarantees on the Boost's flat_multimap documentation[1]. This feature is useful, for instance, in HTTP messages, where field reordering is illegal[2] if the keys are equivalent. I did a few tests and it looks to me that flat_multimap already provides these guarantees, but before I go check the source and possibly provide patches, I need to know if there is interest in turning this accidental behaviour into intentional behaviour through documented guarantees. [1] http://www.boost.org/doc/libs/1_56_0/doc/html/boost/container/flat_multimap… [2] http://tools.ietf.org/html/rfc7230#section-3.2.2 -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker

7 17

Metadata pull requests
by Daniel James 21 Aug '14

21 Aug '14

Hi, I just created about 100 pull requests to add library metadata to modules that don't already have it. Apart from them all containing the same typo, I think it went okay. I forgot to mention that the file format is documented at: http://www.boost.org/development/library_metadata.html I'll spend a bit of time improving that soon, so let me know if there's anything missing. Also, if it wasn't clear, the idea is that you can update this file if you need to change the library details. It might take a little while for the website to update, as it only happens when I run the appropriate script. thanks, Daniel

5 11

[units] Pull request and RFC: information unit definitions for Boost.Units
by Erik Erlandson 20 Aug '14

20 Aug '14

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…

7 14

[type_traits] Interest in is_iterator type trait?
by Beman Dawes 20 Aug '14

20 Aug '14

Back in 2011, Howard Hinnant and I put together an is_iterator type trait based on code Howard had developed and used over a period of time. See http://beman.github.io/is_iterator/is_iterator.hpp for the actual code See http://beman.github.io/is_iterator/is_iterator_test.cpp for a test program. The intent was always to submit is_iterator to Boost, but we never got around to it. Now I need it in Boost.Filesystem, so I'd rather see it go in type traits than just sticking it into boost/filesystem/detail. If there is interest, and John Maddock gives the OK, I'll write docs and integrate into type_traits, then submit a pull request. --Beman

6 20

Ticket system getting spamed
by Mateusz cerkiewny 20 Aug '14

20 Aug '14

#10352 <https://svn.boost.org/trac/boost/ticket/10352> #10351 <https://svn.boost.org/trac/boost/ticket/10351> #10342 <https://svn.boost.org/trac/boost/ticket/10342> #10339 <https://svn.boost.org/trac/boost/ticket/10339> #10335 <https://svn.boost.org/trac/boost/ticket/10335> #10331 <https://svn.boost.org/trac/boost/ticket/10331> #10334 <https://svn.boost.org/trac/boost/ticket/10335> Are spamms

2 1

[log] Problem Building Boost 1.55 With GCC Using C++11 Mode Due to AVX2 Support
by Stewart, Robert 20 Aug '14

20 Aug '14

We've run into a problem building log. It doesn't appear to be a known issue and we're not sure how to work around it. We found a hack to make our builds succeed, but there may well be a better workaround and we're not certain whether there are any issues with what we've done. We tried to build Boost 1.55 with GCC 4.8.1, 4.8.3, and 4.9.1 with the following commands: ./bootstrap.sh --prefix=<prefix> --libdir=<prefix>/lib --with-toolset=gcc ./b2 --build-type=complete --layout=versioned 'cxxflags=-m64 -O2 -g -pipe' 'cflags=-m64 -O2 -g -pipe' 'linkflags=-Wl,-rpath -Wl,<prefix>/lib -L<gcc_dir>/lib64 -Wl,-rpath -Wl,<gcc_dir>/lib64 -m64' -d+2 -j3 ./b2 --build-type=complete --layout=versioned 'cxxflags=-m64 -O2 -g -pipe' 'cflags=-m64 -O2 -g -pipe' 'linkflags=-Wl,-rpath -Wl,<prefix>/lib -L<gcc_dir>/lib64 -Wl,-rpath -Wl,<gcc_dir>/lib64 -m64' -d+2 -j3 install The errors we get come from this command during the build: gcc.compile.c++ bin.v2/libs/log/build/gcc-4.9/release/link-static/log-api-unix/threading-multi/dump_avx2.o "g++11" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -fno-strict-aliasing -ftemplate-depth-1024 -m64 -O2 -g -pipe -march=core-avx2 -mavx -mavx2 -fabi-version=0 -m64 -O2 -g -pipe -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_STATIC_LINK=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DBOOST_LOG_BUILDING_THE_LIB=1 -DBOOST_LOG_USE_NATIVE_SYSLOG -DBOOST_LOG_WITHOUT_EVENT_LOG -DBOOST_SPIRIT_USE_PHOENIX_V3=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_SYSTEM_STATIC_LINK=1 -DBOOST_THREAD_BUILD_LIB=1 -DBOOST_THREAD_DONT_USE_CHRONO=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_LIB=1 -DDATE_TIME_INLINE -DNDEBUG -I"." -c -o "bin.v2/libs/log/build/gcc-4.9/release/link-static/log-api-unix/threading-multi/dump_avx2.o" "libs/log/src/dump_avx2.cpp" There are many lines of output; I've elided similar messages to highlight the unique ones: {standard input}: Assembler messages: {standard input}:611: Error: operand type mismatch for `vpsrldq' ... {standard input}:819: Error: no such instruction: `vextracti128 $0x1,%ymm2,%xmm2' ... {standard input}:1087: Error: no such instruction: `vextracti128 $0x1,%ymm3,48(%r15)' ... {standard input}:1312: Error: operand type mismatch for `vpaddb' While there might be a way to actually get b2 to disable AVX2 support, we hacked libs/log/build/Jamfile.v2 with these commands: sed -i 's:dump_avx2::g' libs/log/build/Jamfile.v2 sed -i 's:<define>BOOST_LOG_USE_AVX2::g' libs/log/build/Jamfile.v2 Those remove dump_avx2 from BOOST_LOG_COMMON_AVX2_SRC and remove the definition of BOOST_LOG_USE_AVX2, which prevents compiling enable_avx2(). Is there a better way to solve or work around this problem? _____ Rob Stewart robert.stewart(a)sig.com Software Engineer, Middleware using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 2

[git] Pushing commit(s) after pulling
by Edward Diener 20 Aug '14

20 Aug '14

I share a library with others and make some commit to a branch of that library. Then I try to 'push' the commit, only to be told that there are changes that have been made which I need to 'pull'. So I 'pull' the latest changes for that branch, and luckily there is no conflict(s) with my local commit(s). What do I do now ? I can 'push' my changes successfully but then the history of my particular changes appears to be lost. Am I supposed to revert my changes to the local repository by doing a 'reset' and then reapply those changes ? That seems onerous. What is the right way to 'push' my changes and still preserve the history of each one of them on the remote repository ?

5 9

[mpl] Proceeding with modularization
by Andrey Semashev 20 Aug '14

20 Aug '14

Hi, Now that 1.56 is out I believe we can proceed with modularization. I'd like to complete Boost.MPL decomposition into Boost.MPL.Core and Boost.MPL that I started some time ago. I can see two ways of doing this: I can keep the two parts in the separate git repositories or I can move Boost.MPL.Core to a sub- library within the same git repo. I'd prefer the second approach since this allows to create a single pull request and keeps the library history in one place, but maybe there are other considerations?

3 3

Re: [boost] [Concepts] Definition. Was [GSoC] [Boost.Hana] Formal review request
by Brian Wood 19 Aug '14

19 Aug '14

Niall Douglas writes: > > Such a design would not make good use of hardware DMA such that use > of the CPU can be completely avoided for bulk data transfers. To > invoke hardware DMA, all i/o must be done from 4Kb aligned memory > buffers. Indeed AFIO can enforce that for you because it's so > important to performance. > > Generally if you're bothering to use async i/o, you have no interest > in *ever* copying memory. That rules out all serialisation usually :) How about calling it OS-level serialization? I don't think the need for message framing goes away. Somehow the length of a message has to be calculated and put in place. -- Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

1 0

GSoC: Pipeline status
by Benedek Thaler 19 Aug '14

19 Aug '14

Hi, As GSoC is coming to its end, I'd like to present you the Pipeline library: code: https://github.com/erenon/pipeline documentation: http://erenon.hu/pipeline I'll continue to work on this project, the next big thing is to implement a coroutine based execution. I hope using cooperative scheduling will enable a much better throughput/latency combination over the nice and easy to use interface we currently have. Thanks, Benedek

1 0

[serialize] Noncopyable errors in the latest 'master'
by Edward Diener 19 Aug '14

19 Aug '14

In testing out libraries which use Boost PP, with clang as the compiler, I am seeing a great deal on 'master' of: > ..\..\..\boost/archive/detail/basic_serializer.hpp:35:7: error: 'operator=' is a private member of 'boost::noncopyable_::noncopyable' > class basic_serializer : Does anybody know what this is all about ? It is occuring in a number of libraries using serialization.

1 0

[GSoC] [Boost.Hana] Status update
by Louis Dionne 18 Aug '14

18 Aug '14

Dear Boost, Summer of code is coming to its end, and I think this is a good time to give an update about Hana and what's going to happen next. In early august, I asked for a review of Hana. As a result, I got many comments and questions which helped me improve the library and also take the pulse of the C++ community. Ever since the review, I've been working on improvements and modifications to the library and its documentation. Thanks to all of those who gave comments, and especially to those who experimented with the library and reported problems/thoughts. My initial (personal) objective was to push a new library in Boost by the end of the summer. I now realize that this is unlikely to happen given the amount of work that's left and the amount of time on my hands. That being said, I still think Hana solves the problem of C++ metaprogramming in a very elegant way, and I'm not giving up on its development because GSoC ends. Hence, I will continue working on the project as much as my studies allow it and I plan to ask for informal reviews during fall. Eventually, I still hope to fulfil my initial goal of making Hana available to a wide audience via Boost. I would also like to mention that I will be presenting Hana at CppCon 2014 in september; consider attending if you followed the project this summer. Finally, I would like to thank everyone that was involved with making my participation to GSoC possible; I worked hard, had a lot of fun and I think my work (or at least derivations of it) will be useful to Boost and the wider C++ community given enough time. Regards, Louis

1 0

Debugger Visualizers discussion
by Antony Polukhin 18 Aug '14

18 Aug '14

Hi all, There is project that contains a bunch of XML files. Those files can be used to improve debugging on MSVC: For example: * using this project debug view of `boost::variant<int, float> i(1);` will show `1` instead of raw memory and internals of boost::variant. * optional<boost::container::string> will show string content or `none` instead of ram memory and some unreadable internals Maybe we should embed those files into the Boost? It would be great to have some magic bjam command `b2 install-debug` after which VisualStudio becomes aware of Boost classes. Files for pretty debugging could be also written for GDB. Will it be useful? Link o the project: https://github.com/KindDragon/CPPDebuggerVisualizers Files are located at https://github.com/KindDragon/CPPDebuggerVisualizers/tree/master/VS2013/Vis… -- Best regards, Antony Polukhin

3 3

[git] [filesystem] [system] [timer...] Remove useless SVN branches?
by Beman Dawes 18 Aug '14

18 Aug '14

Boost library repos converted from Subversion are littered with branches created by the conversion process that seem to me to be quite useless. For example, Boost filesystem has 65 branches, yet only 10 or so have any usefulness I'm aware of. A lot of the useless branches have names that begin "sandbox" or "svn-". I go back to the subversion repo when I want to look at pre-git-conversion history. Is there any point in retaining these branches? Does anyone object if I remove these branches from the libraries where I am the maintainer? What are other maintainers doing about stale branches? --Beman

3 2

clang and variadic macro warnings revisited
by Edward Diener 18 Aug '14

18 Aug '14

After making pull requests for a number of Boost libraries in order to reduce the warnings from compilation from clang using the Boost PP library, John Maddock suggested a specific solution, as Niall Douglas had suggested a general one before, that changes in the Boost PP library could get rid of these extraneous warnings. Originally I thought this would be too difficult and intrusive in Boost PP but after reading John's specific suggestion I decided to try to implement it. The suggestion John made was to surround code in Boost PP which uses variadic macros with: # ifdef __clang__ # pragma clang diagnostic push # pragma clang diagnostic ignored "-Wvariadic-macros" # endif // variadic macros # ifdef __clang__ # pragma clang diagnostic pop # endif This was actually easier than expected since all code in Boost PP which uses variadic macros is surrounded by: # if BOOST_PP_VARIADICS #endif // eventually Of course there are many files changed by this but overall it is very straightforward. This technique does work for the diagnostic "-Wvariadic-macros". Hooray ! Unfortunately the second situation involving warnings, where clang warns about: warning: empty macro arguments are a C99 feature [-Wc99-extensions] coming from what I only see as a specific place in Boost PP in variadic/elem.hpp is not conducive to the same technique. In other words surrounding that one macro with: # ifdef __clang__ # pragma clang diagnostic push # pragma clang diagnostic ignored "-Wc99-extensions" # endif #define BOOST_PP_VARIADIC_ELEM(n, ...) BOOST_PP_CAT(BOOST_PP_VARIADIC_ELEM_, n)(__VA_ARGS__,) # ifdef __clang__ # pragma clang diagnostic pop # endif does not eliminate the warning at all ( I have reported this on the clang developers mailing list ). And since that macro is heavily used in Boost PP this warning occurs quite often when compiling Boost library code using Boost PP wih clang. The only other intrusive Boost PP solution to this problem is to treat clang like gcc as far as Boost PP variadic macro code is concerned: if the end-user compiles with one of the 'std=' dialects which explicitly supports variadic macros, such as 'std=c99', 'std=c++0x, 'std=c++11', then variadic macros are turned on in Boost PP for clang, else they are turned off. Do realize that both gcc and clang support variadic macros even when one of the 'std=' dialects are not chosen, and that in fact clang has always supported variadic macros. Also changing Boost PP support for clang and variadic macros would be a regression from the way it is now where it is always supported. In retrospect, when I changed Boost PP from never supporting variadic macros for clang ( Paul's original conservative choice ) to always supporting variadic macros for clang, I gave in to an outcry that clang users should have variadic macro support in Boost PP. It would have been wiser to follow the gcc method in Boost PP. But that is past and we need a good solution now. Thoughts ? Solutions ? Brickbats <g> ?

3 3

[endian] Was: [Boost-testing] All runners on develop are failing.
by Rene Rivera 18 Aug '14

18 Aug '14

---------- Forwarded message ---------- From: Tom Kent <lists(a)teeks99.com> Date: Fri, Aug 15, 2014 at 8:13 PM Subject: [Boost-testing] All runners on develop are failing. To: Running Boost regression tests <boost-testing(a)lists.boost.org> It is looking for the endian library...which I have, but is still failing. error: Unable to find file or target named error: '../libs/endian/' error: referred to from project at error: '.' I did a: git checkout develop git pull git submodule update --init on my repository, which caused the previously empty endian directory to be populated, but still getting the error. Thoughts? Tom _______________________________________________ Boost-Testing mailing list Boost-Testing(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-testing -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

3 2

[algorithm] Interface for longest_increasing_subsequence (proposal)
by Curdeius Curdeius 17 Aug '14

17 Aug '14

Hi all, I want to propose a new algorithm to Boost.Algorithm: a well-known longest increasing subsequence <https://en.wikipedia.org/wiki/Longest_increasing_subsequence> (LIS for short). Just for a short info: given a sequence like ( 7 )( 2 )( 8 )( 1 )( 3 )( 4 )( 10 )( 6 )( 9 )( 5 ), the result will be a subsequence ( 1 )( 3 )( 4 )( 6 )( 9 ). The proposed algorithm has O(n log n) time and O(n) complexity, where n - sequence length. I have created a pull request https://github.com/boostorg/algorithm/pull/7. I have however some questions. I am not sure what should be the exposed interface. For the moment, I propose (I base it on the existing interface from algorithm/searching functions): - class longest_increasing_subsequence with methods - operator() - *compute_length* (a better name may be needed) - free function longest_increasing_subsequence_length returning the length of the LIS and taking as arguments: - a pair of iterators (first, last) - or a range - and (optionally) a comparison predicate - *free function longest_increasing_subsequence_search taking the same arguments as _length function and an Output Iterator or a tag.* - free function make_longest_increasing_subsequence taking a range and optionally a comparison predicate and returning corresponding longest_increasing_subsequence object The problematic part is the underlined longest_increasing_subsequence_search function and the way in which I should return the resulting LIS. I see possibilities like the following: 1. taking an OutputIterator argument: the best for me, generic and the most flexible solution, but there is a performance hit as we cannot reserve the memory for the output LIS. 2. returning a container with the subsequence, e.g. std::vector<value_type>: no performance hit with small objects or if the user needs a vector of values. However, not really generic as the user would be obliged to use a vector (in the aforementioned example). 3. returning a container with iterators, e.g. std::vector<InputIter>: good if a container of iterators is acceptable, it has a benefit of avoiding possibly expensive copies of sequence elements. As 2., not really generic. 4. -taking a container as an argument: the worst solution in my eyes, there is no way nice way to write generic code that handles all containers. I have coded possibilities 1-3. Thank you in advance for all the comments, corrections etc. Regards, Marek Kurdej

1 0

[testing] Proposal - regression tests results display upgrade
by Adam Wulkiewicz 17 Aug '14

17 Aug '14

Hi, Currently test failures of a new feature are always marked with the yellow color and a word 'fail'. Would it make sense to use some more descriptive color/naming scheme? In particular it would be nice to distinguish between the actual failures and the situations when the compilation of a test took too much time or an output file was too big. Would it make sense to also distinguish between compilation, linking and run failure? E.g. instead of a simple 'fail' use 'fail (c)', 'fail (l)' and 'fail (r)'. E.g. the color for actual failures could be orange and for "others" could stay yellow. Furthermore, currently it's impossible to see the results of compilation if a test passed. Would it make sense to change it? This would allow us to view and fix warnings even if the test was passed. The test passed with warnings could be marked e.g. with 'pass (w)' or the color could be set to some between yellow and this light green. If you directed me where it should be done I could try to change it. I'm guessing it would require modifying some script generating the page and some CSS? Regards, Adam

6 10

Re: [boost] [units] Pull request and RFC: information unit definitions for Boost.Units
by Curdeius Curdeius 16 Aug '14

16 Aug '14

Hi all, I considered proposing myself as a maintainer of Boost.Units for some time, but considered too inexperienced to do it on my own. Therefore I am happy that Jürgen proposed himself and I would like to help him by being a co-maintainer if it is possible and needed. As for me, I have been using the library for at least 3 years now and would like to contribute to it. For the moment, I mainly proposed small bug fixes to Boost libraries. Regards, Marek Kurdej -- Ph.D. candidate Hi Matthias, > Am Donnerstag, 31. Juli 2014, 11:25:35 schrieb Matthias Schabel: > > I would love to pass the responsibility for ongoing maintenance of > > Boost.Units on to a new torchbearer. > First a "Thank you very much" for the great library. > > 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 no one else has stepped up, I'd like to volunteer. I've been using > Boost.Units with great success for the last five years. For my recent Boost > contributions see https://github.com/jhunold. Mostly small bugfixes, > Boost.Build support over the last decade. > Boost.Units is getting more attentions now as c++11 is getting momentum. > Personally, I'd like to get > https://github.com/boostorg/units/pull/5 > into 1.57. > > 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. > It would be nice if one of the current maintainer could comment on this. > > >> Link to PR: https://github.com/boostorg/units/pull/3 > Seems obsolete, > https://github.com/boostorg/units/pull/6 > it the improved commit. > Feel free to ask questions. > Yours, > Jürgen > -- > * Dipl.-Math. Jürgen Hunold ! > * voice: ++49 4257 300 ! Fährstraße 1 > * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen > * jhunold(a)gmx.eu ! Germany

1 0

[config][type_traits] Support for final keyword in Boost?
by John Maddock 16 Aug '14

16 Aug '14

I have a couple of pull requests to add support for the final keyword in Boost.Config and an is_final trait to type traits, so my questions are: 1) Are these generally useful? 2) Do we need BOOST_NO_CXX11_FINAL_CLASS and BOOST_NO_CXX11_FINAL_OVERRIDE or will a single BOOST_NO_CXX11_FINAL do? 3) The trait appears to be unimplementable via SFINAE (anyone care to prove me wrong?) which means it's only usable on GCC and lookalikes which have an __is_final intrinsic. Should we still add this to Boost or is the answer "use GCC's native features" given that a Boost version effectively adds nothing? Thanks! John.

4 3

[docbook] Add detail namespace to Reference section
by Benedek Thaler 16 Aug '14

16 Aug '14

Hi, I have the following example code fragment: namespace boost { namespace detail { /** documentation */ class implementation {}; } // namespace detail using detail::implementation; } // namespace boost I'd like to have the class `implementation` show up in the Reference section generated by doxygen+docbook-xsl+boost build+docbook+... . Issue is, every namespace which name contains the string "detail" is excluded somehow. The direct output of doxygen has it, but not the docbook version. I couldn't find any EXCLUDE_SYMBOLS setting (it's not set in the doxyfile)or anything relevant amongst the docbook-xsl params or in the boost build scripts. Google search term "doxygen ignores detail namespace" and the like did not help. Adding documentation to the using statement and/or TYPEDEF_HIDES_STRUCT did not help. Thanks, Benedek

2 3

Should intrusive_ptr copy constructors be declared noexcept?
by James Yonan 16 Aug '14

16 Aug '14

Currently, intrusive_ptr's copy constructors are not declared noexcept. This disables the std::function small object optimization when intrusive_ptr objects are passed by value in a lambda closure. The attached patch tries to fix this by making the copy constructors conditionally noexcept, based on the noexcept status of the user-provided intrusive_ptr_add_ref function. James

1 0

[Boost][filesystem] imbue in global constructor crashes
by Peter Bindels 15 Aug '14

15 Aug '14

Hi all, When trying to use a global constructor to set the locale to utf8 for an entire project, the system failed to start due to global constructor ordering making the override happen before the std::locale object itself was initialized. Looking into the boost::filesystem code for imbue it seemed that there were a few different implementations, one of which could work. I've tried to keep the same side conditions and made this same lazy-initialization approach for all platforms, which should keep working in all the same conditions and also work for a global constructor overriding the locale. I've attached the patch. I hope that this change can be integrated into boost::filesystem or that we can have a constructive discussion on what solution we should be making. Best regards, Peter Bindels

2 1

[variant] static_visitor constructor error with boost 1.56.0 and g++ 4.5.1
by Richard Hadsell 15 Aug '14

15 Aug '14

I am trying to upgrade from Boost 1.55 to 1.56. I get this error with G++ 4.5.1: In file included from ...: .../boost/variant/static_visitor.hpp:52:24: error: 'boost::static_visitor<R>::static_visitor()' declared with non-public access cannot be defaulted in the class body .../boost/variant/static_visitor.hpp:53:25: error: 'boost::static_visitor<R>::~static_visitor()' declared with non-public access cannot be defaulted in the class body The OS is Linux Fedora 14. The compiler is gcc version 4.5.1 20100924 (Red Hat 4.5.1-4). I saw a similar problem in noncopyable.hpp, when upgrading to Boost 1.55. Andrey Semashev fixed it, and it looks like static_visitor requires the same fix. In static_visitor.hpp change line 51 from #ifndef BOOST_NO_DEFAULTED_FUNCTIONS to #if !defined(BOOST_NO_CXX11_DEFAULTED_FUNCTIONS) && !defined(BOOST_NO_CXX11_NON_PUBLIC_DEFAULTED_FUNCTIONS) I think this would be appropriate for any non-public defaulted functions, not just the ones that trip up code I happen to compile. 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 Follow Blue Sky Studios on Facebook <http://www.facebook.com/BlueSkyStudios> and Twitter <http://twitter.com/#%21/blueskystudios>

2 1

[1.56] PDF documentation available
by John Maddock 14 Aug '14

14 Aug '14

The PDF build of Boost's documentation for 1.56 is now available from the usual address: https://sourceforge.net/projects/boost/files/boost-docs/1.56.0/ Note that it includes only the subset of Boost libraries whose documentation is quickbook/docbook based. John Maddock.

6 8

[container] 1.56.0 flat_map static assert typo ?
by feverzsj 14 Aug '14

14 Aug '14

hi, list in <boost/container/flat_map.hpp>, the ctors seems to contain a wrong static assert: flat_map() : m_flat_tree() { //Allocator type must be std::pair<CONST Key, T> BOOST_STATIC_ASSERT((container_detail::is_same<std::pair<Key, T>, typename Allocator::value_type>::value)); } missing "const" ? regards. -- View this message in context: http://boost.2283326.n4.nabble.com/boost-container-1-56-0-flat-map-static-a… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 3

Boost Library Writers Workshop at CPP Con 2014
by Robert Ramey 14 Aug '14

14 Aug '14

Have you been lurking out there in cyberspace all these years? Slaving away on your fantastic new library for boost? Stuck, discouraged, concerned about getting ripped apart on the mailing list? Well, this is for you !!!! The Boost Library Writers Workshop http://rrsd.com/blincubator.com/open-content/ . Share your library and get it critiqued by you peer group - other unsung authors battling the same daemons. Best of all you can attend this workshop without being registered at the conference - to attend this workshop all you have to do is ... attend!. That's right, it's absolutely free. That's right free. And not free like in free software. Really free like "free beer". (note: there is no free beer). So if you're in the area and you want to get your library off your chest because it's weighing you down, keeping you awake, ruining your love life attend this workshop. Spaces are limited so signup now at the above web page. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Library-Writers-Workshop-at-CPP-Co… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[GitHub] Transferring a new library's repo to boostorg?
by Beman Dawes 14 Aug '14

14 Aug '14

https://svn.boost.org/trac/boost/wiki/NewLibFromGit describes "Creating a new library from an existing Git repository". It seems to cover the case where the existing git repo isn't in the exact boost branch organizational structure required. The Boost Endian library is ready to be moved to boostorg on GitHub so it can be tested on develop, checked by release managers, and otherwise readied to be added to 1.57.0. It is already on GitHub and AFAIK has the usual boost branch and directory structure. GitHub has a mechanism to transfer a repo between users or organizations. This would seem the easiest and most direct approach for boost endian. Is there any reason not to give it a try, and if it works as advertized then add it to https://svn.boost.org/trac/boost/wiki/NewLibFromGit as an additional option? --Beman

3 6

Comments on generic matrix library with specific 3D operations -> news and documentation
by Fabien Picarougne 13 Aug '14

13 Aug '14

Hello Boost, After some holidays, I have finished to implement some functionalities of my matrix library (https://bitbucket.org/fpicarougne/template-matrix-library) I have also begin to write some documentation (http://www.polytech.univ-nantes.fr/wikinfo/gmt/) relatively poor at this stage but sufficient (I think) to give you a real idea of the library. Globally, functionalities are closed to Boost::QVM but implementation strategy is different and uses more C++11 techniques as variadic templates for example. I must also say that I took over the syntax of the swizzling operator from this library. I would appreciate if you could give me feedback on this code. The code has been compiled on MSVC2013 and gcc 4.8 without warning (except those that come from Boost.Preprocessor) by using these parameters (in gcc): -Wall \ -Wextra \ -pedantic \ -Wmain \ -Wundef \ -Wsign-conversion \ -Wuninitialized \ -Wshadow \ -Wunreachable-code \ -Wswitch-default \ -Wswitch-enum \ -Wcast-align \ -Wmissing-include-dirs \ -Winit-self \ -Wfloat-equal \ -Wdouble-promotion \ -Wzero-as-null-pointer-constant \ -Wunused-parameter Current namespace is temporary (and inherited from old library) and will be changed in the future. Code needs also to be separated in more header files (this work will be done soon). I have kept in the git repository the "test.cpp" file which allows me to test some functionalities (and incidentally allow you to evaluate the usage syntax). Fabien

2 1

[git] confusion setting moduler-boost to 'master'
by Edward Diener 13 Aug '14

13 Aug '14

Somehow my local modular-boost is confused. I have set the top-level to 'master' and each of the sub-modules to 'master'. Yet git still shows it wants to commit each of the submodules at the library level as all are marked dirty. So I try: git reset --hard master git submodule foreach --recursive git reset --hard master But still the end result is that git has marked each submodule as 'dirty' and needing to commit. Anybody have any ideas how I straighten out this mess ?

3 4

build of 1.56.0 has no tools/build/v2
by Roger Martin 12 Aug '14

12 Aug '14

Hi, The build has changed or the docs http://www.boost.org/doc/libs/1_56_0/more/getting_started/unix-variants.htm… are correct and tools/build/v2 is missing There is a bootstrap.sh in tools/build and I used it successfully And then built the libs I needed so I'm guessing the docs on getting started aged slightly. I didn't need tools/build/v2/user-config.jam this time but do see the bootstrap build of bjam produces a ./build.tool/share/boost-build/example/user-config.jam For new users maybe a little cleanup on getting started would be helpful

1 0

[git][regression] Regression is not a submodule
by Adam Wulkiewicz 12 Aug '14

12 Aug '14

Hi, I noticed that Regression isn't setup properly as a submodule of modular boost unlike other tools. It isn't present on a list displayed with: git submodule status nor in .gitmodules $ grep 'tools' .gitmodules path = tools/build path = tools/bcp path = tools/inspect path = tools/boostbook path = tools/quickbook path = tools/litre path = tools/auto_index path = tools/boostdep There is a module Regression: https://github.com/boostorg/regression/tree/develop and there is also a non-submodule directory in boostorg: https://github.com/boostorg/boost/tree/develop/tools/regression Unlike the former, the latter seems to be actively developed. I assume that the code should be contributed to the boostorg directly? Is there a reason for this? Regards, Adam

2 1

[interprocess] atomic_write32 on GCC/x86/x68_64 lacks memory barrier
by Lars Hagström 12 Aug '14

12 Aug '14

Hi! In a piece of legacy code I've had a few uses of the atomic operations inside Boost.Interprocess (yes, I know they're internal, but I had no other choice at the time, so sue me :-). I've been debugging a thread synchronization issue which ended up in me actually looking for a problem inside interprocess, and I believe that I found the error. The atomic_write32 function, when running gcc on intel platforms does not have a memory barrier, which causes my threads to not see changes that they should see. A little bit of googling gave me the following link http://boost.2283326.n4.nabble.com/interprocess-atomic-write32-td4173289.ht…, which discusses exactly this issue. I've now fixed my code to use Boost.Atomic instead of relying on boost interprocess internals, so I'm good, but I worry that the issue might affect boost.interprocess as well. So I propose that atomic_write32 should be implemented using atomic_cas32. Or indeed that Boost.Atomic should be used instead, which is more work, obviously. Thoughts? /Lars

5 20

[1.56] Sorry but no PDF doc build (build script has been broken)
by John Maddock 11 Aug '14

11 Aug '14

Sorry folks, but as things stand there will be no PDF build of the docs for 1.56 as the build script appears to be hopelessly broken :-( Each time I fix one Boost.Build error it just leads to another, and frankly at present I have neither time nor inclination to keep tracking these down. If anyone wants to experience some pain then trying to invoke bjam in /doc/pdf/ will give you an idea of some of the issues. Regards, John.

6 7

Re: [boost] [multi_index]: Migration of code to VS12 does not compile anymore
by Brian Wood 11 Aug '14

11 Aug '14

Johannes Brunen writes: >Hello, > > > I'm porting some code fromVS10 to the VS12 compiler on windows. I have a >problem compiling code like the following: Clang didn't like the code either: clang++ -c -I ../boost-1_56_0_b1/ mi.cc mi.cc:21:35: error: use 'template' keyword to treat 'nth_index' as a dependent template name typedef typename container_t::template nth_index<0>::type sequence_index_t; ^ 1 error generated. -- Brian Ebenezer Enterprises - So far G-d has helped us. http://webEbenezer.net

1 0

[multi_index]: Migration of code to VS12 does not compile anymore
by Johannes Brunen 11 Aug '14

11 Aug '14

Hello, I'm porting some code fromVS10 to the VS12 compiler on windows. I have a problem compiling code like the following: //Test.cpp #include <boost/multi_index_container.hpp> #include <boost/multi_index/random_access_index.hpp> #include <boost/multi_index/hashed_index.hpp> #include <boost/multi_index/identity.hpp> template<typename T> class test { public: typedef typename boost::multi_index_container < T*, boost::multi_index::indexed_by < boost::multi_index::random_access<>, boost::multi_index::hashed_non_unique < boost::multi_index::identity<T*> > > > container_t; typedef typename container_t::nth_index<0>::type sequence_index_t; }; This does not compile and gives the following error message: 1> Test.cpp 1>D:\test\Test.cpp(18): error C2059: syntax error : '<' 1> D:\test\Test.cpp(19) : see reference to class template instantiation 'test<T>' being compiled 1>D:\test\Test.cpp(18): error C2238: unexpected token(s) preceding ';' I'm unable to find the reason for this error. Is it a compiler error, or is something wrong with my declaration? Regards, Johannes

2 1

Missing <boost/detail/endian.hpp>
by Edward Diener 11 Aug '14

11 Aug '14

I am not seeing a <boost/detail/endian.hpp> after pulling the latest 'master' and pulling all the submodules. What have I done wrong ?

2 1

Showstopper for Boost 1.56?
by Niall Douglas 10 Aug '14

10 Aug '14

Is anyone else seeing this warnings spew on Boost 1.56 beta when compiled with clang 3.4? https://ci.nedprod.com/view/Boost.AFIO/job/Boost.AFIO%20Build%20POSIX_ Linux64_clang%203.4/11/consoleFull GCC 4.8 produces no such spew. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

10 39

Boost 1.56.0 has been released
by Marshall Clow 09 Aug '14

09 Aug '14

Release 1.56.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains one new library and numerous enhancements and bug fixes for existing libraries. === Modularization === Boost version control has migrated to a system using git submodules. This shouldn't make too much of a difference to users, although the directory structure is now a bit different. Parts of some libraries have been moved into different modules, and several new modules have been extracted from existing code. All header paths should remain the same. The new modules are: • Assert: Customizable assert macros. Maintained by Peter Dimov. • Core: Core utilities used by other libraries, with minimal dependencies. Maintained by Peter Dimov, Glen Fernandes and Andrey Semashev. • Lexical_Cast: General literal text conversions, such as an int represented a string, or vice-versa, from Kevlin Henney. • Throw_Exception: A common infrastructure for throwing exceptions from Boost libraries, from Emil Dotchevski. • Winapi: Windows API declarations without <windows.h>, for internal Boost use. === New Libraries === • Align: Memory alignment functions, allocators, and adaptors, from Glen Fernandes. • Type_Index: Runtime/Compile time copyable type info, from Antony Polukhin. For details, including download links, see http://www.boost.org/users/news/version_1.56.0 You can also download directly from SourceForge: http://sourceforge.net/projects/boost/files/boost/1.56.0/ To install this release on your system, see http://www.boost.org/doc/libs/release/more/getting_started/index.html Thanks, --The Boost release team Vladimir Prus Rene Rivera Marshall Clow Eric Niebler Daniel James Beman Dawes

8 7

[config] Macro for initializer-list literals?
by Peter Dimov 09 Aug '14

09 Aug '14

We have BOOST_NO_CXX11_HDR_INITIALIZER_LIST, which tells us whether we can #include <initializer_list> and use std::initializer_list; we also have BOOST_NO_CXX11_UNIFIED_INITIALIZATION_SYNTAX, which tells us whether we can use X{ 1, 2 }, or X x{ 1, 2}. But we don't have a macro that tells us whether this: struct X { int a, b; }; void f( X x ) { } int main() { f( { 1, 2 } ); } is supported. This is a problem for http://www.boost.org/development/tests/develop/developer/output/Sandia-inte… because the test is guarded by BOOST_NO_CXX11_UNIFIED_INITIALIZATION_SYNTAX: https://github.com/boostorg/smart_ptr/blob/develop/test/allocate_shared_arr… and this macro is not set for Intel 13.1 in C++0x mode. Presumably the compiler allows braced initialization, but not braced literals.

1 0

[1.56.0] Release candidates available
by Marshall Clow 08 Aug '14

08 Aug '14

Release candidate files for 1.65.0 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: MD5 (boost_1_56_0_rc1.7z) = 0ac22b92b24209286d48e4c41925cd9f MD5 (boost_1_56_0_rc1.tar.bz2) = 5b5bfa99244b1ac5737323decceb19c2 MD5 (boost_1_56_0_rc1.tar.gz) = 2047cdd4e09cda34e7f10fec0f821175 MD5 (boost_1_56_0_rc1.zip) = 0c544f6acc85550b15cdc9221f2ac0c9 Thanks! -- The release managers

13 23

A quieter clang build
by Marshall Clow 08 Aug '14

08 Aug '14

I added the following lines to my user-config.jam: using clang-darwin : noC99W : "/usr/bin/clang++" : <cxxflags>"-Wno-c99-extensions -Wno-variadic-macros" ; and then built the 1.56.0 release with "toolset=clang-darwin-NoC99W", and lo! there were a *sane* amount of warnings. Just a quick tip for people drowning under the warnings. — Marshall P.S. I’m leaving for vacation this afternoon, but would like to pick this back up when I return.

1 0

Regression testing unobservable behavior?
by Beman Dawes 08 Aug '14

08 Aug '14

Certain library function errors are difficult to regression test because it is not obvious how to observe their behavior in a test framework. Examples include: 1) Selection of correct overload or template specialization when the only difference in effect is a performance enhancement. 2) Verification that BOOST_ASSERT fires when a precondition is violated. 3) Verification that I/O and other operating system API errors are handled correctly. 4) More generally, something occurs in a function under test that is hard to observe but needs to be verified. How do other boost developers address these regression testing needs? It seems to me all of the examples can be solved by creating some form of back channel (or channels) to pass information between caller and callee functions. All require getting additional information from a function after it is called. (3) also requires passing additional information to a function when it is called. An ideal solution requires: * Works in the existing Boost regression test framework. So much the better if it works in other test frameworks. * Does not violate the ODR or depend on undefined behavior. * Does not alter the interface of the function under test. * Does not generate any code except when the function is actually being tested. * Does not require that each test case be run as a separate program. * Works even if the function under test is noexcept. * Is lightweight, utterly reliable, and has few if any dependencies beyond those already present. --Beman

3 5

Error Handling issue in NonCopyable Interface
by John Pallino 08 Aug '14

08 Aug '14

Hello, I am having error handling issues that is in regards to the NonCopyable Interface library. Here is the source code: #include <boost/noncopyable.hpp> #include <iostream> class A : public boost::noncopyable { public: A() { std::cout << "In A \n" << std::endl; } class AnError {}; void Func() { if () //error condition throw AnError(); } }; int main() { try { A object1; A object2(object1); object1 = object2; } catch (A::AnError) { //tell user about error. } return 0; } } So far, I have tried on the forums in CPlusPlus.com and MSDN, but no responses. Since that Boost.org has created and authored the NonCopyable.hpp library, I would like to get some assistance. Can anybody give me some solutions on how to suppress any compilation errors? Thanks in advance. Email me back at the Cc: if you have any answers or comments with detailed information and examples. John P.

2 1

The release branch is now available for merging
by Marshall Clow 07 Aug '14

07 Aug '14

Now that 1.56.0 is out the door …. — Marshall

2 2

[1.56.0] Release Candidate 3 available
by Marshall Clow 07 Aug '14

07 Aug '14

We've created a third release candidate to fix a one more issue with Boost.Range. The files for 1.56.0 RC3 are available at: http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. The files (and associated md5s) are: MD5 (./boost_1_56_0_rc3.7z) = b7a72a6a6f487fa445333b4e115c6171 MD5 (./boost_1_56_0_rc3.tar.bz2) = a744cf167b05d72335f27c88115f211d MD5 (./boost_1_56_0_rc3.tar.gz) = 8c54705c424513fa2be0042696a3a162 MD5 (./boost_1_56_0_rc3.zip) = fc16da21d641e03715a4144cb093964e Thanks! -- The release managers

7 10

Clang, -pedantic, and variadic macro warnings
by Edward Diener 06 Aug '14

06 Aug '14

My test show that if you compile with clang, pass the '-pedantic' option, and also pass 'std=c++0x' or 'std=c++11', that the many warnings about variadic macro use do not show in the output. I know there was a discussion and an assertion that the warnings do show in the output oonce '-pedantic' is passed as a compiler option even though a 'std=xxx' is passed that covers variadic macros, but I am not seeing that in my tests. If anybody else can tell me of a Boost library build where clang is the compiler, 'pedantic' is passed, and the appropriate 'std=xxx' to cover variadic macro use is passed, and the clang compiler warnings about using variadic macros show up, it would be appreciated.

1 0

[python] Building and Testing needs to be updated for modular-boost
by Edward Diener 05 Aug '14

05 Aug '14

Attempting to follow the building and testing explanation for Boost.Python in modular-boost, it appears it no longer works with the new structure of modular-boost and Boost Build. Staring with the 3.1 Basic Procedure section I invoke in the libs/python/example/quickstart/ directory the command: > b2 toolset=gcc-4.8.1 --verbose-test test only to receive: > Unable to load Boost.Build: could not find build system. > --------------------------------------------------------- > C:\Programming\VersionControl\modular-boost\libs\python\example\quickstart\boost-build.jam attempted to load the build system by invoking > > 'boost-build ../../../../tools/build/v2 ;' > > but we were unable to find "bootstrap.jam" in the specified directory > or in BOOST_BUILD_PATH (searching C:\Programming\VersionControl\modular-boost\libs\python\example\quickstart\../../../../tools/build/v2). > > Please consult the documentation at 'http://www.boost.org'. I do not know who is taking care of Boost Python now but it appears that it needs to be updated for modular-boost.

2 8

Files in Github
by Axel Ismirlian 05 Aug '14

05 Aug '14

Which subrepository do the files under /home/boost/boost belong to? More specifically, I made a change to /home/boost/boost/date_time/time_resolution_traits.hpp and I am looking to push it upstream, but I cannot find who this file belongs to. Sincerely, -Axel

4 3

[filesystem] develop broken after current merge
by Jürgen Hunold 05 Aug '14

05 Aug '14

Hi Beman, the last merge broke Boost.FileSystem on Linux using gcc(-4.8) and clang(-3.6) in c++11 mode. Diagnosic: include/boost/filesystem/path_traits.hpp contains #ifndef BOOST_NO_CXX11_CHAR16_T inline void convert(const char16* from, const char16* from_end, This should most probably be "char16_t" for C++11. The same for "char32" which should be "char32_t". This affects several other files. This one I could patch myself. But then I encountered: BOOST_ROOT/boost/filesystem/path_traits.hpp:131:13: error: ‘interop’ does not name a type typedef interop::conversion_iterator<interop::narrow, interop::utf16, const char16*> I can't find a definition of "interop" anywhere in the current repository... If you need more diagnostics, please ping me. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

2 1

Is there any interest in a dependency injection library?
by Krzysztof Jusiak 05 Aug '14

05 Aug '14

Hi, Is there any interest in a C++03/C++11/C++14 header only, type safe, library providing compile time, macro free *constructor dependency injection <http://en.wikipedia.org/wiki/Dependency_injection>*? *Key features:* * *Compile time *- no exceptions - if application compiles all dependencies will be be created accurately * *Macro free* - by default no need to specify constructor traits or register anything (less intrusive) * *Scopes deduction* - scopes are deduced based on type semantic * *Automatic conversion* between std/boost smart pointers * *Compile time policies* - example to detect circular dependencies or limit supported types only to specified *Hello World* ----------------------------------------------------------------------------------------------------------> #include <memory> #include <boost/shared_ptr.hpp> *#include <boost/di.hpp>* *namespace di = boost::di;* struct interface { virtual ~interface() { } }; struct implementation : interface { }; class hello_world { public: hello_world(std::unique_ptr<interface> up , const std::shared_ptr<interface>& sp1 , boost::shared_ptr<interface> sp2 , int i) : i(i) { assert(dynamic_cast<implementation*>(up.get())); assert(dynamic_cast<implementation*>(sp1.get())); assert(dynamic_cast<implementation*>(sp2.get())); assert(sp1.get() == sp2.get()); assert(i == 0); } int run() { return i; } private: int i = 0; }; int main() { // create injector and configure bindings auto injector = *di::make_injector*( *di::bind*<interface, implementation>() // scope will be deduced ); // create and run hello_world return injector.*create*<hello_world>().run(); } <---------------------------------------------------------------------------------------------------------- *Overview*: * boost library incubator: http://rrsd.com/blincubator.com/bi_library/di-dependency-injection-2 * repository: https://github.com/krzysztof-jusiak/di * documentation: http://krzysztof-jusiak.github.io/di/boost/libs/di/doc/html * issues: https://github.com/krzysztof-jusiak/di/issues * download: https://github.com/krzysztof-jusiak/di/archive/master.zip *Supported Compilers* - 100% test coverage: * Linux (x86/x86-64) * Clang 3.2/3.3/3.4/3.4.2+ (clean with Clang Static Analyzer and Valgrind) * GCC 4.7.3/4.8.2/4.9.0+ (clean with Valgrind) * Intel C++ 14.0.3+ (clean with Valgrind) * Windows (x86/x86-64) * MinGW 4.7.3/4.8.2+ * Visual Studio 2013+ (clean with DrMemory) * Darwin/Mac OS (x86-64) * Clang 503.0.40+ (Apple LLVM version 5.1) *Continuous integration*: * Linux, Darwin/Mac OS: https://travis-ci.org/krzysztof-jusiak/di * Windows: https://ci.appveyor.com/project/krzysztof-jusiak/di * Coverage: https://coveralls.io/r/krzysztof-jusiak/di *Similar libraries*: * https://bitbucket.org/cheez/dicpp * https://code.google.com/p/infectorpp * https://github.com/phs/sauce * https://code.google.com/p/wallaroo * https://code.google.com/p/hypodermic * https://github.com/admiyo/CppInject * http://qtioccontainer.sourceforge.net * https://code.google.com/p/autumnframework * http://sourceforge.net/projects/cpp-resolver (proposal for boost library in 2009: http://lists.boost.org/Archives/boost/2009/10/157477.php) * https://code.google.com/p/pococapsule * https://code.google.com/p/spring-cpp * http://www.cs.utah.edu/~arichard/inject.html * http://bobah.net/d4d/source-code/misc/cpp-dependency-injection * https://code.google.com/p/ffead-cpp * http://codebros.github.io/DiLite * https://code.google.com/p/kindi Java: https://github.com/google/guice C#: http://www.ninject.org/ Source code was internally reviewed. DI was successfully used in a commercial project as well. Looking forward to hear from you. Any feedback is more than welcome. Best regards, Kris

3 13

[1.56.0] Release Candidate 2 available
by Eric Niebler 05 Aug '14

05 Aug '14

We've created a second release candidate to fix a few issues. The three fixes since RC1 are listed at the end of this mail. The files for 1.56.0 RC2 are available at: http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. The files (and associated md5s) are: MD5 (boost_1_56_0_rc2.7z) = 2e1688886aede1c3348e131a0e73a031 MD5 (boost_1_56_0_rc2.tar.bz2) = 2079fabbfb9fb046e6e12e381eff20fa MD5 (boost_1_56_0_rc2.tar.gz) = 96fe9c5f70759399217dc7ee113ecdd3 MD5 (boost_1_56_0_rc2.zip) = df42b60e120841fc3893de7c2529fc4a Thanks! -- The release managers === Changes Since RC1 === Boost.Thread bug is causing coroutine build to fail on gcc 4.6 in C++11 mode. https://github.com/boostorg/thread/pull/21 Boost.Graph broken on MSVC-12 and gcc-4.4. https://github.com/boostorg/graph/pull/14 Boost.System broken on cygwin, local_free_on_destruction not defined. https://github.com/boostorg/system/pull/4

9 12

Re: [boost] [1.56.0] Release Candidate 2 available
by Glen Fernandes 04 Aug '14

04 Aug '14

> We've created a second release candidate to fix a few issues. The three > fixes since RC1 are listed at the end of this mail. > > The files for 1.56.0 RC2 are available at: > http://boost.cowic.de/rc/ Builds successfully on: 1. OSX 10.9.4, x64, clang 3.4 (C++03, C++11) 2. Ubuntu 14.04, x64, gcc 4.8.2, (C++03, C++11) Glen

1 0

Re: [boost] How to establish boost configurations for cross-compilers not currently covered?
by Dave Gomboc 04 Aug '14

04 Aug '14

> > The boost config manual > > does not explicitly address the case where one is attempting to > > determine the relative lack of C++98 compliance of a cross-compiler > > (e.g., for an embedded system) that is not already within Boost's > > supported set of compilers. > > [Christopher Kormanyos] > Dave, may I ask what cross compilers you are considering for > your investigations? I am not sure that I can say precisely which, but I feel safe enough saying that none of them are intended to run under Unix or Linux. Unfortunately, this means I can't directly use "configure" as per John Maddock's suggestion. Though, it is true that some of the compilers run under Windows, so perhaps I could install Cygwin to obtain ./configure capability... or, perhaps I could try running under Wine. For the others, who knows... > Although I can not answer your question directly, I am also > very interested in finding ways to adapt or extend Boost support > to embedded systems compilers --- even for small micros. I am > particularly interested in extending the range of Boost and C++ to > compilers from suppliers such as IAR systems, Green Hills, > and also selected GCC crosses. > > I am also sensing increased interest in the Boost and C++ > communities regarding compilers not running *nix, Win32. > There is, in my opinion, lots of work to do here --- especially > when plain "int" is 16-bits in width or if an STL is lacking, or etc. Int is 32 bits on most, if not all, of the platforms that I was considering when I wrote my email. That said, there appears to be a surprising amount of (hobbyist) retrocomputing activitly over the past few years. So, I don't doubt at all that there might be interest even where plain "int" is even just 8 bits! Dave P.S. I ordered your book recently, Chris, and am looking forward to reading it when it arrives.

2 1

[random] Contributing Well equidistributed long-period linear (WELL) implementation
by Sergiu Dotenco 04 Aug '14

04 Aug '14

Some time ago, I implemented the WELL family of PRNGs introduced in: Francois Panneton, Pierre L'Ecuyer and Makoto Matsumoto. "Improved Long-Period Generators Based on Linear Recurrences Modulo 2". ACM Transactions on Mathematical Software, 32 (1, March) 2006, pp. 1-16. WELL is supposed to provide better equidistribution and bit-mixing properties for equivalent period lengths compared to Mersenne twister. The WELL family of generators provide period lengths ranging from 2^512-1 to 2^44497-1. The implementation can be found at https://bitbucket.org/sergiu/random/src/tip/well.hpp?at=default. The code has to be boostified, which I'm willing to do if there's any interest.

2 4

Hana Typeclass
by Robert Ramey 04 Aug '14

04 Aug '14

I can't review the whole library. So I'm confining my observations to just a couple of aspects. My method is to review some section of the documentation. it looks like a critique of the documentation, but it's really observations on the underlying design of the library. In this post I'm addressing Typeclass. Typeclass "Conceptually, type classes are an artifice allowing humans to manipulate objects of heterogeneous types with well-defined semantics. OK They serve a purpose very similar to C++ concepts (which are not in yet) and to Haskell type classes, except they do not have language support" OK - But I would argue that C++ concepts do have library support. It may not be perfect, but it's good enough for government work. template <class T> struct Printable { private: T t; std::ostream os; public: BOOST_CONCEPT_USAGE(Printable) { os << t; } }; "Type classes in Boost.Hana are a library-level implementation of such type constraints allowing us to organize our generic programming." When I read this it seems to be identical to the definition of what Boost Concept Checking is. "Getting concrete" Here is where we start to have problems. Rather than the simple BCC example above, we've got something a lot more complex and hard to understand. the example struct Printable { BOOST_HANA_TYPECLASS(Printable); // This is valid, but it's probably not a good idea unless those are // strongly related to the type class. int foo; void bar() const { }; struct baz { }; }; Describes what not to do - but doesn't describe what one is supposed to do. "As you will see later with minimal complete definitions, it is often useful to put other related members in a type class; don't hesitate to do it when it makes sense." Upon reading this - we don't know enough to know that "related members" means and what it means to "make sense". "When I introduced type classes, I said they allowed us to bundle together related operations called methods. This is because type classes can be seen as defining some kind of public interface consisting of the operations that are valid with any object satisfying some constraints" which is the C++ concept - or my own "type constraint" "I also said that they made it possible to explicitly state that a type satisfies those constraints, and how it does so" I would phrase this differently: explicitly state what operations must be valid when applied to a given type in order to deem it as fulfilling the "type constraints" "From now on, I will refer to the set of all types satisfying the constraints of a type class T as the instances of T" A big problem as far as I'm concerned. In C++ we use the phrase "instance of type T" for an entirely different thing. I would use the phrase: a "Printable" type - in the case of the example above. When referring to a set of type constraints I would pick something like "modeling the type constraints T or modeling the Printable type". This is familiar language to us. "To associate methods to a type class, we create a layer of indirection through the instance member of the type class. For example, let's say we want to have a method named print in the Printable type class: …" The whole rest of this section goes into how to create a set of types modeling "Printable". OK - But why is this necessary at all? If one tries something like: template<class T> void f(T & x) { BOOST_CONCEPT_ASSERT((Printable<T>)); std::cout << x; } class x { }; f(x); // compile time error here the program will trap at compile time with an error inside of Printable indicating that f doesn't model Printable because the operation ostream << x isn't supported by x; That's what I need. With type class it looks like that is expected that there be a default implementation for f if x isn't printable. It's not at all clear what this default definition is supposed to do. Print default error message at runtime? or what? The documentation notes that the usage of a default would be rare. But if it were to be used - it conflicts with the original purpose if type constraints (or concepts or type classes, etc). It's still not clear to me what happens if I use your type class system and invoke f(x). Do I get a compile time error? - what kind? where does it point to? How does it help the user find his error? To me the "type class" of the Hana library is a muddled re-implemenation of the boost concept check library. Its much more complicated and subtle and not as well documented and doesn't add anything to BCC. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Hana-Typeclass-tp4665978.html Sent from the Boost - Dev mailing list archive at Nabble.com.

5 7

[msm] State Machine and Dependency Injection
by Kris 04 Aug '14

04 Aug '14

Hi, Recently I have implemented Dependency Injection library, which I proposed to boost last week (http://boost.2283326.n4.nabble.com/is-there-any-interest-in-a-dependency-in…) Right now I wanted to shared how dependency injection might be integrated with Boost.MSM (eUML) and would really glad for any feedback. Boost.MSM is a great library, unfortunately actions/guards have to have empty constructor and whole logic has to be handled via Finite State Machine. Such approach is hard to maintain and test, so would be great to have possibility to implement action/guards without FSM dependency and with proper dependency injection instead. More information: http://krzysztof-jusiak.github.io/di/boost/libs/di/doc/html/di/examples/int… Hello World: class guard : public euml_action<guard> { public: guard(shared_ptr<data> data = nullptr, shared_ptr<other_data> = nullptr); // default constructor is required by eUML template<typename TEvent> bool operator()(const TEvent&) const; // no FSM dependency }; class action : public euml_action<action> { public: action(shared_ptr<data> data = nullptr, shared_ptr<other_data> = nullptr); // default constructor is required by eUML template<typename TEvent> void operator()(const TEvent&); // no FSM dependency }; class state_machine_ : public state_machine_def<state_machine_> { public: using initial_state = state1; BOOST_MSM_EUML_DECLARE_TRANSITION_TABLE(( state1() + event() [guard()] / action() == state2() ), transition_table) }; using state_machine = back::state_machine< state_machine_ , back::use_dependency_injection // Boost.DI dependency injection policy >; auto sm = di::make_injector().create<state_machine>(); // create state machine / actions, guards and their dependencies will be injected via DI framework sm.process_event(event()); Hot it works? * we do implement actions/guards with any dependencies we need * we add use_dependency_injection policy in state machine definition * we create state machine using dependency injection framework library What MSM with DI actually give us? * actions/guards are really easy to test / code doesn't require FSM dependency - loosely coupled * signature change of actions/guards may not require binding configuration changes (if it's not an interface or it's an interface already bound) * FSM is just a declarative abstraction - we don't need to test it * we can use all DI goods for controlling how dependencies will be injected - see https://github.com/krzysztof-jusiak/di Project (with workings tests): https://github.com/krzysztof-jusiak/msm Comparison between usage of Boost.MSM with DI and without it: http://krzysztof-jusiak.github.io/di/boost/libs/di/doc/html/di/examples/int… Looking forward to hear from you. Any feedback is more than welcome. Cheers, Kris -- View this message in context: http://boost.2283326.n4.nabble.com/msm-State-Machine-and-Dependency-Injecti… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[Python] Improved exception handling for Python embedding
by Michael Koenig 04 Aug '14

04 Aug '14

Hey guys! Boost.Python throws boost::python::error_already_set exceptions whenever calls to embedding functions such as boost::python::import() or boost::python::exec() fail. This exception is just an empty class. It does not provide any information on the error which occurred on the Python side. It is not even a standard exception in the C++ sense. As a result, debugging problems with embedded Python code or even the Python environment (available packages etc.) with the current exception handling mechanism is difficult. So far, in our company we wrap most Boost.Python functions with custom exception handling code. In our exception handling code, we basically work the CPython API to extract details of Python exceptions such as * Exception types, * Error messages, and * Stack traces. We want to put this part of our embedding library back into the Boost.Python project. At the EuroPython 2014 conference in Berlin, I had a few discussions with Reinhard Wobst, Austin Bingham, and others, and the current exception handling mechanism was perceived an impediment on the usability of Boost.Python. I am most grateful for feedback of seasoned Boost contributors (and users) whether my proposal is of sufficient interest and how best to pursue it. Cheers Michael -- Dr. Michael König Software Engineer Blue Yonder GmbH Ohiostraße 8 76149 Karlsruhe Tel +49 (0) 721 383 117 38 Fax +49 (0) 721 383 117 69 michael.koenig(a)blue-yonder.com www.blue-yonder.com Registergericht Mannheim, HRB 704547 USt-IdNr. DE 277 091 535 Geschäftsführer: Jochen Bossert, Uwe Weiss (CEO)

4 6

Re: [boost] [GSoC] [Boost.Hana] Formal review request
by Dave Gomboc 04 Aug '14

04 Aug '14

> > [pfultz2] > > Yet it uses a lot of foreign functional concepts. Despite what google says, > > boost libraries are built around mostly C++-like 'interfaces'. I don't think > > its bad to introduce some functional-interfaces, but I know in the past > > libraies that libraries that were very functional were rejected from boost, > > because many people didn't grasp the purpose of them. So introducing a lot > > of functional interfaces on the surface of a library can hinder its adoption. This is a solid caution. Louis, it would be worth your while to review the comments made regarding the Boost review of FC++ some years back, in order to prepare you for the kinds of questions and concerns that primarily imperative-style developers raise. > [Louis Dionne] > That is sad, because the functional concepts are exactly what makes Hana so > powerful. Some problems are well suited for functional programming, and some > are not. Metaprogramming is __inherently__ functional, and it's about time > people embrace it. +1. On a related note (not quoting that other discussion here, but there's been some other postings on the subject), inventing new terminology for well-established programming concepts is not merely pointless, it's actually harmful. If C++ already has an established name for the programming concept, that would be a justifiable reason to use that other name instead of the standard functional programming name. So, it would not at all disturb me if "maybe" ends up being called something like "optional" (C++ is not even alone: Scala calls it "Option"). However, http://www.disi.unige.it/person/MoggiE/ftp/ic91.pdf serves as an existence proof that "monad" has been in use within the programming community since at least 1991. C++ doesn't directly model this concept elsewhere in its most generic form (notwithstanding http://bartoszmilewski.com/2014/02/26/c17-i-see-a-monad-in-your-future/) In this case, I am aware of no justification for using any other name. Dave

1 0

Hana Searchable
by Robert Ramey 04 Aug '14

04 Aug '14

I can't review the whole library. So I'm confining my observations to just a couple of aspects. My method is to review some section of the documentation. it looks like a critique of the documentation, but it's really observations on the underlying design of the library. In this post I'm addressing Searchable in the reference section of the documentation. Searchable >From the explanation of Type class - given a type T, I'm expecting to see some sort of list of operations such that Searchable<T> will compile. What I see is: boost::hana::Searchable Struct Reference Type classes Description Data structures that can be searched. Searchables have a concept of keys and values. Searching is always done on the keys and the result is always the associated value. There is no requirement that the keys and values be different. Synopsis of methods constexpr auto any Return whether any key of the structure satisfies the predicate. More... … Instances and minimal complete definitions struct instance< Map > A map can be searched by its keys with a predicate yielding a boolean Integral. More... struct instance< Maybe > Instance of Searchable for Maybes. More... struct instance< Set > The keys and the values of a Set are its elements; the Searchable instance follows naturally from that. More... My first thought is: Searchable is (sort of) a C++ Concept (type constraints) "Synopsis of methods" is what we customarily refer to as "valid expressions" "Instances and minimal complete definitions" is what we customarily refer to as "models" But right away I have a problem - since "any" doesn't show a valid C++ expression at this level of the documentation I click "auto" and get: Initial value: = [](auto predicate, auto searchable) { return Searchable::instance< datatype_t<decltype(searchable)> >::any_impl(predicate, searchable); } which is totally mystifying to me. I realize that it's a C++ lambda expression. But the only reference I see to "any" is (maybe) Searchable::any_impl. I'm guessing that any_impl has some sort of code which uses predicate and searchable to to return some static_assert - or not. The usage of any_impl seems designed to hide the vary thing I'm interested it - what kind of type can I use as an argument to Searchable. This seems not at helpful to the user. Now "predicate" and "searchable" parameters are define (in text). All "searchable" says is that it's a structure to be searched - nothing about what constitutes such a structure. can std::vector<int> be used as this "searchable" parameter? don't know - and the document doesn't tell me. "predict is a little better in that it says that it's something that is called and that it returns a type fulfilling the constraints of "Logical" which itself linked (thank you). Now I have a few examples which are a little more helpful. BOOST_HANA_CONSTEXPR_LAMBDA auto odd = [](auto x) { return x % 2_c != 0_c; }; So now I see what a predicate is supposed to look like - in this case it's a function which returns a bool. The usage of auto certainly isn't helpful here. The syntax x % 2_c != 0_c is suggestive. It seems that 2_c and 0_c refer to integer constants 2 and 0 respectively. I'm sort of wondering why we can't just use 2 and 0 themselves since it seems we're using constexpr here. BOOST_HANA_STATIC_ASSERT(any(odd, list(1, 2))); The above is interesting. From the explanation of type class I expect this to trap at compile time - or not depending upon the type of list. First of all, I don't know whether this refers to std::list or some type of compile time list of types. Again the documentation leaves me mystified. Documentation BOOST_HANA_STATIC_ASSERT leaves me even more befuddled. It says that it resolves to either static_assert or assert depending on whether the argument is a constexpr or not. An interesting idea. But here we're inside the Searchable type class definition - so wouldn't it make more sense to invoke static_assert directly? The most confusing thing about the example is that Searchable is never mentioned. Isn't the point of defining a Typeclass (C++ concept)?. How it envisioned that this be used. Here is what I would expect to see using our customary way of looking at things in the customary way. I realize that it's not an exact match but it's the best I can do from looking at the documentation. #include "boost/concept/assert.hpp" // define concept Searchable template struct<class S, class P, class T> struct Searchable { BOOST_CONCEPT_ASSERT((std::UnaryPredicate<P>)); BOOST_CONCEPT_ASSERT((std::Sequence<T>)); }; // define any for searchable types template<class S, class P, class T> constexpr bool any(const S &s, const P & p){ BOOST_CONCEPT_ASSERT((Searchable<S, P>)); } // example auto constexpr odd = [](auto x) { return x % 2 != 0; }; ?::list<1, 2, 3> l; static_assert( any(list, odd) ); // should not trap ?::list<2, 4, 6> l2; static_assert( any(list, odd) ); // should trap with error at compile time There are lots of "holes" in my example above, I think this more or less captures what you have in mind. But it's much simpler to understand and use. I confess I've failed to understand the runtime aspects of your library. This is true even though I have worked with fusion more than most and a lot with MPL. I think this should be easy for me - but it's not. BTW - I only used "Searchable" as it happened to be the first one I looked at. Personally I don't believe that thinks like "Searchable", and "Sortable" don't belong as models of type constraints. Using "Sortable as a quick example, my complaint is that it's tautological. Something is defined here as "Sortable" if you can sort it. Actually something like "Sortable should be defined as: template<class Iterator> void quicksort(Iterator begin, Iterator end){ BOOST_CONCEPT_ASSERT((RandomAccessIterator<Iterator>)); BOOST_CONCEPT_ASSERT((LessThanComparable<Iterator::value_type)); … } while a different sorting algorithm void mergesort(C & c){ BOOST_CONCEPT_ASSERT((ForwardIterator<Iterator>)); BOOST_CONCEPT_ASSERT((LessThanComparable<Iterator::value_type)); } So the the idea of "Sortable" doesn't make any sense when not coupled with the data structure which holds the data. Although my example above is based on "Sortable" - it really applies to any type constraints with names like "Searchable", "Foldable", etc. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Hana-Searchable-tp4665987.html Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

What are the things that we HAVE TO fix before shipping 1.56.0?
by Marshall Clow 03 Aug '14

03 Aug '14

We’re coming down to the end of the release process, so I’m taking a poll. * What bugs do you think MUST be fixed before shipping 1.56? In other words, if bug XXX is not fixed, then (in your opinion) we should not bother making a release. Thanks in advance. — Marshall

12 26

Algorithm Packages
by Varun Raj 03 Aug '14

03 Aug '14

Hello everyone, I would like to develop packages for Boost Library specifically in the Algorithms section. So i would like to know the feedback on what Algorithms are most needed by the members of the community right now.Thank you for sparing your time for giving me a feedback.

2 2

[utility] string_ref construction from rvalue reference to string
by Андрей Давыдов 03 Aug '14

03 Aug '14

Hello, boost. Are the any reasonable cases when construction boost::string_ref from std::string && is desirable? I mean that usage string_ref in the following examples is totally wrong, but not for compiler: using std::string; using boost::string_ref; // 1 { auto ref = string_ref(string("abacaba") + string("upyachka")); std::cout << ref << std::endl; } // 2 { string very_long(1000000, 'a'); auto ref = string_ref(very_long + "b"); std::cout << ref << std::endl; } In practice it gets worse, because the first example example works (gcc 4.9.1) thanks to optimizations with short literals, I suspect, and the second example leads to segmentation fault, as expected. Those errors can be caught at compile time if class "basic_string_ref" defintion would contain lines like following: template<typename Allocator> basic_string_ref(std::basic_string<charT, traits, Allocator> &&) = delete; I cannot understant does it prevent any correct usage of string_ref? -- Andrey Davydov

6 8

Hangs with Boost 1.56 on clang armhf
by Niall Douglas 03 Aug '14

03 Aug '14

I'm seeing consistent hangs of AFIO on Boost 1.56 on Ubuntu 14.04 LTS for clang armhf. GCC armhf works fine, so this is a clang armhf related issue. https://ci.nedprod.com/view/Boost.AFIO/job/Boost.AFIO%20Test%20POSIX_A RM_clang%203.4/10/console I talked to Ubuntu upstream about this, and I had the idea of trying the LLVM armhf binaries provided at http://llvm.org/releases/3.4.2/clang+llvm-3.4.2-armv7a-linux-gnueabihf .tar.xz as surely LLVM provide good binaries. Same problem - tests hang. I tried running a test manually and I get this: terminate called after throwing an instance of 'boost::thread_interrupted' terminate called recursively terminate called recursively terminate called recursively terminate called recursively terminate called recursively terminate called recursively terminate called recursively terminate called recursively terminate called recursively terminate called recursively terminate called recursively terminate called recursively terminate called recursively terminate called recursively terminate called recursively terminate called recursively terminate called recursively terminate called recursively terminate called recursively terminate called recursively Remember, this is identical code to any other Linux target, plus this works a-ok for GCC armhf. A quick backtrace with gdb reveals this: terminate called after throwing an instance of 'boost::thread_interrupted' [Thread 0xb5b76450 (LWP 12610) exited] Program received signal SIGABRT, Aborted. [Switching to Thread 0xb6376450 (LWP 12609)] __libc_do_syscall () at ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:44 44 ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S: No such file or directory. (gdb) bt #0 __libc_do_syscall () at ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:44 #1 0xb639f0fe in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #2 0xb63a1956 in __GI_abort () at abort.c:89 #3 0xb65377a8 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 #4 0xb65361c8 in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) What looks to be happening here is that thread cancellation, which works by having an exception thrown, appears to not be caught by the thread being cancelled for some odd reason. I don't have time to investigate this until maybe Saturday. I guess we'll just have to ship 1.56 and look into this for 1.57. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 1

Re: [boost] [1.56.0] Release candidates available
by Eric Niebler 03 Aug '14

03 Aug '14

On 07/29/2014 02:44 PM, Boris Schäling wrote: > On Tue, 29 Jul 2014 19:06:43 +0200, Marshall Clow > <mclow.lists(a)gmail.com> wrote: > >> Release candidate files for 1.56.0 are available at >> http://boost.cowic.de/rc/ > > I get a compiler error with g++ 4.8.3 on Cygwin (64-bit): > > In file included from libs\system\src\error_code.cpp:19:0: > ./boost/system/detail/error_code.ipp: In member function ‘virtual > std::string > boost::system::{anonymous}::system_error_category::message(int) const’: > ./boost/system/detail/error_code.ipp:413:5: error: > ‘local_free_on_destruction’ is not a member of ‘boost::detail’ > detail::local_free_on_destruction lfod(lpMsgBuf); > ^ > > This looks like the bug Eric had reported at > <https://svn.boost.org/trac/boost/ticket/10137>. Crud. Beman, did a merge get missed? Eric

5 8

Re: [boost] b2 headers is unreliable on 1.56 on Windows
by Matthew Musto 01 Aug '14

01 Aug '14

Nial, I found you need to run your cmd prompt as administrator before running b2 in order for the sym links to work correctly, otherwise you end up with hard links and the process fails 9 times out of 10. At least that is what I found on Win 8.1, -Matt From: Niall Douglas <s_sourceforge <at> nedprod.com> Subject: b2 headers is unreliable on 1.56 on Windows <http://news.gmane.org/find-root.php?message_id=53D91411.15683.55F433CE%40s%…> Newsgroups: gmane.comp.lib.boost.devel <http://news.gmane.org/gmane.comp.lib.boost.devel> Date: 2014-07-30 15:49:37 GMT (8 hours and 40 minutes ago) Anyone else found that b2 headers in 1.56 randomly misses things to hard link on Windows? If you run it four or five times it eventually hard links everything through monte-carlo, but it is a bit annoying. Niall -- ned Productions Limited Consultinghttp://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 2

Boost logos on mailing list archives linking to non-boost pages instead of boost.org
by Curdeius Curdeius 01 Aug '14

01 Aug '14

Hi all, I have just spotted a curious detail on 3 Boost mailing lists. The logos (C++ Boost / Boost C++ libraries) point to web pages that are not affiliated in any way to boost. The concerned lists are: - http://lists.boost.org/boost-docs/ points to www [dot] boost [dot] com - http://lists.boost.org/boost-testing/ points to www [dot] boost [dot] com - http://lists.boost.org/geometry/ points to www [dot] osl [dot] iu [dot] edu I am not sure if this is the correct list to write to. If anyone knows what to do about it, please answer to the list or inform the correct person. Regards, Marek Kurdej

1 0

Understanding Jam Files
by Axel Ismirlian 01 Aug '14

01 Aug '14

I have been working on boost for about a month now, but I still don't fully understand boost's build configuration very well. More specifically, I do not understand where the properties array gets filled in and where that data comes from. I saw the property.jam file which seems to refine the list of properties and take away unmet conditions, and bind dependencies. I also saw the property-set.jam file which creates property lists from raw properties, but where do the raw properties come from exactly? Does every property-set created come through this file? It would be very helpful if someone could point me in the right direction. Sincerely, -Axel

5 9

synchorize or strand
by dd 01 Aug '14

01 Aug '14

Hi all, There is multi-threaded application which will access data containers at the same time. Which is the best choice between synchronization and strands. Thanks, dd

3 3

local_time seems not monotonic
by Gaetano Mendola 31 Jul '14

31 Jul '14

The following snippet seems to generate non monotonic local_date. I'm using boost 1.55 on linux. #include <boost/date_time/local_time/local_time.hpp> #include <boost/ptr_container/ptr_vector.hpp> int main() { const boost::local_time::time_zone_ptr theTimeZone( new boost::local_time::posix_time_zone( "CET+01CEST+01,M3.5.0/02:00,M10.5.0/03:00") ); boost::local_time::local_date_time myOldValue( boost::local_time::local_microsec_clock::local_time(theTimeZone)); for (size_t i = 0; ; ++i) { const boost::local_time::local_date_time myLocalTime = boost::local_time::local_microsec_clock::local_time(theTimeZone); if (myLocalTime < myOldValue) { std::cout << myOldValue << std::endl; std::cout << myLocalTime << std::endl; std::cout << boost::local_time::local_microsec_clock::local_time(theTimeZone) << std::endl; std::cout << "====================" << std::endl; } myOldValue = myLocalTime; } } As you can see the program is not supposed to print nothing ever, however this is what I'm getting: 2014-Jul-31 00:24:56.005625 CEST 2014-Jul-31 00:24:55.005631 CEST 2014-Jul-31 00:24:56.005946 CEST ==================== 2014-Jul-31 00:24:58.005625 CEST 2014-Jul-31 00:24:57.005629 CEST 2014-Jul-31 00:24:58.005824 CEST ==================== 2014-Jul-31 00:25:02.005624 CEST 2014-Jul-31 00:25:01.005628 CEST 2014-Jul-31 00:25:02.005838 CEST ==================== 2014-Jul-31 00:25:04.005625 CEST 2014-Jul-31 00:25:03.005630 CEST 2014-Jul-31 00:25:04.005826 CEST ==================== 2014-Jul-31 00:25:06.005624 CEST 2014-Jul-31 00:25:05.005633 CEST 2014-Jul-31 00:25:06.005853 CEST ==================== 2014-Jul-31 00:25:07.005625 CEST 2014-Jul-31 00:25:06.005631 CEST 2014-Jul-31 00:25:07.005846 CEST ==================== 2014-Jul-31 00:25:12.005625 CEST 2014-Jul-31 00:25:11.005631 CEST 2014-Jul-31 00:25:12.005822 CEST ==================== as you can see when the local_date is near 0.005631 second fraction it goes back of one second and then forward again on the following call. Am I missing something ? Regards Gaetano Mendola

3 2

Request for feedback on design of concurrent_unordered_map, plus notes on use of memory transactions
by Niall Douglas 31 Jul '14

31 Jul '14

Dear Boost, Finally I have found some time to write up my experimentations with using transactional GCC or Intel TSX TM to make an improved concurrent_unordered_map. The quick tl;dr summary is this: 1. Transactional GCC is great iff you are happy accepting up to a 50% performance reduction in normal code execution. For a greenfield multithreaded project this is absolutely worth it due to the enormous savings in debug effort. 2. First generation Intel TSX isn't worth using in almost any common use case. The only common use place it makes sense is for almost always read only data which is *always* highly contended where speedups can approach linear to execution cores, and even then the refactoring you need to make to avoid writes to any cache line touched by any other thread will make your code slower than throwing everything inside a standard spin lock. Spin locks are well optimised and allow simple implementations, plus spin locks are very fast for uncontended use. Any Intel TSX (HLE, RTM) introduces penalties to uncontended use and seems to force a pipeline stall which can reduce single threaded performance by as much as 40%. 3. Trying to implement atomics-based logic to have the CPU select non-TSX during uncontended and TSX during contended comes out at best as slightly slower than always using TSX. This, for me, simply kills TSX v1.0, I no longer consider it worth thinking about till v2.0 is made by Intel. For reference for those wishing to repeat my experimentations, you can see the history of my four attempts at a concurrent_unordered_map at https://github.com/ned14/boost.spinlock/commits/concurrent_unordered_m ap2 plus benchmark results at https://ci.nedprod.com/view/Boost%20Thread-Expected-Permit/job/Memory% 20Transactions%20Test%20Linux%20GCC%204.8/. So, onto my proposed new concurrent_unordered_map design, which is NOT a split ordered list design as Intel TBB or Microsoft PPL does it. I had four criteria for my concurrent_unordered_map design which were based on my needs for proposed Boost.AFIO: 1. erase() is safe. This is for me the big showstopper with split ordered list designs, and I think it probably is for most people. 2. insert(), find(), and erase() all had to have single threaded performance similar to a std::unordered_map<> with a spin lock around it i.e. fast. 3. Everything apart from rehashing should be able to be concurrent. This includes iteration, inserting, finding, erasing, sizing. 4. Memory transaction friendly. This means transactional GCC right now, but maybe some future Intel TSX v2.0 support later. This criterion, incidentally, *requires* C++ 11 noexcept support, or at least I can't see a way to avoid it otherwise (just to be clear, I am claiming that for the implementation to _efficiently_ use memory transactions it needs noexcept move construction for both key and mapped type). Designs tried and benchmarked and rejected: 1. Items in a bucket were kept via an atomic forward pointer to the next item and one used cmpxchg to insert and remove items. This had really great, even superb, performance for load factors near one, but became pathological for badly distributed hash functions (I'm looking at you libstdc++). Once you rehashed the hash function to make it better distributed, performance nose dived. I was tempted to override std::hash with a decent implementation ... 2. Items in a bucket were kept as as a linear list of hashes and atomic pointers to value_type's. Each atomic pointer's bottom bit was its spin lock to keep each item footprint small, so you could lock each individual item during usage. The problem here really was that how do you safely resize the table without a per-bucket lock, and that halved performance over a spinlocked unordered_map as transactions really didn't deliver as expected here. 3. I created a specialisation only for mapped types of some std::shared_ptr<> which let me implement a completely lock free design. Unfortunately it was also rather slow, also about half the performance of a spinlocked unordered_map. Atomic increments and decrements of the same cache line across execution cores are slow :) Final proposed design (comments welcome): * item_type is allocated via a rebind of the supplied allocator, and looks like: struct item_type { value_type p; size_t hash; }; If value_type has a big sizeof(), a very good idea is to make the above a unique_ptr as otherwise you can't pack many item_type's into a cache line (AFIO's value_type is a std::pair<size_t, std::shared_ptr<>> which is 24 bytes, so item_type is 32 bytes which works well for my purposes). * bucket_type looks like this: struct bucket_type { spinlock<bool> lock; atomic<unsigned> count; // count is used items in there std::vector<item_type, item_type_allocator_type> items; char pad[64-sizeof(spinlock<bool>)-sizeof(atomic<unsigned>)-sizeof(std::vec tor<item_type, item_type_allocator_type>)]; }; static_assert(sizeof(bucket_type)==64, "bucket_type is not 64 bytes long!"); Note that items has its capacity directly managed, and is always expanded to powers of two. The size of actual items stored can float between zero and capacity. * And finally, concurrent_unordered_map itself merely contains: template<class Key, class T, class Hash=std::hash<Key>, class Pred=std::equal_to<Key>, class Alloc=std::allocator<std::pair<const Key, T>>> class concurrent_unordered_map { spinlock<bool> _rehash_lock; hasher _hasher; key_equal _key_equal; std::vector<bucket_type> _buckets; }; * To insert or find an item involves determining the bucket from the modulus of the hash by the number of buckets, locking the bucket and scanning the linear list for an empty item or the right item as appropriate. We know empty items from a magic hash value which is defined to some magic constant (advice on the best magic hash value least likely to turn up from std::hash is welcome). find() starts from the start of the list forwards, insert() starts from the end of the list backwards to help with cache line contention. As insert() needs to check for key matches as well as for empty slots, it needs to happen anyway, but if we knew key collision could never happen we could detect when the table is full from the atomic count and skip the table scan. If insert doesn't find a match nor an empty slot, if there is capacity it appends the item, if no capacity a capacity doubling is done and then an append. If capacity doubling occurs, all references to items in that bucket become invalid. I intend an insert_stable() API which will refuse to modify capacity, plus a bucket_reserve() API. insert() and find() have O(avrg bucket size (not count)). On transactional GCC find() and the initial seach for key equivalence in insert() are implemented as transactions without locking the bucket. All modifications are done by locking the bucket. This was found to have the best performance through trial and error. * To erase an item is easy: iterators store an iterator to the bucket and an offset into the linear table. Erasure involves constructing a temporary value_type, locking the bucket and performing a *move* construction out of the table into the temporary value_type, resetting the hash to empty. Destruction can then occur without holding the bucket lock. If the item just erased is the last in the bucket, the bucket's size (not capacity) is reduced by one, and that is repeated until the bucket size is the minimal possible. I currently violate STL allocator requirements here because I don't use the allocator for the temporary value_type to avoid a usually pointless malloc. Any suggestions on how to fix this would be welcome. You'll note that erasure here is safe as its storage never moves, though if you concurrently use and erase the same item you'll get a race onto a destroyed item which is as expected. erase() is O(1). * size() under this design becomes O(bucket count) as we sum the count members of each bucket. empty() is worst case O(bucket count) when the map is empty, best case O(1) when the first bucket is not empty, average case O(bucket count/item count/2). * Iteration under this design is queerly inversely dependent on load factor - with the higher the load factor, the better the performance. This is because we don't bother with the usual forward pointer per item as those are expensive for concurrent use and doubly linked pointers are rather a lot of overhead per item, so iteration is a case of iterating linear tables and once completed, searching for the next non-empty bucket which in a sparsely occupied bucket list is very lumpy as cache lines are pulled one by one into the cache. * rehash() under this design firstly locks the special rehash lock, then locks every bucket in the list. It then constructs a new empty bucket list and locks every lock in that. It then swaps the bucket lists, and moves all the items from the old buckets to the new buckets. It finally unlocks all the buckets, and the special rehash lock. This function is hard to write completely race free under all CPU load circumstances without burdening the main API implementations. I may use the concept of keeping around the old just emptied bucket list which is permanently marked to users as "go reload the bucket list" to work around this, and then document that you must not rehash too frequently or else you will race your code. Note that rehashing under this design is completely manual. If it were not, insertion, erasure and item referencing could not be safe. This implies that if you rehash, it is up to you to not be using items by reference at the time. Rehashing is also by definition not concurrent, indeed it is the only function in the design which is not capable of concurrency. Thoughts on this design before I write a final implementation are welcome. I don't plan to complete my implementation past the minimum needed for proposed Boost.AFIO, so if someone else wishes to finish it that and make it part of official Boost that would be great. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

4 6

Fwd: [sync?] "Distributed" value (or something...)
by Klaim - Joël Lamotte 31 Jul '14

31 Jul '14

---------- Forwarded message ---------- From: Klaim - Joël Lamotte <mjklaim(a)gmail.com> Date: Tue, Jul 29, 2014 at 9:44 PM Subject: [boost][sync?] "Distributed" value (or something...) To: Boost users list <boost-users(a)lists.boost.org> I would like to ask Boost developers and users: 1. Am I the only one seeing the following pattern in my concurrent systems code? 2. Is there already some tools available in Boost that does what I describe here and that I am not aware of? 3. If not, would there be any interest in the tool I'm describing here or not? Is it a dumb idea? (I keep getting back to this idea but I'm surprised not finding anything similar online) The pattern that I am seeing occurs when: 1. I have a value or a set of values in an object or several objects which value(s) describe some kind of configuration that several other systems will read and use. 2. The object(s) will be updated only by one thread (at a time). 3. When the object's value is modified, all the systems that rely on the object's value have to be notified so that they update themselves using that value. 4. The systems I am refering to can use different threads for updating and we can assume that they are running concurrently. 5. It is not important that the source object's value is synched with the reader's values at all time, however it is important that the sequence of changes to the source object's value is signaled to the readers exactly in the same order and "as fast as possible", but delay is ok. The simplest solution to solve this is to have a mutex locking the value and the systems checking the value regularly. (that is, using syncrhonized_value for example) However the locking and looping reads might not be necessary if it is done in another way (if I am correct, I still lack experience in the domain). The solution that I am thinking about would look like this. ///////// // The object containing the value used by the other systems. class System_A { distributed_source<int> m_foo_count; // changes to this object will be sent to "readers"... public: System_A() : m_foo_count(42) ... {} //... // thread-safe read-only access distributed_value<int> make_foo_count_reader() const { return distributed_value<int>{ m_foo_count }; } }; ///////// // The different systems acquire a read access to the value. class System_B { distributed_value<int> foo_count; // read-only value reflecting System_A::m_foo_count's value since last update. public: SystemB( const System_A& system_a, ... ) : m_foo_count( system_a.make_foo_count_reader() ) { // setup the initial config... on_foo_count_changed( *m_foo_count ); // trigger some processing when SystemA::foo_count's value have been changed: m_foo_count.on_changed( [this]( int new_value ){ // called after the value have been changed m_work_queue.push( [=]{ // will be executed on the next update cycle for this system... on_foo_count_changed( new_value ); / }); }); } //... private: void update_cycle( const UpdateInfo& info ) { // ... // the following is just to clarify: const int foo_before = *m_foo_count; // the value is not updated yet, but we can still use it m_work_queue.execute(); const int foo_after = *m_foo_count; // the value might have been udpated if( foo_before != foo_after ) { // the value have been updated (though you don't need to do this if you used the callback instead). } //... }; }; //////// // At some point the value is changed by the system owning the source object... System_A::change_foo( int new_value ) { m_work_queue.push( [=]{ // will be executed on the next update cycle of this system... // ... *m_foo_count = new_value; // assign the new value then send the new value to the readers... }); } System_A::something_complex( std::function<void(int&)> some_work ) { m_work_queue.push( [=]{ // ... m_foo_count.update( some_work ); // execute on the current value then send the resulting value to the readers }); } Some notes: a. The names are just invented while I write this email. b. I suppose that the distributed_source might have an interface similar to synchronized_value, anyway I didn't get farther than this idea. c. I see several different ways to implement this idea, some might be more efficient than others but I didn't do any tests yet (by lack of time). Thoughts?

3 7

Documentation appears to have part of boost::mpi::packed_iarchive and boost::mpi::packed_oarchive reversed?
by Dominic Marcello 31 Jul '14

31 Jul '14

Hello It seems like the documentation for boost::mpi::packed_iarchive and boost::mpi::packed_oarchive are reversed. boost::mpi_packed_iarchive uses MPI_Unpack and boost::mpi::packed_oarchive uses MPI_Pack. This can be verified by looking at the packed_iprimitive and packed_oprimitive base classes. The documentation, as well as the packed_iarchive and packed_oarchive header files, however, say the opposite - that packed_oarchive uses MPI_Unpack and packed_iarchive uses MPI_Pack. -Dominic

2 1