Home > front end >  C Does passing argument from function to function will copy it's content?
C Does passing argument from function to function will copy it's content?

Time:11-01

The code:

//function prototype
void efg(int x);
//mother functioon
abc()
{
int a=1;
efg(a);
}

When efg is executing, changing x is not changing a then we have a copy of a. But what if we dont want a copy to use memory efficiently?

One way is to pass the a's pointer &a.

I have som constrants:

  1. Don't want to pass anything. Since I have about 20 variable.
  2. Don't want it's pointer's. I want direct access to it.
  3. Dont want to being globally static.
  4. Reluctant to use Heap dynamic allocation since it's embedded also it forces me to use pointer's instead of direct access.

I want my sub function (efg) be able to use the mother function's variable (a in abc) .It means efg being able to access a directly. Why not? Also I want a being being freed after abc execution finishes, since in the way explained the variables are in stack they will freed after function finishes.

The exact problem is: sub_functions initiate some structures in the memory. After sub function is finihed its job (CPU returns to mother function) the memories must be staying untouched untill the mother function finishes (CPU return to main) and here the memory must being freed.

My best dreaming solution is to use extern variable declare to use mother function stack in sub routine.

CodePudding user response:

Don't want to pass anything. Since I have about 20 variable.

I hope you aren't planning to pass 20 variables to a function or you need to start placing related variables together in the same struct. If you have 20 variables total, well what does that have to do with anything?

Don't want it's pointer's. I want direct access to it.

That doesn't make any sense without a rationale why you want direct access. Indirect access vs direct access is such a minor performance difference that one shouldn't even bother considering it. Manually optimize when you actually have real time constraints or bottlenecks, don't optimize just for the heck of it.

If you worry about performance, then one sensible approach is to use small functions with internal linkage that will surely be inlined by the compiler. Note however that inlining is an execution speed over program size optimization.

Dont want to being globally static.

That's kind of contradicting, I assume you mean declared with static storage class specified but declared at file scope. Using such variables may or may not be valid design depending on use-case. For single core embedded systems, there's not really anything wrong with such variables.

Reluctant to use Heap dynamic allocation since it's embedded also it forces me to use pointer's instead of direct access.

Yes heap allocation should be avoided for multiple reasons in such systems. I wrote a summary of all the problems here: Why should I not use dynamic memory allocation in embedded systems? However, avoiding indirect access is not a valid reason.


The exact problem is: sub_functions initiate some structures in the memory. After sub function is finihed its job (CPU returns to mother function) the memories must be staying untouched untill the mother function finishes (CPU return to main) and here the memory must being freed.

So that's solved by declaring the variables as local, on the stack, then pass its address to the other function. If you don't want any other part of the program to touch that memory in the meantime, then simply refrain from writing code which does that...

Summary: don't state a bunch of ultimatums out of the blue, for which you can't sensibly argue in favour for or against. It's pretty clear that you have limited experience of program design, let alone manual code optimization. So for now the best thing you can do is to write code as readable as possible, following well-known best practices (const correctness, private encapsulation etc etc). Because readable code also tends to be efficient, bug-free code. Whereas needlessly contrived and complex code tends to be slow, buggy and hard to maintain.

  • Related