Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
05/03/08 20:10
Read: times


 
Msg Score: +1
 +1 Good Answer/Helpful
#154352 - but it's basically the same...
Responding to: ???'s previous message
... and (buffer+8) would not be a valid indexable identifier for an array in a true HLL. And, it's just an another way how pointer arithmetics accomplishes. After all, the first thing a C course teaches, that arrays in C are just a different notation of pointers, and the indices are just a different notation for the pointer arithmetics.

At the end of the day, I see nothing non-C-ish in *(buffer+8+index), and, as you can see on the example above, it's nicely optimised by SDCC (and I don't doubt Keil would optimise it too).

Nevertheless, in a truely HLL approach, it's the task of the compiler's optimiser to take care of these cases, no matter how are they written down. A HLL program is supposed to convey the programmer's intention, rather than give a prescription to the compiler; and it's the compiler's (or, the compiler-maker's) task to figure out how to accomplish the programmer's intention in the given platform.

JW


PS. Of course I see your point and it's a valid one. But a straightforward agreement would not make a discussion, would it? :-P


List of 20 messages in thread
TopicAuthorDate
"Real C" vs '51 C            01/01/70 00:00      
   there is nothing wrong except...            01/01/70 00:00      
      if you are not , why are you even here            01/01/70 00:00      
         *(buffer+8+index)?            01/01/70 00:00      
            none of the above            01/01/70 00:00      
               OK then how?            01/01/70 00:00      
   like this            01/01/70 00:00      
      but it's basically the same...            01/01/70 00:00      
      YCMV            01/01/70 00:00      
      No            01/01/70 00:00      
         assumptions            01/01/70 00:00      
            Re: assumptions            01/01/70 00:00      
               I took a \'known\' example            01/01/70 00:00      
                  Compiler-independent efficient C            01/01/70 00:00      
                     a clarification and an example            01/01/70 00:00      
                        Two kinds of "efficiency"            01/01/70 00:00      
                     Compiler smarter than coder            01/01/70 00:00      
                        Getting the least out of your compiler            01/01/70 00:00      
   Real C is inherently reentrant            01/01/70 00:00      
      which, even when possible, often is ill advised            01/01/70 00:00      

Back to Subject List