[c++11]

classic Classic list List threaded Threaded
71 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

[c++11]

Sid Sacek-3
This was probably discussed many times already, but I seem to not have been paying close enough attention.

Maybe someone can point me to the discussions in the archives...

With all of the cool new language features of C++11, am I correct in assuming that boost library developers have no real opportunity to use any of it in order to be backwards compliant with all the older standard?

I realize there are many boost equivalents already in place, but when would it become permissible to use native C++11 syntax?

Thanks,
-Sid


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [c++11]

Robert Jones-2
On 14 June 2013 10:35, Sid Sacek <[hidden email]> wrote:

>
> With all of the cool new language features of C++11, am I correct in
> assuming that boost library developers have no real opportunity to use any
> of it in order to be backwards compliant with all the older standard?
>
> I realize there are many boost equivalents already in place, but when
> would it become permissible to use native C++11 syntax?
>
>
Off the cuff I believe there's already plenty of native C++11 in Boost, but
under #ifdef control with as much alternative backward support as possible.
The discussion points are usually around how much and how best to provide
backward compatibility and how much is possible and practical.

- Rob.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [c++11]

Sid Sacek-3
-----Original Message-----
From: Boost [mailto:[hidden email]] On Behalf Of Robert Jones
Sent: Friday, June 14, 2013 5:46 AM
To: [hidden email]
Subject: Re: [boost] [c++11]

> Off the cuff I believe there's already plenty of native C++11 in Boost, but under #ifdef control
> with as much alternative backward support as possible.
> The discussion points are usually around how much and how best to provide backward compatibility
>
> and how much is possible and practical.
> - Rob.


If that is what coders are doing, it sounds pretty complicated.

Multiple #ifdef blocks of code that do the same thing, and combinations of code to build and test, and hope that it still all works when shipped. It could become #ifdef hell.

Sounds like it's not really worth the effort and simply just stick to the old style.
-Sid


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [c++11]

Antony Polukhin
2013/6/14 Sid Sacek <[hidden email]>:
<...>
> Sounds like it's not really worth the effort and simply just stick to the old style.

Stick to the old style. Add #ifndef'ed C++11 specific features if they
add functionality or improve performance much. Boost libraries are
tested using C++11 and C++03 on different compilers and works good in
all situations.

--
Best regards,
Antony Polukhin

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [c++11]

Phil Richards
In reply to this post by Robert Jones-2
On 14/06/2013 10:45, Robert Jones wrote:
> On 14 June 2013 10:35, Sid  Sacek <[hidden email]> wrote:
 >> With all of the cool new language features of C++11, am I correct
 >> in assuming that boost library developers have no real opportunity
 >> to use any of it in order to be backwards compliant with all the
 >> older standard?
 >>
 >> I realize there are many boost equivalents already in place, but
 >> when would it become permissible to use native C++11 syntax?
 > Off the cuff I believe there's already plenty of native C++11 in
 > Boost, but under #ifdef control with as much alternative backward
 > support as possible. The discussion points are usually around how
 > much and how best to provide backward compatibility and how much is
 > possible and practical.

I've sometimes pondered whether C++11 is the obvious point at which
Boost 2.x should start. And I think that the imminent move to Git may
make this a feasible idea... Or maybe I'm just being an idiot, I don't know.

Would it be possible to maintain a "boost1-mainline" (old c++, optional
c++11) and "boost2-mainline" (c++11, optional old c++) for each of the
sub-modules?

Obviously, for those modules that are compatible with both, the two
branches would permanently be in sync, but for other modules, the
"boost2-mainline" could (at the maintainers discretion) remove much of
the conditional compilation stuff, and also take advantage of C++11
features without having to worry about old compilers.

New features could be added to just the "boost2-mainline" without fear
that they will break (or need workarounds) for pre-C++11 compilers. A
maintainer *could* decide that all future work would only be ported to
the boost2, but the boost1 packaged releases would allow users of older
compilers to keep up-to-date with modules that are being kept in sync,
and bug fixes could still be applied.

