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

Improve Glk C++ compatibility #2

Open
cspiegel opened this issue Feb 11, 2021 · 2 comments
Open

Improve Glk C++ compatibility #2

cspiegel opened this issue Feb 11, 2021 · 2 comments

Comments

@cspiegel
Copy link

I've run into a couple issues while working with Glk in C++.

  1. The Glk ABI is C (no mangled names), but the provided glk.h header (at https://www.eblong.com/zarf/glk/glk.h) provides C++ (mangled) names when used with a C++ compiler. Client code can, of course, wrap the include in extern "C", but it would be very convenient if instead glk.h itself had such a declaration, wrapped in #ifdef __cplusplus.
  2. There are many functions which accept a char * parameter where const char * would be preferred. This is actually not strictly a C++ issue, given that it's reasonable in C to use const char * for safety, and then be forced to cast to char *, but it's more pronounced in C++ where string literals have type "array of const char" instead of "array of char".

I request that the offical Glk header file be updated to be more friendly to C++. These changes shouldn't affect existing programs which make use of Glk, except perhaps if a pointer to one of the char *-accepting functions is being stored... but that's probably unlikely, and would be easy to change.

@cspiegel cspiegel changed the title Improve C++ compatibility Improve Glk C++ compatibility Feb 11, 2021
@erkyrath
Copy link
Member

Adding extern "C" is reasonable.

Adding const is a well-known headache. It pretty much requires going through every library and interpreter and const-ing them, all in one release. This is a lovely idea, but wow, I don't see myself sitting down to do it.

@cspiegel
Copy link
Author

Great news on extern "C", thank you!

As for const, I don't think it will affect interpreters: they're already passing unqualified char * (or glui32 *) by necessity, and that will be compatible with const char *, The only weird cases would be where they care about the exact prototype, e.g. if doing something like:

void (*put_string)(char *) = glk_put_string;

That will become invalid, and while it's probably not something anybody is doing, it's possible. It's also a trivial fix, but if it's being used in the wild, I can understand trepidation in forcing a change.

But I understand that it's a big job. If it's at least something that might be acceptable, I'm willing to do the conversions to see what kind of problems might occur, and if you deem it acceptable, I'd provide pull requests/patches. If it's a hard "no" then I won't bother taking the time, but otherwise I'd find it worth trying, even if the end result is to keep the status quo.

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