search

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
952 stars 135 forks source link

Splitting unit definitions into different headers #164

Open JohelEGP opened 6 years ago

JohelEGP commented 6 years ago

Related issues/comments:

Regarding https://github.com/nholthaus/units/issues/48#issuecomment-329987514

deprecated by the define/cmake options to opt-in to specific namespaces

By splitting and not relying on those macros, there's less chances of clash between depending projects using units.

nholthaus commented 6 years ago

We should remove those macros when we split. opt-out was better than nothing, but opt-in will be a lot easier and more intuitive on the user.

Given how much work has been done to make units easy to install, and its availability in package managers, I don't see any downsides.

JohelEGP commented 6 years ago

How granular should the headers be? Per unit would result in a lot of headers, probably to the point of being impractical. Per dimension is another option, like how they are currently separated (as indicated by the is_..._unit type trait.) There could additionally be headers of logical groups, like one including units of length, area, and volume.

How about the directory layout? I'd expect an all-including header and the granular headers to reside within the units directory. I prefer units.h as the all-including header, but I've also some like units/units.h and units/all.h.

We'd need a units/fwd.h header so as to be able to implement the "strengthening" of units without ODR issues. And probably a units/core.h or similar header, that has everything but unit definitions, except for the dimensionless units, the other ones required by the mathematical functions, and the constants.

JohelEGP commented 6 years ago

Actually, unless you're thinking of being conservative on the mathematical functions and constants we have, they should also be split as to prevent someday having too many of them in the core header.

nholthaus commented 6 years ago

My original plan was to split by dimension, and leave dimensionless and core lib stuff (and pi) in units.h.

I like having a units.h as an alll-inclusive in the base directory to maintain some semblance of backwards compatibility,

Constants become funny. I'd make a units/constants.h and include whatever is required. My assumption is people who are like, "why is Mu0 not defined!" won't really care about optimization. We'll see.

Math functions I'd leave in units/h, except for angle-only functions which I'd put in angle.h.

We'd need a units/fwd.h header so as to be able to implement the "strengthening" of units without ODR issues.

Can you elaborate a bit?

That said, I have the utmost respect for your opinion, so let me know if you have other ideas.

JohelEGP commented 6 years ago

That said, I have the utmost respect for your opinion, so let me know if you have other ideas.

I appreciate it!

Can you elaborate a bit?

See #167.

Let's see what we have...

nholthaus commented 6 years ago

sounds good