On Wed, Nov 01, 2017 at 10:30:29AM -0600, Jeff Law wrote: > 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.
You may want to look at how the unique_ptr shim deals with that, though maybe you don't want to copy the ifdef hackery to actually use rval refs when possible. Trev > > 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
