On Friday, 5 February 2016 at 12:35:14 UTC, Artur Skawina wrote:
D's std lib implementations are sometimes really awful, but in
this case it's not actually that bad:
print("hi","there");
->
fwrite("hi", 1, 2, 0x7ff68d0cb640) =
2
fwrite(" ", 1, 1, 0x7ff68d0cb640) =
1
fwrite("there", 1, 5, 0x7ff68d0cb640) =
5
fwrite("\n", 1, 1, 0x7ff68d0cb640) =
1
Oh wow, and you thought to actually test it. I was just
eyeballing the code and running my mouth off. I can't fathom how
that's possible, because the only thing the write() template does
is translate each string argument to put(w,arg) where w is a
LockingTextWriter, and LockingTextWriter.put only outputs a
string if the sizeof... oh.
Yeah, my bad. Now I see it only puts each character as a string,
one at a time, if those characters are wide characters or
multibyte characters. It only does that if C.sizeof!=1 and I was
confusing .sizeof for .length. So for w"abc" it would put "a\0"
"b\0" "c\0" three times, I think, but for just "abc" it goes
straight to fwrite. It's the length of each character in bytes,
not the length of each string.
utf-8 encoded is still C.sizeof==1 I'm pretty sure. It's only
when you try to decode the characters or make "ropes" that you
end up with that iterative expansion of put().
Years ago I had to investigate why phobos showed up in the perf
profile of a program, when the only used part was some `write`
call used to print diagnostics. What I saw made me never use or
look at D's std lib again. Except for meta programing and
toy/example programs where it doesn't matter.
Maybe you should look again? I thought it was rather elegant,
except for the bizarre individual-character expansion that I
mistook for reality. It's not fast, but... very safe. Any D
process is going to lock the specific area of the file, so that
when you read a bunch, you're not going to have it change halfway
through, and two things aren't going to be writing in the same
place at the same time, at least not within individual write
calls.
