[erlang-bugs] ERL_NIF_TERM type collision

[Daniel Goertzen]

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/c3767919/attachment.htm>