Ok, but that has massive consequences:
1. in order to bridge this, the code has to be changed to "*cast*" -> so
the type safety is lost
2. or the *NULL* pointer test is drawn at the top, in the "caller" -> but
this is a MASSIVE change to the existing CODE basis.
3. In "*C*" the call of a method
No, because this is a *printf *like feature and the *callSig* is the format
and the *option[] *are the arguments, which support many different types…
Am Donnerstag, 30. Januar 2020 06:15:28 UTC+1 schrieb Tamás Gulácsi:
>
> What does "argv" hold?
>
> Can it be a concrete type, not an interface ? T
thanks to the Info, don't have profiled this overhead… It was just an
assumtion.
Am Donnerstag, 30. Januar 2020 18:12:50 UTC+1 schrieb Jake Montgomery:
>
>
>
> On Thursday, January 30, 2020 at 2:31:59 AM UTC-5, Andreas Otto wrote:
>>
>>
>>
>> Am Mittwoc
I do nothing on *C* with this pointer… I just give the Pointer as Argument
to an *GO* callback.
Am Donnerstag, 30. Januar 2020 14:25:48 UTC+1 schrieb Tamás Gulácsi:
>
>
>
> How do you handle the interface types on the C side? If you call back to
> Go exported functions,
> then you shouldn't tra
Am Mittwoch, 29. Januar 2020 23:19:34 UTC+1 schrieb Bruno Albuquerque:
>
> One way to work this around is to use https://github.com/mattn/go-pointer.
>
>
> thanks, but also use this kind of "*HASH based and export the hash handle*"
solution.
But I call this a "slow" solution, because of the *has
Am Donnerstag, 30. Januar 2020 06:15:28 UTC+1 schrieb Tamás Gulácsi:
>
> What does "argv" hold?
>
> Can it be a concrete type, not an interface ? That would allow passing it
> - or if you copy it to a C.malloc-ed array..
>
>
> *Argv* are the arguments of *Send* and many kind of types are are
su
Hi,
I have an existing project existing of a "library" creating a wrapper to
"C" using "go install" and on a different place multiple "executable's"
everything glue
together using the *GOPATH* technology. NOW I start using the new "module"
technology.
Library:
1. I create with "mod init
