[erlang-patches] customized ERL_NIF_TERM type support

[Sverker Eriksson]

Thanks for the patch.

I got one objection/question though. My C++ knowledge is a bit rusty but 
as I understand it
the "enum class" construct demands that Type is an integer type.

This is currently true for ERL_NIF_TERM but it might not be in the future.
I earlier tried to define ERL_NIF_TERM as

typedef struct { int x; } ERL_NIF_TERM;

to get stronger type checking even for C. I reverted that due to bad 
performance
as gcc has different calling conventions for int and struct {int}. 
However, future compilers
might be better at passing struct{int} by value in which case we might 
want to change
the definition of ERL_NIF_TERM.

What then? Do we ignore CUSTOM_NIF_TERM_TYPE in such a scenario?


/Sverker, Erlang/OTP


On 02/07/2014 06:34 PM, Daniel Goertzen wrote:
> 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 (
> https://github.com/goertzenator/nifpp).  The wrapper requires manual
> installation of a similar patch, and I would love to remove that
> requirement.
>
> Regards,
> Dan.
>
>
>
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20140207/c0aeb606/attachment.htm>