|
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-2025 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.