On 2015-03-21 at 22:15, FG wrote:
> On 2015-03-21 at 21:02, Dennis Ritchie wrote:
>>> In what universe?! Which OS, compiler and architecture?
>> Windows 8.1 x64, dmd 2.066.1:
>
> That's strange. I cannot recreate the problem on Win7 x64 with dmd 2.066.1, neither when compiled for 32- nor 64-bit. I have saved the a's to a file and use input redirect to load it, while the program is as follows:

Oh, wait. I was wrong. I have the same problem. It didn't appear before because the file of A's that I used didn't have a \r\n EOL at the end. With those two bytes added it failed. It's the EOL at the end of the input word that's the problem. I tested four different inputs:

aaa...aaa           OK
aaa...aaa\r\n       FAIL
aaa...aaa bbb       OK
aaa...aaa bbb\r\n   OK

On Saturday, 21 March 2015 at 16:34:44 UTC, Dennis Ritchie wrote:
> And why in D copied only the first 32767 characters of the string? I'm more days couldn't understand what was going on...

To me, it looks like a bug somewhere, though I don't get where exactly.  Is it in bits of DigitalMars C/C++ compiler code glued into druntime?

Anyway, as for Codeforces problems, you mostly need to read text input as tokens separated by spaces and/or newlines.  For that, D I/O is sufficient, there is no need to use legacy C++ I/O.

Usually, readf(" %s", &v) works for every scalar type of variable v (including reals and 64-bit integers) except strings, and readln() does the thing for strings.  Don't forget to get rid of the newline sequence on the previous line if you mix the two.  Possible leading and trailing spaces in " %s " mean skipping all whitespace before or after the token, respectively, as is the case for scanf in C/C++.

As far as I remember, for reading a line of numbers separated by spaces,
-----
auto a = readln.split.map!(to!int).array;
-----
is a bit faster than a loop of readf filling the array, but that hardly matters in the majority of problems.  You can see my submissions (http://codeforces.com/submissions/Gassa) for example.

If you really feel the need for I/O better suited for the specifics of algorithmic programming contests (as Java people almost always do in their language for some reason), look at Kazuhiro Hosaka's submissions (http://codeforces.com/submissions/hos.lyric).

In case you want to go even further and write your own I/O layer for that, I'll point you to a recent discussion of text I/O methods here: http://stackoverflow.com/q/28922323/1488799 (see comments and answers).

Ivan Kazmenko.

On Saturday, 21 March 2015 at 23:00:46 UTC, Ivan Kazmenko wrote:
> To me, it looks like a bug somewhere, though I don't get where exactly.  Is it in bits of DigitalMars C/C++ compiler code glued into druntime?

As far as I understand, the bug is in snn.lib's scanf.

snn.lib is Digital Mars's implementation of the C standard library (aka C runtime library or just C runtime). By default, some version of the C runtime is linked into every D program, so that you (and phobos and druntime) can use it. snn.lib is used for Windows x86. For other targets, other implementations of the C runtime are used (which don't have that bug).

On Saturday, 21 March 2015 at 23:00:46 UTC, Ivan Kazmenko wrote:
> On Saturday, 21 March 2015 at 16:34:44 UTC, Dennis Ritchie wrote:
>> And why in D copied only the first 32767 characters of the string? I'm more days couldn't understand what was going on...
>
> To me, it looks like a bug somewhere, though I don't get where exactly.  Is it in bits of DigitalMars C/C++ compiler code glued into druntime?
>
> Anyway, as for Codeforces problems, you mostly need to read text input as tokens separated by spaces and/or newlines.  For that, D I/O is sufficient, there is no need to use legacy C++ I/O.
>
> Usually, readf(" %s", &v) works for every scalar type of variable v (including reals and 64-bit integers) except strings, and readln() does the thing for strings.  Don't forget to get rid of the newline sequence on the previous line if you mix the two.  Possible leading and trailing spaces in " %s " mean skipping all whitespace before or after the token, respectively, as is the case for scanf in C/C++.
>
> As far as I remember, for reading a line of numbers separated by spaces,
> -----
> auto a = readln.split.map!(to!int).array;
> -----
> is a bit faster than a loop of readf filling the array, but that hardly matters in the majority of problems.  You can see my submissions (http://codeforces.com/submissions/Gassa) for example.
>
> If you really feel the need for I/O better suited for the specifics of algorithmic programming contests (as Java people almost always do in their language for some reason), look at Kazuhiro Hosaka's submissions (http://codeforces.com/submissions/hos.lyric).
>
> In case you want to go even further and write your own I/O layer for that, I'll point you to a recent discussion of text I/O methods here: http://stackoverflow.com/q/28922323/1488799 (see comments and answers).

Thanks.