-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
User-friendly macros #133
Comments
See 4b774b2 to see what I meant. |
JohelEGP
added a commit
to JohelEGP/units
that referenced
this issue
Jul 8, 2018
Strong unit integer literals have an `int` underlying type. No namespace is assumed, see nholthaus#133.
Merged
JohelEGP
added a commit
to JohelEGP/units
that referenced
this issue
Jul 10, 2018
Strong unit integer literals have an `int` underlying type. No namespace is assumed, see nholthaus#133.
JohelEGP
added a commit
to JohelEGP/units
that referenced
this issue
Jul 10, 2018
Strong unit integer literals have an `int` underlying type. No namespace is assumed, see nholthaus#133.
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:
|
JohelEGP
added a commit
to JohelEGP/units
that referenced
this issue
Jul 14, 2018
Strong unit integer literals have an `int` underlying type. No namespace is assumed, see nholthaus#133.
JohelEGP
added a commit
to JohelEGP/units
that referenced
this issue
Jul 21, 2018
Strong unit integer literals have an `int` underlying type. No namespace is assumed, see nholthaus#133.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.The text was updated successfully, but these errors were encountered: