- 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