The existing code base being prepared for entry into Boost is pure C++11, or at least as much C++11 as is provided by the Nov 2012 CTP experimental MSVC compiler and therefore easily supported by GCC 4.6 and clang 3.x.
I hope that you do realize that the Nov12 CTP does not come with a go-live license, nor is recommended for any human consumption.
It seems quite odd to me to spend significant GSoC resources on making a
Meh. First preview of VS2013 is only a month away. Nov 2012 CTP is usefully broken in ways easy to work around (parser bugs) rather than broken in unhelpful ways (unreliable code generation). It fills a useful slot until VS2013 arrives later this year. library
that targets only two compilers, and assumedly a rather narrow set of OSes.
Actually it targets three compilers (+clang). I might add that Boost.ASIO only officially supports Windows, Linux, Solaris and OS X, and only the compilers MSVC7.1 or later and g++ 3.3 or later. Some would say that is a fairly narrow set in itself. We'll be matching Boost.ASIO's official platform support, but adding official support for FreeBSD 10 with clang and libcxx. In truth though it ought to work on any OS providing a POSIX file i/o API with preadv() and pwritev() which is the majority (including Windows via its MSVCRT incidentally). You may find https://github.com/BoostGSoC/boost.afio/wiki/Status-of-proposed-Boost.AFIO of interest. There it tells you how to get started with the proposed library right now.
Was this C++11-only requirement part of the original project plan, and why didn't anyone object to it then?
Yes, it was an original plan requirement. Having full fat C++11 (esp. the C++11 standard library) to hand made the code and design *very* considerably simpler and *much* easier to read (and therefore maintain) - in fact, there is only 670 lines of active code. Judging from the presentations at C++ Now 2013, this simplification experience of pure C++11 is hardly unique: many presenters commented on just how much their pure C++11 new versions of Boost libraries were cleaner, simpler, faster to compile and faster performance, and hugely more maintainable. Given that we knew that VS2012 would get variadic templates later this year (which it will in the form of VS2013), we decided to just go ahead with what C++11 features will be available to > 90% of C++ users by the end of 2013. That surely should satisfy the portability requirement, if not, then we'll work backwards until we reach > 95% of C++ users or > 99% if Boost peer review really, really wants it. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.
On Mon, Jun 17, 2013 at 6:45 PM, Niall Douglas
I hope that you do realize that the Nov12 CTP does not come with a go-live license, nor is recommended for any human consumption.
Meh. First preview of VS2013 is only a month away. Nov 2012 CTP is usefully broken in ways easy to work around (parser bugs) rather than broken in unhelpful ways (unreliable code generation). It fills a useful slot until VS2013 arrives later this year.
It seems quite odd to me to spend significant GSoC resources on making a library that targets only two compilers, and assumedly a rather narrow set of OSes.
Actually it targets three compilers (+clang). I might add that Boost.ASIO only officially supports Windows, Linux, Solaris and OS X, and only the compilers MSVC7.1 or later and g++ 3.3 or later. Some would say that is a fairly narrow set in itself.
That's not quite what I read here: http://www.boost.org/doc/libs/1_53_0/doc/html/boost_asio/overview/implementa... And the compilers you mentioned as officially supported by ASIO actually cover pretty much every compiler out there nowdays. Comparing that with your requirement of the compiler that has not even been released, it doesn't look like AFIO portability level will be even remotely close to that of ASIO.
Given that we knew that VS2012 would get variadic templates later this year (which it will in the form of VS2013), we decided to just go ahead with what C++11 features will be available to > 90% of C++ users by the end of 2013. That surely should satisfy the portability requirement, if not, then we'll work backwards until we reach > 95% of C++ users or > 99% if Boost peer review really, really wants it.
I think your estimate of "> 90% of C++ users by the end of 2013" is much too optimistic. People in corporate sector are very reluctant to update their toolsets, so expect people trying to use your new library with 3-5 year old compilers. I know, C++11 has many fancy features and all, and I'm all for its adoption too. But Boost also serves practical purpose, and if people can't use your library then that just limits its usefulness. So unless you trying to make some academic work here, the library should be more portable.
On 6/17/2013 10:29 AM, Andrey Semashev wrote:
I know, C++11 has many fancy features and all, and I'm all for its adoption too. But Boost also serves practical purpose, and if people can't use your library then that just limits its usefulness. So unless you trying to make some academic work here, the library should be more portable.
Seems an undue constraint on a new library to me. Adding a new C++11 library harms no one that doesn't have have a C++11 compiler. If you need a C++03 version of a C++11 only library and you feel it is not an unreasonable amount of work to provide you could just fork the library into your own github and do the backporting.
I know, C++11 has many fancy features and all, and I'm all for its adoption too. But Boost also serves practical purpose, and if people can't use your library then that just limits its usefulness. So unless you trying to make some academic work here, the library should be more portable.
Seems an undue constraint on a new library to me.
Adding a new C++11 library harms no one that doesn't have have a C++11 compiler.
If you need a C++03 version of a C++11 only library and you feel it is not an unreasonable amount of work to provide you could just fork the library into your own github and do the backporting.
Whether this is good enough for Boost will be decided during the review and not by individual interests. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
On 6/17/2013 10:55 AM, Hartmut Kaiser wrote:
I know, C++11 has many fancy features and all, and I'm all for its adoption too. But Boost also serves practical purpose, and if people can't use your library then that just limits its usefulness. So unless you trying to make some academic work here, the library should be more portable.
Seems an undue constraint on a new library to me.
Adding a new C++11 library harms no one that doesn't have have a C++11 compiler.
If you need a C++03 version of a C++11 only library and you feel it is not an unreasonable amount of work to provide you could just fork the library into your own github and do the backporting.
Whether this is good enough for Boost will be decided during the review and not by individual interests.
Makes sense.
On Monday 17 June 2013 10:55:32 Hartmut Kaiser wrote:
I know, C++11 has many fancy features and all, and I'm all for its adoption too. But Boost also serves practical purpose, and if people can't use your library then that just limits its usefulness. So unless you trying to make some academic work here, the library should be more
portable.
Seems an undue constraint on a new library to me.
Adding a new C++11 library harms no one that doesn't have have a C++11 compiler.
If you need a C++03 version of a C++11 only library and you feel it is not an unreasonable amount of work to provide you could just fork the library into your own github and do the backporting.
Whether this is good enough for Boost will be decided during the review and not by individual interests.
Agreed.
On Monday 17 June 2013 10:39:10 Michael Marcin wrote:
On 6/17/2013 10:29 AM, Andrey Semashev wrote:
I know, C++11 has many fancy features and all, and I'm all for its adoption too. But Boost also serves practical purpose, and if people can't use your library then that just limits its usefulness. So unless you trying to make some academic work here, the library should be more portable.
Seems an undue constraint on a new library to me.
Adding a new C++11 library harms no one that doesn't have have a C++11 compiler.
If you need a C++03 version of a C++11 only library and you feel it is not an unreasonable amount of work to provide you could just fork the library into your own github and do the backporting.
I wasn't suggesting making the library strictly C++03-compatible. My main point was that the library has to be compatible with _todays_ and even better - _yesterdays_ compilers to be actually useful. My choice of "reasonable" time frame is 3-5 years, as I mentioned. That includes VS 2008 and VS 2010, which already had some C++11 features, including rvalue references. Making VS 2013 absolute minimum is a no-go, IMHO.
On 17 June 2013 18:17, Andrey Semashev
On Monday 17 June 2013 10:39:10 Michael Marcin wrote:
If you need a C++03 version of a C++11 only library and you feel it is not an unreasonable amount of work to provide you could just fork the library into your own github and do the backporting.
I wasn't suggesting making the library strictly C++03-compatible. My main point was that the library has to be compatible with _todays_ and even better - _yesterdays_ compilers to be actually useful. My choice of "reasonable" time frame is 3-5 years, as I mentioned. That includes VS 2008 and VS 2010, which already had some C++11 features, including rvalue references. Making VS 2013 absolute minimum is a no-go, IMHO.
The portability requirements disagree. http://www.boost.org/development/requirements.html#Portability
Daniel James wrote:
On 17 June 2013 18:17, Andrey Semashev
wrote: On Monday 17 June 2013 10:39:10 Michael Marcin wrote:
If you need a C++03 version of a C++11 only library and you feel it is not an unreasonable amount of work to provide you could just fork the library into your own github and do the backporting.
I wasn't suggesting making the library strictly C++03-compatible. My main point was that the library has to be compatible with _todays_ and even better - _yesterdays_ compilers to be actually useful. My choice of "reasonable" time frame is 3-5 years, as I mentioned. That includes VS 2008 and VS 2010, which already had some C++11 features, including rvalue references. Making VS 2013 absolute minimum is a no-go, IMHO.
The portability requirements disagree.
http://www.boost.org/development/requirements.html#Portability
+1 - agree. This has always been the standard and it has worked well. In a practical sense, if one makes new a C++11 only package - no current user is impacted. If someone want's to use it, they'll just have to find a way to upgrade. This is not an unfair, nor unrealistic policy. And it's better for C++. If some submission is very populer but only supports C++11, it will help drive C++ forward - which to me is one of the principle goals and accomplishments of Boost so far. And the work in making a new submission backward compatible is basically wasted and the value of this work diminishes to nothing over time. Let's keep Boost looking forward ! Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 17 June 2013 16:29, Andrey Semashev wrote:
I know, C++11 has many fancy features and all, and I'm all for its adoption too. But Boost also serves practical purpose, and if people can't use your library then that just limits its usefulness. So unless you trying to make some academic work here, the library should be more portable.
And if the maintainers have to spend twice as long implementing it to be C++03-compatible and it isn't ready to be included in Boost until next year that also limits its usefulness, to *everyone* not just the C++03 crowd. One of the main aims of C++11 was "Make C++ a better language for systems programming and library building" so if "one of the most highly regarded and expertly designed C++ library projects in the world" can't benefit from those improvements then something's wrong. If the naysayers win out then maybe someone needs to start a new Boost that isn't stuck in the past and can innovate using the huge improvements in the current language that empower library writers.
On Jun 17, 2013, at 8:47 AM, Jonathan Wakely
On 17 June 2013 16:29, Andrey Semashev wrote:
I know, C++11 has many fancy features and all, and I'm all for its adoption too. But Boost also serves practical purpose, and if people can't use your library then that just limits its usefulness. So unless you trying to make some academic work here, the library should be more portable.
And if the maintainers have to spend twice as long implementing it to be C++03-compatible and it isn't ready to be included in Boost until next year that also limits its usefulness, to *everyone* not just the C++03 crowd.
I'd like to widen this discussion; it's shouldn't be "C++03" vs. "C++11" . The correct question is "How should boost support/deal with the changes in C++?" For a long time, that was C++03 (and TR1). Now we have C++11. A year from now, (seriously - next June) we will have C++14 - and some compilers have (partial) C++14 support today. What is the best way forward for the people who use and/or develop boost libraries? -- Marshall Marshall Clow Idio Software mailto:mclow.lists@gmail.com A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On 17 June 2013 16:47, Jonathan Wakely
And if the maintainers have to spend twice as long implementing it to be C++03-compatible and it isn't ready to be included in Boost until next year that also limits its usefulness, to *everyone* not just the C++03 crowd.
It's worse than that, they could easily loose the motivation to finish. Compatibility work is not an enjoyable programming task, and there are already more than enough hoops to go through to get a library into boost.
participants (8)
-
Andrey Semashev
-
Daniel James
-
Hartmut Kaiser
-
Jonathan Wakely
-
Marshall Clow
-
Michael Marcin
-
Niall Douglas
-
Robert Ramey