Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Are inner items supported? #1036

Open
Xaeroxe opened this issue Apr 11, 2022 · 2 comments
Open

Are inner items supported? #1036

Xaeroxe opened this issue Apr 11, 2022 · 2 comments

Comments

@Xaeroxe
Copy link

Xaeroxe commented Apr 11, 2022

Consider the following C++ code (taken from libwebm)

class BlockEntry {
  BlockEntry(const BlockEntry&);
  BlockEntry& operator=(const BlockEntry&);

 protected:
  BlockEntry(Cluster*, long index);

 public:
  virtual ~BlockEntry();

  // ...
  enum Kind { kBlockEOS, kBlockSimple, kBlockGroup };
  virtual Kind GetKind() const = 0;
  // ...
};

It's not clear to me how you're supposed to create a cxx::bridge for the type BlockEntry::Kind. Trying to treat the class as a namespace doesn't work, and the documentation doesn't show any demonstration of how this should be handled.

@Xaeroxe
Copy link
Author

Xaeroxe commented Apr 11, 2022

On a similar note, how should one go about binding a static function from a class? i.e.

struct Colour {
  // ...
  static bool Parse(IMkvReader* reader, long long element_start,
                    long long element_size, Colour** colour);
  // ...
}

@hntd187
Copy link

hntd187 commented May 22, 2022

At least for the static function I just created outside functions to call the inner static methods on the cpp side. Not ideal, but works.

bsilver8192 added a commit to bsilver8192/autocxx that referenced this issue May 22, 2022
Upcasting can change the value of a pointer in C++. This means anything
upcasting needs both the parent and child class defined, which is
awkward in user code when wrapping functions that accept ownership of a
superclass object (it requires C++ code that depends on
autocxx-generated C++ code that depends on the main C++ code, which then
needs to be depended on by another iteration of autocxx to call it from
Rust).

Ideally this would be a static function in C++ to avoid some potential
name conflicts that this approach produces (with C++ types sharing a
name in separate namespaces), but I don't think cxx supports those yet
(dtolnay/cxx#1036 and dtolnay/cxx#447).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants