nholthaus / units

a compile-time, header-only, dimensional analysis and unit conversion library built on c++14 with no dependencies.
http://nholthaus.github.io/units/
MIT License
951 stars 134 forks source link

User-friendly macros #133

Open JohelEGP opened 6 years ago

JohelEGP commented 6 years ago

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 commented 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.

nholthaus commented 6 years ago

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: