You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the CPACS schema we have many types that wrap sequences, e.g. Fuselages, Wings, Segments, Positionings. From these the code generator creates classes that have a std::vector<std::unique_ptr<XYZ>> member, where XYZ is Fuselage, Wing, Segment, Positioning, respectively. Each generated class provides getters and setters for this vector.
For the internal python bindings of TiGL, however, we prefer not to expose std::vector and std::unique_ptr to the Python API (at least to a large degree). This means that the output of CCPACSWings.get_wings in Python is not a list, but an opaque SwigPyObject that cannot be subscripted.
For most of these "sequence classes" we have getters for elements in the customized classes. For example in CCPACSWings, which is derived from CPACSWings, we have the following getters:
// Returns the total count of wings in a configuration
TIGL_EXPORT int GetWingCount() const;
// Returns the wing for a given index.
TIGL_EXPORT CCPACSWing& GetWing(int index) const;
// Returns the wing for a given UID.
TIGL_EXPORT CCPACSWing& GetWing(const std::string& UID) const;
These getters are automatically exposed to Python. They are necessary to traverse the CPACS tree if we don't wrap the std::vector<std::unique_ptr<XYZ>> classes with SWIG.
Therefore, it would be quite convenient if these getters and setters were part of the generated classes. Otherwise they would have to be added manually to any class that is exposed via the Python bindings.
In the CPACS schema we have many types that wrap sequences, e.g.
Fuselages
,Wings
,Segments
,Positionings
. From these the code generator creates classes that have astd::vector<std::unique_ptr<XYZ>>
member, whereXYZ
isFuselage
,Wing
,Segment
,Positioning
, respectively. Each generated class provides getters and setters for this vector.For the internal python bindings of TiGL, however, we prefer not to expose
std::vector
andstd::unique_ptr
to the Python API (at least to a large degree). This means that the output ofCCPACSWings.get_wings
in Python is not a list, but an opaqueSwigPyObject
that cannot be subscripted.For most of these "sequence classes" we have getters for elements in the customized classes. For example in
CCPACSWings
, which is derived fromCPACSWings
, we have the following getters:https://github.com/DLR-SC/tigl/blob/c5ccbb2b3a22a397e5fcb727cec1b1d1647be5cc/src/wing/CCPACSWings.h#L52-L56
These getters are automatically exposed to Python. They are necessary to traverse the CPACS tree if we don't wrap the
std::vector<std::unique_ptr<XYZ>>
classes with SWIG.Therefore, it would be quite convenient if these getters and setters were part of the generated classes. Otherwise they would have to be added manually to any class that is exposed via the Python bindings.
This is related to DLR-SC/tigl#936.
The text was updated successfully, but these errors were encountered: