mpusz
docs(ref): document `mp_units.core`
This is still a WIP:
This is also blocked on #626 and #627, and a number of minor points which I'll review later.
There are some TBDs for algorithms which need a specification. It would take me too long to correctly decipher these algorithms. And I don't think pasting their lengthy and TMP heavy code will pass. These are:
- The expression template algorithms.
- The quantity specification conversion algorithms.
Now I'm going to start with the magnitude section. I imagine that will also have some algorithms which I'll have to mark as TBD.
This is great! Thanks!
Regarding magnitudes, please note that they are meant to be implementation-defined. Only a few user-facing API things are public (construction helpers (mag, mag_ratio, and mag_power), concept, operators, magnitude<...> where ... is implementation-defined).
Could you please not squash or rebase the branch?
It is impossible to track what changes between commits this way. I need to start reviewing all 2500 lines from scratch as I do not know what has changed.
Maybe provide something for merge and open another PR with additional changes?
Good point.
How are you reviewing? Reading the LaTeX source code, PDF, or HTML?
Here's the whole diff from the first push to now, which unfortunately includes the move of [qty.rep]: https://github.com/mpusz/mp-units/compare/b68cf1baecdbb11d15a5cb48aad5090994000344..8bf5db5e4077d3ae9db70be4bbdf24b79bb46f78. I couldn't get anything more granular, even from my own fork.
If you're using the PDF,
you can check opening comment's history to download the first PDF,
and use a tool like diffpdf.
For the HTML,
you could do the same,
with https://services.w3.org/htmldiff,
but it needs the .csss to look good.
I try to review in LatTeX as it is easier to provide comments that way, and I also need to learn the syntax.
@mpusz
std::remove_X_t<decltype(E)>,
can be replaced with
decltype(auto(E))
when X is const or cvref
and decltype(E) is a symbolic constant (or a type where the copy makes no difference).
Is it OK if I do that?
For reference, in the C++ Standard, those only happen at (search for _t<decltype():
- [func.require] (changes not OK).
- [span.syn] (changes OK).
- [views.multidim] (changes OK).
Sure, I am not sure if that worked in C++20 already, though. So, as long as doing it for API reference is fine, it might break the mp-units code.
Actually, it is even better (or worse). It turns out that all_are_kinds are not needed anymore. It was needed at the beginning when I allowed any quantity spec to be used for a unit. Now we only allow kinds, so they are always kinds for an AssociatedUnit.
There are some things I still want to do, but you can merge this for now.
I also have pending fixing the HTML url bug in the index.html.