www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - file i/o in a variety of languages

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
D doesn't look half bad:

http://stackoverflow.com/questions/3538156/file-i-o-in-every-programming-language-closed

Andrei
Aug 27 2010
next sibling parent reply Trass3r <un known.com> writes:
 D doesn't look half bad:

Yeah that comment about Go says it all:
 It's rather amazing that given 30 years of evolution and language  =

 design, they've still managed to invent a new language that's as hard =

 write error-checking code in as C. Even Java's less verbose! =E2=80=93=

Aug 27 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Trass3r wrote:
 D doesn't look half bad:

Yeah that comment about Go says it all:
 It's rather amazing that given 30 years of evolution and language 
 design, they've still managed to invent a new language that's as hard 
 to write error-checking code in as C. Even Java's less verbose! – DK


Here's the Go example. I think Go has made a serious error in centering their design around error codes. ---------------------------------------- package main import ( "os" "bufio" "log" ) func main() { file, err := os.Open("fileio.txt", os.O_RDWR | os.O_CREATE, 0666) if err != nil { log.Exit(err) } defer file.Close() _, err = file.Write([]byte("hello\n")) if err != nil { log.Exit(err) } _, err = file.Write([]byte("world\n")) if err != nil { log.Exit(err) } // seek to the beginning _, err = file.Seek(0,0) if err != nil { log.Exit(err) } bfile := bufio.NewReader(file) _, err = bfile.ReadBytes('\n') if err != nil { log.Exit(err) } line, err := bfile.ReadBytes('\n') if err != nil { log.Exit(err) } os.Stdout.Write(line) }
Aug 27 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/27/10 11:25 PDT, Walter Bright wrote:
 Trass3r wrote:
 D doesn't look half bad:

Yeah that comment about Go says it all:
 It's rather amazing that given 30 years of evolution and language
 design, they've still managed to invent a new language that's as hard
 to write error-checking code in as C. Even Java's less verbose! – DK


Here's the Go example. I think Go has made a serious error in centering their design around error codes. ---------------------------------------- package main import ( "os" "bufio" "log" ) func main() {

Is it my thunderbird installation, or does everybody see a chopped message? Thanks, Andrei
Aug 27 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:i5902n$20mi$1 digitalmars.com...
 On 8/27/10 11:25 PDT, Walter Bright wrote:
 Trass3r wrote:
 D doesn't look half bad:

Yeah that comment about Go says it all:
 It's rather amazing that given 30 years of evolution and language
 design, they've still managed to invent a new language that's as hard
 to write error-checking code in as C. Even Java's less verbose! - DK


Here's the Go example. I think Go has made a serious error in centering their design around error codes. ---------------------------------------- package main import ( "os" "bufio" "log" ) func main() {

Is it my thunderbird installation, or does everybody see a chopped message?

Works fine in outlook express.
Aug 27 2010
prev sibling next sibling parent simendsjo <simen.endsjo pandavre.com> writes:
On 27.08.2010 20:27, Andrei Alexandrescu wrote:
 On 8/27/10 11:25 PDT, Walter Bright wrote:
 Trass3r wrote:
 D doesn't look half bad:

Yeah that comment about Go says it all:
 It's rather amazing that given 30 years of evolution and language
 design, they've still managed to invent a new language that's as hard
 to write error-checking code in as C. Even Java's less verbose! – DK


Here's the Go example. I think Go has made a serious error in centering their design around error codes. ---------------------------------------- package main import ( "os" "bufio" "log" ) func main() {

Is it my thunderbird installation, or does everybody see a chopped message? Thanks, Andrei

Work's on Thunderbird 3.1.2 on Win7
Aug 27 2010
prev sibling parent reply Johannes Pfau <spam example.com> writes:
On 27.08.2010 20:27, Andrei Alexandrescu wrote:
 
 Is it my thunderbird installation, or does everybody see a chopped message?
 
 Thanks,
 
 Andrei

I see the complete message in this case, Thunderbird 3.1.2 Linux, but I have seen this problem before with other posts. Don't know what causes it, but it seems most people are not affected or I just never saw anyone complaining about it. -- Johannes Pfau
Aug 27 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/27/10 13:18 PDT, Johannes Pfau wrote:
 On 27.08.2010 20:27, Andrei Alexandrescu wrote:
 Is it my thunderbird installation, or does everybody see a chopped message?

 Thanks,

 Andrei

I see the complete message in this case, Thunderbird 3.1.2 Linux, but I have seen this problem before with other posts. Don't know what causes it, but it seems most people are not affected or I just never saw anyone complaining about it.

Thanks. Yah, TB 3.1.2 here too (on OSX though). I've only noticed this after upgrading to 3. Andrei
Aug 27 2010
next sibling parent Peter Alexander <peter.alexander.au gmail.com> writes:
On 27/08/10 9:25 PM, Andrei Alexandrescu wrote:
 On 8/27/10 13:18 PDT, Johannes Pfau wrote:
 On 27.08.2010 20:27, Andrei Alexandrescu wrote:
 Is it my thunderbird installation, or does everybody see a chopped
 message?

 Thanks,

 Andrei

I see the complete message in this case, Thunderbird 3.1.2 Linux, but I have seen this problem before with other posts. Don't know what causes it, but it seems most people are not affected or I just never saw anyone complaining about it.

Thanks. Yah, TB 3.1.2 here too (on OSX though). I've only noticed this after upgrading to 3. Andrei

I'm on TB 3.1.2 on Snow Leopard and haven't noticed any issues yet.
Aug 28 2010
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-08-27 22:25, Andrei Alexandrescu wrote:
 On 8/27/10 13:18 PDT, Johannes Pfau wrote:
 On 27.08.2010 20:27, Andrei Alexandrescu wrote:
 Is it my thunderbird installation, or does everybody see a chopped
 message?

 Thanks,

 Andrei

I see the complete message in this case, Thunderbird 3.1.2 Linux, but I have seen this problem before with other posts. Don't know what causes it, but it seems most people are not affected or I just never saw anyone complaining about it.

Thanks. Yah, TB 3.1.2 here too (on OSX though). I've only noticed this after upgrading to 3. Andrei

I'm using Thunderbird 3.1.2 on Mac OS X and I see the complete message. -- /Jacob Carlborg
Aug 28 2010
prev sibling parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
Johannes Pfau wrote:
 On 27.08.2010 20:27, Andrei Alexandrescu wrote:
 Is it my thunderbird installation, or does everybody see a chopped message?

 Thanks,

 Andrei

I see the complete message in this case, Thunderbird 3.1.2 Linux, but I have seen this problem before with other posts. Don't know what causes it, but it seems most people are not affected or I just never saw anyone complaining about it.

Actually, this was what caused me to wonder if anyone sees my messages correctly (test: does anybody read my messages normally? in D.learn newsgroup). Funny thing, I've posted my message via mailing list (and got it back correctly with Thunderbird on Windows), but later I opened a newsgroup in Icedove 2.0.0.22 and saw my own message as a total mess of text, mail headers and whatnot. I guess it's Thunderbird/Icedove fault.
Aug 27 2010
parent torhu <no spam.invalid> writes:
On 27.08.2010 23:11, Stanislav Blinov wrote:
 Actually, this was what caused me to wonder if anyone sees my messages
 correctly (test: does anybody read my messages normally? in D.learn
 newsgroup). Funny thing, I've posted my message via mailing list (and
 got it back correctly with Thunderbird on Windows), but later I opened a
 newsgroup in Icedove 2.0.0.22 and saw my own message as a total mess of
 text, mail headers and whatnot. I guess it's Thunderbird/Icedove fault.

