Sol3 (sol2 v3.0) - a C++ <-> Lua API wrapper with advanced features and top notch performance - is here, and it's great! Documentation:

sol2

Documentation Status

sol2 is a C++ library binding to Lua. It currently supports all Lua versions 5.1+ (LuaJIT 2.0+ and MoonJIT included). sol2 aims to be easy to use and easy to add to a project. The library is header-only for easy integration with projects, and a single header can be used for drag-and-drop start up.

Sneak Peek

#include <sol/sol.hpp>
#include <cassert>

int main() {
    sol::state lua;
    int x = 0;
    lua.set_function("beep", [&x]{ ++x; });
    lua.script("beep()");
    assert(x == 1);
}
#include <sol/sol.hpp>
#include <cassert>

struct vars {
    int boop = 0;
};

int main() {
    sol::state lua;
    lua.new_usertype<vars>("vars", "boop", &vars::boop);
    lua.script("beep = vars.new()\n"
               "beep.boop = 1");
    assert(lua.get<vars>("beep").boop == 1);
}

More examples are given in the examples directory here.

Documentation

Find it here. A run-through kind of tutorial is here! The API documentation goes over most cases (particularly, the "api/usertype" and "api/table_proxy" and "api/function" sections) that should still get you off your feet and going, and there's an examples directory here as well.

"I need X Feature or Fix, Right Now™"

Find the support option that's right for you, here! If you're happy to wait, you can just file a boring issue and we'll get to it Whenever There Is Time™.

I want to donate to help!

You can find donation and sponorship options here and from the little heart button near the top of this repository that will take you to a bevy of links in which you can donate and show support for this project and others!

Features

  • Fastest in the land (see: sol3 bar in graph).
  • Supports retrieval and setting of multiple types including:
    • std::string, std::wstring, std::u16string and std::u32string support (and for views).
    • understands and works with containers such as std::map/unordered_map, c-style arrays, vectors, non-standard custom containers and more.
    • user-defined types, with or without registering that type
    • std::unique_ptr, std::shared_ptr, and optional support of other pointer types like boost::shared_ptr.
    • custom optional<T> that works with references, and support for the inferior std::optional.
    • C++17 support for variants and similar new types.
  • Lambda, function, and member function bindings are supported.
  • Intermediate type for checking if a variable exists.
  • Simple API that completely abstracts away the C stack API, including protected_function with the ability to use an error-handling function.
  • operator[]-style manipulation of tables
  • C++ type representations in Lua userdata as usertypes with guaranteed cleanup.
  • Customization points to allow your C++ objects to be pushed and retrieved from Lua as multiple consecutive objects, or anything else you desire!
  • Overloaded function calls: my_function(1); my_function("Hello") in the same Lua script route to different function calls based on parameters
  • Support for tables, nested tables, table iteration with table.for_each / begin() and end() iterators.
  • Zero string overhead for usertype function lookup.

Supported Compilers

sol2 makes use of C++17 features. GCC 7.x.x and Clang 3.9.x (with -std=c++1z and appropriate standard library) or higher should be able to compile without problems. However, the officially supported and CI-tested compilers are:

  • GCC 7.x.x+ (MinGW 7.x.x+)
  • Clang 3.9.x+
  • Visual Studio 2017 Community (Visual C++ 15.0)+

Please make sure you use the -std=c++2a, -std=c++1z, -std=c++17 or better standard flags (some of these flags are the defaults in later versions of GCC, such as 7+ and better).

If you would like support for an older compiler (at the cost of some features), use the latest tagged sol2 branch. If you would like support for an even older compiler, feel free to contact me for a Custom Solution.

sol3 is checked by-hand for other platforms as well, including Android-based builds with GCC and iOS-based builds out of XCode with Apple-clang. It should work on both of these platforms, so long as you have the proper standards flags. If something doesn't work or you need special options, you may need to look into the different ways to support the project to have it done for you!

Creating a single header

You can grab a single header (and the single forward header) out of the library here. For stable version, check the releases tab on GitHub for a provided single header file for maximum ease of use. A script called single.py is provided in the repository if there's some bleeding edge change that hasn't been published on the releases page. You can run this script to create a single file version of the library so you can only include that part of it. Check single.py --help for more info.

If you use CMake, you can also configure and generate a project that will generate the sol2_single_header for you. You can also include the project using CMake. Run CMake for more details. Thanks @Nava2, @alkino, @mrgreywater and others for help with making the CMake build a reality.

Testing

Testing turns on certain CI-only variables in the CMake to test a myriad of configuration options. You can generate the tests by running CMake and configuring SOL2_TESTS, SOL2_TESTS_SINGLE, SOL2_TESTS_EXAMPLES, and SOL2_EXAMPLES to be on. Make sure SOL2_SINGLE is also on.

You will need any flavor of python3 and an available compiler. The testing suite will build its own version of Lua and LuaJIT, so you do not have to provide one (you may provide one with the LUA_LOCAL_DIR variable).

Presentations

"A Sun For the Moon - A Zero-Overhead Lua Abstraction using C++"
ThePhD Lua Workshop 2016 - Mashape, San Francisco, CA
Deck

"Wrapping Lua C in C++ - Efficiently, Nicely, and with a Touch of Magic"
ThePhD Boston C++ Meetup November 2017 - CiC (Milk Street), Boston, MA
Deck

"Biting the CMake Bullet"
ThePhD Boston C++ Meetup February 2018 - CiC (Main Street), Cambridge, MA
Deck

"Compile Fast, Run Faster, Scale Forever: A look into the sol2 Library"
ThePhD C++Now 2018 - Hudson Commons, Aspen Physics Center, Aspen, Colorado
Deck

"Scripting at the Speed of Thought: Using Lua in C++ with sol3"
ThePhD CppCon 2018 - 404 Keystone, Meydenbauer Center, Aspen, Colorado
Deck

"The Plan for Tomorrow: Compile-Time Extension Points in C++" ThePhD C++Now 2019 - Flug Auditorium, Aspen Physics Center, Aspen, Colorado Deck

License

sol2 is distributed with an MIT License. You can see LICENSE.txt for more info.

If you need a custom solution, feel free to reach out.

