Open JohelEGP opened 6 years ago
Also, its detail machinery needn't be "exported". It can remain here and have the macro use it.
See 4b774b2 to see what I meant.
The macros were original written, then expanded, to reduce boiler-plate solely within the library. Knowing they'd be useful to people, I documented some of them, but the work to really treat them as part of the public interface wasn't done.
Some random related thoughts:
I have started working on improving the macros for defining units to make them usable from outside the library on my branch johelegp:macros. I'd like input on how to proceed on the following points.
The
UNIT_ADD_NAME
assumes that it is being used inside the::units
namespace, and so do the macros that use it. Since it is a customization point by specialization of the primary templates in::units
, the correct use from outside the library would consist on using the macro on the global namespace, and wrapping it innamespace units { ... }
. I don't know why these were introduced, since they're only (even if indirectly) called inunit
'sname
andabbreviature
member functions.Similarly,
UNIT_ADD_LITERALS
unilaterally places things in theliterals
namespace, which the user might not want. And if they later open than namespace asinline
, they get an error. The other way around, it's a warning. Probably subject to inclusion order, one day the warning might become an error.Perhaps a better approach would be to separate the components of
UNIT_ADD
and similar so as to avoid these clashes. Then, their use might look like this:UNIT_ADD_DIMENSION_TRAIT
has the same problems asUNIT_ADD_LITERALS
. Also, itsdetail
machinery needn't be "exported". It can remain here and have the macro use it.