Re: Review: Special functions, Quaternions, Octonions

From: Hubert HOLIN (Hubert.Holin_at_[hidden])
Date: 2001-05-18 15:40:10

Paris (U.E.), le 18/05/2001

--- In boost_at_y..., Gary Powell <Gary.Powell_at_s...> wrote:
> Regarding operator>>(istream, octonion),
>   where the statement,
> 
>   is >> varName;
> 
>   if (is.fail() ) goto finish;
> 
> I think should be replaced by
> 
>   is >> varName;
> 
>   if (!is.good() ) goto finish;
> 
> 
> My copy of Standard C++ IOStreams and Locales p.35 bottom of the page.
> (section 1.3.2) has a recommendation that we check for error situations via
> fail(), and failure of input operations via !good(). This is because good()
> takes all flags into account, the eofbit included, wheras fail() ignores the
> eofbit.
> 
> Since is >> varName appears to me to be an input operation, the check should
> be !good().

        OK. Will be done.

> Also should the state of the stream be checked after the first call to
> is.putback(ch); before its called the second time? My reading of the
> standard says putback can fail.
> 
> WARNING I haven't used this and therefore may be totally off the wall here.
> I was wondering if a input steam iterator should be used to avoid having to
> call putback(). (On the theory that you can't putback to a readonly file)
> 
> 
> Another suggestion is to use peek() in the places where no matter what the
> next character is, you do a putback. There is at least one place where this
> would work. The comment on the if is "if ( cc == '(' ) // read "(((", where
> both for the if and the else the next statement is "is.putback(ch);"
> 
> and "if (cc == '(' ) // read "((a),(("
> it looks like the second call to putback() here is required.
> 
> While I didn't see a requirement in the standard, my "C++ Programming
> Language" section 21.6.2 has a comment to the effect that "what is
> guaranteed is that you can backup one character after a successful read."
> I'm not sure how that effects, a read, then a peek though.
> 
> Again if there is someone who understands this better than I, please review
> the above suggestions. (Talk about dark corners of C++!)
> 
>   -gary-
> 
> gary.powell_at_s...

        Well, the current form works (as far as I was able to determine, 
anyway :-)  ). Given the uncertainties of the alternate forms, I 
suggest we leave this portion of the code this way.

                Hubert Holin
                Hubert.Holin_at_[hidden]