Parsing CSV files
in [MFC]
|
From: Hector Santos on 25 Jan 2010 15:36 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. -- HLS
From: Tom Serface on 26 Jan 2010 18:10 OK, you make some good points, but I think to the typical PC users, they don't see the action of a carriage any longer. Tom "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:eIFE7gAnKHA.1548(a)TK2MSFTNGP02.phx.gbl... > Not so Tom. > > It is all the still the same! Trust me! Its what we do! This is my > business. (http://www.santronics.com) It is what we do as one of the > early pioneers in the telecommunications market. It is all still the same. > It a natural part of our framework and everyone else in the same market. > It is a fundamental understanding in this market. If you don't follow it, > you will not be compatibility with the rest of the world. > > Our software covers every aspect of the communications market, from mail > readers, telecommunication programs, mail/file distribution and hosting, > dialup vs internet, name it. Your mail post here is guaranteed to be read > by some users in the world with one of our mail reading devices. Your mail > is guaranteed to be stored and forwarded (gated) to servers using our > product, and honestly, if you recently saw a doctor and a health claim was > filed on your behalf, the chances are really good our software was > somewhere in the network loop in getting that claim collected, processed > and the doctor paid! > > When you hit ENTER, depending on the device and the OS, it will do the > translation for you. > > If you going to display a text file on the screen or send it to a printer, > the device is doing the translation for you or not. > > Storage is different because the OS may use 1 EOL (END OF LINE)
From: Tom Serface on 26 Jan 2010 18:12 Yeah, there are too many worlds these days :o) I wish they could all get together and make all of our jobs easier. All I ever need in CSV is a line ending character. More than one is just more than one. Tom "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:OXMXjyAnKHA.1552(a)TK2MSFTNGP04.phx.gbl... > Tom Serface 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. >>
From: Hector Santos on 26 Jan 2010 18:41 +1 and that was the goal, to make it transparent. Reminds me of an old user confuser support question, when told to press any key: "Where is the ANY key?" :) Tom Serface wrote: > OK, you make some good points, but I think to the typical PC users, they > don't see the action of a carriage any longer. > > Tom > > > "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message > news:eIFE7gAnKHA.1548(a)TK2MSFTNGP02.phx.gbl... >> Not so Tom. >> >> It is all the still the same! Trust me! Its what we do! This is my >> business. (http://www.santronics.com) It is what we do as one of the >> early pioneers in the telecommunications market. It is all still the >> same. It a natural part of our framework and everyone else in the same >> market. It is a fundamental understanding in this market. If you >> don't follow it, you will not be compatibility with the rest of the >> world. >> >> Our software covers every aspect of the communications market, from >> mail readers, telecommunication programs, mail/file distribution and >> hosting, dialup vs internet, name it. Your mail post here is >> guaranteed to be read by some users in the world with one of our mail >> reading devices. Your mail is guaranteed to be stored and forwarded >> (gated) to servers using our product, and honestly, if you recently >> saw a doctor and a health claim was filed on your behalf, the chances >> are really good our software was somewhere in the network loop in >> getting that claim collected, processed and the doctor paid! >> >> When you hit ENTER, depending on the device and the OS, it will do the >> translation for you. >> >> If you going to display a text file on the screen or send it to a >> printer, the device is doing the translation for you or not. >> >> Storage is different because the OS may use 1 EOL (END OF LINE) > > -- HLS
From: Hector Santos on 26 Jan 2010 19:35
Tom Serface wrote: > Yeah, there are too many worlds these days :o) I wish they could all > get together and make all of our jobs easier. All I ever need in CSV is > a line ending character. More than one is just more than one. +1. I think overall, as experienced by my own career, system interoperability has been somewhat successful, i.e. it worked to the extent that it did allow you to continue, to enjoy it, not go crazy or give up in this line of work. No doubt there were specific things you wish were different and even felt at times the world would be better of if done things that people knew about but were afraid to do or change. The "Who Moved My Cheese?" syndrome. This CSV topic was interested because it represents a primitive protocol with many open-ended use cases. Yakov made an 2005 attempt to codify the basic simple thinking but it could not cover all bases and in typical RFC fashion, because it can not cover all bases, it intentionally leaves much of this open ended. The document is peppered with this, for example it states in regards to a line ending: Encoding considerations: As per section 4.1.1. of RFC 2046 [3], this media type uses CRLF to denote line breaks. However, implementors should be aware that some implementations may use other values. This is a common approach to RFC documents. Intentional and ambiguous informal notes. It tells you to be aware but only as a READER but not what are the possible cases as a READER or WRITER. There is also a few other subtle points to understand about this document. - This RFC are not standard, they are recommendations, guidelines, - This RFC was an Informational category, not standard track. The latter is important because it means it was fast tracked as an informational RFC and thus didn't require a IETF working group (WG) peer review process that can take 2-4 years or longer. That is probably why I didn't see this in 2005. A Working Group would of scrubbed many issues and for that reason it would of prolonged the RFC publication. I personally find the security section lacking and SQL CSV input formats considerations missing. One thing you can do to help the world is to create IETF draft proposals or get involved in the some of the standardization working groups. -- HLS |