Date: Mon, 14 Aug 2023 13:16:44 -0400
On Mon, Aug 14, 2023 at 12:24 PM Henry Miller via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
>
>
> On Mon, Aug 14, 2023, at 06:44, Frederick Virchanza Gotham via Std-Proposals wrote:
> > To my knowledge, there has never been a C++ compiler for a processor
> > that doesn't have a stack.
> >
> > You can find some C compilers for some very small microcontrollers
> > that don't have a stack, but not C++.
>
> > And also how about we standardise the function "alloca" which allows
> > us to allocate bytes on the stack? For those not familiar with
> > 'alloca', here's the Linux manual entry:
>
> I'd prefer the standard allow/require unique_ptr, shared_ptr, make_unique, make_shared (and others) to implement automatic storage of T within the size allocated on the stack for the pointer if it meets some criteria.
Or you could just have a specific type for doing that.
That way, you also avoid the issue of lying to the user. `unique_ptr`
says that the object is owned by the `unique_ptr`. This means that
ownership can be transferred anywhere *without limit*. `shared_ptr`
says that ownership is *shared* by any holders of a copy of the
`shared_ptr`, without limit. What you want violates the "without
limit" provision that is a core part of the interface of these types.
Also, a smart pointer representing an object on the stack is just...
an object on the stack. Why confuse things with a smart pointer? If
you need to control when it gets initialized (so that it can be
initialized in different ways based on some logic), use `optional<T>`
or an immediately-invoked lambda or something.
<std-proposals_at_[hidden]> wrote:
>
>
>
> On Mon, Aug 14, 2023, at 06:44, Frederick Virchanza Gotham via Std-Proposals wrote:
> > To my knowledge, there has never been a C++ compiler for a processor
> > that doesn't have a stack.
> >
> > You can find some C compilers for some very small microcontrollers
> > that don't have a stack, but not C++.
>
> > And also how about we standardise the function "alloca" which allows
> > us to allocate bytes on the stack? For those not familiar with
> > 'alloca', here's the Linux manual entry:
>
> I'd prefer the standard allow/require unique_ptr, shared_ptr, make_unique, make_shared (and others) to implement automatic storage of T within the size allocated on the stack for the pointer if it meets some criteria.
Or you could just have a specific type for doing that.
That way, you also avoid the issue of lying to the user. `unique_ptr`
says that the object is owned by the `unique_ptr`. This means that
ownership can be transferred anywhere *without limit*. `shared_ptr`
says that ownership is *shared* by any holders of a copy of the
`shared_ptr`, without limit. What you want violates the "without
limit" provision that is a core part of the interface of these types.
Also, a smart pointer representing an object on the stack is just...
an object on the stack. Why confuse things with a smart pointer? If
you need to control when it gets initialized (so that it can be
initialized in different ways based on some logic), use `optional<T>`
or an immediately-invoked lambda or something.
Received on 2023-08-14 17:16:56