Yeah, Thunderbird seems to randomly mess up posts like that. Maybe a reinstall would fix it, but it'd probably just return as the number of posts grow. In the web interface the same posts look just fine. I've got the latest 3.1.x on Windows 7. If only it happened to emails and not just newsgroups then maybe they'd fix it...
Aug 27 2010
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Walter Bright wrote:
 Trass3r wrote:
 D doesn't look half bad:

Yeah that comment about Go says it all:
 It's rather amazing that given 30 years of evolution and language 
 design, they've still managed to invent a new language that's as hard 
 to write error-checking code in as C. Even Java's less verbose! – DK



And here's the C version. Note the heroic attempt to check for errors, and yet how most errors are not checked for: ------------------------------------------ #include <stdio.h> #include <stdlib.h> int main(void) { FILE *file; char buf[128]; file = fopen("fileio.txt", "w"); if (!file) { fprintf(stderr, "Couldn't open file.\n"); exit(1); } fprintf(file, "hello"); fclose(file); file = fopen("fileio.txt", "a"); if (!file) { fprintf(stderr, "Couldn't open file.\n"); exit(1); } fprintf(file, "\nworld"); fclose(file); file = fopen("fileio.txt", "r"); if (!file) { fprintf(stderr, "Couldn't open file.\n"); exit(1); } fgets(buf, sizeof(buf), file); fgets(buf, sizeof(buf), file); fclose(file); puts(buf); return 0; }
Aug 27 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/27/10 11:29 PDT, Walter Bright wrote:
 Walter Bright wrote:
 Trass3r wrote:
 D doesn't look half bad:

Yeah that comment about Go says it all:
 It's rather amazing that given 30 years of evolution and language
 design, they've still managed to invent a new language that's as
 hard to write error-checking code in as C. Even Java's less verbose!
 – DK



And here's the C version. Note the heroic attempt to check for errors, and yet how most errors are not checked for:

Good point. To paraphrase a well-known quote, it does look like exceptions are the worst way to go about error handling, except all others. Andrei
Aug 27 2010
prev sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Andrei Alexandrescu schrieb:
 On 8/27/10 11:25 PDT, Walter Bright wrote:
 Trass3r wrote:
 D doesn't look half bad:

Yeah that comment about Go says it all:
 It's rather amazing that given 30 years of evolution and language
 design, they've still managed to invent a new language that's as hard
 to write error-checking code in as C. Even Java's less verbose! – DK


Here's the Go example. I think Go has made a serious error in centering their design around error codes. ---------------------------------------- package main import ( "os" "bufio" "log" ) func main() {

Is it my thunderbird installation, or does everybody see a chopped message? Thanks, Andrei

Aug 27 2010
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 D doesn't look half bad:
 http://stackoverflow.com/questions/3538156/file-i-o-in-every-programming-language-closed

Yes, it looks nice, File looks well designed, its design is almost equal to the Python one (despite in that page they have used a different code strategy in Python). I guess this line: f.readln; Will need to be written: f.readln(); Regarding this: auto f = File("fileio.txt", "w"); ... f.open("fileio.txt", "r"); It is correct, because it first calls detach(), but what is the purpose of the open() method? At first sight this is the main difference between the D and Python file API. Isn't it more clear and simpler to write just: auto f = File("fileio.txt", "w"); ... f = File("fileio.txt", "r"); I don't see the need of the open() method, it looks like noise in the File API. Do you know its purpose? Bye, bearophile
Aug 27 2010
parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
I'm assuming the file.open() function will close any open file. When does your
suggestion close the file?

bearophile Wrote:

 Regarding this:
 
 auto f = File("fileio.txt", "w");
 ...
 f.open("fileio.txt", "r");
 
 It is correct, because it first calls detach(), but what is the purpose of the
open() method? At first sight this is the main difference between the D and
Python file API. Isn't it more clear and simpler to write just:
 
 auto f = File("fileio.txt", "w");
 ...
 f = File("fileio.txt", "r");
 
 I don't see the need of the open() method, it looks like noise in the File
API. Do you know its purpose?
 
 Bye,
 bearophile