Owner
The Phantom Derpstorm
C++ is my jam (but I program in many other languages, too!)
The Phantom Derpstorm
Comments
  • Alignment error with member callback

    Alignment error with member callback

    The following example, where we try to execute a std::function member object, creates alignment errors on clang 6.0.0 according to the UndefinedBehaviorSanitizer.

    #include <sol.hpp>
    #include <functional>
    #include <iostream>
    
    struct Test{
      std::function<void()> callback = [](){ std::cout << "Hello world!" << std::endl; };
    };
    
    int main() {
      sol::state lua;
      lua.new_usertype<Test>("Test","callback",&Test::callback);
      Test test;
      lua["test"] = &test;
      lua.script("test.callback()");
      return 0;
    }
    

    when compiled using clang++ --std=c++14 -fsanitize=undefined ... a cascade of 'misaligned address' runtime errors is generated, beginning with

    (a.out:x86_64+0x1000d8c48): runtime error: constructor call on misaligned address 0x7fc01c405518 for type 'sol::function_detail::functor_function<std::__1::function<void ()> >', which requires 16 byte alignment
    0x7fc01c405518: note: pointer points here
     00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00
                  ^ 
    

    Otherwise the program executes as expected.

  • sol::variadic_args use in usertype constructor

    sol::variadic_args use in usertype constructor

    struct foo 
    {
    	foo(sol::variadic_args args)
    	{
    		std::cout << args.size() << std::endl;
    	}
    };
    
    
    int main(int argc, char ** argv)
    {
    	sol::state lua;
    
    	lua.open_libraries();
    	lua.new_usertype<foo>("foo", sol::constructors<foo(sol::variadic_args)>());
    
    	lua.script(R"(
    	foo.new()
    	foo.new(0, 1)
    	foo.new(0, 1, 2)
    	foo.new(0, 1, 2, 3)
    	)");
    }
    

    This will be print

    1
    3
    4
    5
    

    why? my compiler is vc2019.

  • Long compilation times when registering usertype with lots (>50) of member functions.

    Long compilation times when registering usertype with lots (>50) of member functions.

    I have a class which has a lot of member functions. I pass them all in usertype constructor but that probably generates huge template intantiations of some functions. This causes CPP file in VS2015 to compile for 3-4 minutes while consuming 1.5 gigabytes of RAM.

    What I need is ability to register functions one by one, not all at once. I realize that this may not be the most efficient way to do this, but compilation times are very important for me, more that runtime performance when registering this stuff.

    I propose something like:

    usertype<SomeClass> ut("SomeClass");
    ut.add_function("someFunc", &SomeClass::someFunc);
    ...
    
  • Calling Unknown function on global variable crashes on cleanup

    Calling Unknown function on global variable crashes on cleanup

    Hey there,

    I just grabbed latest to benefit from the "attempt to index a nil value" fix, but ran into an issue on app exit. When having called an unknown function on a global lua var it will crash on exit with iterator debug level 2, orphaned pointer, read access violation.

    Example:

    class A
    {
    public:
        A() : a(0){}
    };
    
    solState.new_usertype<A>("A", "a", &A::a);
    

    runs and exits fine:

    local test = A.new()
    test:Unknown()
    

    runs fine but will cause app crash on exit:

    test = A.new() -- notice global variable
    test:Unknown() -- having called it will cause app to crash on exit
    

    Looking into it more the crash happens during GC for the fail_on_error functor.

  • AppVeyor for VS 2017/2015 | Travis for g++ 7/6/5 , clang++ 3.7/3.8/3.9/4.0

    AppVeyor for VS 2017/2015 | Travis for g++ 7/6/5 , clang++ 3.7/3.8/3.9/4.0

    All of the old test harnesses should be placed into "Allowed Failures" buckets, including VS 2015. This will let us know what commit exactly breaks a certain compiler level, albeit it would mean tests would take an additional hour to complete in the cloud (mostly because of additional XCode imaging setup).

    • [x] Travis CI:

      • [x] g++ 5.3
      • [x] g++ 5.4
      • [x] g++ 6.3
      • [x] g++ 7.1
      • [x] clang++ 3.6
      • [x] clang++ 3.7
      • [x] clang++ 3.8
      • [x] clang++ 3.9
      • [x] clang++ 4.0
    • [x] AppVeyor:

      • [x] Visual Studio 2015, Latest (allowed failure)
      • [x] Visual Studio 2017, Latest

    All older tests should be bundled up as "allowed failures"

  • Write a tutorial

    Write a tutorial

    The current README is pretty terse, and reading API reference is a not pleasant way to learn any library. I propose to kidnap manual from any competing library (kagaya, selene, lua-intf to name a few), made a few edits to identifiers (and list of supported compilers) and put it into README. You may even combine parts kidnapeed here and there. Later Sol-specific features may be added, but it will be a good start.

    I believe that now, when you are released a major stable version, lack of step-by-step tutorial is main barrier to wider Sol2 acceptance.

  • LuaJIT 5.1: Exceptions are not rethrown through sol::error

    LuaJIT 5.1: Exceptions are not rethrown through sol::error

    In my code, I'm trying to force some sandboxing, one part of this is setting the require function to nil.

    To test this, I create an "library script":

    local M = {}
    function M.foo()
        return "foo"
    end
    return M
    

    I store this into a file in the test dir, m.lua, and then load it via:

    local M= require('m')
    assert(M.foo() == "foo");
    

    On Lua 5.2, this throws a sol::error claiming the require function is nil. This is the expected behaviour, however, luajit exceptions are never caught and it throws an error unrecognized.

  • Usertypes with many members become too complex for the compiler

    Usertypes with many members become too complex for the compiler

    I'm experiencing this issue under MSVC140 (Update 3) on the 64-bit toolchain.

    I have a usertype which has 147 property members (sol::property), a call constructor, and two base classes, and during compilation I'm getting the following errors:

    2>I:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\type_traits(1016): fatal error C1202: recursive type or function dependency context too complex (compiling source file CustomUsertypeClass.cpp)
    2>  I:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\type_traits(1035): note: see reference to class template instantiation 'std::_Choose_conjunction<true,_Lhs,std::is_constructible<const char (&)[27],const char (&)[27]>,std::is_constructible<sol::property_wrapper<bool (__cdecl CustomUsertypeClass::* )(void) const,void (__cdecl CustomUsertypeClass::* )(bool)>,_Ty>,std::is_constructible<const char (&)[27],const char (&)[27]>,std::is_constructible<_Ty,_Ty>,std::is_constructible<const char (&)[30],const char (&)[30]>,std::is_constructible<_Ty,_Ty>,std::is_constructible<const char (&)[26],const char (&)[26]>,std::is_constructible<_Ty,_Ty>,std::is_constructible<const char (&)[16],const char (&)[16]>,std::is_constructible<_Ty,_Ty>,std::is_constructible<const char (&)[15],const char (&)[15]>,std::is_constructible<_Ty,_Ty>,std::is_constructible<const char (&)[20],const char (&)[20]>,std::is_constructible<_Ty,_Ty>,std::is_constructible<const char (&)[25],const char (&)[25]>,std::is_constructible<_Ty,_Ty>,std::is_constructible<const char (&)[34],const char (&)[34]>,std::is_constructible<_Ty,_Ty>,std::is_constructible<const char (&)[28],const char (&)[28]>,std::is_constructible<_Ty,_Ty>,std::is_constructible<const char (&)[32],const char (&)[32]>,std::is_constructible<_Ty,_Ty>,std::is_constructible<const char (&)[21],const char (&)[21]>,std::is_constructible<_Ty,_Ty>,std::is_constructible<const char (&)[18],const char (&)[18]>,std::is_constructible<_Ty,_Ty>,std::is_constructible<const char (&)[23],const char (&)[23]>,std::is_constructible<_Ty,_Ty>,std::is_constructible<const char (&)[21],const char (&)[21]>,std::is_constructible<_Ty,_Ty>,std::is_constructible<const char (&)[24],const char (&)[24]>,std::is_constructible<_Ty,_Ty>,std::is_constructible<const char (&)[26],const char (&)[26]>,std::is_constructible<_Ty,_Ty>,std::is_constructible<const char (&)[25],const char (&)[25]>,std::is_constructible<_Ty,_Ty>,std::is_constructible<const char (...
    

    This could be associated to #202 but since it's an actual issue I'm posted it here for reference.

  • Issue compiling sol on OSX (xcode 8.2.1, LLVM 8.0).

    Issue compiling sol on OSX (xcode 8.2.1, LLVM 8.0).

    I wonder if someone could help me. This is likely something on my end.

    Im trying to use sol2 with luajit. Previously using lua worked fine. I add the header like this:

    ` #define SOL_USING_CXX_LUA

    #define SOL_USING_CXX_LUAJIT

    #include <sol2/sol.hpp> `

    I get an error in compilation: .../include/sol2/sol.hpp:2082:10: Cannot initialize return object of type 'char *' with an rvalue of type 'int'

    It seems strerror_r returns an int, not as expected a char *. Should i be using those 2 defines when trying to use luajit?

    Thanks!

  • Container Usertypes are not iterable

    Container Usertypes are not iterable

    Using the latest release of sol2, Visual Studio 2017 and compiled as C++17 through the appropriate compiler flags

    I have a class, X, which satisfies the requirements of Container and holds a different class, Y.

    Class X has methods and functions that help manipulate Y's, and i want this class to be exposed to Lua. As such, i've attempted to register it as a usertype, which works, but I can't for the life of me figure out how to get the actual Container part to work. No matter what i try i can't iterate over it from Lua.

    I have tried specializing the is_container template to be true, but that does not visibly change anything.

    Is this not possible in sol2? Am i missing something?

  • Large integer support

    Large integer support

    This PR adds large integer support for x86 and integer misrepresentation detection for x86/x64. sol2 will still try to use lua_Integer wherever it is safe to do so, only when the value can't possibly fit in lua_Integer, it uses lua_Number as fallback with optional runtime checks to make sure the floating point value still represents the integer accurately.

    Would appreciate any feedback or concerns, if there are any.

    See #470

    • [x] large integer changes
    • [x] tests
    • [x] working linux:i386 build
    • [x] passes travis-ci (as good as develop)
    • [x] reviewed

    unrelated to this PR:

    • The build for the original develop branch is currently broken, I'll update my fork from upstream as soon as it's fixed.
    • currently both linux:i386 and windows:x86 are failing some tests on upstream/develop (at least with the latest luajit) maybe we could have some i386 builds on travis?
    • you manually need to set SOL_EXCEPTIONS_SAFE_PROPAGATION under windows x86/luajit2.1b3 (the new versions have proper exception handling under windows x86 with \EHsc)
    • single.py is failing with python2.7 and only works with python3
    • it would be nice to have a build config that runs with msvc that you don't need to create yourself
  • Can't bind union members to usertype

    Can't bind union members to usertype

    Greetings,

    First of all, I am using these versions, installed via vcpkg:

    • Lua version 5.4.4
    • sol2 version 3.3.0

    I seem to have trouble assigning union members to usertypes. The compiler produces an error, suggesting that I might be trying to bind members to an unrelated class. Are "raw" unions simply not a thing in Lua/sol2? I'm sorry if it's stated somewhere, I couldn't find any information about it.

    Here is the error message:

    It seems like you might have accidentally bound a class type with a member function method that does not correspond to the class. For example, there could be a small type in your new_usertype(...) binding, where you specify one class "T" but then bind member methods from a complete unrelated class. Check things over!

    Here is a simple main.cpp to reproduce the issue:

    #include <sol/sol.hpp>
    
    struct S {
        int i;
        char c[4];
    };
    
    union U {
        int i;
        char c[4];
    };
    
    int main()
    {
        sol::state lua;
    
        // Test with struct
        sol::usertype<S> struct_type = lua.new_usertype<S>("S");
        struct_type["i"] = &S::i;
        struct_type["c"] = &S::c;
    
        // Test with union
        sol::usertype<U> union_type = lua.new_usertype<U>("U");
        union_type["i"] = &U::i; // <--- Compiler error
        union_type["c"] = &U::c; // Never reached
    }
    

    Same happens trying directly from the new_usertype() function:

    lua.new_usertype<U>("U",
        "i", &U::i,
        "c", &U::c
    ); // Compiler error
    

    Thanks in advance for the help.

  • Performance problem with sol::make_object

    Performance problem with sol::make_object

    I have a set of Nodes, these nodes have properties which have a key (std::string) and value (Variant property_type_t) .

    To convert I am iterating through the properties in the map and calling PropertyToSolObject on each value.

      sol::table Shard::PropertiesToSolObject(const std::map<std::string, property_type_t>& properties) {
        sol::table property_map = lua.create_table();
        for (const auto& [_key, value] : properties) {
          property_map[_key] = PropertyToSolObject(value);
        }
        return property_map;
      }
    

    The definition of PropertyToSolObject is below and uses sol::make_object

    sol::object Shard::PropertyToSolObject(const property_type_t value) const {
    
        switch (value.index()) {
          case 0:
            return sol::lua_nil;
          case 1:
            return sol::make_object(lua.lua_state(), get<bool>(value));
          case 2:
            return sol::make_object(lua.lua_state(), get<int64_t>(value));
          case 3:
            return sol::make_object(lua.lua_state(), get<double>(value));
          case 4:
            return sol::make_object(lua.lua_state(), get<std::string>(value));
          case 5:
            return sol::make_object(lua.lua_state(), sol::as_table(get<std::vector<bool>>(value)));
          case 6:
            return sol::make_object(lua.lua_state(), sol::as_table(get<std::vector<int64_t>>(value)));
          case 7:
            return sol::make_object(lua.lua_state(), sol::as_table(get<std::vector<double>>(value)));
          case 8:
            return sol::make_object(lua.lua_state(), sol::as_table(get<std::vector<std::string>>(value)));
          default:
              return sol::lua_nil;
          }
        return sol::lua_nil;
      }
    

    Converting 100k nodes each with 5 properties or so is taking about 100ms which is 10x more than it takes to gather the data.

    Is there a higher performance way of doing this?

    The code is on https://github.com/ragedb/ragedb/blob/main/src/graph/lua/Helpers.cpp I am following examples found on:

    • https://github.com/ThePhD/sol2/issues/1035
    • https://github.com/ThePhD/sol2/issues/86
  • ASan heap-use-after-free in clear_usertype_registry_names when state is stored with static storage

    ASan heap-use-after-free in clear_usertype_registry_names when state is stored with static storage

    In porting a project to sol2 we have a LuaParser class that uses singleton pattern for now. ASan doesn't report problems when it's just tables, enums, etc, just happens once I add a usertype.

    This happened on my local machine using GCC 12 and my test debian VM using GCC 10. Clang 14 on my local machine also has the same issue. Tried with lua 5.4, 5.1, and LuaJIT 2.1.0_beta3_p20220613 (whatever that is on Gentoo). Sol version was 3.3.0 and tried current develop HEAD

    Here is a repo:

    #include <sol/sol.hpp>
    
    // build: g++ -fsanitize=address -I./include $(pkg-config --libs --cflags lua5.4) heap-after-free.cpp -o heap
    
    static sol::state state;
    
    struct A { };
    
    int main(int argc, char *argv[])
    {
        state.new_usertype<A>("A");
    
        return 0;
    }
    
    
    

    ASan output:

    =================================================================
    ==1287530==ERROR: AddressSanitizer: heap-use-after-free on address 0x603000000a30 at pc 0x7f16e84999c0 bp 0x7fff8442b6e0 sp 0x7fff8442ae88
    READ of size 1 at 0x603000000a30 thread T0
        #0 0x7f16e84999bf  (/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/libasan.so.8+0xab9bf)
        #1 0x7f16e83cf32d  (/usr/lib64/liblua5.4.so.0+0x2732d)
        #2 0x7f16e83b0fd1  (/usr/lib64/liblua5.4.so.0+0x8fd1)
        #3 0x560f7206596e in void sol::stack::field_setter<char const*, false, false, void>::set<char const*, sol::lua_nil_t const&>(lua_State*, char const*&&, sol::lua_nil_t const&, int) (/home/USERNAME/test/sol2/heap2+0x4496e)
        #4 0x560f720624dc in void sol::stack::set_field<false, false, char const*, sol::lua_nil_t const&>(lua_State*, char const*&&, sol::lua_nil_t const&, int) (/home/USERNAME/test/sol2/heap2+0x414dc)
        #5 0x560f7205ca42 in void sol::u_detail::clear_usertype_registry_names<A>(lua_State*) (/home/USERNAME/test/sol2/heap2+0x3ba42)
        #6 0x560f7205cde1 in int sol::u_detail::destroy_usertype_storage<A>(lua_State*) (/home/USERNAME/test/sol2/heap2+0x3bde1)
        #7 0x7f16e83bec6d  (/usr/lib64/liblua5.4.so.0+0x16c6d)
        #8 0x7f16e83befe6  (/usr/lib64/liblua5.4.so.0+0x16fe6)
        #9 0x7f16e83bdf0a  (/usr/lib64/liblua5.4.so.0+0x15f0a)
        #10 0x7f16e83bf3bf  (/usr/lib64/liblua5.4.so.0+0x173bf)
        #11 0x7f16e83c07a5  (/usr/lib64/liblua5.4.so.0+0x187a5)
        #12 0x7f16e83c25f7  (/usr/lib64/liblua5.4.so.0+0x1a5f7)
        #13 0x7f16e83ce40e  (/usr/lib64/liblua5.4.so.0+0x2640e)
        #14 0x560f7202a5b5 in sol::detail::state_deleter::operator()(lua_State*) const (/home/USERNAME/test/sol2/heap2+0x95b5)
        #15 0x560f7203da26 in std::unique_ptr<lua_State, sol::detail::state_deleter>::~unique_ptr() (/home/USERNAME/test/sol2/heap2+0x1ca26)
        #16 0x560f720380c3 in sol::state::~state() (/home/USERNAME/test/sol2/heap2+0x170c3)
        #17 0x7f16e7ed0a27  (/lib64/libc.so.6+0x40a27)
        #18 0x7f16e7ed0b29 in exit (/lib64/libc.so.6+0x40b29)
        #19 0x7f16e7eb92d8  (/lib64/libc.so.6+0x292d8)
        #20 0x7f16e7eb9394 in __libc_start_main (/lib64/libc.so.6+0x29394)
        #21 0x560f720299b0 in _start (/home/USERNAME/test/sol2/heap2+0x89b0)
    
    0x603000000a30 is located 0 bytes inside of 17-byte region [0x603000000a30,0x603000000a41)
    freed by thread T0 here:
        #0 0x7f16e84ac6c8 in operator delete(void*) (/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/libasan.so.8+0xbe6c8)
        #1 0x7f16e7ed0a27  (/lib64/libc.so.6+0x40a27)
    
    previously allocated by thread T0 here:
        #0 0x7f16e84abb88 in operator new(unsigned long) (/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/libasan.so.8+0xbdb88)
        #1 0x7f16e82d0169 in void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag) (/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/libstdc++.so.6+0x146169)
    
    SUMMARY: AddressSanitizer: heap-use-after-free (/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/libasan.so.8+0xab9bf) 
    Shadow bytes around the buggy address:
      0x0c067fff80f0: fa fa 00 00 00 03 fa fa 00 00 00 07 fa fa 00 00
      0x0c067fff8100: 00 07 fa fa 00 00 00 05 fa fa 00 00 00 05 fa fa
      0x0c067fff8110: 00 00 00 06 fa fa 00 00 00 06 fa fa fd fd fd fa
      0x0c067fff8120: fa fa 00 00 00 fa fa fa fd fd fd fa fa fa fd fd
      0x0c067fff8130: fd fa fa fa fd fd fd fa fa fa 00 00 00 07 fa fa
    =>0x0c067fff8140: fd fd fd fd fa fa[fd]fd fd fa fa fa 00 00 00 06
      0x0c067fff8150: fa fa 00 00 00 fa fa fa 00 00 00 02 fa fa 00 00
      0x0c067fff8160: 00 05 fa fa fd fd fd fa fa fa 00 00 00 03 fa fa
      0x0c067fff8170: 00 00 00 07 fa fa fd fd fd fa fa fa fd fd fd fa
      0x0c067fff8180: fa fa 00 00 00 07 fa fa 00 00 00 00 fa fa 00 00
      0x0c067fff8190: 00 04 fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07 
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
    ==1287530==ABORTING
    
  • how to make lua multidimensional array like

    how to make lua multidimensional array like "temp_array[2][3]" in C++

    Hi i am a huge fan of your solution, sol2. and i am adapting that solution on emscripten that make wasm.

    but i cant find the way to make lua multidimensional array like lua_temp_array[2][3].

    On C++, there is a array, int* temp_array. temp_array is 6 size, and temp_array value is 0,1,2,3,4,5. In this situation, how can bind this temp_array with lua_temp_array?

    i know, sol2 offered many ways to use C++ container in lua script like vector, map, ..... and so on. but i just want to bind temp_array with lua_temp_array using sol2.

    if sol2 wouldn't have solution to adapting this situation, then i would have no choice but to use just original lua not sol2


    IDE : Visual Studio Code Language : C++ Compiler: Emscripten

    Thanks.

  • Setter not working in sol::property with static classes (only release 3.3.0)

    Setter not working in sol::property with static classes (only release 3.3.0)

    Using latest release (3.3.0) sol::property setter method is not working:

    auto engine = lua.new_usertype<Engine>("Engine", sol::no_constructor);
    engine["callTouch"] = sol::property(&Engine::isCallTouch, &Engine::setCallTouch);
    

    On release 3.2.3:

    print(Engine.callTouch)  -- working
    Engine.callTouch = true  -- working
    

    On release 3.3.0:

    print(Engine.callTouch)  -- working
    Engine.callTouch = true  -- not working
    
