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 =


to  =


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


 DK
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() {


[post abruptly ends here with a header dump]

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

Thanks,

Andrei
Aug 27 2010
next 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() {


 [post abruptly ends here with a header dump]
 
 Is it my thunderbird installation, or does everybody see a chopped message?
 
 Thanks,
 
 Andrei


I see the whole message (thunderbird/icedove 2.0.0.24 on linux)
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() {


 [post abruptly ends here with a header dump]

 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 "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() {


 [post abruptly ends here with a header dump]

 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() {


 [post abruptly ends here with a header dump]

 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 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 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 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 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 reply bearophile <bearophileHUGS lycos.com> writes:
 I don't see the need of the open() method, it looks like noise in the File
API. Do you know its purpose?


If no one is able or has time to give me an answer I may file a bug report for
removal of that method.

Bye,
bearophile
Aug 27 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/27/10 12:09 PDT, bearophile wrote:

 I don't see the need of the open() method, it looks like noise in the File
API. Do you know its purpose?


 If no one is able or has time to give me an answer I may file a bug report for
removal of that method.

 Bye,
 bearophile


The open() method saves on reallocating the refcounted structured stored 
inside the File.

Andrei
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 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 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 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
parent reply "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
next sibling parent reply 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 


 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.






Read the clarification in the question. Reopening the file for append 
was not required.
Aug 27 2010
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


 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.






 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 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
parent reply "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
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 reply 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.


 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.
Aug 27 2010
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.


 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
Aug 27 2010
prev sibling parent reply "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
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
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei:

 The open() method saves on reallocating the refcounted
 structured stored inside the File.


Thank you for your answer.
So the API is designed a bit larger than necessary for performance reasons.

This the reformatted first part of the interesting implementation of File:


struct File {
    private struct Impl {
        FILE* handle = null;
        uint refs = uint.max / 2;
        string name = null;

        this(FILE* h, uint r, string n) {
            handle = h;
            refs = r;
            name = n;
        }
    }
    private Impl* p;

    this(string name, in char[] stdioOpenmode="rb") {
        p = new Impl(errnoEnforce(.fopen(name, stdioOpenmode),
                                  text("Cannot open file `", name, "' in mode
`", stdioOpenmode, "'")),
                     1,
                     name);
    }

    ~this() {
        if (!p)
            return;
        if (p.refs == 1)
            close;
        else
            --p.refs;
    }

    this(this) {
        if (!p)
            return;
        assert(p.refs);
        ++p.refs;
    }

    void opAssign(File rhs) {
        swap(p, rhs.p);
    }
    
    void open(string name, in char[] stdioOpenmode="rb") {
        detach;
        auto another = File(name, stdioOpenmode);
        swap(this, another);
    }


Few comments:

I am slowly starting to understand the purpose of that Impl :-) It allows to
use File as as a class instance, as it is by reference.


According to D specs on the site, inner structs contain an extra scope pointer,
so this may be better:
private static struct Impl {
I have seen the same problem in other parts of Phobos (see bug
http://d.puremagic.com/issues/show_bug.cgi?id=4087 ).


open() contains:
auto another = File(name, stdioOpenmode);
That calls File.this(), so isn't it creating a new Impl anyway? I don't
understand the performance gain still.


Given the presence of opAssign, I presume this code:
auto another = File(name, stdioOpenmode);
swap(this, another);
May be written just as:
this = File(name, stdioOpenmode);

Bye and thank you,
bearophile
Aug 27 2010