On Tuesday, 27 March 2012 at 15:14:07 UTC, Andrei Alexandrescu
wrote:
On 3/27/12 6:54 AM, Tyro[17] wrote:
On Tuesday, 27 March 2012 at 00:05:51 UTC, Andrei Alexandrescu
wrote:
On 3/26/12 2:52 PM, Tyro[17] wrote:
Couldn't the state of stdin be checked upon entrance into
readf
and reopened if it is already closed?
That won't work.
But this does:
[snip]
Very interesting! But then what if people press Ctrl-C? That
would end the input instead of ending the program.
Could that technique be used to implement readf for stdin?
I don't think we should pursue this path.
Wouldn't that accomplish the desired effect while avoiding
the pitfalls of scanf?
I don't think this is a pitfall. Essentially you don't have a
definition of what constitutes a chunk of input. Once you get
that
define, you should be able to express it more or less easily.
I'm of the opinion that Ctrl-D defines the boundary of that
chunk of input. We simply have to prevent it from closing
the stream when working with stdin.
You're in a sparse minority at best. Every Unix application out
there uses Ctrl-D for end-of-console-input, and your users
would be surprised by your exotic use of it.
Point taken.
Why not pick any other character for end of chunk - double
newline, Ctrl-S, pretty much anything but Ctrl-D? It's a waste
of your time to fight a long-established standard.
Thanks for the clarification. That's me just not knowing. I've
settled on Ctrl-X (\x018) because i have access to it without
doing anything special as opposed to Ctrl-S and no operating
system (as far as I know) uses it as a Command line shortcut.
Thanks for keeping the conversation going so I could find a
solution. Now, is it too much it the standard terminator
for string input from stdin?
Andrei
Andrew
