Script binding automation

Since this switch (and others) would be such a hassle in the current AS situation, it seems to me like getting its autobinding up and running should be our main priority.

Urho3D script binding automation projects:

Not exits any magical automatcs bindings. Just look it https://github.com/***/***/tree/master/Source/Urho3D/CSharp/Swig With a significant change of engine, this will also have to be changed.

So far I didn’t see anybody willing to bring automatic AS bindings in Urho. I saw one attempt, but it didn’t look finished.

There’s no point to call task “main priority” when said priority doesn’t affect the outcome in slightest /sad smile/

How often do you change classes listed in the folder you linked?

I don’t understand why this is a question. I don’t often change engine classes.

Would you agree it is better to remove a boulder from the road than to headbutt it?

Because the folder you mentioned has manual bindings for

1. Object
2. RefCounted
3. Context
4. StringHash
5. Math

And these are not complete bindings. Just a fraction of their functionality requires manual bindings.
What kind of changes in the engine will require changes in these files?

Firstly, there are much more files than you listed. Secondly, where is the contradictory in what I said? Imagine you have to change containers in ***. Do these automatic bindings help you in some way and you don’t have to redo all this?

Not in case lf AS. If SWIG was to be used for lua then it is possible to make use of lua bindings for stdlib, due to identical interfaces. I did just that. Bindings started before EASTL port and making SWIG bindings for custom urho containers was tedious work.

That is, the bindings were made earlier by someone else? Great, we already have AS bindings made by someone else. You only need to change the bindings to the container when changing containers and so on.

I see a lot of annotations in these files. When you just tell SWIG what to bind and what not to bind.
Annotations are not the bindings, and they are much simpler to edit.
I see a lot of autogenerated files there.
I don’t see a lot of manual bindings there. Unlike Urho3D/Script that has thousands of LOCs.

How often do you change containers and how often do you change not containers?

The point is not to get rid of manual bindings at all.
The point is to remove them from the hot path.

PS. Anyway, autobindings for AS do not exist in the nature, so this is moot point to talk about how they can help us

Thus, you say that you do not have to change these files when changing the engine?

Yes, I do not. Because engine has hundreds of classes, and manual bindings are written only for maybe 0.1% of functionality. @rku correct me if I’m wrong

Yeah well… *** happened so i do not have to deal with bindings. So there is a conflict here.

Correct. Most manual part of SWIG bindings is writing rules of what binding code SWIG should generate for certain types in certain cases. StringHash.i is a good example, being compact and not trivial. See StringHash is implemented in C# directly and that SWIG interface tells SWIG how to convert between C++ and C# types. Once written it becomes extremely low maintenance thing.

At the moment our highest maintenance cost comes from template classes. If we add some template type to API, that SWIG is not aware of - we must add one line to the .i file to generate wrapper for that particular template instantiation.

Some bells and whistles (like turning getters and setters into properties) require more effort and maintenance. They are also optional.

True. Manual bindings are a special case. These are our manual bindings: https://github.com/***/***/tree/master/Source/Urho3D/CSharp/Native. As you can see we have very little of them. Most of which are dealing with quite specialized features (factories, events, callbacks). SWIG is not perfect, but it gets us 95% of the way.

So far the biggest flaw of SWIG comparing it to our current AS bindings is that we have no facility to easily wrap user classes when *** is linked as 3rdparty.

@rku You have any idea how can it be supported?

To the contrary - if they indeed do not exist - creating them would add them to nature, making them available to the whole world. It would amount to more than just contributing (greatly) to Urho.

This is actually a strong point of SWIG. User code may import our SWIG modules and magically use of all the rules to bind said types in their own API. User does not need to care how to bind ea::string, VariantMap or Material. All user would have to do is include their headers in .i file and mark class as inheriting from RefCounted (another weak point, still beats writing manual bindings).

Our build system is not rigged to do all that, but it would not be that much work to make it happen. Day’s work maybe.

