Some thoughts about C++ script-ability versus project generation tools

Watched through this video: and this raised some ideas.

First of all, let me try to roll back time a little bit.

Back in 2012 / 2013 I was scanning through cling support - and back then there was a lot of problems with clang and cling compilation. Now by trying same compilation approach in 2018 I’ve noticed that clang and cling compile almost out of box, with exception to clingDemoPlugin. (visual studio is not supported according to Vassil Vassilev).

I find out also that there existed C# scripting support with
additional Visual studio addon, using which you can run C# code without having project.

Also I’ve created my own project generator for C++ project, called syncProj.

It’s similar to cmake with exception to that I’m using C# language instead of custom odd cmake language dialect.

I’ve also coded C# scripting support manually

by collecting .cs dependencies from .cs scripts themselves.

After 1-2 years of expirience with it I’ve realized that it would be better to use Visual studio official open mechanism instead of custom “CS-Script Tools” visual studio plugin - simply because C# scripts become more and more complex and you often need to open them up and even debug in similar manner to other projects - it would be better to have same recently opened solutions / projects list in Visual studio for C# scripts as for rest of projects.

Also what I have initially performance measured for example C# script compilation time versus for example premake5 .lua compilation times - .lua compiles faster even thus C# executes faster (simply because .lua is compiled every time, just temporary boost, will not have effect if .lua gets precompiled versions).

Besides compilation performance, there is also a question in overall programming language performance - same issue as you have highlighted in your video. Replace all c++ with python - and it will kill performance quite seriously.

In similar manner I see C# versus C++ - if you need to tackle a lot of 3d graphics with fast performance, better to go with C++ than C#. For syncProj needs (solution / project generation) it’s not so much about performance,
but I see other code as well besides syncProj, where performance is relevant.

When coded C# script support initially - I have also identified that besides compiling C# script manually
( - it’s also possible to generate project and solution files instead (.csproj + .sln) and compile .sln using normal build tools.

But at that point C# script project generation was not supported:

  1. not supported: c# script (.cs) ====(syncProj)====> .csproj/.sln
  2. supported: c# script (.cs) ====(syncProj)====> .vcxproj/.sln

So there was of analyzing second approach (1) anyhow, as it was not supported.

But syncProj is capable of generating C++ projects (.vcxproj/.sln), after which I could theoretically switch it to generate solution / project for C++ “script” itself. Basically C++ script would not be script anymore - it would be
c++ console application, it will have dynamically generated project & solution, and will be normal application in that sense.

What is my understanding also is that besides aiming towards scripting direction, you try to aim also for keeping everything at run-time - I have also identified that there exists C++ compiler option for making .dll replacable at run-time - called “Create Hotpatchable Image -> Yes (/hotpatch)” - option
existed there for ages, but noone used it before actively - I’ve noticed some demos where this option was used in live++

I haven’t used it by myself, but still curious about how to use it. (seen what kind of magic javascript can perform with their code (So called “hot reload”) - and I find it absolutely stunning, even thus it’s buggy and not always working as it should)

Let me roll bit back as well - you might ask - why you do not want to use cmake language instead of C# or C++ language ?

Try to modify syncProj C# script and cmake file, which goes easier for you ? Debuging support, intellisense, and error handling in tool are main reasons currently. cmake language dialect is not easily extendable as well.

One another thing which I want to try out with syncProj2 (potential future generation of syncProj) - is being able to monitor Visual studio solution / project in live manner and generate / update script based on end-user interactions.

So user adds include directory “include1” to project, and .cs project gets
script line.

Also syncProj2 - upon which “scripting” language it will be based upon is still open. At the moment I see following alternatives / candidates: C++, C#, Python. (C++ for it’s performance, C# for it’s solidness)

If you have some proposals, let me know.

My requirements are: Windows & Visual studio (64-bit compilation) must be supported.
Optional / nice-to-have: C++/cli generation is supported (syncProj has this already), C# project / solutions generation is supported. (not supported at the moment, but there is a small need to support this), C++ “scriptability” on some level needs to be supported.

After deeper thinking about hotreload - how it could be implemented and what kind of mechanisms there should be on background, I’ve understood that I’m completely newbie on subject.

First of all - I have found a collection of links with hotreloading feature:

It would be nice if C++ modules would be not only loadable by unloadable as well. :slight_smile:

And there exists mechanism to load native C++ .dll directly from memory:

which can be used also for hotpatching functionality if necessary (e.g. combined with remote hooking / remote memory overwrite from ) - but by briefly checking Aurora project ( Runtime Compiled C & C++ Solutions), I’ve understood that I know nothing about subject, need to analyze the alternatives and debugger behavior with each framework.

Switching everything to run-time for C++ sounds too perfect to be true, but I definitely miss debugger helping me in this jorney.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.