docs(ref): document more of mp_units.core
#662
Conversation
JohelEGP
changed the title
math.hmp_units.core
| % Should this come before the above, like in the C++ standard? | ||
| \rSec4[qty.rand.bern.geo]{Class template \tcode{geometric_distribution}} |
There was a problem hiding this comment.
See the comment.
In the C++ Standard, geometric_distribution comes between
binomial_distribution and negative_binomial_distribution.
| \indexlibrarymemberx{extreme_value_distribution}{operator()} | ||
| \begin{itemdecl} | ||
| template<typename Generator> | ||
| Q operator()(Generator& g); | ||
| \end{itemdecl} | ||
|
|
||
| \begin{itemdescr} | ||
| \pnum | ||
| \effects | ||
| Equivalent to: | ||
| \tcode{return Q(base::operator()(g));} | ||
| \end{itemdescr} |
There was a problem hiding this comment.
Can I get rid of these optimizations?
The requirements should be equivalent.
However, I don't see that Q::unit is required to be mp_units::one.
There was a problem hiding this comment.
One of our contributors provided this code. I did a short review but never had time to analyze all the generators properly. If you see any issues, please do not hesitate to fix them or create a new Issue with the list of things to do.
| \item | ||
| Otherwise, no effect. | ||
| \begin{note} | ||
| UTF-8 text can't be copied to \tcode{CharT} output. | ||
| \end{note} |
There was a problem hiding this comment.
This should be a constraint (that CharT be either char or char8_t).
| \item | ||
| Otherwise, if \tcode{std::is_same_v<CharT, char>} is \tcode{true}, equivalent to: | ||
| \begin{codeblock} | ||
| out = std::ranges::copy(txt.portable(), out) | ||
| \end{codeblock} | ||
| % The following item can be turned into a compile-time error. | ||
| \item | ||
| Otherwise, no effect. | ||
| \begin{note} | ||
| Portable text can't be copied to \tcode{CharT} output. | ||
| \end{note} |
There was a problem hiding this comment.
So, in this last case,
fmt.char_setischaracter_set::portable, andCharTischar8_t.
Why can you initialize a char8_t from a char literal,
but not write a string of chars to a char8_t stream?
There was a problem hiding this comment.
I really do not know what the rationale was, but I remember that it was the case in https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0482r6.html#design_compat_core_init.
There was a problem hiding this comment.
Hmm... I think you might be referring me to the language rules here.
I literally meant you, as to why, for example, you choose to do *out++ = '1' above.
This is the same issue I mentioned about the bit_cast in #628.
My understanding is that this '1' will be converted to char8_t like any other integer type,
having the same integer value, which isn't required to represent the same character when its character set isn't ASCII.
Likewise, I might just be crazy and we can leave this to the WG21 reviewers.
There was a problem hiding this comment.
According to the language rules I sent you, initializing char8_t from char and vice versa is OK. However, it is not allowed for arrays of characters or pointers to such.
There was a problem hiding this comment.
Is that only for literals?
This is still a WIP (continues #628):
TBDs and still missing:
Representationconcepts.sudo_cast.system_referencemath.hrandom.h