Well… https://github.com/Dviglo/Dviglo/blob/CSharp/Source/Urho3D/CSharp/Managed/Math/StringHash.cs

@1vanK not sure what you are trying to say

My manual version seems more understandable to me than your manually written module

This is actually interesting question how those are different, in the specific case of StringHash. @rku can you explain? I’m curious too.

You are right. SWIG bindings are hell. Also what you see in *** has 2x complexity because we need cs->c->cpp and cpp->c->cs conversions. In case of lua it would be somewhat simpler, because we do not need to generate any wrapper .lua files. Nevertheless SWIG bindings will always be more complicated to write. I actually started writing my own bindings generator because i thought SWIG was too complex and i did not want to put in time to learn. After 3 months of hard work i realized i am re-implementing SWIG. Then i deleted my custom bindings generator and switched to SWIG… Because bindings are hard either way.

SWIG-generated class bindings are basically a class instance + IntPtr holding native instance pointer. As you can see it gets stupid real fast with types like StringHash, as it essentially is a value type in C++, 4 bytes in size. If SWIG wrapped it without manual intervention we would end up with 2 heap objects whenever StringHash is passed to C#: C++ StringHash would have to be copied to heap so we can have it’s pointer and then each class instance in C# is a heap object.

What i did instead is pass StringHash between boundaries as unsigned and implement C# struct StringHash holding uint. struct is a value type in C# so this becomes super-efficient.

See, StringHash is a very special case needing special care. For things like Material we are passing object pointers around already so letting SWIG to wrap them as it does by default is fine (terms and conditions apply!)

Doing a quick search I ran into this outdated article which states the following:

Until C++0x becomes widely implemented, it will be necessary to write specializations like this out long-hand, i.e. a specialization for functions with no arguments, 1 argument, 2 arguments, etc. This works, but is extremely tedious - variadic templates will ultimately make this a lot easier.

Does anyone have experience with these variadic templates?

Well, I use them.

And automatic AS bindings can be implemented, too.
In the similar fashion modern realtime bindings (w/o code generation) are done.

They would not be fully automatic though. It would be required to at least write simple manual binding that bind classes and methods (like pybind11) or write a simple API scanner that generates these bindings. Would work for lua/AS good enough. Not for languages like C# that also need .cs files generated.

Could you explain what you mean by this in more detail, it sounds interesting.

You create generic template functions like RegisterFunction that use variadics and c++ type traits to extract all information about function signature, and you build AS binding string basing on this information, like in the article above.
Just look at modern Lua bindings, they do almost the same except they need to do all this in real-time.
Theory is simple. Practice requires to properly handle every single aspect of c++ signatures and class traits. It is huge but totally doable project.

Like this sort of project for Lua https://github.com/ThePhD/sol2/blob/develop/README.md or pybind11 for Python, right? Or something more advanced than those?

Right. No rocket science, except that you need to know C++ template magic really well. Which may be like rocket science for some.

That sound like fully automatic to me, once in place of course.

It is still better than current situation by the order of magnitude, but you will have to bind manually every name you need in the script.
If you think it’s easy or not too much, just look at the size of our current AS bindings. Sure, they will be safer if automated, but they will not get any bit smaller.

Doesn’t the aforementioned API scanner take care of this?

Maybe a level of automation would be possible where the binding process could be part of compiling?

You mean automatically process C++ headers?
I’m not aware of any lightweight tools capable of doing it. SWIG is the closest thing we have, but I have no idea how hard is to reuse its functionality.

It’s hard and SWIG code is terrible. This would introduce dependency on externally installed libclang. There are bins for all platforms so it’s just somewhat nconvenient on windows.

Can you remind me how SWIG works in ***? Does it use binaries for libclang or what?

SWIG implements it’s own c++ parser.

Do you look at ASBindGen (C++ To AngelScript Bindings Generator) ?

Hello, i’m new in this forum, although i have been using Urho for the past 6 months.

