Hi, i'm writing a program for my homework, like most of you must know. This is the code I have(it's not complete yet)

I want to know is how to display the value of m and b inside the main function. How do i call those values from the function I made above so I can output them on the screen besides rewriting it like i did above, or do I have to make another function for them? can someone EXPLAIN! how to do that?
the program up there might be wrong to you, but it looks right to me 'cause i'm a
I want some advice

Make m and b global.

sounds like a good idea, what a I am, I never thought about it

is there any way I can have two main() functions in the same program like in C++

Instead of returning a single value from that function, you can put ALL the values in an ARRAY and the return the array, which can be accessed in main.

and you can't have two main() neither in C nor in C++.

You can pass the arguments as pointers to variables defined by the caller. You can return a pointer to an array or structure that is statically allocated by the called function. You can allocate an array or structure, pass it by reference and return a reference to it. You can have the caller allocate space for a structure (malloc()/calloc()) and return a pointer to it (but be careful about making sure it gets free()ed appropriately). As others have mentioned, they could be global variables (my last choice).

--- rod.

But global variables are the easiest choice. Maybe not a good practice to use alot but definitely the easiest.
And you can only have one main(). Infact you can only have one function of a particular name.

What you should want to know is how to pass a set of related information into or out of a function.

You do that by defining a structure type, instantiating an instance of the structure at the outermost level needing it and passing a pointer to that structure to inner levels needing it.

I hate giving this much of the answer as code, but my prior attempts at giving you concepts have failed. I hope this is the right amount of code that will encourage you to think rather than just copy.

First we define two structure types, one for the data to be passed in and one for the data to be passed out. This is done outside and before any functions, so all functions share these definitions.

Then the signature of the function indicates that it takes both the output structure and the input structure as input pointers. That may seem a strange concept (both output and input passed as input), but that is how it is done:
Then inside that function, you use input values with structure pointer syntax: Notice how total_x and n are accessed from the structure:
Later in the function you store results into the output structure in a similar way:
Inside the main() function, you define storage space for one instance of each of those structures, such as:
Then you make a pointer variable for that structure to allow main() to use the same syntax for members as other functions use:
Expert programmers usually don't do that, but if you don't you must remember that structures and the members are accessed with a different syntax in the function defining them than in functions getting them via pointer. For a beginner, it is less confusing to use the pointer everywhere.

Then you want to initialize any structure members that need initial values, such as
Then you may directly use structure members in the main function, such as:
Notice I had decided n made more sense as an int, so I fixed the scanf to be consistent with that choice.

Also
Then you pass both structure pointers to the function
finally you can use the results equation->b and equation->m

2 members found this post helpful.

By extension of this logic, all variables should be global. Sorry, not buying that. I think johnsfine said it best when he said Only the code that needs to see some data should be able to see that data. That you can have only one instance of any symbol (variable or function) is exactly the problem that correct use of visibility and scope rules solves.
--- rod.

Obviously you failed to read or interpret this correctly.
Not all variables should be global because most variable do not need to be accessed at global scope.

Note to j360: Please focus on post #8, not this post

He obviously did not fail to read or interpret it correctly.

You are not in disagreement about facts. You are in disagreement about how to teach beginners.

When do you give beginners a simpler method that will become wrong as they advance, justifying that by the fact that too many advanced concepts at once will be overwhelming?

When do you reject certain simpler methods, because they train the wrong way of looking at problems and are harder to unlearn than learning to do it right in the first place.

This is a philosophy of teaching question, not a right/wrong question about C programming.

Issue by issue, I personally might take either side of that question. I strongly believe in teaching complex topics in manageable bits, not every detail the professional way from the start.

On misuse of globals (today at least), I lean the other way. Better to avoid learning what you will need to unlearn.

When you first start, globals are easiest. For any variable accessed by more than one function, a global is clearly easiest. For any variable accessed by only one function a global is easier for a beginner than figuring out that it is only accessed by one function and making it different from variables accessed by more than one function.

But what is easiest for each variable turns out to be impossible when applied to all variables and incredibly ugly and unmaintainable when applied to many variables.

When you write a best_fit function that will be used exactly once in a simple program, it is easiest to make every input to the function a global. By a much wider margin, it is easiest to make every output from the function a global.

But by the time you are writing a best_fit function at all, even if that first example is used exactly once, you are not supposed to be learning how to write functions that are used exactly once. You are already learning how to write general purpose functions. Those do not return their outputs in globals.

I agree about not using globals. Return a struct or pass pointers instead.

An example of the pointer technique:

Here, we pass a pointers the the variables in main() to test_function. test_function() can now access the copies stored in main() via the pointers.

Returning a structure (PITA) is no more portable then creating a global variable structure since it still needs a definition.
Also, who said anything about global inputs?

Note to j360: Please focus on post #8

Most of the discussion after that has been meta discussion about how to teach beginners and/or about programming style. It has not been info directly useful to you.

That is especially true of this post #14.

There are lots of ways to accomplish the basic task of returning multiple values from a function, such as:

1) Globals: Almost always bad.

2) Pass in a pointer to an output struct: My choice in this case.

3) Return a pointer to a struct dynamically allocated within the function: My usual choice in actual programming. Not a good choice for a beginner nor a good choice in most situations (my programming tasks are not typical programming tasks).

4) Return a pointer to a static struct in the function. Generally a bad idea. An expert might do this occasionally and carefully.

5) Return a struct by value. That is one of the simplest choices, but I think it would get a beginner into bad habits.

6) Pass in individual pointers for individual return values. That is probably the common solution.

7) If the types are consistent, you might use an array instead of a struct (see post #5). I would want a lot more consistency than just type among the outputs before I'd consider this choice. Then it has sub choices similar to 2, 3 and 4 above. (C cannot pass or return an array by value, so no choice similar to 5).

You seem to have suggested 5 and you demonstrated 6. In a slightly different example, I'd agree with you about passing individual pointers. It is a judgment call, but in such cases I ask myself what ties this set of values together. Are these outputs (m and b) tied together mainly because they are both computed and returned by best_fit or are they more fundamentally tied together? In this case the pair of outputs is much more fundamentally tied together than simply being outputs of best_fit and the set of inputs (n, total_x, total_x2, etc.) is more fundamentally tied together than just as inputs to best_fit.

So passing struct pointers for each of those sets of values is the right approach, not just a selection from a large set of possible approaches.

A beginner doesn't have the experience to make best choices. But that experience level will be even harder to reach if the beginner isn't shown best choices in examples along the way.

The global struct definition is an abstraction one level above an instance of data, just as a global function definition is an abstraction at that same level. I don't think anyone in this thread disagreed with having best_fit defined at global scope.

The bigger your project is, the uglier globals gets. Globals for data instances such as function return values get too ugly too fast to belong in even the trivial example of this thread. Even global abstractions, such as struct definitions and function definitions eventually become too ugly for routine use in giant projects. But global abstractions are OK well beyond beginner C programming and global abstractions are hard to avoid in C programming. I prefer C++, in small part because it is better at organizing those abstractions.

But to answer your point, just notice the fundamental difference between a global data instance and a global abstraction.

Rod and I both extrapolated (I think correctly) from your statement:

Also notice the quoted original program failed to pass the inputs to the function. The OP asked about the problem returning results from the function, but we can see help is also required for inputs.

We know you only meant outputs when you said "global variables are easiest". But your logic applies equally well (in our view equally badly) to inputs.

It's not about portability, it's about readability, modularity, and good practice.