On 10/31/2017 08:47 PM, Trevor Saunders wrote:
On Tue, Oct 31, 2017 at 11:38:48AM -0600, Jeff Law wrote:
On 10/31/2017 11:22 AM, Eric Botcazou wrote:
I don't see a reason not to other than a pretty small amount of work
each time we make a release.

I'm not sure it would be so small an amount of work, especially on non-Linux
platforms, so this would IMO divert our resources for little benefit.
Having done this for years on HPUX, yes, it takes more time than one
could imagine.  THen I went to work for a company that did this for
hpux, solaris, aix, irix and others and well, it was very painful.

I'm sure its a project one can spend arbitrary amounts of time on if one
wishes or is payed to do so.  That said I'm considering the scope here
limitted to running configure / make  / make install with the defaults
and taring up the result.  I'll admitt I've only done that on linux
where it was easy, but people do keep AIX and Solaris building and they
really are supposed to be buildable in a release.  However at some point
it can be less work to do this than to beat C++98 into doing what is
desired.
It sounds so easy, but it does get more complex than just build and tar the result up. How (for example) do you handle DSOs that may or may not be on the system where the bits get installed. Do you embed them or tell the user to go get them? That's just one example of a gotcha, there's many.

It's really not something I'd suggest we pursue all that deeply. Been there, done that wouldn't want to do it again.

Thirdly making it easier to work on the compiler and understand it makes
things easier for those possible contributors, so if being able to use
C++11 advances that goalthings could be better over all for possible
contributors with different system compilers.

I don't buy this at all.  You don't need bleeding edge C++ features to build a
compiler and people don't work on compilers to use bleeding edge C++.  Using a
narrow and sensible set of C++ features was one of the conditions under which
the switch to C++ as implementation language was accepted at the time.
Agreed that we need to stick with a sensible set of features.  But the
sensible set isn't necessarily fixed forever.

Also as a counter example what brought this thread up is Richard wanting
to use something from C++11.  So in that particular case it probably
would make something better.
In my particular case I could use certain C++11 features to make the code cleaner/easier to prove right -- particularly rvalue references and move semantics. I've got an object with a chunk of allocated memory. I want to move ownership of the memory to another object.

C++11 handles this cleanly and gracefully and in doing so makes it very hard to get it wrong.

However, I don't think my case, in and of itself, is enough to push us into the C++11 world. Nor am I convinced that the aggregate of these things is enough to push us into the C++11 world. But I do think we'll be there at some point.

jeff

Reply via email to