3

Is there a significant impact of the new standard's features on the boost library implementation in C++11?

Especially interested in boost::variant (BOOST_VARIANT_LIMIT_TYPES) and boost::spirit parts of the library in light of the presence of variadic templates.

Is there a good article about this?

sehe
  • 374,641
  • 47
  • 450
  • 633
Tomilov Anatoliy
  • 15,657
  • 10
  • 64
  • 169
  • 1
    the only impact is some things can be removed from boost (for example shared_ptr), and the implementation – BЈовић Apr 19 '13 at 06:57
  • 1
    @BЈовић I don't think that's accurate, boost::shared_ptr still has more features, boost::regex many more and a different interface to boot; Also, the integration with PhoenixV2 is present for boost shared_ptr, but not std::[tr1::]shared_ptr and so on. – sehe Apr 19 '13 at 07:08
  • 6
    @BЈовић that's not true. With C++11, many parts of the libraries *could* indeed be implemented easier, but probably won't be necessarily to be backwards compatible with C++03 compilers. On the other hand, some parts will need to be improved, e.g. to support move-only types. That will be interesting especially for variant - a variant that contains move-only types should be movable in C++11. I know of a ticket for Boost.Optional to become move-aware, so it seems they are at it :) – Arne Mertz Apr 19 '13 at 07:08
  • @Dukales Boost is specifically designed to be C++03 friendly, so most libraries don't use the 'goodness' of C++11 by default. However, as an example, Fusion will use variadics when you include `fusion/adapted/std_tuple.hpp` - and you'd actually see compile times reduce when you switch from boost::tuple (however, see above: boost tuples have (far) more features, and a different interface so don't assume it's a drop in replacement) – sehe Apr 19 '13 at 07:10
  • @ArneMertz Good points. I forgot about the move – BЈовић Apr 19 '13 at 07:10
  • @sehe I'm ask about the implementation. – Tomilov Anatoliy Apr 19 '13 at 07:12
  • @Dukales I know (I addressed that: "Boost is specifically designed to be C++03 friendly, so most libraries don't use the 'goodness' of C++11 by default", also the Fusion example). By now, see my answer as well - HTH – sehe Apr 19 '13 at 07:16
  • Some classes can now be way cleaner then before. For example, `boost::mpl::vector` is now clean if needed thanks to variadic templates (nothing to do with the previous implementations that used macros in order to be usable with too much boilerplate). Moreover, variadic templates improve a lot the time needed to compile this class (see [this blog post](http://cpptruths.blogspot.fr/2010/03/faster-meta-programs-using-gcc-45-and.html)). – Morwenn Apr 19 '13 at 07:20
  • I retracted my very own 'mark as duplicate'. To my own surprise it turns out that the specific wording of the question made it sollicit quite a bunch of information that isn't covered elsewhere Sorry :) – sehe Apr 19 '13 at 07:38
  • @ArneMertz: I see no reason why a C++03 and a C++11 implementation could not live side-by-side. This would ensure both backward compatibility for C++03 and better compile times (and less limitations) for C++11. Boost.Config is all about detecting compiler features (and working around bugs), so new macros like `BOOST_COMPILER_SUPPORT_VARIADIC_TEMPLATE` or the like could pop up and be used to simplify implementation. – Matthieu M. Apr 19 '13 at 08:12
  • @MatthieuM. I think that exists, look at BOOST_NO_VARIADIC_TEMPLATES in the example I mentioned before: http://www.boost.org/doc/libs/1_53_0/boost/fusion/adapted.hpp – sehe Apr 19 '13 at 08:15
  • @MatthieuM. Yeah, such macros already live in Boost.Config. – Morwenn Apr 19 '13 at 08:18
  • @MatthieuM. that's a bit of what I meant by "won't be necessarily", in the sense of that the C++03 implementations need to remain anyways and C++11 implementations will be provided only where they provide a benefit, at least for the time being. Right now, move-awareness will be of more importance than to provide variadic template implementations for features that still work well with BOOST_PP_* n-ary function overload abominations. – Arne Mertz Apr 19 '13 at 08:42

1 Answers1

7

(I was writing my third comment, which is going to address the topic of Spirit specifically. I decided to mesh my comments into an answer anyways)

Boost Spirit is going to be using C++11 features exclusively (i.e. drop C++03 support) so that it can take full advantage of the improved TMP abilities and reduced compile times - compilation times are a big drawback of using Spirit V2.

Spirit X3 (the experimental V3 branch) is already under active development:

And in yet other news: Spirit V3 will be C++11 only and move-enabled:

Feb 11, 2013; 12:02pm, Joel de Guzman wrote:

No, X3 will be C++11 only. Pure. No workarounds.

Keep in mind though that X3 is, by its nature, X-perimental. A lot of things can happen from X3 to final. I am not closing the door on C++03 support, although I am heavily inclined to move on without 03. V2 will not be going away anytime soon anyway.

Also, expression templates will be auto-safe, no more need for the BOOST_SPIRIT_AUTO macro whenever you want to keep a 'raw' parser expression bound to a local variable.>

I found the link to the Spirit X3 repositories:

Note the status of the development at http://boost-spirit.com/home/2013/02/23/spirit-x3-on-github/

sehe
  • 374,641
  • 47
  • 450
  • 633
  • `Spirit V3 will be C++11 only and move-enabled` sounds good. This should lead to a reduction in compile time? – Tomilov Anatoliy Apr 19 '13 at 07:29
  • Added a link to Spirit X3 repository – sehe Apr 19 '13 at 07:29
  • @Dukales yes, this vastly reduces compile times (e.g. - browsing SpiritX3: TOTAL : 4.27 secs vs. Spirit2: TOTAL : 10.00 secs) – sehe Apr 19 '13 at 07:30
  • I think more libraries should take this 'bold' approach, using C++11 features leads to less code, easier to read and smaller compilation times. – demorge Apr 19 '13 at 07:39
  • @demorge I agree, but I also appreciate that Boost needs to keep a large user base. I a sense, Spirit is an outlier, in that it's highly specific (contrast, e.g. with MPL) and already is so heavy on the compiler, that it basically requires a very recent compiler anyways. These two factors make it so that Spirit wouldn't alienate _much_ of it's user base by making this move. Also, like Spirit Classic, the current SpiritV2 will continue to exist for compatibility purposes. – sehe Apr 19 '13 at 07:42
  • When they say "C++11 only", do they mean to support Visual Studio at all, or are they going to use any feature where applicable, no matter where it is or is not supported? – Nicol Bolas Apr 20 '13 at 03:47
  • @NicolBolas I have no authoritative source, but I can only assume MSVC support is a given. I have always presumed this is a requirement for each and any boost library project. – sehe Apr 21 '13 at 11:11
  • @sehe [Boost Library Requirements and Guidelines](http://www.boost.org/development/requirements.html#Portability): "There is no requirement that a library run on C++ compilers which do not conform to the ISO standard.", etc – Evgeny Panasyuk Apr 24 '13 at 22:44