Correct and streamline documentation
ckormanyos opened this issue · 5 comments
Correct and streamline readme. In particular, new docs on WIDE_INTEGER_NAMESPACE are slightly incorrect regarding the default state of the preprocessor option which is now not defined.
List of things to improve/correct:
- Docs on
WIDE_INTEGER_NAMESPACE(see above). - Section on Conversion rules
Not sure if this is the right place but in terms of API design, I'd highly recommend doing as the ints do. If I made a wide integer out of two shorts, I would expect it to behave exactly like an int. Make sense?
Not sure if this is the right place but in terms of API design, I'd highly recommend doing as the ints do.
I try. It's a fine place for a small version of this discussion.
This is really a tough one for me, cause sometimes I struggle with the syntax and enable_if-ing this-or-that and it gets super confusing.
If I made a wide integer out of two
shorts, I would expect it to behave exactly like an int. Make sense?
Anyway...,
Yes. Wide integer is close, but not exactly there. ultimately a UDT can, in my opinion, never behave truly like a built-in. If I go for some implicit conversions with int, float, of short, long long, I might end up getting some warnings. Fine. I get warned.
If, however, i'm writing a C++ UDT, I seem to get two (maybe three) choices, either I can silently allow implicit conversion, or I can demand explicit conversion, or i can delete functions and get an error. What I can't get is a warning that sails through the compiler.
The long form of this discussioon belongs in the SG for numerics (is that SG6?) and beyond. Things like wide-integer can (or could) be drafts or even get close to reference implementatins. But ultimately we need specification(s) --- needed for big fixed, float, int, resulting in a whole bunch of missing specs.
Yes I'd stop short of implementing all promotions. E g. a two-char wide integer should not promote to int width.
Oh geez. I guess. Well I think wide-integer is at a good starting point. With successive rounds we can probably get around to all the necessary syntax and enable_if-ing.
Anyway, I'm pretty happy with the state, being used off the rack in cnl and many other projects. So it's a good start...
Thanks as always John for sage advice!