jordan-cottle / pythontocpp Goto Github PK

dictionaries can map nicely to std::unordered_map. The std::unordered_map has an initializer that can probably be used to imitate the python dict syntax.

This will primarily be for supporting the dict conversions from #2 for custom types.

Automatically convert import statements to #includes

#includes are a lot less intelligent than the python import system. Do not attempt to automatically handle including the same thing multiple times across multiple files at this time.

Type information is critical in c++. For the converter to support a wider array of features and contexts a more robust method for tracking and expressing the type of a variable needs to be implemented.

Properties are not going to be natively supported in c++.

Translating them to a private attribute with a public getter/setter should be possible though.

If there is a mechanism to support an accessor interface that won't require explicit function/method calls (preserve the way the python code looks) then do that.

It is common for c++ source to be split into header and cpp files.

The output from converting a python file should generate a header file with just the declarations (and some include guards) and the cpp file with just the implementations.

Any private module functions can be defined in the cpp file only. Since they aren't in the header, they shouldn't be included when the header is used.

This is primarily to extend the support for dict mentioned in #2

To support easily translating python classes to c++ classes, each dunder method could be an abstract interface.

Then when a class is parsed and translated, it can multiply inherit from each of the bases it implements. If one of its super classes already inherits from one of the bases, it should be ommitted from the subclass declaration.

Automated conversion will be nearly impossible without at least some of the built-ins.

range will be critical for writing standard c style for loops.

str will be important for explicitly invoking __str__.

A good number of the dunder methods would be valuable as well.

I might be worthwhile to implement a base PyBase class/struct that implements a lot of the same interfaces python objects expect to have. Then all new classes that don't have an explicit super class can extend from that predefined base to make parsing/converting much easier.

A similar approach that defines a series of functions with the same(ish) signatures as the python built-ins may be valuable as well. Then functions wouldn't need to be mapped to another name/signature.