Nuitka is sort of that, but it still links against CPython to provide object semantics and such. What's your end goal here?

Let me explain a trick. Jinja2 is a template script that can generate text from templates. What you need to do is write your C code template main.c.j2:

#include <stdio.h>

int main()

{

    printf("hello {{name}}.\n");

    return 0;

}

then you can transform it into C code with the trans.py:

import os

from jinja2 import PackageLoader, Environment, FileSystemLoader



TemplateLoader = FileSystemLoader(os.path.abspath("."))

env = Environment(loader = TemplateLoader)



template = env.get_template("main.c.j2")



print(template.render(name = "Jack"))

run python trans.py and you will see this C code on screen:

#include <stdio.h>

int main()

{

    printf("hello Jack.\n");

    return 0;

}

That's real C code, {{name}} is replaced into Jack. See the Jinja2 doc for more interesting features.

If you want to do this simply with just standard Python stuff you might try making template files that use the Python 3 style string formatting. For example, a class template might look something like this:

{className}::{className}()
{{
}}

{className}::~{className}()
{{
}}

{className}::{className}(const {className}& other)
{{
}}

{className}& {className}::operator=(const {className}& other)
{{
    return *this;
}}

Then your Python code is super simple:

d = {}
d['className'] = 'MyCPlusPlusClassName'
with open(yourTemplateFile, 'r') as ftemp:
    templateString = ftemp.read()
with open(generatedFile, 'w') as f:
    f.write(templateString.format(**d))

Of course you can add lots of other fields alongside 'className' using the same trick. If you don't need stuff like conditional code generation you can get a lot of mileage out of something this simple.

So you want to translate some (yours) domain specific language (DSL) to some flavor of C++. I am doing exactly the same in my GCC MELT implementation (inactive as of 2017). It is a Lisp-y domain specific language to customize the GCC compiler. See also this answer giving slightly more details, and this one giving relevant references.

Here are some advice; I cannot be more specific because I have absolutely no idea what your domain specific language is for. Is it Turing-complete (perhaps accidentally)? Probably yes! Read also this draft report.

• if you never studied it, study compiler techniques (including lexing & parsing). They are highly relevant.

• read Scott's book Programming Language Pragmatics (at least for inspiration).

• consider (instead of developing your own DSL) embedding some existing interpreter, perhaps Guile or Lua. It might be considerably simpler.

• be aware that designing and implementing a passable DSL which is compiled (perhaps to C++) is a lot of work (years!). Read the mythical man month, Hofstadter's law, etc... Perhaps you want (or not) to bootstrap your language implementation...

• if your DSL is somehow useful (e.g. you are not the only one writing scripts in it), be aware that eventually some crazy user would code large scripts (many thousands lines) in it. So design the language seriously!

• first, you need a well defined (in your head!) representation of the abstract syntax tree (which might not be a tree, but a graph) of the generated C++ code and you should build (in memory) the AST before emitting the corresponding C++ code

• you might want to emit #line directives (referring to positions inside your DSL scripts). It is very useful (for debugging) but emitting them is quite hard.

• you might need several other internal representations, between the DSL source and the generated C++ code, and your C++ code generator (actually a specialized compiler) is transforming some representations into another ones, and finally into an AST which is emitted as C++ code.

• you should care about the memory model; so read about garbage collection techniques (at the very least, for terminology and concepts), see the GC handbook. You probably don't want a stupid user script to crash the computer or the process. So you need to handle memory (& memory leaks).

• perhaps you might consider, instead of generating C++ code, to use JIT compiling techniques: GCCJIT, LLVM, libjit, asmjit, ...

• perhaps SciLab, R, Octave, Julia might be relevant for your work (because they might avoid you to start your own DSL)

• On Linux specifically, you might generate C++ code in some temporary file, compile it into a plugin (read Drepper's paper How To Write Shared Libraries and about Invoking GCC and see elf(5)) , then dlopen(3) it (and use dlsym(3) to get function pointers). Read then the C++ dlopen mini-howto. The RefPerSys project is doing that.

The CLASP project should be relevant: it is about Common Lisp and molecular chemistry simulation.