Formatted read consumes input

monarch_dodra monarchdodra at gmail.com
Sat Sep 8 10:19:04 PDT 2012


On Saturday, 8 September 2012 at 12:10:26 UTC, kenji hara wrote:
> 2012/9/8 monarch_dodra <monarchdodra at gmail.com>:
> [snip]
>>
>> Still, I find it horrible to have to create a named "dummy" 
>> variable just
>> when I simply want to pass a copy of my range.
>
> Why you are afraid to declaring "dummy" variable?
> formattedRead is a parser, not an algorithm (as I said in the 
> pull
> request comment). After calling it, zero or more elements will 
> remain.
> And, in almost cases, the remains will be used other purpose, 
> or just
> checked that is empty.
>
> int n = formattedRead(input_range, fmt, args...);
> next_parsing(input_range);   // reusing input_range
> assert(input_range.empty);  // or just checked that is empty
>
> If formattedRead can receive rvalue, calling it would ignore the
> remains, and it will cause hidden bug.
>
> int n = formattedRead(r.save, fmt, args...);
> // If the remains is not empty, it is ignored. Is this 
> expected, or
> something logical bug?
>
> auto dummy = r.save;
> int n = formattedRead(dummy, fmt, args...);
> assert(dummy.empty);   // You can assert that remains should be 
> empty.
>
> formattedRead returns multiple states (the values which are 
> read, how
> many values are read, and remains of input), so allowing to 
> ignore
> them would introduce bad usage and possibilities of bugs.
>
> Kenji Hara

Hum, I think I see your point, although in my opinion, checking 
the return value is all that is required for generic error 
checking.

Checking the state of the range afterwards is being super extra 
careful for a specific use case, and should not necessarilly be 
forced onto the programmer.

I'll close the pull in the morning.


More information about the Digitalmars-d mailing list