@:functionCode does not work in haxe inline methods about hxcpp HOT 8 CLOSED

Yes, this is a documentation issue because it is probably never going to work as you had hoped.
I am putting together a talk about this sort of thing for wwx2014, so hopefully I can make this clearer.

from hxcpp.

I have been using @:functionCode a lot... I'm pretty much doing all native extensions through it. It works really well, apart from this small hickup.
Being able to inline c++ code to achieve native performance is really the way to go, and it was a decisive factor for me in using the platform. I hope it continues to be supported somehow! Great job! 👍

from hxcpp.

Should I leave it open? maybe as a reminder to document it?

from hxcpp.

There is a workaround:

    public inline function printSomethingInline() {
        untyped __cpp__('printf("something inline!\\n");');
    }

And in fact I prefer this over @:functionCode as it is more flexible.

from hxcpp.

Indeed, I understand the metadata on type level, but it seems a bit strange at method level.

from hxcpp.

Hmm, I didn't know about that @andyli ! Very useful! Thanks!

from hxcpp.

Yeah, the @FunctionCode may become deprecated soon, as better solutions emerge.
You still have a big problem with inline functions and arg names. eg:

inline funciton x(aaa:Int) { __cpp__('printf("%d",aaa);')__; }
x(1234)

You will get an error about 'aaa' not being defined, because it is treated as a string. Maybe some macro magic could work now - I am open to suggestions here.
The solution, which may event work today, is to define a "c++" inline function, which the haxe compiler either does not know about, or thinks is "extern". This can be done by injecting at the cpp file or include level. You can then call this, using untyped or extern, and the c++ compiler will inline it for you in the way that c++ compilers do (not the haxe compiler). I will be putting together some stuff for wwx about this.
I will close it now and work on sorting out the best solution. I am also interested in your specific use-cases, so these can be covered too.

from hxcpp.

@hughsando , one way to deal with the problem you mentioned above is to support the following:

inline function x(aaa:Int) { untyped __cpp__('printf("%d",{1};', aaa); }

On the OCaml side, every time you find that __cpp__ has more than one argument, {\d} patterns will be replaced by their expr_s conversion.

from hxcpp.