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

Tarmo_Pikaro · November 25, 2018, 10:05am

Watched through this video: https://www.youtube.com/watch?v=f9Xfh8pv3Fs 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 http://www.csscript.net/ 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.

Tarmo_Pikaro · November 25, 2018, 10:06am

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

Tarmo_Pikaro · November 25, 2018, 10:06am

I’ve also coded C# scripting support manually

github.com

tapika/syncProj/blob/master/CsScript.cs

//#define NODEBUGTRACE
using System;
using System.Linq;
using System.Text;
using Microsoft.CSharp;
using System.CodeDom.Compiler;
using System.IO;
using System.Reflection;
using System.Diagnostics;
using System.Text.RegularExpressions;
using System.Collections.Generic;
using System.Threading;

/// <summary>
/// class for executing c# script.
/// </summary>
public class CsScript
{
    static CSharpCodeProvider provider;
    static ICodeCompiler compiler;

This file has been truncated. show original

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
(https://github.com/tapika/syncProj/blob/master/CsScript.cs) - 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:

not supported: c# script (.cs) ====(syncProj)====> .csproj/.sln
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.

Tarmo_Pikaro · November 25, 2018, 10:07am

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++

https://molecular-matters.com/docs/livepp/documentation.html
https://molecular-matters.com/products_livepp.html

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
includedirs(“include1”);
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.

Tarmo_Pikaro · November 27, 2018, 5:07pm

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.

And there exists mechanism to load native C++ .dll directly from memory:
https://www.joachim-bauch.de/tutorials/loading-a-dll-from-memory/

which can be used also for hotpatching functionality if necessary (e.g. combined with remote hooking / remote memory overwrite from https://sourceforge.net/projects/diagnostic/ ) - 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.

system · December 11, 2018, 5:08pm

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