You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The emitted names for some core library C types can conflict with definitions in other headers. For example, I'm trying to use some generated Carp C along with Apple framework headers--unfortunately one the the framework headers defines Pattern as a struct, while core defines it as char*
Should we prefix the emitted C names of core types to avoid this situation? e.g. CARP_Pattern? Or at least expose this as a compiler option?
The text was updated successfully, but these errors were encountered:
Thinking about these issue a bit more—I suppose the first question we should answer is whether or not we care about C++ compatibility. After all, C and C++ are two different languages. It might be best to stick to one and leave the rest up to particular project maintainers, if needed. That said, when it comes to code that's valid in C and C++ but only required by C++ (e.g. explicit casting of void* during initialization, maybe it'd be helpful for us to support that?)
I think this suggestion makes sense. Supporting C++ would definitely be nice, since it's such a common language for useful libraries. Prefixing sounds good.
The emitted names for some core library C types can conflict with definitions in other headers. For example, I'm trying to use some generated Carp C along with Apple framework headers--unfortunately one the the framework headers defines
Pattern
as a struct, while core defines it aschar*
Should we prefix the emitted C names of core types to avoid this situation? e.g.
CARP_Pattern
? Or at least expose this as a compiler option?The text was updated successfully, but these errors were encountered: