It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
My question is particulary to function calls in C. So, either we can call functions normally or through function pointers. When your interface remainas the same but with different implementations, function pointers are used, but even if you have a single implementation having function pointers can improve the readabilty of the code.
So, what are the benefits of having static calls rather than dynamic function pointers. The call will obviously be implemented in 2 instructions as the address of the function needs to be fetched, but return will take equal cycles. I just want to understand, how can if at all processor and compiler optimize static calls over dynamic functions pointers?
Thanks,
Calling a function through a pointer will in most cases result in the compiler not being able to inline the call (if the compiler has determined that it would be beneficial to do so.) In some cases, the compiler is even able to determine the result of a function call at compile time, and thus optimize-away the whole code of the function. Function pointers also prevent this from happening.
That doesn't mean that the impact will be noticeable in any way that actually matters though. The only way to determine that, is to go and benchmark/profile your code.
However, I don't see how function pointers would be able to provide better code readability. You might want to give an example of that.
In general, direct call allows way more optimization to the compiler.
If there is really only one implementation and compiler can see it [*], it can optimize and do exactly as with direct call. But it of course depends on how smart the compiler is and what optimization options you use.
[*] i.e. if the pointer value is known in compile time; i.e. if it is 'static' variable, its address never passed outside the compilation unit, etc.
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
In C I have noted that pointers result in faster program execution. How is it possible, as it must fetch the pointer variable before going to the actual variable?
Pointers don't result in faster program execution. Smart algorithms result in faster program execution. Sometimes algorithms can be made smarter by using pointers in the right way. Pointers are never a magic wand to throw at problems to make the solutions faster.
Pointers are just a design paradigm though, using functional programming you do not use any pointers at all.
This is not true. The reason for faster program execution is not the availablility of pointers. It's a question of what you do with the pointers. The (possibly) faster program execution yields from the fact that no hidden functionality is introduced with C.
Take a string for example. Common implementations in other languages introduce a length field along with the string in order to keep track of the length of the string. This "bookkeeping" (although hidden from the programmer) causes extra cycles to be executed.
Another example is the fact that C does not check if the pointer you are dereferencing is valid or not. This evaluation would also cost extra cycles.
The C standard does not specify any required speed, so it doesn't make sense to attribute speed to features of C. Consider that some C implementations produce more optimal machine code than others, and it might make more sense to attribute speed to aspects of specific implementations of C1. Don't confuse implementation and specification.
1: To make a meaningful comparison of the speed of specific implementations of C, you'd probably want to mention your OS (major and minor version), your compiler (major and minor version), your CPU (model), mainboard, memory (model and configuration) and the command line arguments you used.
While I am aware every answer to the question come from people far more knowledgeable than me in C (and I am out of my league actually), IMVHO and/or limited knowledge, pointers do improve efficiency.
To answer the OP's question (and ignoring the rest about program execution and fetching):
How can pointers improve program efficiency?
By avoiding duplication of data. Although this efficiency may only be notable when dealing with user-defined variables, "structures".
Here is a nice read I found on C pointers: Why C has Pointers
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I read that a running C program can be referred to as an "instance".
Is this really correct? The word instance is usually used for OOP.
And C also has "objects" hasn't it, but it's not the same as in OOP.
An "object" in C is just something in memory like a union with some value could be called an object can't it?
An "object" in C is just something in memory, but that's also true of all computer languages.
An object in real life is a thing that physically exists. Being in memory is the closest something in a program can come to physical existence, so we apply the same term.
An instance in real life is a specific example of a generic concept. The term has similar generality in computers. When you tell the computer to run a program, it generates an instance of that program, among many potential instances of running that program. Again, nothing specific to C, this terminology usually occurs in operating systems (which manage running of programs, and define what a "program" is).
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I'm using the PellesC C compiler. Sometimes my code randomly stops working. A particular statement can trigger it. For example, I multiplied a variable by sin(c) (c is a double) and my code seemed to just finish execution with no result. Sometimes it freezes, sometimes it appears to just return, but I can always fix it by removing the offending statement or disabling compiler optimizations, specifically "maximize speed" or "maximize speed more". The freezing will also go away nearly 100% of the time if I add a printf statement somewhere near the point at which it crashes. I've never found anything to suggest that I am accessing memory improperly, I'm fairly sure its a compiler issue. I was wondering if anybody could shed some light on this. Is it possible that I am, in fact, doing something wrong? Or is this a known issue with the Pelles C compiler?
Edit:
Changing
canvas->pixels[(y*canvas->pitch)+(x*canvas->Bpp)+2]=(unsigned char)(255.0*dtempA*(1-sin(c)));
canvas->pixels[(y*canvas->pitch)+(x*canvas->Bpp)+1]=(unsigned char)(255.0*dtempA*(1+cos(c)));
canvas->pixels[(y*canvas->pitch)+(x*canvas->Bpp)]=(unsigned char)(255.0*dtempA*(1+sin(c)));
to (difference at the end of the last line)
canvas->pixels[(y*canvas->pitch)+(x*canvas->Bpp)+2]=(unsigned char)(255.0*dtempA*(1-sin(c)));
canvas->pixels[(y*canvas->pitch)+(x*canvas->Bpp)+1]=(unsigned char)(255.0*dtempA*(1+cos(c)));
canvas->pixels[(y*canvas->pitch)+(x*canvas->Bpp)]=(unsigned char)(255.0*dtempA*(1+1));
makes it work.
It could be either but a good bet is that it's you :) Variables that are not explicitly initialized will often get different values in a optimized vs an un-optimized build because the stack layout can change subtly depending on how aggressively the compiler removes temporaries, as well as other factors.
You're probably accidentally using undefined behavior somewhere, and changing random instructions in the program is breaking the very fragile alignment of the code on the stack that happens to make the program work.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
The following code uses the __interrupt as the interrupt service routine. How to comment
on the below code.
#include<stdio.h>
#define PI 3.14
__interrupt double compute_area(double radius)
{
double area=PI*radius*radius;
printf("\narea=%f",area);
return area;
}
This is the piece of code i got for solving. I haven't tried a program that uses interrupts before, but
have read that the interrupts are not a function call and interrupt flags are used to set
the interrupt service routine. I don't really have an in-depth knowledge of interrupts. How do you use them? Why would you use them?
I'm not sure exactly what you are asking here. The __interrupt specifier you are using is not a part of the C language, but is instead an extension to the language. You will need to tell us what system you are compiling for in order to get a more specific answer for your use case.
That code does not appear to be a valid interrupt function. Typically the arguments to the function will be void or the state of the registers when the interrupt occurred. You can also typically change the value of the registers via the arguments (not always safe to do!). Returning a value from an interrupt handler doesn't make a lot of sense either as it would not be called directly by user code.
Interrupts may be handled in many ways, but a simple mechanism would be to declare a function as an interrupt handler, a pointer to the function would be stored somewhere, and when an interrupt occurs on a specific CPU the registers functions would be called asynchronously (as the interrupt probably did not occur on your current thread).
I don't know that any of this generalist information will help you. I can't really make out what you are asking here. Perhaps if you narrowed things down a bit more we could offer more assistance.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
A challenge for all the C experts out there:
On a linux machine, you have an already compiled C program, and you are given its source code:
...
char buffer[20];
int code;
gets(buffer);
if(code==1234) ...
...
...
if(0) func();
You don't posses root privileges and the program is read-only. Find a way to execute func. I am certain this is possible, so please don't post any "It isn't possible" answers.
Good luck!
The answer lies in the unchecked buffer overflow that is waiting to happen with gets(buffer); and an understanding of what the stack looks like.
You could try setting the return address to the func() call by overflowing buffer.
http://en.wikipedia.org/wiki/Stack_buffer_overflow#Exploiting_stack_buffer_overflows
It may or may not be possible. If there are no other references to func(), the compiler may well have decided not to generate code for it in the first place -- dead code can be optimized away entirely.
This question is pretty underspecified, anyway. What do you mean by "the program is read-only"? The source code, or the executable? Are we attacking it from inside the process at runtime, inside the process by changing the source code, outside the process by trying to invoke it in funny ways, ...?
If the compiler generated code for the function (i.e. it didn't get chopped by the dead code optimizer) and you have a debugger and debug symbols, just attach a debugger and tell it to find and invoke func().
If you want to exploit the code at runtime, you can cause a buffer overflow in gets(), and take control of the process from inside, but you still have to find func() so you can jump to it -- having the source code won't help you here, and nothing will help you here if the compiler didn't generate code for it.
Since we have the source code, I would make the following edit and recompile:
-if(0) func();
+func();
Serious answer, there are thousands of ways of doing it (hacked environments, buffer overflows, etc), but the common pitfall is that a good compiler should optimize if (0) {} away. If that is the case there would be no way of executing func(). If not, then I would just start up my trusty debugger and jumping to the right spot.
Obviously, execute the famous set 0=1 command before running your executable.
But seriously, this is way off-topic...