Printable View
In general is it better to keep main() as small as possible? is like one page too big? what about in larger projects with thousands of lines? this is just in relation to my query about getting my work more organised.
the question was prompted after reading the development process thread, where he says 'main is getting a bit big' yet to me seemed fine.
In general, you should cut some pieces out if they are used repetitively, or you might want to use them in another project. I don't think you really need to worry about the literal length of main() too much. At the end, I think its personal taste.
And about the development process thread, he's talking *in general*. Even though it doesn't look too big now, it usually would be in a real project.
Code:printf("%u\n", sizeof(main));
the rule of 1 page could be applied to any function as well as main
The discussion on "when is a function too large should apply to main as well as any other function". Although in general, I prefer to make main really short, and put the "overall function of the application" into another function that then does all the relevant work and calls other functions from there. If you do that from the outset, there is less risk that "other crap" ends up in main.
Of course, the same rules apply to main as any other function: It should do one thing, and one thing only - which in this case is "start and finish the program", so ideally, main should be something like this:
Of course, small applications can be pretty much "just main", but as soon as it's not, then the above type of model is ideal.Code:int main()
{
Initialize();
result = DoStuff();
CleanUp();
return result;
}
Edit: And sizeof(main) will either not compile, or return the size of a pointer to a function, neither of which is particularly useful.
--
Mats
matsp, i do exactly like you have shown. my main always calls a few functions and exits.
otherwise a bigger main confuses me.
>sizeof(main)
i was just joking there.
neat one with the sizeof() hoho, you win a bottle of our second least expensive champagne!
Going on to what was mentioned by Matsp, i also read in a tutorial to always keep a function within one screen length wherever possible, its probably just my rubbish coding but is that always 'on'?
Also is it good just to call a function that executes maybe one line of code? i understand its better that way becasue you can forget about it, but is it wasteful in any way? what does it cost calling functions?
Well, many people advise against a function of one line of code. But for a few lines, a function can do well.
If a function is sufficiently small and not called very often the compiler might just inline it and eliminate the function call overhead.
Still, overhead is not something you really have to be worried about.
thanks rogster001! i am already drunk! hic! hic!
i don't mind writing one line functions. in c++ they are even efficient. use inline keyword.
a classic example would be:
Code:inline bool equals(const char *s1, const char *s2)
{
return (strcmp(s1, s2) == 0);
}
Yeah, there's nothing inheritably wrong with them, but some people don't like them.
The cost of a function is about a penny each :-)
The general rule of optimization is "don't optimize things until you know it's part of the 'slow' bits of your software". Since it's often much easier to make a tiny function work right than to make a large function work right, it's a good idea to make small functions for that reason.
When it comes to the cost of actually calling a function, it depends on many things. Most compilers support automatic inlining, where the compiler itself decides "if it's worth it" to inline a function, so many times, writing a small function isn't actually costing anything, because the compiler inlines the function. In gcc, I've seen pretty huge chunks of code inlined if the function is called only once.
The most obvious case of "non-inlinable" small functions are:
1. functions defined in another source file - the compiler must be able to see the source code of the function to inline it.
2. functions called via function pointers. (This also applies to C++ virtual methods)
As to the recommendation for function size, the MAX size is about a page [now, the next discussion is if that's a page on a 19" high-res monitor, or a 80x25 text-display with two lines of "editor info"...].
There are situations when really long functions make more sense than splitting, for example a function that takes 200 values into a switch statement and doing one simple thing for each case (like calling a function or setting a variable), then you can probably get away with making that one function.
--
Mats
use function pointers then!
Hope you're sarcastic.
The point was not to use them.
Not to mention that sizeof() doesn't return an unsigned int, so either a cast or the C99 %z format specifier would need to be used . . .Quote:
Edit: And sizeof(main) will either not compile, or return the size of a pointer to a function, neither of which is particularly useful.Quote:
Code:printf("%u\n", sizeof(main));
And I think it would compile, and return the size of a function pointer, pointing to main. Which would likely be the same size as any other pointer: 2 (for 16-bit), 4 (for 32-bit), or 8 bytes (for a 64-bit computer). Of course, main() might be different, because main() is unique and strange. (For example, you can't call it in C++.)
Well, that's what I thought . . . until I tested it.
I'm working on a 64-bit computer at the moment, as you may have guessed. However, I have no idea why the sizeof a function is 1 and the sizeof a function pointer is 8 (or whatever). Any suggestions as to why this is?Code:$ cat sizeofmain.c
#include <stdio.h>
void func(void) {}
int main() {
void (*fp)(void) = func;
printf("main: %lu\n", (unsigned long)sizeof(main));
printf("func: %lu\n", (unsigned long)sizeof(func));
printf("fp : %lu\n", (unsigned long)sizeof(fp));
printf("cast: %lu\n", (unsigned long)sizeof((int (*)(void))main));
return 0;
}
$ ./sizeofmain
main: 1
func: 1
fp : 8
cast: 8
$
What's that about you can't call main?
You can, but it's probably undefined.