Can addFunction support lambda?

[wenyg]

I want to pass some local variables from C++ to lua, but these variables can only be global variables.

This is what I want

void my_process(){
  std::string my_data;
  luabridge::getGlobalNamespace(L)
      .beginNamespace ("ctx")
          .addFunction("get", [&my_data](){ return my_data.c_str();})
          .AddFunction("set", [&my_data](const char *data){ my_data = std::string(data);})
      .endNamespace();
  // process my_data in lua
  luaL_dofile(L, "./test.lua"); 
  // now, my_data is the processed data
}

./test.lua like this

data = ctx.get()
-- do something in lua
ctx.set(processed_data)

What should I do to pass C++ local variables to Lua, and then get it from lua? Thank you very much

[kunitoki]

This is fully supported in https://github.com/kunitoki/LuaBridge3

[dmitry-t]

OK, once kunitoki's fork is fully compatible with the LuaBridge2, anybody can switch to the LuaBridge3.
@kunitoki Can you confirm your version is fully compatible?

[kunitoki]

It's not fully compatible, i made some design decisions that were needed to support using the library without exceptions (games you know, game developers are allergic to exceptions), so some stuff has changed. There is a long list of breaking changes and removals. See https://kunitoki.github.io/LuaBridge3/CHANGES

[dmitry-t]

I see. And I'd prefer C++17 :)

Most of code including older compiler support and e.g. addData are just for backward compatibility.

BTW the most unpleasant thing for one who wants to migrate from the LB2 to the LB3 is a different stack push signature. I guess this can be simplified by adding support for methods with the old signature using a meta-programming trick.
And you could also add the aliases like addData back and mark them [[deprecated]].
The only really breaking change then would be mandatory C++17 support which isn't really rare nowadays :)

[kunitoki]

I want to polish the library, i'm seeking of removing legacy. If one wants addData can work with the older lb2.

[kunitoki]

Yeah for the stack changes, i might introduce more changes, like rolling an own expected as return value http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0323r8.html