In terms of testing: well, a compiler would (generally) fall into either
the boost1 or boost2 camp, so it shouldn't increase the testing
overheads above what they already are. I suppose there might be a desire
to test some of the more popular C++11 compilers against boost1 as well
as boost2, but I'm not sure how common that would be.

The biggest downside, and the one that I think is probably the reason
why this can't/won't happen, is that potentially this ends up
significantly increasing the release managers work load by having to
handle two releases instead of one. (And having been somebody who has
done that role in my day job, I do *not* underestimate the effort involved.)

And, of course, there is the risk of patches not being applied to both
(as is already occasionally seen with the current trunk versus release
branches).

I would suspect that at some point (as compiler support improves/old
compilers disappear), maintainers would end up just working on the
boost2 mainline, and the frequency of boost1 releases would reduce
significantly.

I realise it is very easy to come up with ideas that require other
people to do more work. These are just random thoughts, and I'm sure
other people have better ones. I suppose my questions are:
* Is doing this technically feasible?
* Is doing this actually desirable?
* Is doing this beneficial to the maintainers and/or the community?
* If yes to all (most of?) those: is it practical to do (in terms of
release manager load/testing etc), and if not, what could be done
(scripts, tools) to make it practical?

Sorry for being waffly, and sorry if these ideas have been proposed
before and rejected!

Phil
--
Phil Richards, <[hidden email]>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [c++11]

Andrey Semashev-2
On Friday 14 June 2013 11:40:35 Phil Richards wrote:
>
> Would it be possible to maintain a "boost1-mainline" (old c++, optional
> c++11) and "boost2-mainline" (c++11, optional old c++) for each of the
> sub-modules?

As a library maintainer, I wouldn't like doubling the maintenance effort and
forking the code into boost 1.x and 2.x. That, of course, implies that I want
to support C++03 compilers in my library (which I do, at least for a few years
from now).

IMHO, it would be much better to just state clearly the level of compatibility
for each library in the docs and the library list [1], so that this
information is immediately apperent to users. Library authors may choose to
drop support for older compilers as they see fit, in newer Boost release. I
think, this will make a more natural transition to C++11.

[1] http://www.boost.org/doc/libs/release/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [c++11]

Phil Richards
On 14/06/2013 11:53, Andrey Semashev wrote:
> On Friday 14 June 2013 11:40:35 Phil Richards wrote:
>> Would it be possible to maintain a "boost1-mainline" (old c++, optional
>> c++11) and "boost2-mainline" (c++11, optional old c++) for each of the
>> sub-modules?
> As a library maintainer, I wouldn't like doubling the maintenance effort and
> forking the code into boost 1.x and 2.x. That, of course, implies that I want
> to support C++03 compilers in my library (which I do, at least for a few years
> from now).
But, I think my point is, with the combination of breaking boost into
sub-modules, and using git, that, in your case, you wouldn't need to
fork your code base. The boost2 release would incorporate your (single)
mainline as a sub-module, as would the the boost1 release.

It's only if you wanted to support both separately that it would double
your maintenance effort, and that's assuming that you were trying to
implement the same functionality in both. And with git's cherry-picking
merges, any common code would be a lot easier to share between branches.
It is more likely a maintainer would draw a line under boost1 (except
bug-fixes), and do all new development on boost2. The testing system
would still test boost1 on appropriate platforms, and would catch any
incompatibilities that might get introduced.
> IMHO, it would be much better to just state clearly the level of compatibility
> for each library in the docs and the library list [1], so that this
> information is immediately apperent to users. Library authors may choose to
> drop support for older compilers as they see fit, in newer Boost release. I
> think, this will make a more natural transition to C++11.
The problem with this approach is that, as an end-user, you might find
that Boost 1.78 supports library X for C++03 (and contains features you
want), but the last version of Boost that supported library Y is 1.61.
Yes, you can roll your own set of modules, but then you are at the risk
of other modules being incompatible between versions.

As I said, it was just a thought,
Phil
--
Phil Richards, <[hidden email]>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [c++11]

Niall Douglas-2
In reply to this post by Sid Sacek-3
> 2013/6/14 Sid Sacek <[hidden email]>:
> <...>
> > Sounds like it's not really worth the effort and simply just stick to
the old style.
>
> Stick to the old style. Add #ifndef'ed C++11 specific features if they add
> functionality or improve performance much. Boost libraries are tested
using
> C++11 and C++03 on different compilers and works good in all situations.

Speaking of which, I was going to ask this list about the minimum compiler
requirements for proposed GSoC Boost.AFIO, so now is as good a time as any.

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.

The variadic templates used probably can be swapped out easily enough with
Boost Preprocessor generators. The very extensive use of C++11 only library
features could probably be replaced with Boost equivalents in most cases,
though we really do need a fully C++11 functional std::exception_ptr rather
than Boost's limited boost::exception_ptr.

The thing we probably can't replace without major surgery is rvalue
reference usage. It's used very extensively. Moreover, performance without
rvalues would truly suck.

So here's the question: is C++03 compiler and C++03 TR1 standard library
support still an absolute, unnegotiable requirement for a library to become
an official part of Boost? Or can we at least require rvalue reference
support as a minimum?

Or do we add a new category to Boost: some bits of C++11 requiring
libraries? We're going to have to do this eventually anyway.

Niall



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [c++11]

Lars Viklund
On Fri, Jun 14, 2013 at 04:21:38PM +0000, Niall Douglas wrote:

> > 2013/6/14 Sid Sacek <[hidden email]>:
> > <...>
> > > Sounds like it's not really worth the effort and simply just stick to
> the old style.
> >
> > Stick to the old style. Add #ifndef'ed C++11 specific features if they add
> > functionality or improve performance much. Boost libraries are tested
> using
> > C++11 and C++03 on different compilers and works good in all situations.
>
> Speaking of which, I was going to ask this list about the minimum compiler
> requirements for proposed GSoC Boost.AFIO, so now is as good a time as any.
>
> 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
library that targets only two compilers, and assumedly a rather narrow
set of OSes.

Was this C++11-only requirement part of the original project plan, and
why didn't anyone object to it then?

--
Lars Viklund | [hidden email]

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [c++11]

Jonathan Wakely-2
On 14 June 2013 18:53, Lars Viklund wrote:

> On Fri, Jun 14, 2013 at 04:21:38PM +0000, Niall Douglas wrote:
>>
>> 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
> library that targets only two compilers,

You make it sound like C++11 is going to disappear or be a temporary fad.
Other compilers will catch up at some point.

> and assumedly a rather narrow
> set of OSes.

Is there any compiler that targets more OSes than GCC?

In fact are there any OSes supported by Boost that GCC *doesn't* target?


> Was this C++11-only requirement part of the original project plan, and
> why didn't anyone object to it then?

Expecting authors of new libraries to refrain from using features of
the current C++ standard seems a bit ridiculous to me.  Not everyone
will be able to use C++11-only libraries, but why should those users
hold everyone else back?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [c++11]

Lars Viklund
On Fri, Jun 14, 2013 at 07:04:36PM +0100, Jonathan Wakely wrote:

> On 14 June 2013 18:53, Lars Viklund wrote:
> > On Fri, Jun 14, 2013 at 04:21:38PM +0000, Niall Douglas wrote:
> >>
> >> 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
> > library that targets only two compilers,
>
> You make it sound like C++11 is going to disappear or be a temporary fad.
> Other compilers will catch up at some point.
>
> > and assumedly a rather narrow
> > set of OSes.
>
> Is there any compiler that targets more OSes than GCC?

Even if GCC can target an OS, it's not always as suitable as the native
compiler on the OS, with the native runtime. There are also several
alternative C++03 compilers that serve special purposes. Should projects
needing their other features (excellent auto-vectorisation, etc.) have
to completely drop Boost due to an urge to constantly target the
bleeding edge.

> In fact are there any OSes supported by Boost that GCC *doesn't* target?

That depends on what you consider supported by Boost. A lot of the
courtesy support for the native compilers for many OSes out there seems
to be dying out.

> > Was this C++11-only requirement part of the original project plan, and
> > why didn't anyone object to it then?
>
> Expecting authors of new libraries to refrain from using features of
> the current C++ standard seems a bit ridiculous to me.  Not everyone
> will be able to use C++11-only libraries, but why should those users
> hold everyone else back?

