Re: Implementing std::dynarray [Fwd: C++14 implementation status]

[Lawrence Crowl <crowl at googlers dot com>]

On 6/13/13, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> Do you follow the libstdc++ mailing list?

No, I haven't been.

> There's a bit of a discussion starting about implementing dynarray,
> so I thought you might be able to give some valuable input.

My general view was that the library code only needed to deal
with heap allocation, and the compiler would recognize the places
where it could replace the constructors/destructors with alternate
implementations.

My detailed view was that the front end would generate code that:

 Computed the total size of the elements.  Compare the total size
 against a run-time defined maximum size.

 If the size is less than the maximum call an alternate constructor
 that uses the stack.  Otherwise, call the regular constructor.

 If the maximum size can change during the lifetime of a dynarray
 object, save the decision above somewhere.  Otherwise the decision
 can be recomputed from the size.

 On destruction, use the saved decision to call the appropriate
 destructor.

There are more constructors now than the proposal originally had.
So, the compiler's job would be simplified if instead it could
recognize an internal allocation function.  This is possible only
if the constructors are inlined and/or templates.  Whichever way
things went, the recognized function would likely need to be part
of the ABI.

> The sub-thread starts at
> http://gcc.gnu.org/ml/libstdc++/2013-06/msg00045.html
>
> On 13 June 2013 16:37, Gabriel Dos Reis wrote:
> > On Jun 13, 2013 Marc Glisse
> > > > allocation if the size request is too large for a stack
> > > > frame.  Finding a meaningful upper limit of stack frame
> > > > size might be a trick.
> > >
> > > I think 2048 bytes is a good start as a switch point between
> > > stack and heap ;-)
> >
> > Well, that is lot :-)
> >
> > Also, this is usually a per-user runtime environment variable...
> > I suspect we need to gather lot of information about what the
> > C-land does in these cases for VLAs.

My expectation was that implementations would provide an API for
the program to set the maximum size that they wanted on the stack.
The default could as well consult an environment variable.

-- 
Lawrence Crowl