I don’t wanna be a jerk here, but is AngelScript really worth it ? I mean, it seems a lot of work, just to keep using a language that is not really widely used outside of Urho.

I’ve used ASBindGen, and while it works ok if you want to bind AS user code, it was not appropriate for adding Urho Core classes. It uses comments in the code to know what to make bindings for, which pretty much polluted my source code. The code gen structure it produces is technically correct, but it does not play well with existing Urho AS integration code, nor was it designed to. I ended up using the generated code, but had to repackage it into a form like the existing AS integration. Now, I just maintain it by hand, once you learn it, it’s far less work.
And don’t get me started on the Lua binding with the custom constructors.

Let’s find out:

@brokensoul Welcome to the forums, btw!

Before running into Urho3D I had never even heard of AngelScript but I like how it is similar to C++. If this is true for more people, Urho is increasing the popularity of AS and so might a good autobinder, even if created with primarily Urho3D in mind.

I have the opposite - in one of my projects I needed a scripting language that was as close as possible to C++ and native calls to the x86 code. So I found AngelScript. And already working with him, I learned about Urho3D, in which he was used.

@1vanK suggested the following on GitHub:

Currently we use Doxygen for generation of docs. Doxygen fully parses C++ sources, so has full information about classes. Is it possible to use it information to generate bindings?

http://www.doxygen.nl/manual/features.html

Generates structured XML output for parsed sources, which can be used by external tools.

I have never seen doxy output used for binding, so I just assume this idea unviable. Tell me if I’m wrong.
I’m not sure if doxy extracts enough information, if it’s stable enough to reliably parse c++ headers, and I don’t even mention that one will have to write actual binding code generator.

Doxygen extract all information (even comments) because use clang.

Set GENERATE_XML = YES in file Urho3D\Docs\Doxyfile.in and build Urho3D with docs. Doxygen place all information about classes/structs/etc in separate files:

• Build\Docs\xml\struct_*
• Build\Docs\xml\class_*
• Build\Docs\xml\namespace_*
  …

Doxygen already split information to parts.

class_urho3_d_1_1_color.xml

...
<memberdef kind="variable" id="class_urho3_d_1_1_color_1af0749ad190652fe9b992185b65beac81" prot="public" static="no" mutable="no">
        <type>float</type>
        <name>r_</name>
...
<memberdef kind="function" id="class_urho3_d_1_1_color_1a06623b98b5524439f8a243d103b214dd" prot="public" static="no" const="yes" explicit="no" inline="no" virt="non-virtual">
        <type>unsigned</type>
        <name>ToUInt</name>
...

<memberdef kind="function" id="class_urho3_d_1_1_color_1acb5866e1447fd157ebd5a8292e6a5b6c" prot="public" static="no" const="no" explicit="no" inline="no" virt="non-virtual">
        <type>void</type>
        <name>FromUInt</name>
        <param>
          <type>unsigned</type>
          <declname>color</declname>
        </param>

Oh, I see, so it uses clang.
It solves both my questions but creates new one. Urho is built from source so it doesn’t have any external dependencies. We cannot build doxy from source, tho.

There is no need to force users to generate bindings on their own, just like he does not need to generate documentation or AngelScriptAPI.h file on his own (but he can do it).

I mean bindings can be automatically generated like documentation and placed in the repository.

@1vanK does it extract the default values for function parameters?

And I’m definitely in favor of it if it does, even if it’s something we have to run as a separate tool rather than something that the user builds and runs like tolua.

I see one more issue here.
Doxy doesn’t have annotations required for bindings.
How to mark functions that shall be ignored during bindings?
How to override bindings for specific functions with manually written ones?
Shall we invent our own language of annotation to use doxy for bindings?

