Handling native side (C/C++) nested structures in Wren

[stopaloglu]

Hello guys,

I have just started to learn Wren, sorry in advance, for my dummy expectations if there is.

I am trying to access (set/get) some C++ classes which is nested (more than 3 levels), i.e. some classes includes other classes and all classes may have leaf nodes (basic types that can be set/get). Both (C/C++ and Wren) sides shall be auto generated during production, so I will just edit some templates. I cannot find a guide about nesting, is there an idiomatic way, Wrenish way to handle this problem?

I asked the problem to ChatGpt and Gemini, they took me to the open seas, showed me around for a while and left me on an island I didn't know :) . After 5 days of struggling, I determined that 50% of recommendations of these AI tools are definitely incorrect about the subject.

Thanks in advance, regards

[mhermier]

Hi, Please provide an exemple code of what you are trying to do. The description is vague enough to be hard to help you. If you don't succeed, you are probably try to do too much in C/C++ trying to handle the wren side. Making simple is hard, and wren callbacks must be simple.

[stopaloglu]

Hi again,

Let me try to describe what I mean with the nested structs in a simplified way. I hope I can.

C/C++ side:

struct ComposedField
{
	int i;
	double d;
}

struct Message
{
    float f;
    struct ComposedField c;
};

struct Package
{
	struct Message m;
	struct MessageX mx;
	   :
	   :
	//only Message structs on this level
};

struct Package p1 = {0};

### Wren Side:
//I wanted to access fields (or setters/getters) in the following way on Wren Side

p1.m.c.i = 15
p1.m.c.d = 42.0
p1.m.f = 6.0

System.print("d: %(p1.m.c.d)");

Notes:

• By the nature of the app, I need to preserve the composition hierarchy.
• Structs may define setters/getters for the leaf fields (int, double, float, etc.).
• C/C++ side allocates the object on the "Package" level only, in the example, "p1" represents the object.
• My main problem is handling nesting like "p1.m.c."

For Wren side, ChatGPT recommends some "Cached Proxy" Patterns, with getter/setters, sometimes it suggests full foreign wren classes, etc. I have totally lost.

Thanks,

[mhermier]

What I would do in that case, is create view objects. Each view would have a wren handle to the Package and a raw pointer to the viewed structure. In practice it looks like a shared pointer.

[stopaloglu]

Actually I don't know anything about view objects.
I searched a bit and I assumed that I need to implement an object on C/C++ side to keep a WrenHandle to the root object as you wrote,
and any other necessary data about the native object, like pointer to the native viewed object or offset, root object address, some validity flags, etc.
Are my assumptions are correct? Could you please share me some tutorial or example code about this if you know one?