Aug 27 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Jesse Phillips:
 I'm assuming the file.open() function will close any open file. When does your
suggestion close the file?

If you write: auto f = File("foo.txt", "w"); f = File("bar.txt", "r"); I think the first file will be closed, thanks to the reference counter. My complete version was: import std.stdio: write, File; void main() { auto f = File("fileio.txt", "w"); f.writeln("hello"); f.writeln("world"); f.close(); f = File("fileio.txt", "r"); f.readln(); auto s = f.readln(); // as required write(s); f.close(); // optional } Bye, bearophile
Aug 27 2010
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 D doesn't look half bad:
 http://stackoverflow.com/questions/3538156/file-i-o-in-every-programming-language-closed

I find it stupid that they have closed this quite interesting thread. Even if the purpose of the stackoverflow site is a bit of difference, they have shown the flexibility of 4-years-old people. I presume those comparisons may be moved to the Rosettacode site, that is designed for this purpose. Bye, bearophile
Aug 27 2010
next sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Friday, August 27, 2010 08:16:39 Andrej Mitrovic wrote:
 They keep closing informational topics like these. And yet topics like
 "Jon Skeet facts" stay open. It's ridiculous.

There's definitely some great stuff at stack overflow, and it's generally a great place to ask questions, but it does seem like there are folks there who love to close questions if they can. So, it can be painfully often that good questions get closed as "not a real question," though bad questions that deserve to be closed do show up. It can be a bit weird when something stays and when it doesn't. My general experience has been though, that something good is more likely to be closed than something bad kept. Though, whether that's good or bad is another question. - Jonathan M Davis
Aug 27 2010
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:i58fdo$rub$1 digitalmars.com...
 Andrei Alexandrescu:

 D doesn't look half bad:
 http://stackoverflow.com/questions/3538156/file-i-o-in-every-programming-language-closed

I find it stupid that they have closed this quite interesting thread. Even if the purpose of the stackoverflow site is a bit of difference, they have shown the flexibility of 4-years-old people.

There's a lot about Stack Overflow that has struck me as being run by 4-year-olds.
Aug 27 2010
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
They keep closing informational topics like these. And yet topics like
"Jon Skeet facts" stay open. It's ridiculous.

On Fri, Aug 27, 2010 at 3:43 PM, bearophile <bearophileHUGS lycos.com> wrote:
 Andrei Alexandrescu:

 D doesn't look half bad:
 http://stackoverflow.com/questions/3538156/file-i-o-in-every-programming-language-closed

I find it stupid that they have closed this quite interesting thread. Even if the purpose of the stackoverflow site is a bit of difference, they have shown the flexibility of 4-years-old people. I presume those comparisons may be moved to the Rosettacode site, that is designed for this purpose. Bye, bearophile

Aug 27 2010
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Fri, 27 Aug 2010 14:27:27 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 8/27/10 11:25 PDT, Walter Bright wrote:
 Trass3r wrote:
 D doesn't look half bad:

Yeah that comment about Go says it all:
 It's rather amazing that given 30 years of evolution and language
 design, they've still managed to invent a new language that's as hard
 to write error-checking code in as C. Even Java's less verbose! – DK


Here's the Go example. I think Go has made a serious error in centering their design around error codes. ---------------------------------------- package main import ( "os" "bufio" "log" ) func main() {

Is it my thunderbird installation, or does everybody see a chopped message? Thanks, Andrei

My newsreader (Opera) reads it fine.
Aug 27 2010
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I wonder if Go will become another "Wave" from Google. :p

On Fri, Aug 27, 2010 at 8:25 PM, Walter Bright
<newshound2 digitalmars.com> wrote:
 Here's the Go example. I think Go has made a serious error in centering
 their design around error codes.
 snip

Aug 27 2010
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:i580v8$2usc$1 digitalmars.com...
D doesn't look half bad:

 http://stackoverflow.com/questions/3538156/file-i-o-in-every-programming-language-closed

LOLCODE is my new favorite langauge. (Previously it was fuckfuck - like brainfuck, but replaces the symbols with four-letter words) I knew JS and Go sucked, but holy hell, I didn't know they were THAT bad.
Aug 27 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/27/10 12:12 PDT, Nick Sabalausky wrote:
 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:i580v8$2usc$1 digitalmars.com...
 D doesn't look half bad:

 http://stackoverflow.com/questions/3538156/file-i-o-in-every-programming-language-closed

LOLCODE is my new favorite langauge. (Previously it was fuckfuck - like brainfuck, but replaces the symbols with four-letter words) I knew JS and Go sucked, but holy hell, I didn't know they were THAT bad.

In the defense of JS, it does everything asynchronously. Andrei
Aug 27 2010
prev sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Nick Sabalausky <a a.a> wrote:

 LOLCODE is my new favorite langauge. (Previously it was fuckfuck - like
 brainfuck, but replaces the symbols with four-letter words)

LOLCODE is indeed a great language. Perhaps not the biggest on features or standardization, but who cares when you can program in cat macros? -- Simen
Aug 27 2010
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Someone even made a Brainfuck compiler in LOLCODE. I don't have the
link, but google should help. :p

On Fri, Aug 27, 2010 at 9:12 PM, Nick Sabalausky <a a.a> wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 news:i580v8$2usc$1 digitalmars.com...
D doesn't look half bad:

 http://stackoverflow.com/questions/3538156/file-i-o-in-every-programming-language-closed

LOLCODE is my new favorite langauge. (Previously it was fuckfuck - like brainfuck, but replaces the symbols with four-letter words) I knew JS and Go sucked, but holy hell, I didn't know they were THAT bad.

Aug 27 2010
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 27 Aug 2010 05:36:32 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 D doesn't look half bad:

 http://stackoverflow.com/questions/3538156/file-i-o-in-every-programming-language-closed

Note that D's version doesn't follow the rules, you were supposed to re-open the file for appending, they just never closed it. It also reads the first line into a buffer and then throws it away. Does File have a way to skip a line? -Steve
Aug 27 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/27/10 13:01 PDT, Steven Schveighoffer wrote:
 On Fri, 27 Aug 2010 05:36:32 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 D doesn't look half bad:

 http://stackoverflow.com/questions/3538156/file-i-o-in-every-programming-language-closed

Note that D's version doesn't follow the rules, you were supposed to re-open the file for appending, they just never closed it.

The call to open() closes the file (and throws on error) and then opens the file (and throws on error). I think that's fair.
 It also reads the first line into a buffer and then throws it away. Does
 File have a way to skip a line?

Not that I know of. Save for the allocation, the effort is the same - the implementation still has to look for the '\n'. Andrei
Aug 27 2010
next sibling parent Don <nospam nospam.com> writes:
Steven Schveighoffer wrote:
 On Fri, 27 Aug 2010 16:18:26 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 On 8/27/10 13:01 PDT, Steven Schveighoffer wrote:
 On Fri, 27 Aug 2010 05:36:32 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 D doesn't look half bad:

 http://stackoverflow.com/questions/3538156/file-i-o-in-every-program
ing-language-closed 

re-open the file for appending, they just never closed it.



Read the clarification in the question. Reopening the file for append was not required.
Aug 27 2010
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/27/10 13:28 PDT, Steven Schveighoffer wrote:
 On Fri, 27 Aug 2010 16:18:26 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 On 8/27/10 13:01 PDT, Steven Schveighoffer wrote:
 On Fri, 27 Aug 2010 05:36:32 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 D doesn't look half bad:

 http://stackoverflow.com/questions/3538156/file-i-o-in-every-programming-language-closed

Note that D's version doesn't follow the rules, you were supposed to re-open the file for appending, they just never closed it.

The call to open() closes the file (and throws on error) and then opens the file (and throws on error). I think that's fair.

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.
 It also reads the first line into a buffer and then throws it away. Does
 File have a way to skip a line?

Not that I know of. Save for the allocation, the effort is the same - the implementation still has to look for the '\n'.

Allocation can be expensive. With D-allocated buffers, this would be trivial to do without allocation, just keep refilling the buffer until you find a '\n'. But searching in the FILE * buffer is not trivial at all. I think D is going to eventually have to address this. 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); Andrei
Aug 27 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/27/10 13:48 PDT, Steven Schveighoffer wrote:
 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!