I don’t remember whether the default values are used in bindings (bindings should not somehow change values), but

      <memberdef kind="function" id="class_urho3_d_1_1_text_1a7f99f0265997743f8e91b0436c80bd73" prot="public" static="no" const="no" explicit="no" inline="no" virt="non-virtual">
        ...
        <param>
          <type>float</type>
          <declname>size</declname>
          <defval>DEFAULT_FONT_SIZE</defval>
        </param>

      <memberdef kind="variable" id="_text_8h_1ae03d382e84a0a13b3dd8146e1dbc14a7" prot="public" static="yes" mutable="no">
        <type>const float</type>
        <name>DEFAULT_FONT_SIZE</name>
        <initializer>= 12</initializer>

we can use comments before function to mark all we need

It would be basically re-inventing SWIG, just worse.
Because all internal binding details will be in our public headers and in our published documentation too.

I think you saw *** SWIG files and they are nasty.
Imagine all this mess in our main headers instead of separate folder.

SWIG modules look awful because they contain a bunch of C # code, which should be placed in separate manually written files and already located in the output directory. The module should only contain a mark to ignore this class / function (because the binding is written manually and is already located where necessary).

Also, I don’t understand why property marks are needed, since properties can be automatically generated if a function name starts with “get” / “set”

You cannot do it if you don’t know where to put this code.
What if you need to add C#/Lua function for each class?
You cannot just make for_each_RefCounted.cs and write it there.
I’m not sure if generics can be used there, I’m not C# guy.

Because it’s Urho-specific rule, SWIG doesn’t know anything about it.
So we have our own scripts to generate property annotations.
If you use doxy, you will have to do the same, maybe on the different level.

Use copy to target dir

What if you need to add C#/Lua function for each class?

Examples pls. Also I don’t see why manual written file cannot contain everything I need (or was added there by a generator: file may contain “// PLACEHOLDER FOR ADDITIONAL FUNCTIONS”)

If you use doxy, you will have to do the same, maybe on the different level.

Doxy just give xml files, generator still need to write

   string result = ""
   foreach xmlFile
      if xmlFIle is class
         foreach member
             result +=
     if xmlFIle is struct
         ...

The very file you mentioned here:

SWIG modules look awful because they contain a bunch of C # code

How would you extract code in RefCounted.i into *.cs file?
I mean, maybe this is possible, I just have no idea how to do it.

How would you extract code in RefCounted.i into *.cs file?

https://github.com/Dviglo/Dviglo/blob/CSharp/Source/Urho3D/CSharp/Managed/Container/RefCounted.cs

It offers only a fraction of functionality of RefCounted.i. It’s not surprising for me that it’s simpler.

No instance cache. No utilities for automatic marshaling of raw and shared and weak pointers to RefCounted – your bindings are fully manual. No weak pointers. No derived classes support.

I added functionality as needed when porting examples, I threw the project in half, because C# is not a scripting language, but an analogue of C ++ (only slower).

Yeah, I ignore C# for the same reason, I just don’t need it.

It doesn’t change the fact that it’s pointless to compare code complexity when feature set is different by the order of magnitude.

Since Lua has simpler requirements, it may be ok with simpler bindings.

SWIG interface files are awful because they contain templates for type marshalling. We can not extract RefCounted.i to RefCounted.cs because that interface defines things that have to be added to every generated wrapper of subclass of RefCounted. Same is for type marshalling. You can not extract rules of how to marshal SharedPtr<T> into .cs/.cpp. You would still need a SWIG interface except then you would have another indirection to some hidden code in some .cpp file. And possibly pay a cost for function call while at that.

Also it is important that users can easily generate bindings themselves. Users will want to bind their own code and thus they must be able to. Suggestion to just generate bindings and include them in the repo sounds much like what UrhoSharp did and that is not a good solution.

Let’s be honest, this will not make it easier for users to create bindings. To create bindings, users will need to learn the new SWIG tool because it does not work in fully automatic mode.

Let’s be honest, better option does not exist.
You cannot have truly automatic bindings without annotations to handle exceptions.
User will either have to learn existing and popular 3rdPatry tool with documented annotation language, or our custom tool with our custom annotation language.

Amount of manual annotations in both cases will be about the same.

I talked about this earlier, that there is no magic that creates automatic bindings.

Yeah, exactly. We will have to do something manually.
How does it make custom tool better than existing tool?
Effort is bigger by the order(s) of magnitude, but the outcome is lower.

*** still does it in some cases, tho. List of RefCounted, renames, properties…

My other question is, should the user, when creating semi-automatic bindings, understand what result should be generated? I guess so. In addition to this, he now needs to learn the strange syntax of SWIG modules.

I found this

/// RGBA color.
/// @xmlonly IGNOE_IT @endxmlonly
class URHO3D_API Color

INGNORE_IT is written to xml, but no written to generated docs

What do you suggest?

There are only two fair options.
A) Bindings do not require manual update every time function signature or class interface is updated, exceptions are rare;
B) Bindings stay in separate repo and are maintained by dedicated person.