I used to see Boost as an empowering library, enhancing and evening out
the playing field among the compilers out there.

Some seem to see it as a playground to gain recognition and fast-track
things into the coming standard libraries, instead of producing
something usable in the real world.

I guess it's losing the goal and aim I perceived, if it ever had it to
begin with. To me, it feels like a betrayal from the library I have
spent many manhours supporting.

I've been on this rant before on the lists, in the big sprawling
discussions about the feasibility of a Boost 2.0, but it seems nothing
was learned then, and I don't expect anything to be learned going
forward either.

As for limiting Boost authors, for leaf libraries that end users can
avoid, sure, there might not be too much harm. It's creeping into the
very core libraries as well, which _does_ bother me, as it can render
whole swaths of the library utterly unusable.

In the end, we need a definitive statement from whatever cabal is
controlling Boost, so we don't get these kinds of discussion
resurrections every few months. All this causes is a lack of faith in
the project.

--
Lars Viklund | [hidden email]

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [c++11]

Andreas Schäfer
Hi,

On 20:20 Fri 14 Jun     , Lars Viklund wrote:
> Even if GCC can target an OS, it's not always as suitable as the native
> compiler on the OS, with the native runtime. There are also several
> alternative C++03 compilers that serve special purposes. Should projects
> needing their other features (excellent auto-vectorisation, etc.) have
> to completely drop Boost due to an urge to constantly target the
> bleeding edge.

I'd like to add some examples here: if you work on any IBM big iron
(e.g. Blue Gene), then you're expected to use XL C++, on Cray it's
crayCC and finally Fujitsu ship their own compiler for their vector CPU
machines, too. Even if you use GCC, you might need to use an older
version, e.g. folks working with CUDA are currently tied to GCC 4.6.

Best
-Andreas


--
==========================================================
Andreas Schäfer
HPC and Grid Computing
Chair of Computer Science 3
Friedrich-Alexander-Universität Erlangen-Nürnberg, Germany
+49 9131 85-27910
PGP/GPG key via keyserver
http://www.libgeodecomp.org
==========================================================

(\___/)
(+'.'+)
(")_(")
This is Bunny. Copy and paste Bunny into your
signature to help him gain world domination!


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [c++11]

Nevin Liber
In reply to this post by Lars Viklund
On 14 June 2013 13:20, Lars Viklund <[hidden email]> wrote:

> I used to see Boost as an empowering library, enhancing and evening out
> the playing field among the compilers out there.
>

That's you.  I see Boost as a useful collection of libraries.

>
> Some seem to see it as a playground to gain recognition and fast-track
> things into the coming standard libraries, instead of producing
> something usable in the real world.
>

Fast-track??  Can you name even *one* library based on a version of Boost
that was fast-tracked (and the number of months it took from request for
review on Boost to acceptance in a C++0x draft) into C++11 (let alone not
usable in the real world)?  This sounds like fantasy.


> I guess it's losing the goal and aim I perceived, if it ever had it to
> begin with. To me, it feels like a betrayal from the library I have
> spent many manhours supporting.
>

Again, no one is stopping you from supporting C++03.


> As for limiting Boost authors, for leaf libraries that end users can
> avoid, sure, there might not be too much harm. It's creeping into the
> very core libraries as well, which _does_ bother me, as it can render
> whole swaths of the library utterly unusable.
>

Again, what are the concrete examples of this?  What previously useable
libraries are now "utterly unusable" because of C++11 support?
--
 Nevin ":-)" Liber  <mailto:[hidden email]>  (847) 691-1404

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [c++11]

Daniel James-2
In reply to this post by Niall Douglas-2
On 14 June 2013 17:21, Niall Douglas <[hidden email]> wrote:
> So here's the question: is C++03 compiler and C++03 TR1 standard library
> support still an absolute, unnegotiable requirement for a library to become
> an official part of Boost?

No.

http://www.boost.org/development/requirements.html#Portability

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [c++11]

