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.<div><br></div><div>Dan.<br><br><div class="gmail_quote">On Mon, Mar 19, 2012 at 9:07 AM, Daniel Goertzen <span dir="ltr"><<a href="mailto:daniel.goertzen@gmail.com">daniel.goertzen@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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).<div>
<br></div><div>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...</div><div><br></div><div>// term is ERL_NIF_TERM containing {"hello", 123, decode_me_later}</div>
<div>std::tuple<std::string, int, ERL_NIF_TERM> tup;</div><div>get(env, term, &tup);</div><div><br>... where the std::tuple overload of get() recursively calls get() for all its constituent types. You can crack nested tuples in this manner too.</div>
<div><br></div><div><br></div><div>Dan.<div><div></div><div class="h5"><br><br><br><br><div class="gmail_quote">On Sun, Mar 18, 2012 at 8:41 PM, Patrick Baggett <span dir="ltr"><<a href="mailto:baggett.patrick@gmail.com" target="_blank">baggett.patrick@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
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)<br>
<br>Patrick<br><br><br><div class="gmail_quote"><div><div></div><div>On Sun, Mar 18, 2012 at 8:07 PM, Daniel Goertzen <span dir="ltr"><<a href="mailto:daniel.goertzen@gmail.com" target="_blank">daniel.goertzen@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div>
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:<div>
<br></div><div>int get(std::string var) {...}</div><div>int get(unsigned long var) {...}</div><div>int get(ERL_NIF_TERM var) {...} //compile error because ERL_NIF_TERM is really an unsigned long.</div><div><br></div><div>
It would be great it ERL_NIF_TERM was a unique type so it could be used in this situation.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><div>Has this problem come up before?</div><div><br></div><div>Is there some easy alternative that I am missing?</div><div><br></div><div>Should I submit a patch for the erl_nif.h hack? (It is conditionally compiled, by default nothing changes)</div>
<div><br></div><div><br></div><div>Thanks,</div><div>Dan.</div>
<br></div></div>_______________________________________________<br>
erlang-bugs mailing list<br>
<a href="mailto:erlang-bugs@erlang.org" target="_blank">erlang-bugs@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-bugs" target="_blank">http://erlang.org/mailman/listinfo/erlang-bugs</a><br>
<br></blockquote></div><br>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div>