Skip to content
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

Open
JohelEGP opened this issue Jun 3, 2018 · 2 comments
Open

User-friendly macros #133

JohelEGP opened this issue Jun 3, 2018 · 2 comments

Comments

@JohelEGP
Copy link
Contributor

JohelEGP commented Jun 3, 2018

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 in namespace units { ... }. I don't know why these were introduced, since they're only (even if indirectly) called in unit's name and abbreviature member functions.

Similarly, UNIT_ADD_LITERALS unilaterally places things in the literals namespace, which the user might not want. And if they later open than namespace as inline, 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:

namespace my_lib {
  UNIT_ADD(my_units, fortnight, fortnights, ftn, units::unit_conversion<std::ratio<14>, units::time::days>)
  inline namespace literals {
    inline namespace time_literals {
      UNIT_ADD_LITERALS(my_units, fortnight, ftn)
    }
  }
}
UNIT_ADD_NAME(my_lib::my_units, fortnight, ftn)

UNIT_ADD_DIMENSION_TRAIT has the same problems as UNIT_ADD_LITERALS. Also, its detail machinery needn't be "exported". It can remain here and have the macro use it.

@JohelEGP
Copy link
Contributor Author

JohelEGP commented Jun 3, 2018

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.

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.
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.
@nholthaus
Copy link
Owner

nholthaus commented Jul 13, 2018

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:

  • user defined dimensions should have similar, easy to use macros
  • we'll want an additional single-line macro for novice users that just ignores all namespacing considerations.

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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants