Does Zngur support subclassing a C++ class directly in Rust

[Omkv28]

Does Zngur support subclassing a class in Rust that was originally defined in C++, including classes with virtual and pure virtual (abstract) methods?
If not, what is the recommended pattern in Zngur to achieve similar behavior?

[hkalbasi]

It doesn't currently, but it is a good idea to expose C++ classes as a trait in Rust to be implemented for Rust types. I need to think more about it, but in the first glance it seems feasible.

For now, you can write a class wrapper for the Rust type, inherit from the C++ parent, and call the rust methods in the C++ implementation.

[adsnaider]

I just ran into a situation where I would really want this.

I'm trying to interop async rust with a custom C++ async-like runtime. Rust futures need to be wrapped in a pointer indirection since their sizes are not known. In order to "inherit" from a generic C++ task, I would have to wrap my pointer in a C++ Task class. But since the runtime expects pointers, I would have to heap allocate this task too which isn't ideal...

For a feature like this, I would imagine that we would have to implement the Rust struct differently by adding the virtual dispatch table at the end of the struct. I don't know how this all plays out with strict aliasing though... C++23 has std::start_lifetime_as but that's not where the industry as a whole is right now

[hkalbasi]

I think we don't need to have the C++ vtable in the Rust struct. We just need to inherit from the C++ class in the zngur generated equivalent of Rust type. But I'm not sure if this feature helps with your goal of having one level of heap indirection.

[adsnaider]

@hkalbasi that wouldn't let you call into virtual functions from rust though

[adsnaider]

I think the problem with what I would want is that it basically requires, by definition, that we can have C++ objects in the Rust stack. If we add support for trivially relocatable types to be exported to Rust, then this would be feasible by forcing the user to place some autogenerated metadata as part of their Rust-equivalent struct

[hkalbasi]

@hkalbasi that wouldn't let you call into virtual functions from rust though

If it needs to be, It can be bridged like any other C++ function.

I think the problem with what I would want is that it basically requires, by definition, that we can have C++ objects in the Rust stack. If we add support for trivially relocatable types to be exported to Rust, then this would be feasible by forcing the user to place some autogenerated metadata as part of their Rust-equivalent struct

I'm generally in favor of having trivially relocatable types, but I don't see how they are related to the inheritance or your async problem. But you know the details of your problem more than me.

[adsnaider]

If it needs to be, It can be bridged like any other C++ function.

I don't think so. Imagine the following

class Task {
  public:
     virtual PollResult Poll() = 0;
  private:
    // Some data fields (e.g. list of wakers)
};

class Executor {
  public:
    void Post(Task* task) {...}
    void Run() { ... }
};

I would want to have the following

pub struct RustTask<F: Future<Output = ()>> {
  f: F
}

// RustTask should inherit from `Task` so I can pass it to C++'s executor 

I can create a C++ executor in Rust by bridging it as an owned opaque type. But I want to use it like this

fn main() {
   let executor = todo!("Binding to create the executor");
   let task = RustTask {
      f: async { ... } 
  };

  executor.Post(&task as *const RustTask as *const Task);
  executor.Run();
}

This can't work because RustTask doesn't actually inherit from Task so its memory layout is ill-defined for the Task class. We would need to have space in RustTask for the Task object itself which would include the virtual dispatch table. Only then, if the Task data is the first element in the RustTask (i.e. repr(C)), can we actually hookup the virtual dispatch table with a Rust implementation. Am I missing something?

[hkalbasi]

If we go the way I'm saying, it would become something like this:

your_code.rs

pub struct RustTask {
  f: Box<dyn Future<Output = ()>>
}

impl TaskTrait for RustTask {
    fn Poll(&self) {
         // some logic
    }
}

struct Task(ZngurRefObject);

impl RustTask {
     fn into_cpp(&self) -> &Task {
          generated::rust_task_into_cpp(self)
     }
}

generated.h

class RustTask: Task {
    std::array<u8, 8> data;
    bool drop_flag;
    PollResult poll() override {
        // some generated zngur magic
    }
};

your_code.cpp

Task* rust_task_into_cpp(rust::Ref<rust::RustTask> self) {
    dynamic_cast<Task*>(self.as_raw())
}

It could also work with your template function, but in that case you need to wrap every single instantiation of it in the zng file, and for async blocks which have opaque impl Future types, zngur do the Box<dyn> under the hood so avoiding it is pointless.

[adsnaider]

I think this part doesn't work:

Task* rust_task_into_cpp(rust::Ref<rust::RustTask> self) {
    dynamic_cast<Task*>(self.as_raw())
}

You are assuming that Task is zero sized. Because of this you can't actually cast the rust object into the C++ object. Unless the rust object has a Task object in its first field which it doesn't