Any other option is basically freeloading.

Do you have an option where a person doesn’t need to learn strange syntax?

I take time to experiments with doxygen

This reminds … when I was doing the realXtend Urho port (at work) we also used Doxygen-based bindings generation to replace Qt’s JavaScript engine with duktape.

This is the C++ code structure inspection from Doxygen xml, originally written by Jukka Jylänki (clb):

And this is the generation of duktape bindings using the data generated above (ugly, but illustrates the idea):

Do you remember how did it turn out?
How much manual tinkering was needed?

There’s a caveat that we didn’t actually expose Urho, but rather the realXtend Tundra core classes, which in the port used Urho as an internal engine similarly like the original was using Ogre + Qt. But for what it was worth, the actual bindings worked well and similarly to the QScriptEngine-based bindings. There were some hacks and special cases built into the bindings generator .cs code itself.

I like how the BindingsGenerator was written in C# :).

To throw fuel on fire, shouldn’t AngelScript people write automated C++ binding tool mostly or entirely in AngelScript? I suppose possibly AngelScript and C++ since that’s their compatibility culture. Seems like they are the language community who should be trying to control their own fate, not Urho3D. Like, bring it up in their official forum and see what people have done and what they want.

I doubt it’s SWIG. Aside from being ugly as far as I’ve heard in all times in history, today I learned it’s GPLed. Didn’t realize. I don’t personally like worrying about convolutions, even if for this case it may not matter. I also hate contributing to GPLed projects, basically I will almost never do so. Big problem for indie game devs is almost every game project is GPLed, so spending time on open source games is mostly career suicide. Got off that boat after my Battle for Wesnoth debacle. Freeciv before that.

If AngelScript community doesn’t want to control its own destiny, then I don’t think it should be holding Urho3D community back. It’s tiny, micro dot of significance in broader world of language ecosystems. It’s not the only scripting language selling itself as similar to C++ syntax and C++ binding friendly. I don’t want to undermine extant Urho3D users, but they shouldn’t hold Urho3D progress hostage either. C++ contributors shouldn’t have to worry about AS problems when submitting pull requests to Urho3D.

Lua ecosystem for dealing with C++ is excellent and advanced. Many choices. Sol3 developer is very serious, has feature matrix of all major binding options, including the mediocre SWIG. Has strong benchmarks. Another author did kaguya, also has benchmarks that are close, so also considered serious. Good to have choice! Lua attracts language binding experts. That’s how “Lua jocks” roll, they can solve these kinds of problems.

Don’t think C++ pull requests should need to worry about Lua either. But in Lua’s case, pretty good binding tools are right there. Don’t know about 100% automated, but that goal seems realistic, given the expertise available.

Well that is not the same. Thing is current *** SWIG bindings have all pieces needed for user to wrap their own new classes with little care. Yes user would have to annotate every class with that refcounted macro (these annotations we pre-generate for engine itself). Anything else is optional addons. Now including binding code in the repository is essentially saying “here you can use Lua/AS/whatever, but you cant mix your c++ code in” which is unacceptable to me.

