Possible conflicts between Lua C++ bindings - c++

I am currently working on a project. One library I would like to consider using in the future uses ToLua++ as a method of binding Lua. Currently, the library I am looking at is CEGUI, and it uses ToLua++. I am currently considering using LuaBind for the implementation in the project I'm working on. I was wondering if anyone would have any insight as to if that would cause clashes and break things, or if it would work just fine.

As long as you don't define the same Lua entities with both tools, LuaBind and ToLua++ coexist nicely. You can use either tool to add more functions and classes to a module, but you can't add more methods to a class defined by the other tool.

Related

Use C++ library object from within Lua

So for the past few hours I've been trying to figure out how to use C++ classes contained in static (or dynamic) libraries from within Lua. I've found several packages, such as LunaFive or SimpleCppBinding, but I seem not to understand how to use them properly. From what I see there's a main function, therefore I guess it's not a library, but an executable which I run and then run the Lua script, which will hook the app and get the class, or something? What I basically want to do is:
create a library containing, for example, a class 'Player' in C++
modify this library to be usable from Lua
somehow use this class and it's methods from within the Lua in the same way as if it would be a Lua class
Is such thing even possible? And if so, could someone explain how such thing can be done?
I'm currently on Windows, but I can do it on Linux as well. On windows I'm using VS, on Linux I'd be using CLion paired with g++. Lua 5.3.
I'm not sure if this is somewhat relevant, but I'm developing a game-mode for FiveM (GTA V multiplayer client). The FiveM comes with a Lua support for scripting by default, but I'd love to use some of the C++ standard libraries and features. Therefore I'd really love to create some libraries for the server in C++, and then use them from within the Lua supplied by FiveM.
Static library: not possible. Your options are: 1. a dynamic library (binary) with some kind of interface accessible by Lua executable (Alien, Lua-specific hooks....) or 2. A custom executable which includes the Lua engine and the C++ stuff with some glue. Your examples with the 'main' function probably are the latter type.
Lua was designed, from the beginning, to be integrated with software written in C and other conventional languages. This duality of languages brings many benefits. Lua is a tiny and simple language, partly because it does not try to do what C is already good for, such as sheer performance, low-level operations, or interface with third-party software.
-Preface
I understand your pain, however Lua simply isn't meant to be used the way you intend, it's actually built to be used the other way around.
The closest thing I can think of to get the result what you want is to have a host C++ application from which you immediately create a lua state and push results of the functions you called from the C++ program into the stack, in return can be used in your Lua script and processed.
If this is something you might be able to adjust to, here is a great starting point

How to integrate c++ classes and objects around winApi?

Hey so for one of my c++ projects I need to develop a 4-5 window application.Now the issue is that currently all of my programs tasks are divided into classes, and I have tested them by passing 'dummy' values and returning print results. That's all fine and working, however now as I want to introduce a GUI interface it presents me with the problem of how my processing should communicate with the front end, since winAPI is initially meant for c and not object oriented language.
What I am thinking of doing, and have a feeling is going to be a tedious task, to make a class which does the win api's registrations and methods for me. Is there any other alternative to this ???
I was looking at integrating Qt into eclipse but I think they stopped providing the library for eclipse, because I couldn't find a download for the library anywhere, not even on the Qt download page.
Well, if you want to use Win32, then you have to do all the stuff that Win32 needs you to do. It's a rather low level API, so you just have to take care of a lot of details.
However, don't over-engineer things. You don't have to write a generic C++ wrapper for Win32... you just have to make a GUI for your program.
If your problem is only that classes are not supported by C, then simply replace the keyword class with the keyword struct. Just make sure to declare the access types of all variables (private, public, protected), that way it becomes interchangeable (Works for both). The only difference between them is the default access type, which for classes is private. In case you used other syntax that is unique to C++, then this wouldn't work.
There are code generators from C++ to C as well. The optimal solution would be to create a GUI using an IDE specifically for that purpose which uses C++ as its base language. MFC works well, but it is not open-source and you will need a considerable knowledge on inheritance and comfort with "class typecasting". Using the included wizards in Visual Studio will help.
Try the first option; it will possibly work the same way.

Mixing C++ code from different compilers

Suppose I have two projects that I would like to link together:
A C++ library compiled with Visual C++ to a DLL file.
A C++ executable compiled with C++ Builder that uses the classes in the library.
I realize that there is no standard C++ ABI and that any attempts to directly link these two C++ projects together will fail. What is a good, automated way of creating a compatibility layer that allows me to accomplish this?
For example, conceivably the C++ library could expose itself via a C interface. Then the executable would have some C++ classes that wrap the C interface exposed by the C++ library. Since there is a standard ABI for C, it would work.
The only question is how to automatically create the C interface and C++ wrapper classes - manually maintaining this would not be an option. The SWIG project looks promising, but unfortunately, C++ is not one of the exits of SWIG listed on their web site. Is there a way to do what I want with SWIG? Or is there another project other than SWIG that would help me with this task?
Or am I going about this the wrong way?
Edit: The core C++ library is intended to be cross-platform. The executable, obviously, is Windows-specific. I don't want to pollute the core library to the extent that it becomes impossible to compile it on other platforms.
If it only has to run on Windows, I would expose the classes as COM objects. They'll still be in a DLL and they can be used by any language which understands COM.
The "standard" way of doing this, in Windows, is to use COM objects. So, that is certainly a good option to look at. In Linux systems, the module interaction model (e.g., executable-DLL interaction) is very different, and ABIs exist for C++.
If you would want to do this manually (create your own COM-like library), it can be a lot of work with many little tricky issues to take seriously. You'll need a cross-module RTTI system, you'll need an interface query/definition protocol, some mechanism to manage memory across modules, etc. Beyond that, to "automate" it, you will probably need a combination of MACROs and template meta-functions.
One cross-platform option that I would highly recommend that you consider or at least look at is using Boost.Python and the Python language as the "glue" between your modules. The Boost.Python library basically does the whole "automated exporting / importing of classes", but it exports your C++ classes and functions as Python classes and functions. And, it is completely non-intrusive and cross-platform, so this is really an ideal example of automated exporting. So, you might consider using Python to write your high-level glue-code, or using Python as an intermediate between the C++ modules, or even reworking the Boost.Python library to use only the "automated exporting" mechanisms to export to whatever interface system you design or use.
I'm sure there a plenty other similar libraries out there. But the number one question is, of course, do you really need this? You might be using a bazooka to kill a fly.
Why not just compile the library with C++ builder as well?
Looking around at swig (I knew swig should be able to wrap C++ in C):
SWIG and C++
If core library is cross-platform why not also write the UI as a cross-platform Qt application and build everything in Visual C++ on Windows.

Convert Lua code to C++ classes back in C++

I've seen similar posts but none that quite asked the question in the same way.
Basically, I've been playing with Shiva3d lately ( http://www.stonetrip.com/ ), which is a 3d engine. The coding inside the engine is in Lua, however, the actual product when exported from the IDE is C++ code. While the coding is restricted, it does a fair job at exporting function, variables and everything back in C++ code.
What I want to know is, can I create a base engine, where there would be a set of predefined class and then use Lua to extend/overload these base classes (by providing certain predefined required functions) and get that code back in C++ with the different Lua/C++ binding libraries that exist?
Have a look at SWIG http://www.swig.org/
It parses the C++ headers and creates binding for several languages (including Lua).
Although I really like SWIG, I fell in love with luabind, because you have more direct control. Additionally it provides a built-in object orientation system and you do not need an additional translator/compiler like swig.

Exposing C++ library to Python + PIL

I started using SWIG on a huge C++ library (made of of several inter-dependent static libs) to expose it to python. This library defines many primitive classes that are used throughout as parameters (images of different types for example). There is extensive use of STL, inheritance and templating in the lib as well.
So far I have a minimal portion of the lib usable from Python but would like to progressively add the remaining 90+%.
For my part, working with SWIG is really no fun: Battling with template instantiations, learning all that SWIG syntax and keywords, etc. I recently played a bit with CTypes and found it so enjoyable that I am now considering writing an extern C interface for the whole library instead of using SWIG.
I would rather be coding in C/C++ and/or Python than learning an obscure set of SWIG commands (that counts for SIP also).
There are quite a few questions out there already asking similar advice so I'll add something new and specific:
I would like for the library's internal images classes to be visible from python as PIL images transparently, not as SWIG-Wrapped native classes. Will I have to resort to the plain-old Python External API to accomplish that?
I welcome any and all advice!
Have you considered looking into using Boost.Python?