In my project I have a group of foreign types (C++ classes) that I want to use, but don't want to represent as structs within LLVM. For example, for each field in each C++ class I have a setter and getter function that I'd like to use. The setters and getters are "extern C" functions to avoid problems with C++'s name mangling.
After going over the documentation it seems like I can do this by creating a unique opaque type for each C++ class to track types during my compilation, and then resolving all of the opaque types to void*
Is this a reasonable approach?
Robert
In my project I have a group of foreign types (C++ classes) that I want to use, but don't want to represent as structs within LLVM. For example, for each field in each C++ class I have a setter and getter function that I'd like to use. The setters and getters are "extern C" functions to avoid problems with C++'s name mangling.
After going over the documentation it seems like I can do this by creating a unique opaque type for each C++ class to track types during my compilation, and then resolving all of the opaque types to void*
(void in LLVM isn't like void in C. Use i8 instead.)
Is this a reasonable approach?
Very much so. There's little reason for the extra step of refining the opaque types to i8, though. Since you won't be dereferencing the pointer directly, you can use either the opaque types you propose or i8, whichever is more convenient.
— Gordon
Yes, looks reasonable, except that you don't need to resolve the
types; it's perfectly legal to leave a type as opaque.
-Eli
You can also just declare them in the IR as "i8*" which is llvm's equivalent to void*. Either way works 
-Chris