× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Retrieving a Pointer to an Object
  • From: "Simon Coulter" <shc@xxxxxxxxxxxxxxxxx>
  • Date: Sat, 27 Jun 98 18:01:59 +1000

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


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.