lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Fri, Jun 30, 2017 at 5:31 PM, ThePhD <jm3689@columbia.edu> wrote:

> When "nil" is present, only the forms [ 2a ] and [ 2e ] are valid ways of working with it. I am a little disappointed about [ 2d ], because it's a value and we should _reasonably_ be able to create a nullptr-containing object (default-constructed, as you say), but I cannot differentiate between someone asking for a reference std::shared_ptr, versus a value std::shared_ptr (it's a C++ quirk about conversions that would probably not be useful to fully discuss on the list). That means I can't construct something on the stack and then return it, because I would ultimately be returning a dangling reference when this conversion is done.

It sounds like the difficulty in instantiating a temporary smart pointer to represent the nil stands in the way of a good solution. I am afraid this is a C++ issue rather than a Lua issue. I had a brief look at your code, and I understand why a stack-based temporary would be difficult to inject.

I think, however, that you could still allocate a temporary on the heap in the stack_detail::call/eval chain. The record/tracking structure can keep track of those temporaries and deallocate them when done. You could probably optimise that by having a stack-based buffer (established in call()) for the first few temporaries, thus avoiding the heap overhead in the common case. I am less sure here, but your code seems to know all the C++ parameters expected at that point, which makes the max size of the stack based buffer known, thus allowing to dispense with heap allocation completely.

One interesting issue is how to construct the temporary. I said earlier that perhaps this could done using the default constructor. But it is also reasonable to believe that a constructor taking a nullptr could be used. Either way will break some user code that used parameter types non constructible in those ways, but such code was unsafe to begin with, while code using std pointers types will not be affected.

Anyway, I think that pushing nil is the right approach, and the above makes it possible to have automatic conversion from nil to empty smart pointers.

Cheers,
V.