Strange syntax is not that strange once you get grip of it. I admit it is not ideal. But if you decided to write your own bindings generator you would be solving same problem SWIG solved already. I am telling you this as a person who out of lazyness to to learn SWIG wrote his own bindings generator for C# and then switched to SWIG. *** git history has my old and terrible bindings generator. Anyway ya all can learn from my mistake or can repeat it. Your choice

Edit: I misunderstood your question. User does not need to learn any strange syntax actually. All the hard work is done already. This is what user has to do:

%{
#include "my/class.h"
%}
%include "my/class.h"
URHO3D_REFCOUNTED(MyClass);

That’s it. It is possible to reuse SWIG interfaces in order to take advantage of type marshalling we already implemented. It would be crazy if each user had to write rules for string marshalling. There would be hard cases like marshalling std::shared_ptr that we do not implement because we do not use it.

Irrelevant personal preferences are irrelevant. The fact that you do not like the license has no effect on quality of the tool. This is also irrelevant because product never ships with any SWIG code and therefore it is not a derivative project. SWIG interface files are explicitly mentioned as a license exception and are not covered by GPL. SWIG is a compiler, nothing more and it’s license does not extend to projects that use it any more than license of GCC.

SWIG is perfect for *** because all languages we will possibly ever support are covered by it. It is not the case for Urho3D so if there is intention to keep AS then by all means SWIG may not be the best choice. But it still is better than any custom solution that i can guarantee will be dead once person who wrote it moves on to do the next thing.

Well, I don’t really like GPL too… so what?
Doxygen is GPL too and Urho uses it to generate docs.
How is it different from using SWIG to generate bindings?

Community preferences matter though. Like for AngelScript community controlling their own destiny. Have you asked what they want to put the energy into supporting? AngelScript is zlib, and that is likely their dominant development culture.

SWIG’s coverage of Lua is grossly inferior. I’m aware that you don’t seem to like Lua anyways. It means that you are interested / working with technology that is bad, to the extent that Urho3D wants to continue to support Lua or AngelScript. I’m showing up here and putting in my $2 (I’m verbose) because I’ve done a lot of homework now. I hope I can persuade people to back different strategy than SWIG. I’ll also make no bones about the fact, that I don’t care about C# and think it’s open source suicide for Urho3D to ever worry about it.

Furthermore I note you can’t count on SWIG to continue to support minority languages in its portfolio. I used to be CMake buildmaster for Chicken Scheme. That’s another one of my open source debacles. Yes Chicken Scheme doesn’t have CMake, but it did, for awhile under my watch. Until we had a big fight about author not liking CMake because it was “buggy”. As though he never wrote a bug. Somehow over the years, Chicken Scheme got into SWIG, I don’t know how. Fast forward to SWIG-4.0.0 release notes and I see that support is gone. Along with CFFI, CLISP, UFFI, and Pike, names of things I recognize from “back in the day”. Says to me, language authors and communities decided to dump SWIG as inferior and control own destinies. SWIG didn’t get the love because there’s nothing to love. AngelScript definitely has the profile of a language that, long term, would get dumped.

I also suspect your best C# option is not SWIG. Won’t be doing any research on that, but c’mon. C# ecosystem is huge, there has to be better “talk to C++” solution than SWIG.

Docs aren’t code. There’s a well-defined problem boundary where interference is not a problem. Somebody writing docs, doesn’t want to cut and paste their intellectual effort into a program. Whereas, programmers want to do this all the time. I don’t want my intellect wasted on the GPL, speaking for me personally.

Note furthermore that Linux’s success really isn’t GPL, it’s GPL with linkage exception. Really big pragmatic difference of philosophy there. Not that I want to contribute to Linux kernel anyways, just saying that what people tend to think of as “GPL success story”, isn’t actually so. It’s much more similar to LGPL and it might take a lawyer to spell out the exact difference, other than marketing.

