I'm trying to make some structs that are dependant on each other in Lua like so. But I'm having problems doing it. Is there anyway I can predefine Foo as an empty struct and define it afterwards?
Thanks.
ffi.cdef[[
typedef struct {
Foo* foo;
} Bar;
]]
ffi.cdef[[
typedef struct {
Bar* bar;
} Foo;
]]
This is not a problem specific of LuaJIT and the FFI but how to declare interdependent data structures and functions in C.
C requires that a function has been defined before using it. For instance:
int foo() {
bar();
}
int bar() {
return 42;
}
To solve this issue is necessary to declare function bar() at the beginning of the file. The behavior of the function can be defined later.
int bar();
int foo() {
bar();
}
int bar() {
return 42;
}
Similarly, you need to declare Foo before using it in Bar. Also notice it's possible to put all the C definitions in the same block.
ffi.cdef[[
typedef struct Foo Foo;
typedef struct {
Foo* Foo;
} Bar;
typedef struct {
Bar* bar;
} Foo;
]]
Related
How can I expose a struct generated from the quote macro in my derive macro without having to introduce a struct name out of the blue in my usage file (due to macro expansion)?
To illustrate the point, currently, my code looks something like this:
// "/my_derive/lib.rs"
// inside a derive macro function
let tokens = quote! {
struct MyDeriveMacroInternalStruct {
variant: #ident_name,
// other stuff ...
}
impl #ident_name {
pub fn something() -> Vec<MyDeriveMacroInternalStruct> {
vec![MyDeriveMacroInternalStruct { variant: #ident_name::#variant_name, /*...*/ }, /*...*/]
}
}
};
tokens.into()
The usage of my code would look something like this:
use my_derive::MyDerive;
#[derive(MyDerive)]
enum Something {
A,
B,
C,
}
fn process_data() -> Vec<MyDeriveMacroInternalStruct> { // having to write that struct name that came out of nowhere bothers me
Something::something()
}
fn main() {
let result = process_data();
// do stuff...
}
This is a condensed version of my actual code (process_data is in another file). To reiterate my question in light of the example, how can I access the struct without having it randomly appear out of nowhere (due to macro expansion)? To me the code unchanged is hard to understand, read, and change.
I would like to be able to do something like this:
use my_derive::{MyDerive, MyDeriveStruct};
#[derive(MyDerive)]
enum Something {
A,
B,
C,
}
fn process_data() -> Vec<MyDeriveStruct> { // importing the struct instead of magically appearing
Something::something()
}
fn main() {
let result = process_data();
// do stuff...
}
Obviously the idea seems quite stupid, but there has to be a way around it (an arbitrary struct definition). If what I imagined isn't possible, is there some way to be more clear about where the random struct came from?
Actually I thought of something better. Your derive should probably be associated with a trait of the same name.
Add an associated type to your trait:
trait MyDerive {
type Output;
...
}
Then set the associated type when you impl the trait:
struct MyDeriveMacroInternalStruct {
variant: #ident_name,
// other stuff ...
}
impl MyDerive for #ident_name {
type Output = MyDeriveMacroInternalStruct;
pub fn something() -> Vec<MyDeriveMacroInternalStruct> {
vec![MyDeriveMacroInternalStruct { variant: #ident_name::#variant_name, /*...*/ }, /*...*/]
}
}
Then you can refer to that associated type in return position or wherever:
use my_derive::MyDerive;
#[derive(MyDerive)]
enum Something {
A,
B,
C,
}
fn process_data() -> Vec<<Something as MyDerive>::Output> {
Something::something()
}
fn main() {
let result = process_data();
// do stuff...
}
Note: the convention is for #[derive(Trait)] to correspond to an impl for the given Trait, but your proc macro crate can't export a trait directly for importing in your library code.
So generally the solution is to have two crates:
my-trait is the "library" crate which contains the MyTrait trait definition
my-trait-derive is the proc-macro crate which contains the derive macro code
my-trait has my-trait-derive as a direct dependency, and re-exports the proc macro from it:
// my-trait lib.rs
pub use my_trait_derive::MyTrait;
// macro and trait names can overlap as they're
// treated as different item kinds
pub trait MyTrait {
type Output;
fn something();
}
see how clap does it here (they also re-export the whole clap_derive)
Then a user can use your proc macro + trait like this:
use my_trait::MyTrait;
#[derive(MyTrait)]
enum Something {}
fn process_data() -> Vec<<Something as MyTrait>::Output> {
Something::something()
}
Older Answer
What I would do is create a trait MyDeriveOutput or something with whatever stuff you want exposed from MyDeriveMacroInternalStruct:
trait MyDeriveOutput {
fn variant() ...
}
And then generate an impl for each internal struct you create:
struct MyDeriveMacroInternalStruct {
variant: #ident_name,
// other stuff ...
}
impl MyDeriveOutput for MyDeriveMacroInternalStruct {
// whatever
}
Then you can expose the trait and require it to be imported and used with impl Trait in return position:
use my_derive::{MyDerive, MyDeriveOutput};
#[derive(MyDerive)]
enum Something {
A,
B,
C,
}
fn process_data() -> Vec<impl MyDeriveOutput> {
Something::something()
}
fn main() {
let result = process_data();
// do stuff...
}
I would like to wrap a Rust struct in a C++ class.
Rust:
#[repr(C)]
pub struct RustStruct {
num: i32,
// other members..
}
pub extern "C" fn update(rust_struct: *mut RustStruct) {
(*rust_struct).num = 1i32;
}
extern "C" {
void update(void*);
}
C++:
class Wrapper {
public:
Wrapper();
// ..
private:
void* rustStruct;
// ..
};
Wrapper::Wrapper() {
update(rustStruct); // crash
}
int main() {
std::cout << "Testing..";
}
I understand why this wouldn't work. My question is: how can I achieve what I'm basically trying to do (wrap a rust struct in a c++ class)?
There is a mix of multiple FFIs concepts in your answer, so first let me recommend that your read the Reference.
There are two ways to achieve what you wish, you can either:
use a POD struct (Plain Old Data), aka C-compatible struct
use an opaque pointer (void* in C)
Mixing them, as you did, does not make sense.
Which to pick?
Both solutions have advantages and disadvantages, it's basically an expressiveness versus performance trade-off.
On the one hand, opaque pointers are more expressive: they can point to any Rust type. However:
they require dynamic memory allocation
they require being manipulated by Rust functions (so always indirectly from C or C++)
On the other hand, POD struct do not require either of those, but they are limited to only a subset of types expressible in Rust.
How to use a POD?
This is the easiest, actually, so let's start with it!
In Rust:
#[repr(C)]
pub struct RustStruct {
num: i32,
// other members, also PODs!
}
In C++
struct RustStruct {
int32_t num;
// other members, also with Standard Layout
// http://en.cppreference.com/w/cpp/types/is_standard_layout
};
class Wrapper {
public:
private:
RustStruct rustStruct;
};
Note that I just got along with your question stricto censu here, you could actually merge the two in a single C++ class:
class RustStruct {
public:
private:
int32_t num;
// other members, also with Standard Layout
// http://en.cppreference.com/w/cpp/types/is_standard_layout
};
Just avoid virtual methods.
How to use an opaque pointer?
This gets trickier:
Only the Rust code may correctly create/copy/destruct the type
Beware of leaking...
So, we need to implement a lot of functions in Rust:
#![feature(box_raw, box_syntax)]
use std::boxed;
pub struct RustStruct {
num: i32,
// other members, anything goes
}
pub extern "C" fn createRustStruct() -> *mut RustStruct {
boxed::into_raw(box RustStruct::new())
}
pub extern "C" fn destroyRustStruct(o: *mut RustStruct) {
boxed::from_raw(o);
}
Alright... now on to C++:
struct RustStruct;
RustStruct* createRustStruct();
void destroyRustStruct(RustStruct*);
class Wrapper {
public:
Wrapper(): rustStruct(RustStructPtr(createRustStruct())) {}
private:
struct Deleter {
void operator()(RustStruct* rs) const {
destroyRustStruct(rs);
}
};
typedef std::unique_ptr<RustStruct, Deleter> RustStructPtr;
RustStructPtr rustStruct;
}; // class Wrapper
So, yes, a bit more involved, and Wrapper is not copyable either (copy has to be delegated to Rust too). Anyway, this should get you started!
Note: if you have a lot of opaque pointers to wrap, a templated C++ class taking the copy/destroy functions as template parameters could alleviate a lot of boiler plate.
I want to generate a unique id for every type at compile time. Is this possible in Rust?
So far, I have the following code
//Pseudo code
struct ClassTypeId{
id: &'static uint
}
impl ClassTypeId{
fn get_type<T>(&mut self) -> &'static uint {
let _id :&'static uint = self.id + 1;
self.id = _id;
_id
}
}
let c = ClassTypeId{id:0};
c.get_type::<i32>(); // returns 1
c.get_type::<f32>(); // returns 2
c.get_type::<i32>(); // returns 1
c.get_type::<uint>(); // returns 3
I stole this idea from a C++ library, which looks like this
typedef std::size_t TypeId;
template <typename TBase>
class ClassTypeId
{
public:
template <typename T>
static TypeId GetTypeId()
{
static const TypeId id = m_nextTypeId++;
return id;
}
private:
static TypeId m_nextTypeId;
};
template <typename TBase>
TypeId ClassTypeId<TBase>::m_nextTypeId = 0;
}
std::any::TypeId does something like that:
use std::any::TypeId;
fn main() {
let type_id = TypeId::of::<isize>();
println!("{:?}", type_id);
}
outputs:
TypeId { t: 4150853580804116396 }
This sounds like a job for the bitflags! macro:
#[macro_use] extern crate rustc_bitflags;
bitflags!(
#[derive(Debug)]
flags ComponentMask: u8 {
const Render = 0b00000001,
const Position = 0b00000010,
const Physics = 0b00000100
}
);
// the set of components owned by an entity:
let owned_components: = Render | Position;
// check whether an entity has a certain component:
if owned_components.contains(Physics) { ... }
http://doc.rust-lang.org/rustc_bitflags/macro.bitflags!.html
If you want to manage type ids manually, you can use my unique-type-id crate. It allows you to specify what ids a type has in a special file. It will generate them at compile time. Currently it can be used in this way:
use unique_type_id::UniqueTypeId;
#[derive(UniqueTypeId)]
struct Test1;
#[derive(UniqueTypeId)]
struct Test2;
assert_eq!(Test1::id().0, 1u64);
assert_eq!(Test2::id().0, 2u64);
It can both generate types using incremental number and use the id from a file.
I have this struct:
struct foo {
int a;
union {
struct {
int b;
struct bar
{
int c;
int d;
} *aBar;
} in;
} u;
};
How I need to declare a variable of type bar, in Visual C++ ?
When you declare an structure like this:
struct
{
int b;
} in;
You are actually creating an object with name in, having unnamed-data type. This data-type would be named internally by compiler, and depends on compiler. The style given above does not declare in to be a type, but a variable!
If you want to make it a type, use either of given approaches:
// Approach 1
struct in{...};
// Approach 2
typedef struct {..} in; // in is now a type, because of `typedef`
If you have compiler that supports C++0x, and specifically type decltype keyword, you can use it against the first style (which makes in a variable). Example:
decltype(in) in_var;
in_var.b = 10;
Thanks Ajay, I solved that way:
foo *k;
decltype(k->u.in.aBar) j;
j->c = 1;
j->d = 1;
I'm having problems passing a structure of vectors to an OpenCL kernel.
Long story short, I have found that I CAN pass a C structure:
typedef struct {
cl_float4 vec;
} my_type;
. . . to a kernel, if I declare it like:
typedef struct { float s[4]; } my_float4;
typedef struct { my_float4 vec; } my_type; //use custom float4
__kernel void function(const my_type test) {}
. . . but NOT, if I declare it like:
typedef struct { float4 vec; } my_type; //use built-in float4
__kernel void function(const my_type test) {}
So my question is, what makes a float4 different and special? In the second example, I get CL_INVALID_ARG_SIZE on clSetKernelArg. In the host code, I'm using cl_float4--isn't that supposed to be paired with float4 in the kernel?
EDIT: by request, the clSetKernelArg code (error handling cropped):
template <typename type_data> void set_argument(int arg_index, const type_data* data) {
cl_int err = clSetKernelArg(kernel,arg_index,sizeof(type_data),data);
if (err!=CL_SUCCESS) throw "ERROR"; /*simplified*/
}
I call the function with a struct declared exactly as above:
my_type test;
my_kernel->set_argument(0,&test);
This sounds like a bug with your implementation - you should be able to pass that user-defined type to a kernel without issue. What platform / SDK are you using? I was able to successfully declare this type in host code:
typedef struct _mytype {
cl_float4 val;
} mytype;
... and then later use it:
mytype t;
status = clSetKernelArg(kernel, argc++, sizeof(mytype), &t);
check_status("clSetKernelArg:mytype t", status);
Where check_status does what you'd expect: checks for a non-CL_SUCCESS return value.
The kernel looks like this:
typedef struct _mytype {
float4 value;
} mytype;
kernel void do_it(/* ... */, const mytype test) { /* ... */ }
This compiles and executes, giving correct results on the CPU device.