Yah, nice touch. By the way, it's embarrassing that the C version is incorrect (albeit thankfully not unsafe) on input lines longer than 128 chars. Andrei
Aug 27 2010
prev sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article
 On Fri, 27 Aug 2010 16:41:58 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> 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.

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);

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.
Aug 27 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 27 Aug 2010 16:18:26 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 8/27/10 13:01 PDT, Steven Schveighoffer wrote:
 On Fri, 27 Aug 2010 05:36:32 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 D doesn't look half bad:

 http://stackoverflow.com/questions/3538156/file-i-o-in-every-programming-language-closed

Note that D's version doesn't follow the rules, you were supposed to re-open the file for appending, they just never closed it.

The call to open() closes the file (and throws on error) and then opens the file (and throws on error). I think that's fair.

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.
 It also reads the first line into a buffer and then throws it away. Does
 File have a way to skip a line?

Not that I know of. Save for the allocation, the effort is the same - the implementation still has to look for the '\n'.

Allocation can be expensive. With D-allocated buffers, this would be trivial to do without allocation, just keep refilling the buffer until you find a '\n'. But searching in the FILE * buffer is not trivial at all. I think D is going to eventually have to address this. 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. -Steve
Aug 27 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 27 Aug 2010 16:35:49 -0400, Don <nospam nospam.com> wrote:

 Steven Schveighoffer wrote:
 On Fri, 27 Aug 2010 16:18:26 -0400, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

 On 8/27/10 13:01 PDT, Steven Schveighoffer wrote:
 On Fri, 27 Aug 2010 05:36:32 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 D doesn't look half bad:

 http://stackoverflow.com/questions/3538156/file-i-o-in-every-programming-language-closed

