Make C++ as first-class language to choose in the Attach Node Script dialog

[nonunknown]

Describe the project you are working on:
A 3D Platformer

Describe the problem or limitation you are having in your project:
I Would like to have some features done in c++

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
Make c++ scripting language as a option to attach into nodes like csharp. Actaully the way to make cpp files needs to do a lot of configurations,compilations, and so on to simply make one script. So by adding it as a language option would work like csharp works, just select it and code!

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:

If this enhancement will not be used often, can it be worked around with a few lines of script?:
It will be used often
Is there a reason why this should be core and not an add-on in the asset library?:
This is already possible but for someone who wants to focus on game-making its not intuitive

[Xrayez]

I think this can be (partially) implemented as #119 / godotengine/godot#11080 , also see #565.

Formally, I think GDScript could be already considered as a C++ scripting language to some extent as it acts as a wrapper over C++, but I get what you suggest.

[girng]

I was thinking of this idea a few years back, but i could never put it into words concisely. I think I ended up not posting it or closing my issue. I can't remember. Kudos to @nonunknown for having a good mock-up picture!!

[willnationsdev]

Technically speaking, there is already a system for registering third-party languages as built-in languages based on a plugin: PluginScript (the thing that the Python bindings use). Both NativeScript and PluginScript both run off the GDNative C API.

Anyway, while I do believe you could theoretically make C++ an integrated language that way, there would be two weird details about it.

1. Most of the time, C++ code is broken down between .h/.hpp and .cpp files. Godot has a pretty strict one-file=one-resource assumption. You'd need to not only register them as resources in the engine, but also teach the engine how to search for and pair up files based on class name or something (and even that wouldn't be terribly reliable since you could have duplicates in different parts of a project's directory structure). This is just begging for a huge amount of overhead and maintenance that no one will want to put up with.*

2. The Create a built-in editor tool for organizing and mass/selectively compiling GDNative projects and addons #119 proposal goes the other route and brings NativeScript C++ up to snuff as far as comparability to C# and GDScript is concerned. It's also arguably better since the maintenance work done for that language also benefits every other NativeScript language, not just C++. The same cannot be said for a PluginScript solution.

* Yes, you could just mandate that C++ scripts have to be header-only or something, but then you're also blocking the engine from being able to include and use most third-party C++ code. NativeScript doesn't have this limitation.

Given the vast difference in quality between NativeScript C++ (good) and PluginScript C++ (bad), and because we already have a proposal for NativeScript C++, this proposal could be, in my opinion, closed as its scope is already covered by another proposal.

[nonunknown]

maybe a new kind of file: .cph (cplusheaders) which points to all files related to a cpp -> (hpp and h)

[blockspacer]

Note that C++ can be used as scripting language (via Cling interpreter) and how to do it is described at godotengine/godot#31630 (comment)

Main benefit from Cling-based approach in ability to disable C++ interpreter and compile C++ as usual for max. speed (example: code in C++ without re-compile in dev. mode, but compile C++ as usual in release builds).

Is anyone interested in proof-of-concept demo that uses Cling interpreter?

[nonunknown]

@willnationsdev @Calinou I was thinking here, maybe this language makes possible to have what we need/want

https://marcobambini.github.io/gravity/#/

this means we can easily have a language attached to a node, that doesnt need to recompile anything and its very c++ like. Any thoughts on it?

[Calinou]

@nonunknown That's unrelated to this proposal, which is about having "proper" C++ as a first-class language. I don't think we need to officially support yet another uncommon language in Godot 🙂

[nonunknown]

well I understand it, I just mentioned it cuz I thought using c++ as first-class wouldnt be possible!

[willnationsdev]

@nonunknown If anything, someone could create GDNative bindings to Gravity and it would be yet another option people can use just like C++, Nim, D, Rust, Haskell, etc.

The notion of using C++ as a "first-class" language is more about improving the usability of NativeScript itself to make it behave more like a "first-class" language.

Theoretically, if #119 gets implemented, you could teach the editor to also detect the presence of GDNativeBuild script types and generate new options in the "add a script" popup that would generate language-specific source code files and a .gdns file to go with them. You could also program the scene to require a re-compilation of any modified language-specific scripts prior to actually executing a scene the same way that the editor does it for GDScript and C#.

At that point, the barrier between what is and isn't a first-class language becomes so miniscule that it hardly matters ("Oh no, I have to have a .gdns file paired with each of my .h/.cpp files. C++ isn't a legit first-class language! Booooo", etc.).

[touilleMan]

Hi, just my 2 cents on this topic:

Here is what I would consider "first class citizen C++":

1. C++ API to access Godot features
2. integration into the Godot editor: C++ choice from the "create new script dialogue" syntax highlighting, code format and linter etc.
3. build system embedded into the Godot editor so that hitting the play button would compile what's needed before running the game

The good news is I think Godot already has everything needed to achieve this \o/

1. is already done by Godot-CPP
2. would be achieved by creating a pluginscript module. It could typically detect the path of external tools such as clang-format (and allow user to customize their path in the Godot project settings !) and manage the creation/update of the gdnlib/gnds files
3. would be achieved by creating an editor plugin and overwritting the build method, it gets called before running the game and can return a boolean to indicate something went wrong

