Re: [09/nn] Add a fixed_size_mode_pod class

[Jeff Law <law@redhat.com>]

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