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
<>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 <
>> 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 <
>>> 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
>>>>>>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.html>