extern C const pointer

[abakoboParticipant]

I’m trying to implement the chipmunk’s debug draw…
I Encountered a problem with this callback function pointer:
in the chipmunk_extern.monkey2:
Alias cpSpaceDebugDrawPolygonImpl:Void( Int, cpVect Ptr, cpFloat, cpSpaceDebugColor, cpSpaceDebugColor, cpDataPointer )

in the chipmunk C code:
typedef void (*cpSpaceDebugDrawPolygonImpl)(int count, const cpVect *verts, cpFloat radius, cpSpaceDebugColor outlineColor, cpSpaceDebugColor fillColor, cpDataPointer data);

I had to remove the “const” in the C code because I was having the following compilation error:
invalid conversion from ‘void (*)(bbInt, cpVect*, bbDouble, cpSpaceDebugColor, cpSpaceDebugColor, void*) {aka void (*)(int, cpVect*, double, cpSpaceDebugColor, cpSpaceDebugColor, void*)}’ to ‘cpSpaceDebugDrawPolygonImpl {aka void (*)(int, const cpVect*, double, cpSpaceDebugColor, cpSpaceDebugColor, void*)}’ [-fpermissive]

But I would prefer to keep chipmunk’s C code in it’s original state as far as it’s possible.
I’ve seen that there’s is a const_char type but could not take that as an example to pass a const cpVect* to the C code…

[abakoboParticipant]

ok found how to do it

modified the chipmunk_extern.monkey2:
added

Monkey

[crayon-5cba8d8d08d0b069785874 inline="true" ]Struct const_cpVect="const cpVect" Field x:cpFloat Field y:cpFloat End

1 2 3 4

[crayon-5cba8d8d08d0b069785874 inline="true" ]Struct const_cpVect="const cpVect" Field x:cpFloat Field y:cpFloat End

[/crayon]

and modified the problematic line

Monkey

[crayon-5cba8d8d08d12832732363 inline="true" ]Alias cpSpaceDebugDrawPolygonImpl:Void( Int, cpVect Ptr, cpFloat, cpSpaceDebugColor, cpSpaceDebugColor, cpDataPointer ) To Alias cpSpaceDebugDrawPolygonImpl:Void( Int, const_cpVect Ptr, cpFloat, cpSpaceDebugColor, cpSpaceDebugColor, cpDataPointer )

1 2 3

[crayon-5cba8d8d08d12832732363 inline="true" ]Alias cpSpaceDebugDrawPolygonImpl:Void( Int, cpVect Ptr, cpFloat, cpSpaceDebugColor, cpSpaceDebugColor, cpDataPointer ) To Alias cpSpaceDebugDrawPolygonImpl:Void( Int, const_cpVect Ptr, cpFloat, cpSpaceDebugColor, cpSpaceDebugColor, cpDataPointer )

[/crayon]

and my implementation has a const_cpVect Ptr as argument of course…

[Mark SiblyKeymaster]

Nice hack! But it’ll mean you end up with 2 unrelated cpVert classes wont it? Perhaps that’s not a problem though, or perhaps it’s a rare enough issue – it should only be a problem with function pointers like this I guess.

I guess the user can always cast a const_cpVect Ptr to a plain cpVect Ptr if they only want to deal with the 1 type. In fact, perhaps const_cpVect should be ‘anonymous’ and they should have to do this? This would be easier to automate anyway.

[abakoboParticipant]

The first ideal idea I had was trying to write this:
Alias cpSpaceDebugDrawPolygonImpl:Void( Int, cpVect Ptr="const cpVect*" ,...

Hoping all would be internally managed by the transpiler/linker! But not..

If this is possible it could be a good solution for automation.
c2mx2 detects an un-implemented typedef func (Alias func:..(..)) or a pure virtual method with some const/const& as parameter then adds ="const foo" or ="const foo&" or wathever.
And this way there’s no conversion to be done..

In the chipmunk’s debugdraw case the actual hack is not problematic because the module user won’t even notice it’s there. He/She’s just gonna call it with a simple call. If someone want to create it’s own implementation then he/she will have to notice it but has an example to start with.

Is there any plan on c2mx2 being c++ aware?

[Mark SiblyKeymaster]

> If this is possible it could be a good solution for automation.

This wont work, because the munging needs to be done on the mx2 function, and since a function pointer can point to *any* function the compiler can’t know which functions to mung, eg if the compiler sees a function such as:

Function MyDebugDraw( p:cpVect Ptr,…)

Should the compiler use ‘const’ or not? It doesn’t know if it’s supposed to be used with a debugdraw function ptr or not. It *probably* is – although even that would be hard to work out – but it can’t know for sure.

[abakoboParticipant]

tried some implicit conversion from const_cpVect to cpVect with “struct extension” and “operator to:” but no luck, the “‘const cpVect'” is crapping the .h and .cpp output

I’ll stop trying to mess with it..

Do you think it’s better to remove the “const” in the original “chipmunk.h” or use the =”const cpVect” hack.
or is there any other better solution in your mind? Should I post an issue on github?

The debugDraw is kind of mandatory so something have to be done.. the actual “build in” chipmunk module can’t manage debug polygon draws for now.(and probably other callbacks with “const”)

[Simon ArmstrongParticipant]

I was hoping monkey2 would follow Java and adopt final variables (const). Maybe not immediately but perhaps somewhere in the future before threading which I realise is not a given.

[abakoboParticipant]

I saw there has been some things modified in chipmunk and c2mx2 but It’s still the same on my side. Need to hack the “const”.

[Mark SiblyKeymaster]

Ok, major overhaul of chipmunk now up.

cpSpace, cpBody etc. are now ‘extends void’ objects so you don’t need use ‘Ptr’ with them anymore. You still need to use cp ‘new’ functions to create them though, eg: cpSpaceNew().

Callbacks for debug draw and collision handlers are now ‘proper’ mx2 function pointers, ie: you can use functions, methods or lambdas with them. Note that other callbacks are still plain ‘C’ function pointers so they need to be used with global functions or you’ll get a ‘null function’ error when they’re invoked. These may or may not be converted over too depending on demand and whether it’s even possible (the function type really needs a ‘userdata’ pointer for mx2 to hook into). There is also some overhead involved in using mx2 function pointers in terms of GC, so that needs to be taken into consideration too.

I also added a bunch of ‘extension properties’ to most types too, so you can now go…

space.Gravity=cv( 0,100 )

…instead of…

cpSpaceSetGravity( space,cv( 0,100 ) )

…but either way will work.

I’m very happy with this as it’s pretty much zero overhead (except for function pointer glue code) so should be nice and fast, yet it still looks mx2-ish.

I dealt with the ‘const*’ issue inside the function pointer glue code, and I think in general glue code is probably the sanest way to deal with type system problems like this. A bit tedious, but glue code offers full flexibility.

Maybe c2mx2 will be able to help with writing glue code one day, but in this case at least (where the function pointer was actually a struct field) it was a little more complex than I could imagine doing via c2mx2 so doing it by hand was really the only option. But it wasn’t a big deal, and I expect all modules produced by c2mx2 will require some amount of tweaking.

[abakoboParticipant]

Great! waw! My debugDraw implementation looks so awful compared to yours!
Happy this is now built in! (woohoo)

[Author]

Posts