Introduce new macro to wrap a C++ class: cpp_class! #28

ogoffart · 2018-01-20T16:30:15Z

A macro which allow to wrap C++ class into rust types with and call
their destructor and copy constructor appropriatly

Example of use:

cpp_class!(pub struct MyClass, "MyClass");
impl MyClass {
    fn new() -> Self {
        unsafe { cpp!([] -> MyClass as "MyClass" { return MyClass(); }) }
    }
    fn member_function(&self, param : i32) -> i32 {
        unsafe { cpp!([self as "const MyClass*", param as "int"] -> i32 as "int" {
            return self->member_function(param);
        }) }
    }
}

A macro which allow to wrap C++ class into rust types with and call their destructor and copy constructor appropriatly

ogoffart · 2018-03-30T16:46:01Z

@mystor Do you have any feedback to give?

I'm slowly developing a crate that uses a C++ library, and uses this feature and the other ones.
Would be nice to have it merged.

ogoffart · 2018-04-14T16:34:46Z

@mystor ping?

mystor · 2018-04-16T23:17:28Z

@ogoffart Hey, so sorry for how long this has taken. I'll try to take a look at this in the next few days, but I'm pretty busy with work right now.

mystor

This looks awesome! Thank you so much for doing this work & sorry for how long it's taken me to get back to you. I'll try to be more prompt with follow-ups.

mystor · 2018-05-16T17:24:11Z

cpp/src/lib.rs

+/// class is copyable (or Copy if it is trivialy copyable), and Default if the class
+/// is default constructible
+///
+/// Warning: This only work if the C++ class can be moved in memory (using


nit: Can you make this warning more prominent (perhaps above the example code invocation?). I think it's pretty important :-)

yes, it's pretty important and quite a bad restriction.
There is unfortunately afaik no way to tell the rust compiler that a type should not be moved around, but only copied, or to call the move constructor.

Fortunately, most value types i've been using can be safely moved. Altough this is not the case for types from the standard library such as std::string.

mystor · 2018-05-16T17:24:25Z

cpp/src/lib.rs

+/// is default constructible
+///
+/// Warning: This only work if the C++ class can be moved in memory (using
+/// memcpy). This disallow most classes from the standard library.


nit: s/disallow/disallows

mystor · 2018-05-16T17:26:02Z

cpp/src/lib.rs

+///
+#[macro_export]
+macro_rules! cpp_class {
+    (struct $name:ident, $type:expr) => {


It might be really slick to support this as a mode of operation for the cpp! macro (e.g. cpp! { struct... } or cpp! { pub struct... }), rather than introducing the cpp_class macro.

Thats a good idea.

cpp! { struct Foo as "Foo" }

Note that is was thinking the macro could be also extended to more complex constructs

// This will automatically use operator== cpp! { #[derive(Eq)] struct Foo as "Foo" } // map the members to the C++ structure and somehow check it is valid cpp! { struct Point as "Point" { x : u32, y: u32 } }

Actually, i'm a bit unsure.

having only one macro cpp! could be nice, and would avoid wondering if cpp_class is the right name or if it should be cpp_struct.

However, having a separate macro makes it easier to document or to lookup what it is, than having a single macro that does everything.

mystor · 2018-05-16T17:30:36Z

cpp_build/src/lib.rs

                hash = hash
            ));
        } else {
            sizealign.push(format!("{{
                {hash}ull,
                sizeof({type}),
-                rustcpp::AlignOf<{type}>::value
+                rustcpp::AlignOf<{type}>::value,
+                rustcpp::Flags<{type}>::value


Perhaps this could be made cleaner by unifying all of this logic into a single ::Flags-like invocation. We could just have a list of rustcpp::Meta<{type}, {hash}ull>::value?

I'm not sure I understand what you mean.
You mean that rustcpp::Meta<{type}, {hash}ull>::value would be a SizeAlign object?

Yeah, that was my thought.

This needs C++11's constexpr, so it depends on the other change that enables C++11

Note that MSVC 2013 which is still tested in the CI doesn't support constexpr enough to get this to work.

mystor · 2018-05-16T17:32:15Z

cpp_build/src/lib.rs

+extern "C" {{
+void __cpp_destructor_{hash}(void *ptr) {{
+    typedef {cpp_name} T;
+    static_cast< {cpp_name} *>(ptr)->~T();


Why use static_cast<{cpp_name} *> here instead of just casting to T*?

mystor · 2018-05-16T17:43:43Z

test/src/lib.rs

 }

+


nit: extra whitespace

mystor · 2018-05-16T17:45:29Z

test/src/lib.rs

+
+#[test]
+fn move_only() {
+    cpp_class!(struct MoveOnly, "MoveOnly");


nit: perhaps use as instead of the comma in cpp_class! to make it more consistent with how the type is usually used?

mystor · 2018-05-16T17:47:10Z

cpp_build/src/lib.rs

+            output,
+            r#"
+extern "C" {{
+void __cpp_destructor_{hash}(void *ptr) {{


It's unfortunate that we define these no-op functions even if we will never use them (because they aren't available). :-/ Not much that can be done about that AFAIK though.

For the destructor and copy constructor, we can't do anything.

For the default constructor, I was considering making it explicit by having to write
#[derive(Default)] in the macro.

I am actually undecided if it is good to have it explicit or implicit.

Implicit is quite convinient : if the C++ has a default constructor, it is automatic. But the rust rules seems to prefer explicit for this kinf of things.

But then what about all the other trait, should we automatically derive PartialEq or PartialOrd if the operator exists?

mystor · 2018-05-16T17:47:41Z

cpp_build/src/lib.rs

+typename enable_if<is_copy_constructible<T>::value>::type copy_helper(const void *src, void *dest)
+{ new (dest) T (*static_cast<T const*>(src)); }
+template<typename T>
+typename enable_if<!is_copy_constructible<T>::value>::type copy_helper(const void *, void *) { }


Perhaps make this code path abort() the process, just to double-down on the "this should never be called" angle?

mystor · 2018-05-16T17:48:00Z

cpp_build/src/lib.rs

@@ -45,6 +45,50 @@ const INTERNAL_CPP_STRUCTS: &'static str = r#"
 #include "stdint.h" // For {u}intN_t
 #include <new> // For placement new

+#if __cplusplus <= 199711L && !defined(_MSC_VER)


I don't think we support C++ < 11 right now.

#28

ogoffart · 2018-05-24T15:37:36Z

I made most change, but I did not rename the macro to re-use cpp.

I think it is better to be implicit about the difference of usage of the macro.
That makes the code more readable and lets the user find the documentation for the relevant macro more easily. Is this also not a reason why there are no overloaded functions in rust?
This is not a strong opinion. What do you think?

For example if there is a typo in the C++ class name, or if the class cannot be destructed or is only forward declared.

Note that some type traits are still not implemented in old GCC

mystor · 2018-06-07T22:19:22Z

Thanks for the changes :-) Looks good now.

#28

ogoffart added 3 commits January 20, 2018 17:51

Add cpp_class!

d217410

A macro which allow to wrap C++ class into rust types with and call their destructor and copy constructor appropriatly

cpp_class! automatically implement Default and support move only types

cef628e

Use atomic for the counter test

26712ab

mystor requested changes May 16, 2018

View reviewed changes

ogoffart added 3 commits May 17, 2018 11:10

Change the syntax of cpp_class: replace the ',' with 'as'

68468e4

small changes to the documentation

efc5a19

Fix issues raised in the pull request

c5a61ba

#28

ogoffart added 2 commits May 25, 2018 11:35

Use #line to report the error at the cpp_class location

9ac8cea

For example if there is a typo in the C++ class name, or if the class cannot be destructed or is only forward declared.

Use C++11 unconditionally

44791f4

Note that some type traits are still not implemented in old GCC

mystor merged commit e727d74 into mystor:master Jun 7, 2018

mystor pushed a commit that referenced this pull request Jun 7, 2018

Fix issues raised in the pull request

72e8377

#28

ogoffart mentioned this pull request Jun 19, 2018

Is it possible to use foreign types? #16

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Introduce new macro to wrap a C++ class: cpp_class! #28

Introduce new macro to wrap a C++ class: cpp_class! #28

ogoffart commented Jan 20, 2018

ogoffart commented Mar 30, 2018

ogoffart commented Apr 14, 2018

mystor commented Apr 16, 2018

mystor left a comment

mystor May 16, 2018

ogoffart May 16, 2018

mystor May 16, 2018

mystor May 16, 2018

ogoffart May 16, 2018

ogoffart May 17, 2018

mystor May 16, 2018

ogoffart May 16, 2018

mystor May 17, 2018

ogoffart May 24, 2018

ogoffart Jun 5, 2018

mystor May 16, 2018

mystor May 16, 2018

mystor May 16, 2018

mystor May 16, 2018

ogoffart May 17, 2018

mystor May 16, 2018

mystor May 16, 2018

ogoffart commented May 24, 2018

mystor commented Jun 7, 2018

Introduce new macro to wrap a C++ class: cpp_class! #28

Introduce new macro to wrap a C++ class: cpp_class! #28

Conversation

ogoffart commented Jan 20, 2018

ogoffart commented Mar 30, 2018

ogoffart commented Apr 14, 2018

mystor commented Apr 16, 2018

mystor left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ogoffart commented May 24, 2018

mystor commented Jun 7, 2018