Re: [09/nn] Add a fixed_size_mode_pod class

[Trevor Saunders <tbsaunde@tbsaunde.org>]

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