|
Hello Tim, Well actually, I have used C for a goodly number of years. It is just one of the many tools in my toolkit. I don't like the language much, mostly because I expect more from a compiler than the average C compiler provides. That's why there are so many 'lint' type products available. However that is another topic entirely. I did not intend to teach "Granny to suck eggs" but I am pleased you found the refresher useful. I was simply pointing out that a commonly accepted construct is not necessarily a good construct. Just because it is a common C statement does not make it intelligent. ptr++ is certainly simple and if all you are doing is bumping up through bytes of storage then it is acceptable (although using an array index is equally simple and obvious). However I have had the unenviable role of teaching "C-programmers" not to increment pointers to structs or anything else that is not a basic data type. Doing so reduces the reliability of your code and is similar to the standard C technique of treating pointers and integers identically due to the underlying implementation of these data types on certain hardware platforms. The SPI APIs were merely one example. I would also state that: if (A = B) { /* do something */ } is an unintelligent use of a C construct because it is open to misinterpretation (even by old hands). Eric DeLong's response has dealt with your comment about pointer arithmetic being essential to a good programming language. Pointers are often more trouble than they are worth especially in languages like C which treat non-pointer data types as pointers; arrays for instance. Your argument to Jon Paris about list APIs doesn't hold water either. Using the QUSRTVUS API in a loop is just as obvious and maintainable as bumping a pointer through the space. Granted the pointer approach makes more efficient use of system resources but that doesn't necessarily lead to better programs. I really don't want to start a "My language is better than yours" war (although I do seem to have a remarkable ability to poke people in their soft spots). Regards, Simon Coulter. //---------------------------------------------------------- // FlyByNight Software AS/400 Technical Specialists // Phone: +61 3 9419 0175 Mobile: +61 0411 091 400 // Fax: +61 3 9419 0175 E-mail: shc@flybynight.com.au // // Windoze should not be open at Warp speed. //--- forwarded letter ------------------------------------------------------- > X-Mailer: Windows Eudora Light Version 3.0.1 (16) > Date: Fri, 26 Jun 98 12:36:15 +1000 > From: "Tim McCarthy" <twmac@mindspring.com> > To: MIDRANGE-L@midrange.com > Reply-To: MIDRANGE-L@midrange.com > Subject: Re: Retrieving a Pointer to an Object > > Simon, > I fear you have not been long coding in C. The very "unintelligent" ptr++; > is probably the most common C statement I can think of beside 'if'. Hey, > most C examples even call their pointers 'ptr'. If you have a better way of > parsing a string then legions of C programmers would love to hear from you. > > I understand what you're saying about using IBM API structures and offsets > but you completely missed the point I was making which had nothing to do > with these API's. Pointer arithmetic (which goes beyond simple > incrementing) is an essential part of any good programming language. I'm > very familiar with using supplied offsets to position to information > structures and I don't believe I was proposing anything else. But thank you > for the "re-fresher" anyway. > +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.