Daniel James-2
In reply to this post by Andrey Semashev-2
On 14 June 2013 11:53, Andrey Semashev <[hidden email]> wrote:
>
> IMHO, it would be much better to just state clearly the level of compatibility
> for each library in the docs and the library list [1], so that this
> information is immediately apperent to users.

If you haven't noticed, I've removed some of the data from that list
because it was often incorrect. I'm not keen on adding extra data
until there's a decent system for people to update it. Hopefully the
module metadata thing that I mentioned recently might meet that need.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [c++11]

Lars Viklund
In reply to this post by Nevin Liber
(Do take some of the original reply with a bit of salt. It's something I
feel very strongly about, so some superlative and emotion will have
crept into my posting)

On Fri, Jun 14, 2013 at 02:00:29PM -0500, Nevin Liber wrote:
> On 14 June 2013 13:20, Lars Viklund <[hidden email]> wrote:
> > I guess it's losing the goal and aim I perceived, if it ever had it to
> > begin with. To me, it feels like a betrayal from the library I have
> > spent many manhours supporting.
> >
>
> Again, no one is stopping you from supporting C++03.

Support as in the end-user support and troubleshooting I provided for
years and years on IRC out of belief that a strong community and
responsive aid would help Boost.

Not all contribute through libraries, and thus, cannot affect the path
of the library in any way but discussion in the hope of aligning
intents.

I see a significant issue in that no-one with the power to do so has the
guts to make a solid decision, instead letting the library waffle along
without any overarching guidance in a situation that in my not so humble
opinion needs some proper action.

Deferring it to the benevolence of library authors might feel democratic
and all, but it puts a big burden on them to each make decisions that
in conjunction may not turn out well.

> > As for limiting Boost authors, for leaf libraries that end users can
> > avoid, sure, there might not be too much harm. It's creeping into the
> > very core libraries as well, which _does_ bother me, as it can render
> > whole swaths of the library utterly unusable.
> >
>
> Again, what are the concrete examples of this?  What previously useable
> libraries are now "utterly unusable" because of C++11 support?

You misread me. The last statement is speculative, about what I believe
is going to happen if we continue on this path of slowly going from
C++03 compatibility with a sprinkling of functionality that makes the
library equivalent but faster for people who happen to build on a C++11
compiler.

Pretty much anything that fakes variadics is under the constant pressure
to disregard compatibility and "just use variadic templates already".
Thankfully the authors of those libraries haven't folded.

Boost libraries are encouraged to use other Boost libraries to avoid
duplicating functionality, so once one library folds, the rest are
affected.

As a closing statement:
I'm not advocating staying on C++03 forever, that would be delusional.
I am, however, imploring that we need to sort out a common vision going
forward, with the support of the active maintainers, the Steering
Committee and the developer community. I don't see any bright future in
letting the transition just happen without a common plan, breaking the
world as it goes.

--
Lars Viklund | [hidden email]

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [c++11]

Jonathan Wakely-2
In reply to this post by Lars Viklund
On 14 June 2013 19:20, Lars Viklund wrote:

> On Fri, Jun 14, 2013 at 07:04:36PM +0100, Jonathan Wakely wrote:
>> On 14 June 2013 18:53, Lars Viklund wrote:
>> > On Fri, Jun 14, 2013 at 04:21:38PM +0000, Niall Douglas wrote:
>> >>
>> >> 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
>> > library that targets only two compilers,
>>
>> You make it sound like C++11 is going to disappear or be a temporary fad.
>> Other compilers will catch up at some point.
>>
>> > and assumedly a rather narrow
>> > set of OSes.
>>
>> Is there any compiler that targets more OSes than GCC?
>
> Even if GCC can target an OS, it's not always as suitable as the native
> compiler on the OS, with the native runtime. There are also several
> alternative C++03 compilers that serve special purposes. Should projects
> needing their other features (excellent auto-vectorisation, etc.) have
> to completely drop Boost due to an urge to constantly target the
> bleeding edge.

Those projects cannot possibly be using AFIO, since it isn't in Boost
yet, so why would they have to "completely drop Boost" if a library
they don't use is C++11-only?  Stop being melodramatic.

> I used to see Boost as an empowering library, enhancing and evening out
> the playing field among the compilers out there.

