Skip to content
This repository has been archived by the owner on Nov 29, 2023. It is now read-only.

Use void pointers instead of C++ object pointers. #10

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

aartaka
Copy link
Contributor

@aartaka aartaka commented Feb 3, 2021

This uses void * instead of QWhatever pointers in function return types. This is consistent with how we treat C++ objects -- as opaque pointers -- and will probably cause less errors on the side of the testing/application C/Lisp code.

All the C++ idioms in main() of interface.cpp are replaced with equivalent C code. This required writing a new function (newEmptyKeyPressFilter(), namely). Should there be a Lisp binding for it? Doesn't look really useful.

It's fully compatible with the existing Lisp-side code. Compiles, runs (I was able to test the C version only, so not sure about the CL one).

How does it look to you?

@Ambrevar
Copy link
Member

Ambrevar commented Feb 4, 2021

Is this going in the right direction though? For a well typed programming language, I'd say that we are losing a lot of information here. But this is C/C++, so maybe it's actually wiser to use void*. I'm not sure here.

About newEmptyKeyPressFilter(), I'd say just write the binding if you ever need it. Exposing more bindings than necessary can result in too complicated interfaces you can't withdraw one you've published a stable API.

What's blocking the Lisp test? If you are experiencing errors, can you report them? (Possibly in another issue.)

@aartaka
Copy link
Contributor Author

aartaka commented Feb 4, 2021

Is this going in the right direction though? For a well typed programming language, I'd say that we are losing a lot of information here. But this is C/C++, so maybe it's actually wiser to use void*. I'm not sure here.

We're expecting void * in almost all the functions we bind, so void * does match that.

About newEmptyKeyPressFilter(), I'd say just write the binding if you ever need it. Exposing more bindings than necessary can result in too complicated interfaces you can't withdraw one you've published a stable API.

Sounds reasonable :)

What's blocking the Lisp test? If you are experiencing errors, can you report them? (Possibly in another issue.)

I will, I'm still gathering data. Having a clean type-matching C/C++ side can help to find out where it breaks, though (maybe).

EDIT: I'm not sure whether matching types will help in debugging my issue.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants