Parsing CSV files
in [MFC]
|
From: Joseph M. Newcomer on 1 Feb 2010 08:45 Yes, that is correct. It malfunctions, because it is working precisely as specified, not as anyone would actually want it to. But strtok is such a fundamentally BAD design that it should never be used in real code. The number of times I've seen an embedded strtok added long after program creation completely nuke an existing strtok is amazingly high. But by the early 1980s, we had learned to never, ever use strtok in any code we cared about, which was typically 100% of our code. joe On Sat, 23 Jan 2010 18:52:05 -0000, "Stanza" <stanza(a)devnull.com> wrote: >Thanks for everyone's contributions. There's quite a lot here to digest. Re >strtok - I remember using this many years ago, and as far as I recall it >would jump over empty csv entries, so the string "one,,three" would return >"one" followed by "three". Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 1 Feb 2010 08:49 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 On Sat, 23 Jan 2010 15:02:00 -0500, Hector Santos <sant9442(a)nospam.gmail.com> wrote: >There is one explanation for this spin. You are visually handicap. If >that is the case, I wish to extend my apology for my ignorance. > >-- >HLS > >Joseph M. Newcomer wrote: > >> Logically, many rendering programs will try \r as "reset cursor to beginning margin" >> (which in most languages is the left side of the display area, but in some languages like >> Arabic and Hebrew is the right side). But that's a display technique, and he somehow made >> the leap from my discussing how to parse stored data to thinking I was talking about >> display rendering, a topic that was not under discussion. >> joe >> >> On Fri, 22 Jan 2010 23:58:13 -0800, "Tom Serface" <tom(a)camaswood.com> wrote: >> >>> I think Joe is saying it is meaningless these days because there is no >>> carriage to return any longer. I think most of us consider \n synonymous >>> with Enter and that implies the start of a new line. A lot of this is >>> carry over from the days of teletype and paper terminals and we're just >>> stuck with it as part of ASCII. >>> >>> Tom >>> >>> "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message >>> news:uqDAH$$mKHA.1548(a)TK2MSFTNGP04.phx.gbl... >>>> Joseph M. Newcomer wrote: >>>> >>>>> One of the rules we developed about forty years ago (1968) is that \r is >>>>> meaningless noise >>>>> treated as whitespace, and \n is a newline. This works until you import >>>>> a text file >>>>> creating on a pre-OS X Mac, where \r is the newline character. >>>>> joe >>>> >>>> Don't confuse raw vs cooked vs display/print device vs storage systems! >>>> >>>> \r\n has their basis as hardware device codes for the harder devices of >>>> the day; printers, teletypes, dumb terminals, etc >>>> >>>> \r <CR> is what it is - a carriage return (move it to the first column) of >>>> the printer head! Note the operative word - Carriage! >>>> >>>> \n <LF> is what it is - a line feed (move carriage head down one line) of >>>> the printer head! >>>> >>>> When the consoles came, the printer head was now your cursor. That is why >>>> it is paired whether there are from translations or not. >>>> >>>> Now, your Terminal and Printer could have OPTIONAL translation for an >>>> automatic line feed (/n) with each carriage return (/r) which means it >>>> APPEAR as it was a line delimiter as in in the unix wienie world. In the >>>> MAC word, a /n is the line delimiter. DOS of courses uses /r/n (<CR><LF>) >>>> pairs. >>>> >>>> But it is your terminal or printer providing the illusion with >>>> translations which may be default depending on the OS it connected to). >>>> So if you dumped a unix file or mac file to a printer, it did the proper >>>> translation for you. The printer or carriage or laser point did not >>>> change, you still need to tell it to go left, right, up or down! >>>> >>>> Geez, Meaningless? >>>> >>>> This again is a example of insane revisionist comments. >>>> >>>> -- >>>> HLS >> Joseph M. Newcomer [MVP] >> email: newcomer(a)flounder.com >> Web: http://www.flounder.com >> MVP Tips: http://www.flounder.com/mvp_tips.htm Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 1 Feb 2010 09:01 See below... On Mon, 25 Jan 2010 14:08:28 -0500, "Pete Delgado" <Peter.Delgado(a)NoSpam.com> wrote: > >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message >news:s33ll5l35qnknus8i1n06qitu1r5f750jv(a)4ax.com... >> On Fri, 22 Jan 2010 23:44:44 -0500, Hector Santos >> <sant9442(a)nospam.gmail.com> wrote: >> >>>Joseph M. Newcomer wrote: >>> >>>> This code looks like something from K&R C programming first edition. >>> >>> >>>HA! you shouldn't be ashame about it, Joey! You're too easy. :) >> >> Huh? I'd be embarassed to publish an algorithm that was based on K&R C. >> It represents >> the best of mediocre programming of thirty years ago. When I first read >> it, in 1975, I >> said "This language is really badly done", > >From my understanding, the book wasn't published until 1978! ;-) You may >have been thinking of the version of the C reference manual that was >provided with the Unix operating system. **** The book was a repackaging of the C reference manual. **** > >Other than that little nitpick, I think you are confusing the defects in the >implementation of the standard library with the true language defects. >Additionally, I think to compare a 30+ year old language that was originally >designed as a system implementation language with the modern general purpose >languages of today is misleading. C met its goals and became wildly >successful despite its flaws and is still very widely used even today. **** Both the standard library and the language had serious problems. Some of them persist to this day, such as the strcpy/strcat/sprintf buffer overrun problems. Sadly, there are people today who use C as if it is K&R C, in spite of the fact that both the language and the runtimes have matured. You can spot these people right away, because they toss strcpy, strcat, and sprintf around like they ever made sense, they use silly prefix names inside structures for fields (putting some prefix like "tmHour" does inside the "tm" struct, because struct field names were global in K&R C and had to be globally unique). And today, especially in Windows, we can add people who use the 'char' data type as the natural representation of text. C became successful because it was given away free on a bunch of machines. Quality of the language or the runtime had nothing to do with its popularity. And for those who thought C was a "successful" system implementation language: I was working with a compiler company in the 1980s, and our compiler could not compile the Unix kernel. Why? Because AFTER the compiler ran, for some modules it ran a sed script over the generated code to change it, and our compiler assigned registers differently than the AT&T C compiler, and broke all the sed scripts. Now it is really hard for me to take seriously a "system implementation language" that requires hand-editing of the generated code (no matter how automated this is made) in order to work in its specified role. So it only barely made the grade. Remember, VHS tapes succeeded over Beta tapes, also, but it didn't make VHS a better quality format! joe **** > >-Pete > > > > >-Pete > > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 1 Feb 2010 09:06 If you look at functional programming closely, especially along the dimensions of concepts such as "total" functions, "partial" functions, "pure" functions, and such, you see a powerful evolution of the thinking of ways to do software. Sadly, none of these languages has a significant following outside a few academics. As a former compiler writer, functional languages contain massively interesting amounts of information that can be used to create super-quality code; languages like C, C++ and even C# have a lot of issues that prevent good code generation. Personally, I'd love to be able to look back on languages like C, C++ and C# as the antiquated artifacts they are. But if you can't use a motorcycle, you might at least use a competition-quality racing bike, or even a really good 10-speed, instead of a "bone-shaker" (look up the history of bicycles if you don't know what this means...) joe On Mon, 25 Jan 2010 15:36:37 -0500, Hector Santos <sant9442(a)nospam.gmail.com> wrote: >Pete Delgado wrote: > > >> Joesph M. Newcomer wrote: > >> > >>> Huh? I'd be embarassed to publish an algorithm that was based on K&R C. >>> It represents the best of mediocre programming of thirty years ago. > > >> When I first read it, in 1975, I said "This language is really > >> badly done", > >> >> ..... I think you are confusing the defects in the >> implementation of the standard library with the true language defects. >> Additionally, I think to compare a 30+ year old language that was originally >> designed as a system implementation language with the modern general purpose >> languages of today is misleading. C met its goals and became wildly >> successful despite its flaws and is still very widely used even today. > > >Excellent point Pete. > >My opinion on a related note: > >I find it increasing harder to shallow how even today, people are >getting locked into thinking or "mindset" molded that what you did in >the past was all wrong and today's method is the better way. While >one might be able explain why the "militants" of this mantra are they >way they are, I just find the "stubbornness" very vexing, especially >from those who are obviously veterans of the industry. Generally, it >is the opposite. > >Again, a rhetorical opinion. > >I personally find it very odd that a dialect of the C language or any >language for that matter, has been "kludge" to support a syntax that >is cluttered with type casting. > >So as Joe might has stated 25 years ago in regards to C: > > "This language is really badly done" > >I can easily say the same thing today with today's C/C++ syntaxing to >support unicode. I say that because 25 years from now, programmers >will most likely be saying the same sort of thing: > > "This language is really badly done! It isn't > necessary today. Why all the extra coding?" > >I only say that because I am firm believer in functional programming >where such specifics are excluded from the overall "thinking" and >interfacing, I/O transformation or function generators. > >This is closer and it also it is a rebirth direction of where MS and >others are going with its languages. It is more "natural" per se, >without the wasteful "think time" to address minor details one has to >put into current C/C++ programming. > >These minor details are quite often SO "touchy" in its required >construct that if one subtle mistake will create the same or worst >problem that it attempted to resolved or be part of the two part solution. Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Hector Santos on 2 Feb 2010 02:02
Well, APL was my among my first and favorite among the 20+ or so languages under my belt. It molded my problem solving and programming thinking for everything that followed. As a current compiler writer, I appreciate all languages for what they do or are. I doubt anyone can design a perfect language for all - unless of course, you wish to force it down their throats. -- HLS Joseph M. Newcomer wrote: > If you look at functional programming closely, especially along the dimensions of concepts > such as "total" functions, "partial" functions, "pure" functions, and such, you see a > powerful evolution of the thinking of ways to do software. Sadly, none of these languages > has a significant following outside a few academics. > > As a former compiler writer, functional languages contain massively interesting amounts of > information that can be used to create super-quality code; languages like C, C++ and even > C# have a lot of issues that prevent good code generation. > > Personally, I'd love to be able to look back on languages like C, C++ and C# as the > antiquated artifacts they are. But if you can't use a motorcycle, you might at least use > a competition-quality racing bike, or even a really good 10-speed, instead of a > "bone-shaker" (look up the history of bicycles if you don't know what this means...) > joe > > On Mon, 25 Jan 2010 15:36:37 -0500, Hector Santos <sant9442(a)nospam.gmail.com> wrote: > >> Pete Delgado wrote: >> >>>> Joesph M. Newcomer wrote: >>>> >>>> Huh? I'd be embarassed to publish an algorithm that was based on K&R C. >>>> It represents the best of mediocre programming of thirty years ago. >>>> When I first read it, in 1975, I said "This language is really >>>> badly done", >>> ..... I think you are confusing the defects in the >>> implementation of the standard library with the true language defects. >>> Additionally, I think to compare a 30+ year old language that was originally >>> designed as a system implementation language with the modern general purpose >>> languages of today is misleading. C met its goals and became wildly >>> successful despite its flaws and is still very widely used even today. >> >> Excellent point Pete. >> >> My opinion on a related note: >> >> I find it increasing harder to shallow how even today, people are >> getting locked into thinking or "mindset" molded that what you did in >> the past was all wrong and today's method is the better way. While >> one might be able explain why the "militants" of this mantra are they >> way they are, I just find the "stubbornness" very vexing, especially >>from those who are obviously veterans of the industry. Generally, it >> is the opposite. >> >> Again, a rhetorical opinion. >> >> I personally find it very odd that a dialect of the C language or any >> language for that matter, has been "kludge" to support a syntax that >> is cluttered with type casting. >> >> So as Joe might has stated 25 years ago in regards to C: >> >> "This language is really badly done" >> >> I can easily say the same thing today with today's C/C++ syntaxing to >> support unicode. I say that because 25 years from now, programmers >> will most likely be saying the same sort of thing: >> >> "This language is really badly done! It isn't >> necessary today. Why all the extra coding?" >> >> I only say that because I am firm believer in functional programming >> where such specifics are excluded from the overall "thinking" and >> interfacing, I/O transformation or function generators. >> >> This is closer and it also it is a rebirth direction of where MS and >> others are going with its languages. It is more "natural" per se, >> without the wasteful "think time" to address minor details one has to >> put into current C/C++ programming. >> >> These minor details are quite often SO "touchy" in its required >> construct that if one subtle mistake will create the same or worst >> problem that it attempted to resolved or be part of the two part solution. > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm -- HLS |