I don't see it as evening out differences at all. Even the name
suggests it's meant to offer *more* than the standard library, not
poorer functionality due to being stuck in the last decade.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [c++11]

Jonathan Wakely-2
In reply to this post by Andreas Schäfer
On 14 June 2013 19:41, Andreas Schäfer wrote:

> Hi,
>
> On 20:20 Fri 14 Jun     , Lars Viklund wrote:
>> Even if GCC can target an OS, it's not always as suitable as the native
>> compiler on the OS, with the native runtime. There are also several
>> alternative C++03 compilers that serve special purposes. Should projects
>> needing their other features (excellent auto-vectorisation, etc.) have
>> to completely drop Boost due to an urge to constantly target the
>> bleeding edge.
>
> I'd like to add some examples here: if you work on any IBM big iron
> (e.g. Blue Gene), then you're expected to use XL C++, on Cray it's
> crayCC and finally Fujitsu ship their own compiler for their vector CPU
> machines, too. Even if you use GCC, you might need to use an older
> version, e.g. folks working with CUDA are currently tied to GCC 4.6.

Sure. And how many of those folks are currently relying on Boost.AFIO
and so are affected by it being C++11-only?

Hint: the answer is less than one.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [c++11]

John Maddock
In reply to this post by Lars Viklund
> That depends on what you consider supported by Boost. A lot of the
> courtesy support for the native compilers for many OSes out there seems
> to be dying out.

That may well be due to lack of testing resources - Boost authors can only
suppport obscure compilers if we have someone running tests for them and/or
someone willing to supply patches.  For example I notice we don't have any
Intel test runnners at present which is a real shame...

>> > Was this C++11-only requirement part of the original project plan, and
>> > why didn't anyone object to it then?
>>
>> Expecting authors of new libraries to refrain from using features of
>> the current C++ standard seems a bit ridiculous to me.  Not everyone
>> will be able to use C++11-only libraries, but why should those users
>> hold everyone else back?
>
> I used to see Boost as an empowering library, enhancing and evening out
> the playing field among the compilers out there.
>
> Some seem to see it as a playground to gain recognition and fast-track
> things into the coming standard libraries, instead of producing
> something usable in the real world.

Ouch.  Boost has always been about championing the "next thing" and always
been ahead of the compiler curve, if that wasn't the case we'd still be
targetting VC6.  Yesterdays bleading edge is tomorrows mainstream.

> I guess it's losing the goal and aim I perceived, if it ever had it to
> begin with. To me, it feels like a betrayal from the library I have
> spent many manhours supporting.
>
> I've been on this rant before on the lists, in the big sprawling
> discussions about the feasibility of a Boost 2.0, but it seems nothing
> was learned then, and I don't expect anything to be learned going
> forward either.
>
> As for limiting Boost authors, for leaf libraries that end users can
> avoid, sure, there might not be too much harm. It's creeping into the
> very core libraries as well, which _does_ bother me, as it can render
> whole swaths of the library utterly unusable.

For example?

> In the end, we need a definitive statement from whatever cabal is
> controlling Boost, so we don't get these kinds of discussion
> resurrections every few months. All this causes is a lack of faith in
> the project.

Cabal?  Well that would be you then - you have as much say over Boost's
future direction as anyone else.

I hadn't noticed this discussion cropping up every few months either, but
then again I tend to file a lot of stuff in the "lifes too short" folder ;-)

John.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [c++11]

John Maddock
In reply to this post by Daniel James-2
> On 14 June 2013 17:21, Niall Douglas <[hidden email]> wrote:
>> So here's the question: is C++03 compiler and C++03 TR1 standard library
>> support still an absolute, unnegotiable requirement for a library to
>> become
>> an official part of Boost?
>
> No.
>
> http://www.boost.org/development/requirements.html#Portability

I suspect this may come down to the review ultimately: I can imagine that
any library that was C++11 only would have a hard time getting through
review "as is", *unless* there's a really compelling reason for it to be
that way (and for some libraries that may well be the case).  However, I can
also imagine a library being developed as a C++11 only lib and only ported
back to C++03 and/or less capable compilers once it's stable (or vice
versa).

John.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
1234