[erlang-bugs] ERL_NIF_TERM type collision

[Paul Davis]

Its been awhile since I C++'ed heavily and had the more nuanced
details of types in my brain cache but here's something turned up
after a quick Google:

http://stackoverflow.com/questions/9378338/c-overloading-operators-for-similar-integer-types

On Mon, Mar 19, 2012 at 9:25 AM, Daniel Goertzen
<daniel.goertzen@REDACTED> wrote:
> 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
>>>>
>>>
>>
>
>
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs
>