luabind / luabind Goto Github PK

View Code? Open in Web Editor NEW

341.0 24.0 235.0 3.12 MB

Home Page: http://code.rasterbar.com/luabind

License: Other

Perl 1.10% CSS 0.88% C++ 96.51% Lua 1.15% PHP 0.08% JavaScript 0.29%

luabind's People

Contributors

Stargazers

Watchers

Forkers

rasterbar neomantra tsuckow rpavlik jlsandell fire-archive mikhainin acmorrow bbias mrapplejuice satofumi quarnster matsu911 skyostil thomasnelson devurandom oberon00 vilarion phere halmd-org imeteora wuhao5 gezidan adanselm lucryan chenyu2202863 hubolin vheuken authenticate totalgee wotan chenbk85 zachlindblad zester youngsoonpark dreamflywang glockenmeier chiur take-cheeze megatronx till-devel qq260327056 funixfu lowsar eagle-su sixten-hilborn chrisg0x20 starius elliottslaughter gaoxiaojun dailypipsgxj trepidjon evoxalien pzz2011 edson-gaspar rch otristan cd756819220 gaoyou wutzi15 zupm domain wyrover kaiqinetwork jameslinus amyvmiwei deeplearningsprint lijin1989422 seancaus weimingtom fast01 nvoronetskiy liangyaozhan shenlubin hinike liutianshui xiaoxf rootslinux blockchainmaster cutepig123 manhelp merlinxyoung onexianjian nizvoo malofficial metalmaxplus alexandrosk0 bigcat2f rongqf brinkqiang2lua zhklearn aleguna sillyamao motis-project shane0314 quabqi 375187588 hallgeirl 3137464563 cn00

luabind's Issues

Адская ошибка(FATALERROR) в компиляторе при использование out_value. Что делать?!!!

В стандартной версия luabind при использование out_value компилятор ВЫДАЁТ ОШИБКУ.
При компиляции S.T.A.L.K.E.R.
Примеру вот эту:


  void function(int &aa)
	{
		aa = 10;
	}
def("function", &function,out_value(_1)),

Ошибка C2352 luabind::native_converter_base<int,luabind::default_converter>::match: недопустимый вызов нестатической функции-члена StalkerEngine D:\GameDev\AgameA big sdk\include\luabind\out_value_policy.hpp 105

Я так понял что match не у всех классов статический.

Большому счастью есть способ исправить есть но он действует не на все типы.
Помогает при использование обычных переменных число или десятичная дробь и так далее.
В файле:
luabind\detail\policy.hpp
Заменить:

# define LUABIND_NUMBER_CONVERTER(type, kind) \
    template <> \
struct default_converter<type> \
  : native_converter_base<type> \
{ \
    int compute_score(lua_State* L, int index) \
    { \
        return lua_type(L, index) == LUA_TNUMBER ? 0 : -1; \
    }; \
    \
    type from(lua_State* L, int index) \
    { \
        return static_cast<type>(BOOST_PP_CAT(lua_to, kind)(L, index)); \
    } \
    \
    void to(lua_State* L, type const& value) \
    { \
        BOOST_PP_CAT(lua_push, kind)(L, BOOST_PP_CAT(as_lua_, kind)(value)); \
    } \
}; \
\

На:

# define LUABIND_NUMBER_CONVERTER(type, kind) \
    template <> \
struct default_converter<type> \
  : native_converter_base<type> \
{ \
    static int compute_score(lua_State* L, int index) \
    { \
        return lua_type(L, index) == LUA_TNUMBER ? 0 : -1; \
    }; \
    \
    type from(lua_State* L, int index) \
    { \
        return static_cast<type>(BOOST_PP_CAT(lua_to, kind)(L, index)); \
    } \
    \
    void to(lua_State* L, type const& value) \
    { \
        BOOST_PP_CAT(lua_push, kind)(L, BOOST_PP_CAT(as_lua_, kind)(value)); \
    } \
}; \
\

Заменить:

template <class T, class Derived = default_converter<T> >
struct native_converter_base
{
    typedef boost::mpl::true_ is_native;

    int const consumed_args(...)
    {
        return 1;
    }

    template <class U>
    void converter_postcall(lua_State*, U const&, int)
    {}

    int match(lua_State* L, detail::by_value<T>, int index)
    {
        return derived().compute_score(L, index);
    }

    int match(lua_State* L, detail::by_value<T const>, int index)
    {
        return derived().compute_score(L, index);
    }

    int match(lua_State* L, detail::by_const_reference<T>, int index)
    {
        return derived().compute_score(L, index);
    }

    T apply(lua_State* L, detail::by_value<T>, int index)
    {
        return derived().from(L, index);
    }

    T apply(lua_State* L, detail::by_value<T const>, int index)
    {
        return derived().from(L, index);
    }

    T apply(lua_State* L, detail::by_const_reference<T>, int index)
    {
        return derived().from(L, index);
    }

    void apply(lua_State* L, T const& value)
    {
        derived().to(L, value);
    }

    Derived& derived()
    {
        return static_cast<Derived&>(*this);
    }
};

На:

template <class T, class Derived = default_converter<T> >
struct native_converter_base
{
    typedef boost::mpl::true_ is_native;

    int const consumed_args(...)
    {
        return 1;
    }

    template <class U>
    void converter_postcall(lua_State*, U const&, int)
    {}

    static int match(lua_State* L, detail::by_value<T>, int index)
    {
        return Derived::compute_score(L, index);
    }

	static int match(lua_State* L, detail::by_value<T const>, int index)
    {
        return Derived::compute_score(L, index);
    }

	static int match(lua_State* L, detail::by_const_reference<T>, int index)
    {
        return Derived::compute_score(L, index);
    }

    T apply(lua_State* L, detail::by_value<T>, int index)
    {
        return derived().from(L, index);
    }

    T apply(lua_State* L, detail::by_value<T const>, int index)
    {
        return derived().from(L, index);
    }

    T apply(lua_State* L, detail::by_const_reference<T>, int index)
    {
        return derived().from(L, index);
    }

    void apply(lua_State* L, T const& value)
    {
        derived().to(L, value);
    }

    Derived& derived()
    {
        return static_cast<Derived&>(*this);
    }
};

args not popped from stack after trying to use unregistered class

I'm using luabind0.9.1 on Ubuntu natty x86_64.

If you repeatedly use luabind::call_function but attempt to pass an object which has not been luabound, resulting in a "Trying to use unregistered class" exception, the arguments already pushed on the lua virtual stack are not cleaned up during the exception unwind. As a result, the arguments are leaked and remain on the stack forever.

If you repeatedly attempt to invoke the function, the stack will eventually overflow. Here is a condensed test case that demonstrates the problem:

extern "C" {
#include <lualib.h>
}

#include <cassert>
#include <cstdio>

#include <luabind/luabind.hpp>
#include <luabind/class_info.hpp>

class HasNoLuaBindings {
public:
    HasNoLuaBindings() {}
};

int main(int argc, char* argv[])
{
    lua_State* state = luaL_newstate();
    luaL_openlibs( state );

    luabind::open( state );
    luabind::bind_class_info( state );

    static const char lua_code[] =
        "callme = function(arg1, arg2)" "\n"
        "\t" "print('called with ' .. tostring(arg1) .. ' and ' .. tostring(arg2))" "\n"
        "end" "\n"
        "print('loaded ok')" "\n";

    int status = luaL_loadbuffer( state, lua_code, sizeof(lua_code) - 1, "chunkybacon" );
    assert( status ==  0 );
    lua_pcall(state, 0, 1, 0);
    lua_pop(state, 1);

    luabind::table<> root = luabind::object_cast< luabind::table<> >(luabind::globals(state));
    assert(root);

    const luabind::object callme = root["callme"];
    assert(callme);
    assert(luabind::type(callme) == LUA_TFUNCTION);

    const HasNoLuaBindings bad_object;

    for(size_t i = 0; true; ++i)
    {
        printf("[iteration %zd], Calling 'callme', expecting exception\n", i);

        try
        {
            luabind::call_function<luabind::object>(
                callme,
                i, boost::cref(bad_object));

            printf("[iteration %zd], FAILED to get expected exception\n", i);
            assert( false );
        }
        catch(...)
        {
            printf("[iteration %zd], got expected exception\n", i);
        }
    }

    return 0;
}

On my system, I compiled and linked this as:

g++ -g ./stack_killer.cc -I /usr/include/lua5.1/ -lluabind -llua5.1

If you run the resulting a.out, it will crash with a segfault after some number of iterations. Valgrind says this is a result of an invalid write while pushing a new value on to the (now full) stack:


==7081== Invalid write of size 4
==7081==    at 0x4C48EF2: lua_pushlstring (lapi.c:448)
==7081==    by 0x403EE5: luabind::detail::class_rep* luabind::detail::get_pointee_class<HasNoLuaBindings const*>(lua_State*, HasNoLuaBindings const* const&, unsigned long) (make_instance.hpp:54)
==7081==    by 0x403CB9: void luabind::detail::make_instance<HasNoLuaBindings const*>(lua_State*, HasNoLuaBindings const*) (make_instance.hpp:76)
==7081==    by 0x403C35: void luabind::detail::make_pointee_instance<HasNoLuaBindings const>(lua_State*, HasNoLuaBindings const&, mpl_::bool_<false>, mpl_::bool_<false>) (policy.hpp:189)
==7081==    by 0x403BF3: void luabind::detail::make_pointee_instance<HasNoLuaBindings const, mpl_::bool_<false> >(lua_State*, HasNoLuaBindings const&, mpl_::bool_<false>) (policy.hpp:195)
==7081==    by 0x403B54: void luabind::detail::const_ref_converter::apply<HasNoLuaBindings>(lua_State*, HasNoLuaBindings const&) (policy.hpp:435)
==7081==    by 0x403A25: void luabind::detail::convert_to_lua<boost::reference_wrapper<HasNoLuaBindings const> >(lua_State*, boost::reference_wrapper<HasNoLuaBindings const> const&) (convert_to_lua.hpp:73)
==7081==    by 0x4037EB: void luabind::detail::push_args_from_tuple<2>::apply<boost::reference_wrapper<HasNoLuaBindings const> const*, boost::tuples::null_type>(lua_State*, boost::tuples::cons<boost::reference_wrapper<HasNoLuaBindings const> const*, boost::tuples::null_type> const&) (object.hpp:1079)
==7081==    by 0x4034ED: void luabind::detail::push_args_from_tuple<1>::apply<unsigned long const*, boost::tuples::cons<boost::reference_wrapper<HasNoLuaBindings const> const*, boost::tuples::null_type> >(lua_State*, boost::tuples::cons<unsigned long const*, boost::tuples::cons<boost::reference_wrapper<HasNoLuaBindings const> const*, boost::tuples::null_type> > const&) (object.hpp:1080)
==7081==    by 0x402F79: luabind::detail::proxy_function_caller<luabind::adl::object, boost::tuples::tuple<unsigned long const*, boost::reference_wrapper<HasNoLuaBindings const> const*, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> >::~proxy_function_caller() (call_function.hpp:91)
==7081==    by 0x40208D: main (stack_killer.cc:52)
==7081==  Address 0x5ba6978 is 8 bytes after a block of size 720 alloc'd
==7081==    at 0x402BED4: malloc (vg_replace_malloc.c:236)
==7081==    by 0x402C142: realloc (vg_replace_malloc.c:561)
==7081==    by 0x4C5138B: luaM_realloc_ (lmem.c:79)
==7081==    by 0x4C54EA6: stack_init (lstate.c:49)
==7081==    by 0x4C54F71: f_luaopen (lstate.c:73)
==7081==    by 0x4C4D736: luaD_rawrunprotected (ldo.c:116)
==7081==    by 0x4C54E2E: lua_newstate (lstate.c:182)
==7081==    by 0x4C5939E: luaL_newstate (lauxlib.c:648)
==7081==    by 0x401EB1: main (stack_killer.cc:18)

Luabind should properly undo the modifications to the virtual stack if an error occurs before the dispatch to lua occurs.

If you set a breakpoint in gdb after each invocation of the function you can observe the lua stack directly:

$ gdb ./a.out 
Reading symbols from a.out...expanding to full symbols...done.
(gdb) break 59
Breakpoint 1 at 0x40210b: file ./stack_killer.cc, line 59.
(gdb) add-symbol-file /usr/lib/debug/usr/lib/liblua5.1.so.0.0.0 0
add symbol table from file "/usr/lib/debug/usr/lib/liblua5.1.so.0.0.0" at
    .text_addr = 0x0
(y or n) y
Reading symbols from /usr/lib/debug/usr/lib/liblua5.1.so.0.0.0...expanding to full symbols...done.
(gdb) sta
Temporary breakpoint 2 at 0x401ead: file ./stack_killer.cc, line 18.
Starting program: a.out 

Temporary breakpoint 2, main (argc=..., argv=...) at ./stack_killer.cc:18
18      lua_State* state = luaL_newstate();
(gdb) n
(gdb) print state->base
$5 = (StkId) 0x409520
(gdb) print state->top
$6 = (StkId) 0x409520
(gdb) c
...
(gdb) c
Continuing.
[iteration 20], got expected exception
[iteration 21], Calling 'callme', expecting exception

Breakpoint 1, main (argc=..., argv=...) at ./stack_killer.cc:59
59              printf("[iteration %zd], got expected exception\n", i);
(gdb) print state->base
$53 = (StkId) 0x409520
(gdb) print state->base + state->stacksize
$54 = (TValue *) 0x4097f0
(gdb) print state->top
$55 = (StkId) 0x4097e0
(gdb) c
Continuing.
[iteration 21], got expected exception
[iteration 22], Calling 'callme', expecting exception

Breakpoint 1, main (argc=..., argv=...) at ./stack_killer.cc:59
59              printf("[iteration %zd], got expected exception\n", i);
(gdb) print state->base
$56 = (StkId) 0x409520
(gdb) print state->base + state->stacksize
$57 = (TValue *) 0x4097f0
(gdb) print state->top
$58 = (StkId) 0x409800
(gdb) c
Continuing.
[iteration 22], got expected exception
[iteration 23], Calling 'callme', expecting exception

Breakpoint 1, main (argc=..., argv=...) at ./stack_killer.cc:59
59              printf("[iteration %zd], got expected exception\n", i);
(gdb) print state->base
$59 = (StkId) 0x409520
(gdb) print state->base + state->stacksize
$60 = (TValue *) 0x4097f0
(gdb) print state->top
$61 = (StkId) 0x409820

As you can see, the stack has overflowed because it was not unwound during the exception propagation.

Warning: type qualifiers ignored on function return type [-Wignored-qualifiers]|

Warnings when compiling using GCC 4.7.1 on the 0.9 branch.

On files:
luabind\detail\policy.hpp
luabind\adopt_policy.hpp
...

they can easily be suppressed by changing this:

int const consumed_args(...)

to that:
int consumed_args(...) const

So please, at least answer me so I can provide a patch.

More then 10 arguments to a method

