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