Replies: 3 comments 1 reply
-
I must say this is a really interesting observation. In this case, Side note: "dimension" usage in most physical units libraries is not ISO conforming anyway. The only thing that ISO defines is https://mpusz.github.io/units/glossary.html#term-dimension. It has sense, only for "derived quantities" and there is officially no such thing as a "base dimension". As for engineering purposes we already "abuse" the term dimension maybe we can extend it to also determine if we are dealing with a point or kind? Any preferences anyone? |
Beta Was this translation helpful? Give feedback.
-
With this, |
Beta Was this translation helpful? Give feedback.
-
A point against:
|
Beta Was this translation helpful? Give feedback.
-
And/or
quantity_kind
integrated intoquantity
, andquantity_point_kind
integrated intoquantity
/quantity_point
? (See #204).This is the current state. The last 2 can be redundant and long:
quantity_point<dim_length, metre>
,quantity_kind<height, metre>
,quantity_point_kind<altitude, metre>
.I think these are mostly clear:
quantity<dim_length, metre>
,quantity<point<dim_length>, metre>
,quantity<height, metre>
,quantity<altitude, metre>
,quantity<point<height>, metre>
(point<height>
andaltitude
are the "same").By integration, I mean making them partial specializations of
quantity
. Or generalizingquantity
'sUnit
template parameter to acceptKind
s/PointKind
s.For integrating
quantity_point
intoquantity
, apoint<Unit>
wrapper could me made along the lines ofkind
/derived_kind
/point_kind
.I'm concerned about the lengthy names and numerous
quantity
*_cast
s. Althoughquantity_kind_cast
andquantity_point_kind_cast
could just be overloads ofquantity_cast
.A touch of reality:
Beta Was this translation helpful? Give feedback.
All reactions