A lightweight, dependency-free library for binding Lua to C++
A lightweight, dependency-free library for binding Lua to C++

LuaBridge 2.6 LuaBridge is a lightweight and dependency-free library for mapping data, functions, and classes back and forth between C++ and Lua (a po

Sep 22, 2022
libffi wrapper for quickjs

Libffi wrapper for QuickJS. Now supports almost every features of C including primitive types, structs, callbacks and so on License MIT License Copyri

Sep 5, 2022
ChakraCore is an open source Javascript engine with a C API.

ChakraCore ChakraCore is a Javascript engine with a C API you can use to add support for Javascript to any C or C compatible project. It can be compil

Sep 27, 2022
Structy is an irresponsibly dumb and simple struct serialization/deserialization library for C, Python, and vanilla JavaScript.

Structy Structy is an irresponsibly dumb and simple struct serialization/deserialization library for C, Python, and vanilla JavaScript. You can think

Sep 13, 2022
Libraries and examples to support Pimoroni Pico add-ons in C++ and MicroPython.

Pimoroni Pico Libraries and Examples Welcome to the brave new world of Pico! This repository contains the C/C++ and MicroPython libraries for our rang

Oct 2, 2022
Tools and libraries to glue C/C++ APIs to high-level languages

CppSharp is a tool and set of libraries which facilitates the usage of native C/C++ code with the .NET ecosystem. It consumes C/C++ header and library

Sep 25, 2022
A tool for generating cross-language type declarations and interface bindings.

Djinni Djinni is a tool for generating cross-language type declarations and interface bindings. It's designed to connect C++ with either Java or Objec

Sep 27, 2022
Duktape - embeddable Javascript engine with a focus on portability and compact footprint

Duktape ⚠️ Master branch is undergoing incompatible changes for Duktape 3.x. To track Duktape 2.x, follow the v2-maintenance branch. Introduction Dukt

Sep 29, 2022
The missing bridge between Java and native C++

JavaCPP Commercial support: Introduction JavaCPP provides efficient access to native C++ inside Java, not unlike the way some C/C++ compilers interact

Sep 30, 2022
Seamless operability between C++11 and Python
Seamless operability between C++11 and Python

pybind11 — Seamless operability between C++11 and Python Setuptools example • Scikit-build example • CMake example Warning Combining older versions of

Oct 2, 2022
SWIG is a software development tool that connects programs written in C and C++ with a variety of high-level programming languages.

SWIG (Simplified Wrapper and Interface Generator) Version: 4.1.0 (in progress) Tagline: SWIG is a compiler that integrates C and C++ with languages

Sep 28, 2022
A minimalist and mundane scripting language.

Drift Script A minimalist and mundane scripting language. I like all simple things, simple and beautiful, simple and strong. I know that all developme

Apr 3, 2022
An operating system. Its main goal? Readable code, developer experience and documentation.

OS Dependencies Required for development. sudo apt install build-essential nasm grub-pc-bin grub-common xorriso Required for building cross-compiler.

Jun 20, 2022
Repository of some great classical and Advanced cryptosystems

CryptoSystems ?? Repository of some great classical and Advanced cryptosystems Every C file here contains one of the most popular Cryptosystem in hist

Nov 12, 2021
A beginner friendly repo in the world of open source. Contribute here to add here project in any languages.
A beginner friendly repo in the world of open source. Contribute here to add here project in any languages.

Hacktober Fest 2021 Heyy There (●'◡'●) Here you can contribute to opensource project in any valid language and project. Just follow the contribution g

May 24, 2022
Utility on top of the Flutter Driver API that facilitates measuring the performance of your app in an automated way created by Very Good Ventures 🦄
Utility on top of the Flutter Driver API that facilitates measuring the performance of your app in an automated way created by Very Good Ventures 🦄

Very Good Performance Developed with ?? by Very Good Ventures ?? Utility on top of the Flutter Driver API that facilitates measuring the performance o

Sep 19, 2022
Make Lua great again

LuaLibs Lua 模块合集 • 让 Lua 再次伟大 Lua module collection · Makes Lua great again 已收录项目 项目名称 简介 开发者 Lua API 版本 是否跨平台 LuaHttpLib 阻塞式 HTTP 库 Voidmatrix 5.4.0

Jul 14, 2022
An advanced in-memory evasion technique fluctuating shellcode's memory protection between RW/NoAccess & RX and then encrypting/decrypting its contents
An advanced in-memory evasion technique fluctuating shellcode's memory protection between RW/NoAccess & RX and then encrypting/decrypting its contents

Shellcode Fluctuation PoC A PoC implementation for an another in-memory evasion technique that cyclically encrypts and decrypts shellcode's contents t

Sep 29, 2022
Project to create a teensy based gamecube controller with hall effect sensors, snapback filtering, and notch calibration
Project to create a teensy based gamecube controller with hall effect sensors, snapback filtering, and notch calibration

PhobGCC Gamecube controller motherboard using a teensy as the microcontroller. Aim is to make an accessible and consistent controller. Has the option

Sep 20, 2022
Hello, I am creating this file to make everyone understand the basis of C++ language which is actually the advanced version of C but better than C because of its OOPs feature.

Hello-in-C++ ?? ?? FOR BEGINNERS IN C++ Hello, I am creating this file to make everyone understand the basics of C++ language which is actually the ad

Dec 27, 2021