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

C friendly header #40

Open
NullMember opened this issue Jul 28, 2021 · 1 comment
Open

C friendly header #40

NullMember opened this issue Jul 28, 2021 · 1 comment

Comments

@NullMember
Copy link

I'm currently writing a Max/MSP library (external) using JoyShockLibrary in C. Current header file is not so C friendly. Seperating headers for C and C++ or modifying current file could work. What you think?

@Peter0x44
Copy link

Peter0x44 commented Mar 4, 2023

I tried this myself and identified these issues:

JoyShockLibrary.h:114:9: error: unknown type namebool114 |         bool t0Down;
      |         ^~~~

Access to the bool type in C requires an include of stdbool.h

JoyShockLibrary.h:122:8: error: expected identifier or ‘(’ before string constant
  122 | extern "C" JOY_SHOCK_API int JslConnectDevices();
      |        ^~~

extern "C" is not valid under C, it is C++ only

These two are easy to fix with some #define

152 extern "C" JOY_SHOCK_API TOUCH_STATE JslGetTouchState(int deviceId, bool previous = false);
153 extern "C" JOY_SHOCK_API bool JslGetTouchpadDimension(int deviceId, int &sizeX, int &sizeY);

The last problem that isn't so quick and uncontroversial to correct is that the API uses references and default arguments.
These are both C++ features. I'm honestly not sure how it works at all with the current extern "C" in front of everything, I wouldn't think those would be usable features for functions marked like that.

It would be a breaking change to fix that, which would surely annoy existing users. Perhaps a reason supporting creating a separate header with a C api for the library, though it would be questionable code duplication.

So it leaves the question:
Is it worth breaking current programs to leave a C compatible API?
If yes, then changing all the references to pointers and removing default arguments is the easiest way to go.
If no, then I guess creating a header with a few functions wrapping the C++ feature usages would be the way to go.

The API is very close to being C compatible, but not quite...

I'm happy to submit a PR implementing whichever approach the maintainer(s) deem appropriate.

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