Parsing CSV files
in [MFC]
|
From: Joseph M. Newcomer on 2 Feb 2010 15:46 See below... On Tue, 02 Feb 2010 02:32:48 -0500, Hector Santos <sant9442(a)nospam.gmail.com> wrote: >Joseph M. Newcomer wrote: > >> You seem to be very confused. You are thinking that CR has meaning in parsing text lines. >> Except in the one rare exception of older Macintosh text files, it has no meaning in >> parsing text lines. It has relevance in rendering output, but you are confusing storage >> and rendering here. I was talking about the original topic, the parsing of text lines >> from Windows-compatible files. I'm not at all sure what you are talking about. >> joe > >Of course you don't because you took something and total >discombobulated it to show a meaningless point. > >Storage/Rendering are parts of the same coin. You are reading or more >specifically, your LINE READER is done for a purpose, either for >display, printing or what have you. A generalized line reader >understands all the conditions for EOL for all platforms. **** No. Storage is storage. Rendering is rendering. Sometimes, there is an encoding overlap, but it is purely coincidental. Unix, for example, stores "lines" as sequences of characters terminated by a newline (\n). The \r is supplied gratuitously when the line is rendered to a display device. In fact, in Unix it was difficult to get the cursor to move vertically because you had to override everything and work with pure binary output. When writing an application that runs on Windows, there is no reason to understand, or in general, even CARE about, EOL sequences on other platforms. You only have to worry about the EOL sequence in Windows-based files. **** > >You said the \r was meaningless since 1968 when in fact, you were >incorrect in it value in not only for rendering but storage. You said >it is ignored, well, first of all, thats not a meaningless action. >You took it into account. I could only be meaningless if it didn't >provide value to some rendering or print or output process - a total >waste in storage and for rendering. This is not reality across the board. **** No, I said that in 1968 we recognized that in parsing input, \r was meaningless. It was, and nothing you can say will change the fact that we KNEW it was meaningless noise in 1968; you can't rewrite history to satisfy your specification. I don't understand how you can make a claim that we were doing things in a way you think we SHOULD have been doing them, instead of the way we WERE doing them. I was there. This is the way we wrote input parsers. By the way, IBM systems stored lines as either fixed-length or variable-length records, with no terminator. I wrote text editors for those systems. I don't mean 8088-based PCs, I mean IBM mainframes. They had no carriage return, or line feed, or NUL character conventions. Records had a length which was determined either by the file type (fixed-length records) or the individual record (variable-length records). **** > >Maybe you might had been attempting to suggest it is "transparent", as >in a cooked I/O functionality under windows, but thats only because >the cooked functions themselves do the interpretation for you - that >is not meaningless. **** You are still insisting that whitespace noise has meaning. \r is whitespace noise. It only has value in rendering. It has no semantic content. It is used in edit controls to force rendering. It is not meaningful when parsing input. joe **** > >Bye Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Tom Serface on 2 Feb 2010 17:03 I've been doing more and more C# programming. I find it to be a very rapid development environment, but not so much because of the syntax. There is simply more "stuff" readily available in libraries and the VS IDE works so much better with it. All I've done are dialog type applications with WinForms and WebForms, so I suspect it may fail some (or not be as easy) to do SDI or MDI type applications. Tom "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:u42dmY#oKHA.4648(a)TK2MSFTNGP06.phx.gbl... > Hector Santos wrote: > >> I agree. But I decided I am going to invest in C# for development >> products but only provide the .NET interface and examples for our server. > > > Correction, "I am NOT...." > > -- > HLS
From: Ismo Salonen on 3 Feb 2010 01:34 --snip-- > **** > You are still insisting that whitespace noise has meaning. \r is whitespace noise. It > only has value in rendering. It has no semantic content. It is used in edit controls to > force rendering. It is not meaningful when parsing input. > joe --snip-- As a side not , in OS/9 (( 20 years ago ?) the \r was used as line delimiter. Don't know whye they picked different than the \n. Cannot not remember if the c runtime interbally did change from \n to \r and vice versa, I could dig old manuals iff I still can find them :-) ismo
From: Tom Serface on 3 Feb 2010 02:00 I think it doesn't matter what character signifies the end of the line. We just don't really need two of them for each line in flat files. In the old "terminal" days it made more sense because going to be beginning of a line was different operation than going down a line, but these days that doesn't make so much sense from a file point of view. Tom "Ismo Salonen" <ismo(a)codeit.fi> wrote in message news:OIAj3rJpKHA.5508(a)TK2MSFTNGP02.phx.gbl... > --snip-- > >> **** >> You are still insisting that whitespace noise has meaning. \r is >> whitespace noise. It >> only has value in rendering. It has no semantic content. It is used in >> edit controls to >> force rendering. It is not meaningful when parsing input. >> joe > --snip-- > > As a side not , in OS/9 (( 20 years ago ?) the \r was used as line > delimiter. Don't know whye they picked different than the \n. Cannot not > remember if the c runtime interbally did change from \n to \r and vice > versa, I could dig old manuals iff I still can find them :-) > > ismo
From: Hector Santos on 3 Feb 2010 10:10
Tom Serface wrote: > I think it doesn't matter what character signifies the end of the line. > We just don't really need two of them for each line in flat files. In > the old "terminal" days it made more sense because going to be beginning > of a line was different operation than going down a line, but these days > that doesn't make so much sense from a file point of view. Tom, I guess at the point, its clear that it really depends on ones experience and needs as system, protocol, tools and/or application developers. Try it yourself, create three flat files: MAC.TXT <CR> DOS.TXT <CR><LF> UNIX.TXT <LF> each with their natural corresponding EOL requirement. And good power programmer text editor will support this or write a piece of code to create example flat files. Now see how they NATURALLY apply at the application level for a WIDE degree of usages from simple to more detailed. See how meaningless it is? At the simplest: TYPE xxxx COPY xxxx LPT1: Or try to read each one with a DOS only based editor, like NotePad and see how it differs? Now if you were an internet mail (smtp, pop3, nntp, etc) protocol author, see how meaningless the STORAGE when these files content have RFC 2822 information. I can go on forever, its not a meaningless concept at ANY level. Protocol authors or implementations have seen enough of these talk from application developers that its part of reason there were many goof ups. An application developer take a LIBRARY, doesn't quite get the "details" but begins to use it simplistically. He will find out very quickly how "meaningless" its not AT ALL LEVELS and in particular the STORAGE level. Why? For example, assume an application has 1 file per message concept. He can't just COPYFILE to another sub-system or maybe GATEWAY QUEUE. If he doesn't take into account what EOL is used, he will RUN into trouble. I guess, understanding these subtle design points might be related to one's experience. If you don't deal with this on an everyday basis, across many protocols and application areas, a wide variety of interface and integrated considerations, then I can clearly understand the higher level view point, but that doesn't mean it is or was meaningless at ANY level. -- HLS |