<div dir="ltr"><div>Thank you for your feedback. Maybe the "hook" approach I suggested is too generic. My original patch from nifpp actually looks like this...<br><br><span style="font-family:courier new,monospace">#ifdef CPP11_UNIQUE_TERM_TYPE<br>
enum class ERL_NIF_TERM : ERL_NIF_UINT;<br>#else<br> typedef ERL_NIF_UINT ERL_NIF_TERM;<br>#endif<br><br></span>...and then to use the typed enum in your c++ nif you write...<br><br><span style="font-family:courier new,monospace">#define CPP11_UNIQUE_TERM_TYPE<br>
#include <erl_nif.h><br></span><br><br>In the future ERL_NIF_TERM can be changed to a struct and the CPP11_UNIQUE_TERM_TYPE option can just be ignored. What do you think?<br><br></div><div>Cheers,<br></div><div>Dan.<div class="gmail_extra">
<br><br><div class="gmail_quote">On Fri, Feb 7, 2014 at 12:46 PM, Sverker Eriksson <span dir="ltr"><<a href="mailto:sverker.eriksson@ericsson.com" target="_blank">sverker.eriksson@ericsson.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Thanks for the patch.<br>
<br>
I got one objection/question though. My C++ knowledge is a bit
rusty but as I understand it<br>
the "enum class" construct demands that Type is an integer type.<br>
<br>
This is currently true for ERL_NIF_TERM but it might not be in the
future.<br>
I earlier tried to define ERL_NIF_TERM as<br>
<br>
typedef struct { int x; } ERL_NIF_TERM;<br>
<br>
to get stronger type checking even for C. I reverted that due to
bad performance<br>
as gcc has different calling conventions for int and struct {int}.
However, future compilers<br>
might be better at passing struct{int} by value in which case we
might want to change<br>
the definition of ERL_NIF_TERM.<br>
<br>
What then? Do we ignore CUSTOM_NIF_TERM_TYPE in such a scenario?<br>
<br>
<br>
/Sverker, Erlang/OTP<div><div class="h5"><br>
<br>
<br>
On 02/07/2014 06:34 PM, Daniel Goertzen wrote:<br>
</div></div></div>
<blockquote type="cite"><div><div class="h5">
<pre>When writing NIFs in C++, it is impossible to employ C++ function
overloading because the underlying type of ERL_NIF_TERM is "unsigned int".
For example:
// won't compile :(
#include <erl_nif.h>
void my_func(ERL_NIF_TERM a) {...}
void my_func(unsigned int a) {...}
This patch allows NIF authors to mutate the type of ERL_NIF_TERM by
defining the macro CUSTOM_NIF_TERM_TYPE(). In the example below, the
underlying unsigned integer type gets wrapped as a C++11 typed
enumeration. The type of ERL_NIF_TERM is now unique and can be used in
overloaded functions.
// compiles! :)
#define CUSTOM_NIF_TERM_TYPE(Type) enum class ERL_NIF_TERM : Type {};
#include <erl_nif.h>
void my_func(ERL_NIF_TERM a) {...}
void my_func(unsigned int a) {...}
The patch has no impact on erl_nif.h if CUSTOM_NIF_TERM_TYPE is not defined
(other than flipping the definition order of ERL_NIF_TERM and ERL_NIF_UINT).
A similar approach has been used on my C++11 NIF wrapper (
<a href="https://github.com/goertzenator/nifpp" target="_blank">https://github.com/goertzenator/nifpp</a>). The wrapper requires manual
installation of a similar patch, and I would love to remove that
requirement.
Regards,
Dan.
</pre>
<br>
<fieldset></fieldset>
<br>
</div></div><pre>_______________________________________________
erlang-patches mailing list
<a href="mailto:erlang-patches@erlang.org" target="_blank">erlang-patches@erlang.org</a>
<a href="http://erlang.org/mailman/listinfo/erlang-patches" target="_blank">http://erlang.org/mailman/listinfo/erlang-patches</a>
</pre>
</blockquote>
<br>
</div>
</blockquote></div><br></div></div></div>