call to sel::tie result in second call to lua function on destruct

[phand00]

Let say we have a simple lua function like this:

Lua:

function test(id)
    print("Test")

    local result = id
    local str = "In Lua: ..."

    print("content of result item: "..item)
    print("Content of str: "..str)

    return result, str
end

In C:

auto result = state["test"](400);
sel::tie(rc, str) = result;

on the console we see the second call to the lua when result get out of scope (destruct) console:

Test
content of id: 400
Content of str: In Lua: ...
Test
content of id: 400
Content of str: In Lua: ...

just to give more information. I'm running my test in visual Studio 2013 in debug mode. Any idea how to correct this? If the result isn't a tuple, we don't see the second call.

I'm running my test in Visual Studio 2013 in debug mode.

Thanks for your help.

[phand00]

I looked to the code and here is what I think should solve it:

In Selector.h

template <typename... Ret>
    std::tuple<Ret...> GetTuple() const {
        _traverse();
        _get();
        if (_functor) {                                       -- line added
            _functor(sizeof...(Ret));
            _functor = nullptr;                               -- line added
        }                                                     -- line added 
        return detail::_pop_n_reset<Ret...>(_state);
    }

Does my solution to the problem look correct?

[jeremyong]

The problem you're encountering is very similar to the problem you'd encounter when using auto with a data structure like std::vector<bool>. The problem is that the type of auto result is not actually the std::tuple but a sel::selector type I believe which causes the selector to get copied. I think the safest way to handle this is to not use auto with the selector semantics here, in the same way that usage of auto with std::vector<bool> is discouraged. Both sel::selector and std::vector<bool> use proxy objects as intermediate representations of the final result. A better option might be to disable copy construction since that seems to have unintended side-effects. Does this explanation make sense?

[AnonymousProgrammerLandau]

The code in Selector.h you are referring to seems to stem from the tagged version v0.4. Since then there have been corrections in master. One fixed issue I remember was actually the one you describe. In addition to the suggestions from jeremyong you might want to try a more recent version from master.

[phand00]

Hi Jeremyong,

if I don't use the auto, I still have 2 call to the lua function.

Anonymous, I saw that there is a lot of new stuff in the master and the code change a lot. I tried the new master but it wasn't working with VS 2013 since default (copy move constructor) is not supported. Today, I'll try VS 2015 and see if it's ok since the VS 2015 seems to support C++11 and the default keyword. I'll let it know over here.

Thanks.