Whether Doxygen would work as a code generation tool, seems to be up to 1vanK’s research and contemplation at this point. My wonderment, is whether this will handle Windows-specific compilation. Historically, Clang broke down on that, but it’s been a long time so maybe it’s been solved by now.

Meanwhile, I know that Doxygen is not needed or desired for Lua C++ binding.

I think AngelScript community should be consulted about what they think of the idea.

It is not important to bind all languages. There should be a business strategy for any choice made, for Urho3D’s future. So having generic XML specs that anyone could use for anything, doesn’t strike me as a value add. It’s all contingent upon what a specific language is capable of doing with C++.

@bvanevery to be honest i do not even read most of your brain dump, just skim it over. That is way too many words for not saying much…

I understand, but at the same time, you are biased towards your own *** development. You are of course not equally vested in what is best for Urho3D. Maybe by way of Python 3.x, someday you can live “downstream” of Urho3D, but right now you are forked. I am trying to persuade people, possibly including you, not to walk down this SWIG road. Many words are required to explain, why not just grab SWIG and call it a day. The TL;DR version is “because it’s a bad idea” but of course nobody who actually thinks, is going to accept that. You might start meditating about this in the future. You might not, because of your bias.

My writeup doesn’t have to be for you. You’re forked. My writeup is for Urho3D community decision making. I’d like to head SWIG off at the pass, make it stop, before that train gets rolling in any way.

There are 2 binding problems to solve for Urho3D right now. Lua, and AngelScript. Nothing else.

I looked through swig docs for lua and there indeed is no mention of director classes. You are indeed right about swig for lua being suboptimal. It is great for c# though. And by that I mean there are so many nasty cases handled… I would totally go with pybind11 for python or something comparable for lua in that case. Too bad cpp metaprogramming magic isn’t really a viable option for binding to c#.

You mean you researched lots of things in the C# ecosphere and there’s uniform agreement that this is some impossible and foolish developer journey?

Right. Problem is there is no pure c API as flexible as 8n say lua. So we need to wrap c++ in a c API and we need a managed wrapper that consumes this c API. C++/CLI might make it possible, but it is windows-only therefore not an option. Short of generating IL code manually… we are stuck with generating bunch of c and cs code. Situation indeed isn’t that good when it comes to cs bindings.

Mono never provided this?? If true, Good Lord.

Nah, mono has just c# compiler. But it has extensive c API. But probably not enough to bind it like lua. Btw if you are wondering - unity binds same way: a mix of c# wrapper code + c API, manually written. So yeah…

I am really confused now. What is the Mono Runtime? They say:

The Mono runtime implements the ECMA Common Language Infrastructure (CLI). The Mono runtime implements this virtual machine.
If you are interested in the technical aspects of the Mono runtime check the Runtime Documentation.

I thought a CLI VM is a CLI VM is a CLI VM. You should be able to “run languages” on this. Shouldn’t be a Windows thing. Thought that was the whole point of ECMA standardization.

C++/CLI is a c++ dialect that compiles to a mixed mode assembly containing both managed CLI bytecode and native code. Mixing c++ and .NET is easy. It’s an awesome tech. Too bad it’s not xplat

My lingo is out of date. This sort of thing used to be called “Managed C++”. In 2004 the so-called “C++/CLI” takes over. Ok, so the open source world never came up with an equivalent. I see the problem now.

Note though:

It has been standardized by ECMA (ECMA-372).

Nobody in open source picked up that ball in practice?

There was at least one attempt based on llvm but it was left unfinished. https://github.com/tritao/clang-cli

I’m not clear on whether that’s the same thing as the Nuanti C++/CLI compiler, circa 2012. Searching around, it seems to have vanished from open source radar. I don’t see Alp Toker as an author in the Git repository you gave, nor any mention of Nuanti.

Never heard of one you mentioned. One i pointed to was an experiment by João Matos (employee of Xamarin).