Finally the whole thing should be packaged and provided through the Godot AssetLib, so C++ support would be trivially simple to install ^^

@Zylann since you are the more active on godot-cpp, I'm curious on what you think this ;-)

[Xrayez]

There's https://gitlab.com/turtlewit/godot_cpp_helper_plugin which can help this already I think, not sure if this was mentioned before.

[touilleMan]

@Xrayez wow thanks for the link, this is a super cool project ! (I'm just sorry I don't know Kat Witten's github nick to congratulate here her 😃 )

[Zylann]

From the first post:

for someone who wants to focus on game-making its not intuitive

And you want C++? It can be made much friendlier with a bunch of tooling, but keep in mind C++ is a beast many consider to be broken. I personally like it, but IMO it's really not the best language if your goal is to focus on making a game, which is why even Unreal put so much effort into developping Blueprints, and right now is apparently preparing a new scripting language. It's not a choice to take lightly just because "C++ is fast".

From touilleMan:

C++ API to access Godot features

That would unlock a lot of nice things, but I'm not sure this will ever happen because Godot was absolutely not written for this, but it's not impossible (my previous engine was basically built that way). The hard part is keeping libraries compatible because compared to C, the ABI can break for every tiny version or even compiler versions, such that to share something, you would do so by source code and not prebuilt binaries, and let the user build it assuming they have the right compiler (which can be problematic for plugins).

integration into the Godot editor: C++ choice from the "create new script dialogue" syntax highlighting, code format and linter etc.

Godot needs to integrate a language server client to have rich coding experience and implement a debugger interface for known C++ debuggers. But honestly, I would still not use Godot as a C++ code editor, there are much better external editors for this at the moment.

build system embedded into the Godot editor so that hitting the play button would compile what's needed before running the game

That could work for game scripts but much harder for plugins or tool scripts because the libraries (and then all tool scripts currently loaded) have to be pulled off somehow, just so Godot can overwrite the library.
Also, it means we need to either define one single build system that always work with minimum user intervention (such as having to edit build scripts), or support every build systems that people want to use, considering people may want to also use third party libraries which may need specific setup. Also requires a compiler toolchain of course.

is already done by Godot-CPP

This allows to make NativeScripts. These are scripts that can talk directly to Godot using ptrcalls, as long as the language can talk to C. And by this, I mean the language gets direct pointers from Godot, and Godot gets direct pointers from the language, without going through variants or maps.

would be achieved by creating a pluginscript module.

I'm not well versed into PluginScript but from what I've seen so far, it's not designed to handle compiled languages that "talk to C directly", but rather more oriented toward dynamic languages, which doesn't fit C++. So I'm really not sure about it being a candidate here.
Besides, it assumes we could identify a script by its file, while C++ does not have this, and can even have multiple classes per file (and is much harder to parse than C# if we want to associate a file). You have to choose either cpp or header file, which is messy unless you associate by class name. You also loose the info of which library the class can be found, unless once again you suppose all C++ "scripts" go to the same library, which is not true with plugins (which people can ship precompiled). There is a bunch of simplification work to strip away just to get that "scripting experience", which means imposing rules to how you code and compile. Unreal is the best example I know about it, and Godot can't get as close to it in its current design.
(the absolute need to associate a script by file and not by class name still bothers me in general like with C#, as well as the idea of calling this "scripting" in C++, when C++ is extremely far from what a "scripting language" is for the majority of devs).

would be achieved by creating an editor plugin and overwritting the build method, it gets called before running the game and can return a boolean to indicate something went wrong

Again assuming all toolchain is correctly setup it's no big deal, although you'd need more than just a boolean, you need colored error logs and the ability to click on one to go to a file etc...
Godot has lots of bugs in more used areas already, and adding this on top is a massive amount of work overall. I dont have enough built confidence to stuff this into Godot yet compared to GDScript. Not saying it's impossible though.

---

My concerns about C++ and Godot are actually quite different from wanting to "make it more like a scripting language". It's more about the fundations.
In short, here are the things I miss from C++ and GDNative:

• The ability to write C++ classes in a dynamic library that get truly integrated as engine classes, to the best degree of possibility, much more like writing a module than adding a scripting language. It's the language of the engine. In a way, having the engine being designed with a C++ API would pretty much do that, but we know it's unlikely to happen so it may be done in other ways. It's just that having C++ classes go through the scripting layer still adds up overhead and limitations.
• As a result, the ability for C# to have access to these classes, not just GDScript, which makes much easier to share and friendlier native extensions to the engine. Currently using a NativeScript library from C# is terrifying, both because of the code the user has to write, and because this code has to go through several layers of inefficient reflection rather than being integrated natively.
• And included in this, having a rich API. Classes registered with GDNative at the moment are close to being black boxes even when interacted with GDScript, and can cause crashes if "not called properly". No types, no checks. I mention C# and GDScript here despite the issue being about "C++ as first class", because far from everyone writes all their one-use game code in C++, engine extensions with nice APIs are important too.

The rest is about tooling, like this issue mostly notes. I think a lot needs to be defined beyond just the option of adding a "C++ script".

[aaronfranke]

Closing as obsolete as of the new GDExtension system. It actually goes in the opposite direction, GDExtension classes behave more like engine built-in types, while GDNative classes behave more like scripts you attach.