[coyotos-dev] [PATCH included] Test infrastructure for bignum
Thomas Stratmann
thomas.stratmann at rub.de
Fri May 16 17:32:10 CDT 2008
Jonathan S. Shapiro wrote:
---snip---
> Yes. In my opinion there are only two correct choices:
>
> 1. Raise an exception because input is malformed.
> 2. Behave like strtol and stop at first non-digit.
Exactly. My suggestion is to have two functions for these two cases...
the constructor can raise an exception, the istream operator stops at
garbage. If you like, we can also introduce an additional "silent"
member function for assignment from a string that also stops at garbage.
Either way, it has to be documented.
Enough said. I suggest you make up your mind and let me code (test,
document) what you need ;-)
>
> The current code does neither, which is a clear bug.
>
> The second is convenient for parser-like processing, which is why I
> (very slightly) prefer it.
>
>> When constructing a BigNum from a string, I would say that it is an
>> error if the string does not properly represent a bignum in the first
>> place (the reason I am making this claim is that there is no way to
>> return the actual valid read length, or equivalent). Am I guessing right
>> that you would not like raising an exception here?
>
> Hmm. You are raising a very good point about the read length here. This
> may be a use-case for another constructor variant.
How would you pass back that info? Pass a pointer for storage? That
would be more ugly than raising an exception!
>
> Yes, there is something very ugly about C++ exceptions, so I had hoped
> to avoid them.
>
---doublesnip---
>
> My opinion:
>
> If a base is supplied explicitly, it should be honored. Deducing the
> base from the leading 0 (or 0[Xx]) is a fall-back kludge.
>
> If the base is supplied explicitly, then there is no need to do anything
> special to ignore leading zeros, because the "mulitply by radix and add
> next digit" step automatically does the right thing.
Oh, I missed that... nothing to do in that case. I will build fixtures
to include that.
T
More information about the coyotos-dev
mailing list