re-open the file for appending, they just never closed it.



Read the clarification in the question. Reopening the file for append was not required.

Oops I missed that. Then the other examples are not optimized ;) In particular, the C one reopens the file for appending. -Steve
Aug 27 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 27 Aug 2010 16:41:58 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> 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
Aug 27 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 27 Aug 2010 17:16:37 -0400, dsimcha <dsimcha yahoo.com> wrote:

 == Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article
 On Fri, 27 Aug 2010 16:41:58 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> 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.

correct, my apologies.
 I bring it up because people look at the C++ or C version and say  


 ugly, look how nice D looks," but the C++ version doesn't incur extra
 allocations AFAIK. It's like commenting on how beautiful function  


 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  


 comment on how the orange looks like a much better apple.

I agree. In fairness, the same goes about comparing incorrect code

 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);

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
Aug 27 2010
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
On Fri, 27 Aug 2010 22:28:56 +0200, Steven Schveighoffer  
<schveiguy yahoo.com> 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.

From the OP:
 Clarification:
 * You should show how to do this in one programming language per answer  
 only.
 * Assume that the text file doesn't exist beforehand
 * You don't need to reopen the text file after writing the first line

The third point here might be important. -- Simen
Aug 27 2010
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 27 Aug 2010 18:03:19 -0400, Simen kjaeraas  
<simen.kjaras gmail.com> wrote:

 On Fri, 27 Aug 2010 22:28:56 +0200, Steven Schveighoffer  
 <schveiguy yahoo.com> 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.

From the OP:
 Clarification:
 * You should show how to do this in one programming language per answer  
 only.
 * Assume that the text file doesn't exist beforehand
 * You don't need to reopen the text file after writing the first line

The third point here might be important.

Yes, I've already acknowledged my mistake. Thanks for pointing it out again ;) -Steve
Aug 30 2010