[erlang-bugs] ERL_NIF_TERM type collision

[Daniel Goertzen]

I note that c++11 now lets you specify the underlying integer type of the
enum; I now see that enums are the way to go.

Dan.

On Mon, Mar 19, 2012 at 9:07 AM, Daniel Goertzen
<daniel.goertzen@REDACTED>wrote:

> ERL_NIF_TERM is 32 bits for the 32 bit and halfword emulators, and 64 bits
> for the 64 bit emulator.  Maybe I could use an enum (32 bits) for the
> halfword emulator, and pointer-to-dummy-struct for the others (since
> Sverker says structs are slow).
>
> I really do need to use overloading.  I am working on overloaded c++
> wrappers for enif_get_XXX() and enif_make_XXX(), and I support tuple
> cracking like...
>
> // term is ERL_NIF_TERM containing {"hello", 123, decode_me_later}
> std::tuple<std::string, int, ERL_NIF_TERM> tup;
> get(env, term, &tup);
>
> ... where the std::tuple overload of get() recursively calls get() for all
> its constituent types.  You can crack nested tuples in this manner too.
>
>
> Dan.
>
>
>
>
> On Sun, Mar 18, 2012 at 8:41 PM, Patrick Baggett <
> baggett.patrick@REDACTED> wrote:
>
>> At this point, you're effectively fighting the compiler. You could try an
>> enum since enum values aren't directly convertible to integers without an
>> explicit typecast -- maybe the compiler will get the hint.
>> Do you really need to have the exact same name? Is it completely
>> infeasible to have a function like int get_nif(...) instead of just "get"
>> as an overload? (aka: the easy solution)
>>
>> Patrick
>>
>>
>> On Sun, Mar 18, 2012 at 8:07 PM, Daniel Goertzen <
>> daniel.goertzen@REDACTED> wrote:
>>
>>> I am working on a c++ nif and have an overloaded function that takes a
>>> number of different types including integers and ERL_NIF_TERMs.  The
>>> problem is that ERL_NIF_TERM really just an integer and collides with my
>>> integer functions, for example:
>>>
>>> int get(std::string var) {...}
>>> int get(unsigned long var) {...}
>>> int get(ERL_NIF_TERM var) {...}  //compile error because ERL_NIF_TERM is
>>> really an unsigned long.
>>>
>>> It would be great it ERL_NIF_TERM was a unique type so it could be used
>>> in this situation.
>>>
>>> My first attempt to solve this involved creating wrappers for each NIF
>>> API function.  The wrapper used a new unique type instead of ERL_NIF_TERM,
>>> and did type casting as needed.  It was a type punning bloodbath.  This was
>>> complex and unsatisfactory.
>>>
>>> My second attempt was to hack erl_nif.h to change the definition of
>>> ERL_NIF_TERM to a struct containing an int, and this worked great.  But
>>> this is not very portable due to the custom erl_nif.h.  Also, I don't know
>>> enough about linkers to know for sure if this is permitted.
>>>
>>>
>>> Has this problem come up before?
>>>
>>> Is there some easy alternative that I am missing?
>>>
>>> Should I submit a patch for the erl_nif.h hack? (It is conditionally
>>> compiled, by default nothing changes)
>>>
>>>
>>> Thanks,
>>> Dan.
>>>
>>> _______________________________________________
>>> erlang-bugs mailing list
>>> erlang-bugs@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-bugs
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20120319/b0bd68aa/attachment.htm>