There's a bit of ugliness in the UniqueHandle implementation regarding lack of constexpr of macros that requires casting and an odd template instantiation syntax using numeric literals rather than defined macro names. Perhaps the code can be updated to use a traits based approach, such as is presented in the following StackOverflow answer:
Is it possible to treat a pointer as an integral type in non-type template parameters?
The trait would be named, rather than a numeric literal, so should aid clarity in the code. It would also result in better compiler error messages. Currently error messages that involve the template will list the integer literal as a template parameter, which doesn't really add to clarity.
None of this is really able to work around the lack of constexpr for macros that evaluated to a cast, though it can perhaps help hide some of the details.
There's a bit of ugliness in the
UniqueHandle
implementation regarding lack ofconstexpr
of macros that requires casting and an odd template instantiation syntax using numeric literals rather than defined macro names. Perhaps the code can be updated to use a traits based approach, such as is presented in the following StackOverflow answer: Is it possible to treat a pointer as an integral type in non-type template parameters?The trait would be named, rather than a numeric literal, so should aid clarity in the code. It would also result in better compiler error messages. Currently error messages that involve the template will list the integer literal as a template parameter, which doesn't really add to clarity.
None of this is really able to work around the lack of
constexpr
for macros that evaluated to a cast, though it can perhaps help hide some of the details.