On Fri, 27 Aug 2010 17:16:37 -0400, dsimcha <[email protected]> wrote:
== Quote from Steven Schveighoffer ([email protected])'s article
On Fri, 27 Aug 2010 16:41:58 -0400, Andrei Alexandrescu
<[email protected]> wrote:
> On 8/27/10 13:28 PDT, Steven Schveighoffer wrote:
>> No, the code does this:
>>
>> f.writeln("hello");
>> f.writeln("world");
>>
>> The example is supposed to demonstrate how to re-open the file for
>> appending and write "world". Look at some of the other examples. Not
>> that it's a big deal, because I think it's just one more line.
>
> Oh, I understand now. Thanks.
BTW, Don pointed out the clarifcation that I missed. It actually is
correct, my apologies.
>> I bring it up because people look at the C++ or C version and say
"how
>> ugly, look how nice D looks," but the C++ version doesn't incur extra
>> allocations AFAIK. It's like commenting on how beautiful function
qsort
>> looks. In reality, it's not as bad, because it's just that the
>> functionality isn't there yet. If it were, it would still look as
>> beautiful :) I just hate it when people compares an apple to orange
and
>> comment on how the orange looks like a much better apple.
>
> I agree. In fairness, the same goes about comparing incorrect code
with
> correct code. My understanding is that quite a few examples given in
> that thread are not correct, in spite of looking quite elaborate.
>
> FWIW it's not much aggravation to avoid unnecessary allocations:
>
> char[] line;
> f.readln(line);
> f.readln(line);
Hm.. this still allocates. We can do better than the C++ example:
char[128] buf;
char[] line = buf[];
f.readln(line);
f.readln(line);
Which should not allocate at all in this case, and is completely safe if
it *does* have to allocate (like if some malicious code came along and
rewrote the file to have a 500-character first line). Try to do *that*
with std::string :)
Man D is just so cool!
-Steve
I actually have no idea whether this reallocates or not because of the
way the
scarily complex readlnImpl() code works in std.stdio, and I think I was
the last
person to modify that code.
Having had to understand it a bit because I just updated appender and it
uses appender, I can assure you it only reallocates if it runs out of
provided buffer space.
In fact, before my changes, I think it would have allocated. I think
actually, the second call will definitely reallocate if the first one
did. I think we may need to revisit readlnImpl. It might be better if
readln in general took an output range instead of a buffer.
-Steve
