On Monday, 30 December 2013 at 02:59:23 UTC, Marco Leise wrote:
Am Sun, 29 Dec 2013 22:03:14 +
schrieb Jeroen Bollen jbin...@gmail.com:
On Sunday, 29 December 2013 at 18:13:30 UTC, Jakob Ovrum wrote:
On Sunday, 29 December 2013 at 17:25:39 UTC, Jeroen Bollen
wrote:
Wouldn't byline
Am Tue, 31 Dec 2013 13:09:34 +
schrieb Jeroen Bollen jbin...@gmail.com:
On Monday, 30 December 2013 at 02:59:23 UTC, Marco Leise wrote:
Am Sun, 29 Dec 2013 22:03:14 +
schrieb Jeroen Bollen jbin...@gmail.com:
On Sunday, 29 December 2013 at 18:13:30 UTC, Jakob Ovrum wrote:
On
On 31/12/2013 14:45, Marco Leise wrote:
snip
I guess I just don't see what an immutable string buys you.
The mutable part in a string is just a pointer and length pair.
Just write:
immutable s = readln()[0 .. $-1];
and you have an immutable string at no cost.
What if the line is at EOF
Am Tue, 31 Dec 2013 16:21:14 +
schrieb Stewart Gordon smjg_1...@yahoo.com:
On 31/12/2013 14:45, Marco Leise wrote:
snip
I guess I just don't see what an immutable string buys you.
The mutable part in a string is just a pointer and length pair.
Just write:
immutable s =
Stewart Gordon:
I'd be inclined to define a function like
string stripLineBreak(string s) {
while (s.length != 0 s[$-1] != '\n' s[$-1] != '\r') {
s = s[0..$-1];
}
return s;
}
See the chop and chomp functions in std.string.
Bye,
bearophile
On 28/12/2013 16:49, Jeroen Bollen wrote:
Why is when you do readln() the newline character (\n) gets read too?
Wouldn't it make more sense for that character to be stripped off?
The newline character needs to be read - how else will it know when it's
got to the end of the line? :)
Of
On Sat, 28 Dec 2013 17:42:23 -, Jakob Ovrum jakobov...@gmail.com
wrote:
On Saturday, 28 December 2013 at 17:23:30 UTC, Jeroen Bollen wrote:
Usually if you're working with a console though the input stream won't
exhaust and thus the blocking 'readln' would be a better option, no?
The
On Monday, 30 December 2013 at 12:36:15 UTC, Regan Heath wrote:
Cue empty vs null theme music..
Empty vs null is not a factor here. It returns a string
containing the line terminator(s) for an empty line, but an empty
string (incidentally non-null) if the file is closed.
On Mon, 30 Dec 2013 13:51:46 -, Jakob Ovrum jakobov...@gmail.com
wrote:
On Monday, 30 December 2013 at 12:36:15 UTC, Regan Heath wrote:
Cue empty vs null theme music..
Empty vs null is not a factor here. It returns a string containing the
line terminator(s) for an empty line, but an
On Saturday, 28 December 2013 at 17:42:26 UTC, Jakob Ovrum wrote:
On Saturday, 28 December 2013 at 17:23:30 UTC, Jeroen Bollen
wrote:
Usually if you're working with a console though the input
stream won't exhaust and thus the blocking 'readln' would be a
better option, no?
The blocking
On Sunday, 29 December 2013 at 17:25:39 UTC, Jeroen Bollen wrote:
Wouldn't byline return an empty string if the inputstream is
exhausted but not closed?
No, both `readln` and `byLine` will block until either EOL or
EOF. They differ in their handling of EOF - `readln` returns an
empty string,
28-Dec-2013 21:13, Vladimir Panteleev пишет:
On Saturday, 28 December 2013 at 17:07:58 UTC, Andrei Alexandrescu wrote:
On 12/28/13 8:50 AM, Jeroen Bollen wrote:
On Saturday, 28 December 2013 at 16:49:15 UTC, Jeroen Bollen wrote:
Why is when you do readln() the newline character (\n) gets read
On Sunday, 29 December 2013 at 18:45:36 UTC, Dmitry Olshansky
wrote:
I've come to conclusion that the only sane line ending behavior
is to do what Unicode standard says, and detect the following
pattern as line separator:
\r\n | \r | \f | \v | \n | \u0085 | \u2028 | \u2029
This includes
29-Dec-2013 23:28, Vladimir Panteleev пишет:
On Sunday, 29 December 2013 at 18:45:36 UTC, Dmitry Olshansky wrote:
I've come to conclusion that the only sane line ending behavior is to
do what Unicode standard says, and detect the following pattern as
line separator:
\r\n | \r | \f | \v | \n |
On Sunday, 29 December 2013 at 18:13:30 UTC, Jakob Ovrum wrote:
On Sunday, 29 December 2013 at 17:25:39 UTC, Jeroen Bollen
wrote:
Wouldn't byline return an empty string if the inputstream is
exhausted but not closed?
No, both `readln` and `byLine` will block until either EOL or
EOF. They
Am Sun, 29 Dec 2013 22:03:14 +
schrieb Jeroen Bollen jbin...@gmail.com:
On Sunday, 29 December 2013 at 18:13:30 UTC, Jakob Ovrum wrote:
On Sunday, 29 December 2013 at 17:25:39 UTC, Jeroen Bollen
wrote:
Wouldn't byline return an empty string if the inputstream is
exhausted but not
Am Sat, 28 Dec 2013 17:08:38 +
schrieb Vladimir Panteleev vladi...@thecybershadow.net:
On Saturday, 28 December 2013 at 17:07:23 UTC, Andrei
Alexandrescu wrote:
On 12/28/13 8:49 AM, Jeroen Bollen wrote:
Why is when you do readln() the newline character (\n) gets
read too?
Wouldn't
On Monday, 30 December 2013 at 03:03:37 UTC, Marco Leise wrote:
Am Sat, 28 Dec 2013 17:08:38 +
schrieb Vladimir Panteleev vladi...@thecybershadow.net:
On Saturday, 28 December 2013 at 17:07:23 UTC, Andrei
Alexandrescu wrote:
On 12/28/13 8:49 AM, Jeroen Bollen wrote:
Why is when you do
Why is when you do readln() the newline character (\n) gets read
too? Wouldn't it make more sense for that character to be
stripped off?
On Saturday, 28 December 2013 at 16:49:15 UTC, Jeroen Bollen
wrote:
Why is when you do readln() the newline character (\n) gets
read too? Wouldn't it make more sense for that character to be
stripped off?
I just want to add to this, that it makes it really annoying to
work with the command
Jeroen Bollen:
it makes it really annoying to work with the command line, as
you kinda have to strip off the last character and thus cannot
make the string immutable.
void main() {
import std.stdio, std.string;
immutable txt = readln.chomp;
writeln(, txt, );
}
Bye,
bearophile
On 12/28/13 8:49 AM, Jeroen Bollen wrote:
Why is when you do readln() the newline character (\n) gets read too?
Wouldn't it make more sense for that character to be stripped off?
So you know that if it returns an empty string the file is done.
Andrei
On Saturday, 28 December 2013 at 16:50:21 UTC, Jeroen Bollen
wrote:
On Saturday, 28 December 2013 at 16:49:15 UTC, Jeroen Bollen
wrote:
Why is when you do readln() the newline character (\n) gets
read too? Wouldn't it make more sense for that character to be
stripped off?
I just want to add
On 12/28/13 8:50 AM, Jeroen Bollen wrote:
On Saturday, 28 December 2013 at 16:49:15 UTC, Jeroen Bollen wrote:
Why is when you do readln() the newline character (\n) gets read too?
Wouldn't it make more sense for that character to be stripped off?
I just want to add to this, that it makes it
On Saturday, 28 December 2013 at 17:07:23 UTC, Andrei
Alexandrescu wrote:
On 12/28/13 8:49 AM, Jeroen Bollen wrote:
Why is when you do readln() the newline character (\n) gets
read too?
Wouldn't it make more sense for that character to be stripped
off?
So you know that if it returns an empty
On 12/28/2013 08:50 AM, Jeroen Bollen wrote:
On Saturday, 28 December 2013 at 16:49:15 UTC, Jeroen Bollen wrote:
Why is when you do readln() the newline character (\n) gets read too?
Because it is possible to remove but hard or expensive or even
impossible (was there a newline?) to add back
On Saturday, 28 December 2013 at 17:07:58 UTC, Andrei
Alexandrescu wrote:
On 12/28/13 8:50 AM, Jeroen Bollen wrote:
On Saturday, 28 December 2013 at 16:49:15 UTC, Jeroen Bollen
wrote:
Why is when you do readln() the newline character (\n) gets
read too?
Wouldn't it make more sense for that
On Saturday, 28 December 2013 at 16:59:51 UTC, bearophile wrote:
void main() {
import std.stdio, std.string;
immutable txt = readln.chomp;
writeln(, txt, );
}
Bye,
bearophile
These examples are cute, but I think in real programs it's
usually important to handle `stdin` being
On Saturday, 28 December 2013 at 17:15:17 UTC, Jakob Ovrum wrote:
On Saturday, 28 December 2013 at 16:59:51 UTC, bearophile wrote:
void main() {
import std.stdio, std.string;
immutable txt = readln.chomp;
writeln(, txt, );
}
Bye,
bearophile
These examples are cute, but I think in
On Saturday, 28 December 2013 at 17:23:30 UTC, Jeroen Bollen
wrote:
Usually if you're working with a console though the input
stream won't exhaust and thus the blocking 'readln' would be a
better option, no?
The blocking behaviour of `stdin` by default is fine. The issue
is that `readln`
30 matches
Mail list logo