I'm binding a class from a library i'm using (i can't change the method of that class). This class can be derived from in lua so i'm using the method mentioned in the Documentation of luabind (using default_* static functions). Now i have methods that have more then 10 parameters, i can't bind them, looking over the internet i couldn't find a solution to this problem, is it possible to do at all ?

Wrapping my method parameters in a structure would be an option, but that changes the bound method and the method never gets called (as it says in the documentation the parameter list must match)

Any solutions for this issue ?

The virtual functioin with custom type param just can be called 125 times.

I have a problem.
There is a virtual function that be exported to lua by luabind. When I haven't overwrite the virtual function in lua, it will debacle. The virtual functioin with custom type param just can be called 125 times.
This problem happened beacuse the times of call function is too much possibly .
This is my code:

struct Point
{
	int x;
	int y;
};

class Base
{
public:

	virtual void f(Point* pt)
	{
		printf("Base:f [%d, %d] \n", pt->x, pt->y); 
	}
};

struct Base_wrap : Base, luabind::wrap_base
{
	virtual void f(Point* var)
	{
		luabind::call_member<void>(this, "f", var);
	}

	static void default_f(Base* p, Point* var)
	{
		p->Base::f(var);
	}
};

Base* g_BaseHandle = NULL;

void SetDelegator(Base* handle)
{
	g_BaseHandle = handle;
}

lua_State *L;

int main()
{
	L = ::luaL_newstate(); 
	luaL_openlibs(L);
	luabind::open(L);
	luabind::module(L)
		[
			luabind::class_<Point>("Point")
			.def(luabind::constructor<>())
			.def_readwrite("x", &Point::x)
			.def_readwrite("y", &Point::y)
			,

			luabind::class_<Base, Base_wrap>("Base")
			.def(luabind::constructor<>())
			.def("f",		&Base::f,		&Base_wrap::default_f),

			luabind::def("SetDelegator", &SetDelegator)
		];

	// lua codes
	// LuaClass in lua codes is inherited from Base in cpp codes.
	// But LuaClass doesn't overwrite the virtual function f()
	luaL_dostring(L,"class 'LuaClass' (Base) \
						function LuaClass:__init()	\
							Base.__init(self) \
						end \
					SetDelegator(LuaClass()) \
					");

	while (g_BaseHandle != NULL)
	{
		Point pt;
		pt.x = 101;
		pt.y = 102;
		static int i = 0;
		printf("This is call f() %d times.\n", i++);

		// The virtual functioin with custom type param just can be called 125 times.
		g_BaseHandle->f(&pt);
	}

	::lua_close(L);

	getchar();

	return true;
}

class_rep::add_base_class should throw on attempt to derive from unregistered

Currently, luabind::detail::class_rep::add_base_class asserts that the base class has already been registered, and includes a helpful comment explaining the situation:

    // If you hit this assert you are deriving from a type that is not registered
    // in lua. That is, in the class_<> you are giving a baseclass that isn't registered.
    // Please note that if you don't need to have access to the base class or the
    // conversion from the derived class to the base class, you don't need
    // to tell luabind that it derives.
    assert(binfo.base && "You cannot derive from an unregistered type");

However, in builds of luabind where this assertion is compiled out, attempts to register classes when the appropriate base classes have not been registered will result in a segfault. I believe that the debian luabind packages are compiled this way.

If possible, this assertion should be changed to throwing a std::exception so that library users will get a runtime error explaining the problem, rather than a mysterious crash.

luabind::def(char const*, F) failed to compile on VS 2013 Update 3 when F takes zero arguments.

Any code like my example below used to compile, but now fails with the latest luabind source. Looks like the def() function ends up attempting to instantiate luabind::detail::invoke_actual() which contains some code like this:

if (arity == arguments)
{
int const scores[] = {
compute_score(L, converters, indices[Indices + 1])...
};

However, a function passed to def() with zero arguments produces an invalid array.

Code to reproduce the problem:

class MyClass
{
public:
static int GetCount() { return 1; }
};

// Later

module(L)
[
class_< MyClass, shared_ptr >("MyClass").scope
[
def("GetCount", &MyClass::GetCount)
]
];

Incorrect order of arguments

I'm pretty sure there is a bug in the order of arguments passed here:

https://github.com/luabind/luabind/blob/master/src/inheritance.cpp#L193

I think it should be:

m_cache.put(src, target, dynamic_id, object_offset, -1, cache::invalid);

The cache::invalid value only makes sense as a std::ptrdiff_t and the compiler accepts the wrong order because of implicit type casting of integer types.

I've copied a lot of luabind code for my own binding library 'clbind' in clasp (https://github.com/clasp-developers/clasp.git) - a Common Lisp that interoperates with C++.

Segmentation fault - objects created by a coroutine.

I've found that objects (class instances) created by a Lua coroutine will cause a segfault when garbage collected by the main thread, unless the coroutine releases the objects and forces a garbage collection before it ends. This I guess is happening as the coroutine thread no longer exists, and the object has some connection to it, which is needed at destruction. I'm not sure how hard this would be to change to always create objects against the main thread.

Here is a small program which shows the problem.

#include <iostream>
#include <lua.hpp>
#include <luabind/luabind.hpp>

using namespace luabind;

class test
{
public:
    test()
    {
        std::cout << "test constructor" << std::endl;
    }
    ~test()
    {
        std::cout << "test destructor" << std::endl;
    }
};

int main()
{
    lua_State *L;

    L = lua_open();

    luaL_openlibs( L );

    luabind::open(L);

    module(L)
    [
        class_<test>("myclass")
        .def(constructor<>())
    ];

    if( luaL_dostring( L, 
                "function func()\n"
                "    instance = myclass()\n"
                "    print'Instance created'\n"
                "end\n"
                "function test()\n"
                "    co = coroutine.wrap(func)\n"
                "    co()\n"
                "    instance = nil\n"
                "    print 'Instance no longer referenced'\n"
                "end\n"
                "for i=1,100 do test() end\n"
                ))
    {
        object error( from_stack( L, 1 ) );
        std::cout << error << std::endl;
    }

    lua_close( L );
}

luabind fails to build with boost 1.57

luabind fails to build with boost 1.57.

The errors look like:

In file included from src/class.cpp:30:
In file included from ./luabind/class.hpp:93:
In file included from ./luabind/back_reference.hpp:27:
In file included from ./luabind/wrapper_base.hpp:31:
In file included from ./luabind/detail/call_member.hpp:34:
./luabind/object.hpp:556:3: error: no matching function for call to 'operator=='
  LUABIND_OPERATOR_ADL_WKND(==)

Here are full build logs.

`def` does not work for lambda functions

def seems not to be working for lambda functions, i.e. the following does not work, but should:

const auto foo = []{};

module(lua_state)[
    def("foo", foo)
]

The following does work:

void foo () {};

module(lua_state)[
    def("foo", foo)
]

(Specifying the template works, but this should not be necessary:)

const auto foo = []{};

module(lua_state)[
    def<void()>("foo", foo)
]

patch to fix compilation error on gcc 4.4.1

Nothing huge, just one file: class.cpp The compiler didn't like the var with the same name as its type.

*** class.cpp   2009-11-12 14:36:14.023942385 +1300
--- class.cpp.old   2009-11-12 14:34:41.311948311 +1300
***************
*** 242,251 ****
      }

      void class_base::init(
!         type_id const& typeId, class_id id
        , type_id const& wrapper_type, class_id wrapper_id)
      {
!         m_registration->m_type = typeId;
          m_registration->m_id = id;
          m_registration->m_wrapper_type = wrapper_type;
          m_registration->m_wrapper_id = wrapper_id;
--- 242,251 ----
      }

      void class_base::init(
!         type_id const& type_id, class_id id
        , type_id const& wrapper_type, class_id wrapper_id)
      {
!         m_registration->m_type = type_id;
          m_registration->m_id = id;
          m_registration->m_wrapper_type = wrapper_type;
          m_registration->m_wrapper_id = wrapper_id;

anonymous namespace warnings

I'm getting the following warnings when compiling Luabind on GCC 4.1.2:
luabind/src/class.cpp:62: warning: 'luabind::detail::class_registration' has a field 'luabind::detail::class_registration::m_casts' whose type uses the anonymous namespace
luabind/src/inheritance.cpp:109: warning: 'luabind::detail::cast_graph::impl' has a field 'luabind::detail::cast_graph::impl::m_vertices' whose type uses the anonymous namespace
luabind/src/inheritance.cpp:109: warning: 'luabind::detail::cast_graph::impl' has a field 'luabind::detail::cast_graph::impl::m_cache' whose type uses the anonymous namespace

Are these warnings something to be worried about? Can they be silenced/fixed somehow?

Enable "custom" tostring operators

In cases where an existing operator<< doesn't exist or is unsuitable for use in this way, it would be good to be able to optionally pass a function, taking a (reference/const reference/pointer/pointer to const) and returning a string.

Right now this can kind of be "hacked" into place with something like this above the binding:

namespace luabind {
    static inline std::string tostring_operator(CLASSNAME const& val) {
         /// your code here
         return s;
    }
}

which will be preferentially selected over the function template in operators.hpp, but it's not pretty or particularly expressive.

Luabind can't be built using xcode 4 ( Apple's LLVM 2.0)

Hello, luabind fails to build using Apple's LLVM 2.0, it throws a lot of semantic issues, and a lot of compiler errors.

Maybe it's not a luabind issue itself, or maybe it is and GCC was being permissive about it.

This isn't a part of the Lua library by default

WARNING: Not an actual code issue.

This makes Lua so much easier to use, I'm amazed the Lua project hasn't adopted this into their code base. Manually creating wrappers using just what Lua gives you is terrible. This project has saved me so much time, and contains such a small code base! I'm not sure how to go about it, but we need to figure out a way to convince the Lua project maintainers to integrate this automatic wrapping into their code.

shared_ptr use_count corruption

Luabind causes a shared_ptr corruption when you do this in lua:

local gSharedObject = nil;
function Testfunction()
    gSharedObject = SharedObject.Create();
    return gSharedObject;
end

where the C++ export looks like that:

class SharedObject {
public:
    SharedObject() {}

    static boost::shared_ptr<SharedObject> Create() {
        return boost::make_shared<SharedObject>();
    }
}

luabind::module(L) [
    luabind::class_<SharedObject, boost::shared_ptr<SharedObject>>("SharedObject")
        .scope [ luabind::def("Create", &SharedObject::Create) ]
];

Now when you do the following you will get a use_count == 1 where it should actually be 2 because lua should hold a shared_ptr and your code should:

boost::shared_ptr<SharedObject> obj = luabind::call_function<boost::shared_ptr<SharedObject>>(L, "Testfunction");
std::cout << obj.use_count() << std::endl;
// prints 1 but should actually be 2, one from the current scope and one in lua globals, because the lua state is still alive... ?!?

This is a huge problem when your GC runs because it always thinks the shared_ptr is the only one in use and it will always release objects created like that, not matter if a ptr is used by the c++ code atm.

Example:

boost::shared_ptr<SharedObject> obj = luabind::call_function<boost::shared_ptr<SharedObject>>(L, "Testfunction");
std::cout << obj.use_count() << std::endl;

lua_close(L); // invokes ~SharedObject -_-

std::cout << obj.use_count() << std::endl; // still 1

The problem exists in lua 5.1 and 5.2, everywhere I checked

CentOS package?

Could we get a CentOS package published for luabind? I'm trying to build vera++ for CentOS, and I'm not sure whether to disable Lua support in vera++ while waiting for luabind and luabind-devel to come to CentOS, or what.

Memory leak on luabind::call_function

Is this project still active? It seems there is memory leak on luabind::call_function, but still not fix yet.

To replicate this issue, just call this function with empty lua function in script. The memory keep on increase by 4k. Any one has any solution for this?

I found an old question on sourceforge, but no one follow up on the solution. [https://sourceforge.net/p/luabind/mailman/luabind-user/thread/1342019800.9006.YahooMailClassic%40web130206.mail.mud.yahoo.com/#msg29526914]

The luabind repository is a complete mess

Hi there,

Sorry, I hate to add things that negative, especially as a title, but this is just stating the truth.

The 0.9 branch has got patches to add lua5.2 support thanks to the luabind debian maintainer AFAIK.
and those patches are part of master.
The master branch has got preliminary support from for c++0x but it's not really done unfortunately.
Several people, and especially @rpavlik have made custom forks with many improvements, and several have proposed PR, but most of those never get answered.

I know what it is to develop a spare-time project and what it takes to make it keep going.
So I'd like a frank answer:
Luabind is a very powerful tool when used correctly. Thus, are you guys planning to keep working on it, or are you needing help for anything? Have you got plans for it, a roadmap by any chance?
I'm sure many people around including myself would gladly help testing/rebasing and whatever is needed to clean the current project state. Maybe asking someone worthy and volunteering for the general project management would be cool as well.

Best regards,

luabind/detail/index_tuple.hpp is missing from the repository

When compiling with C++11 the LUABIND_CPP0x flag gets enabled. This includes call_0x.hpp which references the above file which doesn't exist.

Revive project / transfer ownership to one of the active developers?

Hi,

there are several developers that try to keep luabind alive. Is it possible to transfer admin rights / ownership of this repository to one of these developers (maybe rpavlik)? This would help in synchronising efforts in adapting luabind to changes in C++ and Lua.

Regards,

Please support tr1

std::shared_ptr etc should be supported. Maybe with a macro. What do you think?