| ??? 12/15/04 14:30 Read: times |
#83150 - myth Responding to: ???'s previous message |
Erik Malund said:
The above example of pointer to pointer to pointer will not lead to efficient code on any processor I know ... In the PC world where you have multimegabytes executed at multimegahertz you can get by with such sloppiness If the pointer-to-pointer-to-pointer construct truly represents what you actually need to do, then it is not "sloppy" to use it. I can think of some comms protocols with variable-length frames where you could well end up with such things. What is sloppy is to use such a construct and then complain that the compiler makes a lot of code; as I said to Zahar originally, if you wrote it by hand in assembler it would still take a lot of code - doing hard stuff takes lots of code! I said:
Going through so many levels of indirection will be "inefficient" on any processor. But I think we're agreed on the principle here: if you understand the architecture, you won't be surprised to find that the pointer-to-pointer-to-pointer construct (or whatever) makes lots of code; and then you can make an intelligent decision on whether that "overhead" is really appropriate to the task you're trying to achieve. |
| Topic | Author | Date |
| asm vs C | 01/01/70 00:00 | |
| HLL | 01/01/70 00:00 | |
| asm vs C | 01/01/70 00:00 | |
| C and other HLLs | 01/01/70 00:00 | |
| modern - productive | 01/01/70 00:00 | |
| Lunch | 01/01/70 00:00 | |
| Speed writing vs speed running. | 01/01/70 00:00 | |
| C | 01/01/70 00:00 | |
| Belt or suspenders? | 01/01/70 00:00 | |
| Learn C Then... | 01/01/70 00:00 | |
| beware | 01/01/70 00:00 | |
| This advice is great | 01/01/70 00:00 | |
| I love C !!! | 01/01/70 00:00 | |
| Easy migration | 01/01/70 00:00 | |
| 3rd party | 01/01/70 00:00 | |
| Having recently started converting... | 01/01/70 00:00 | |
| Learning C for tte 8051 and 8-bit uC | 01/01/70 00:00 | |
| Obviously there is a reason... | 01/01/70 00:00 | |
| as to reasons | 01/01/70 00:00 | |
| Obviously there is a reason... | 01/01/70 00:00 | |
| 8051 vs C :) | 01/01/70 00:00 | |
| 8051 efficiency | 01/01/70 00:00 | |
| a 51 for handling large amount of data | 01/01/70 00:00 | |
| 8051 vs C - answer is wrong | 01/01/70 00:00 | |
| addendum to post Andys above | 01/01/70 00:00 | |
| asm.vs.C forever | 01/01/70 00:00 | |
| click, click, click | 01/01/70 00:00 | |
| Eh?? | 01/01/70 00:00 | |
| 8051 vs C - answer is wrong | 01/01/70 00:00 | |
| Don't believe all you hear! | 01/01/70 00:00 | |
| the C myth | 01/01/70 00:00 | |
| myth | 01/01/70 00:00 | |
| Then Don't Do that | 01/01/70 00:00 | |
| Exactly! | 01/01/70 00:00 | |
| why only? | 01/01/70 00:00 | |
| Right tool for the Job | 01/01/70 00:00 | |
| asm VS C | 01/01/70 00:00 | |
| Which C? | 01/01/70 00:00 | |
| ? | 01/01/70 00:00 | |
| Handly, But | 01/01/70 00:00 | |
| Both i think | 01/01/70 00:00 | |
| Neither! | 01/01/70 00:00 | |
| Compiler on a floppy? | 01/01/70 00:00 | |
| Why do people use C? | 01/01/70 00:00 | |
| Code Complete | 01/01/70 00:00 | |
| Ironic | 01/01/70 00:00 | |
| Re: asm VS C | 01/01/70 00:00 | |
| re:asm vs C | 01/01/70 00:00 | |
| derivatives of same | 01/01/70 00:00 | |
| portability | 01/01/70 00:00 | |
| re: portability | 01/01/70 00:00 | |
| (non-)portability | 01/01/70 00:00 | |
| re: | 01/01/70 00:00 | |
re: | 01/01/70 00:00 | |
| What do you want? | 01/01/70 00:00 | |
| HLL | 01/01/70 00:00 | |
| Personal dislike... | 01/01/70 00:00 | |
| A comment to ASM versus C | 01/01/70 00:00 |