Which one is better in C++?

[Shervan360]

Hello,

Which one is better in C++? before or after main? ( for performance)

#include<iostream>
using namespace std;

int f1(int);
int main()
{

}
int f1(int a)
{
	return a;
}

Or

#include<iostream>
using namespace std;

int f1(int a)
{
	return a;
}

int main()
{

}

[dutch]

What do you think?

[Shervan360]

@dutch second form is better because in the first form compiler copies the f1 function in beyond main.

[dutch]

Why would that make it more performant?
Actually, neither is better for performance.

[seeplus]

There is no performance difference. It's where you want to define the function body in the code.

[TheIdeasMan]

I prefer the first version, so I don't have to go looking for the main function, finding it eventually on line 500 or something. But I guess that really only applies to toy code, one can always refactor to make the main.cpp file smaller.

[George P]

Is this better or worse?

Foo.hpp:

#pragma once

int Foo(int);

Foo.cpp:

#include "Foo.hpp"

int Foo(int a)
{
   return a;
}

Main.cpp:

#include <iostream>
#include "Foo.hpp"

int main()
{

}

<spoiler>HINT: this is no better or worse than the previous two code snippets</spoiler>

A C++ compiler will still generate the same machine code no matter how the source is formatted.

[JLBorges]

> this is no better or worse than the previous two code snippets

If foo() is called, say from main(), it would be the same only if the optimiser inlines the call.
For this version with the definition in a different translation unit, only if cross-translation-unit optimisation is enabled, for example with -flto (gnu) or -GL (microsoft)

[George P]

Yet none of the snippets called Foo(), nor f1().

Admittedly a rather useless example either way.

[keskiverto]

I'd argue that Furry Guy's separate files approach has multiple benefits.
* It puts focus on interfaces
* It emphasizes that a function is a separate entity
* It prepares your workflow for "real" projects, which cannot possibly fit into one file

[JRManx]

keskiverto wrote:

* It prepares your workflow for "real" projects, which cannot possibly fit into one file

Those are all well and good, but for a small program, say 40 lines or so, is it really necessary? I mean, in that case, wouldn't having multiple files just take up disk space and make things unnecessarily complicated?

I usually don't make multiple files unless I'm making a really big project, like a database or something like that (which is something C++ is really, really good for).

[zapshe]

Important functions that you're actively working on you would benefit to have it right on top of int main for quick access without switching between files or scrolling all the way down to find it.

[keskiverto]

agent max wrote:

Those are all well and good, but for a small program, say 40 lines or so, is it really necessary? I mean, in that case, wouldn't having multiple files just take up disk space and make things unnecessarily complicated?

Hence the quotes and mention of workflow. Yes, there can be tiny, but very real programs.
If you work in a way that is not affected by the number of files, then having more than one is less an issue.

Number of files on modern storage is not a huge issue either. Filesystems typically use 4kB blocks, so yes, small files "waste" space, but disks today are "big".
There was a filesystem that had option to use unused part of data blocks of directories for tiny files.

Other than space is "inodes", the number of files that a filesystem can hold. One terabyte disk has about 250'000'000 4kB blocks, doesn't it? I have a 20 TB volume that can have "only" 60 million files ...


Furthermore, there is issue of reuse. What if you write a "perfect" function? So good that you use it in more than one 40-liner program? Do you copy-paste? What if you find a way to make the function "better"? Copy-paste again?

[JLBorges]

> Important functions that you're actively working on you would benefit to have it right on top of int main
> for quick access without switching between files or scrolling all the way down to find it.

This is what I tend to do often for a reasonably small set of functions currently under development.

>> Furthermore, there is issue of reuse.
>> What if you write a "perfect" function? So good that you use it in more than one 40-liner program?

Once the functions are refined, tested and debugged, when they are stable and good enough to be reused (though usually not really "perfect"), one can easily move it into a separate component or a library. The first priority is to make the code usable; reusability may follow.

[z05DSL3A]

I tend do the following...(for small projects/test code/learning...)

#include<iostream>

// forward declaration
int f1(int);


// Declarations
//
int f1(int a)
{
	return a;
}

// main 
//
int main()
{

}

[seeplus]

Unless the functions are not mutually exclusive, there's no need to have a forward declaration of a function before it's definition when it's used after its definition.

[z05DSL3A]

There is no need...but it's what I do.
I find it easier to concentrate on the code I'm working on rather than worrying to much about the structure of the file it's in. I also find it easier to tidy the code up and/or split it out into separate files later if needed.

[JRManx]

keskiverto wrote:

Number of files on modern storage is not a huge issue either. Filesystems typically use 4kB blocks, so yes, small files "waste" space, but disks today are "big".

The only reason I'm picky about disk space is because my disk is almost full (the result of having a photography obsession for 15 years), and I need to get a NAS or something to store stuff on.

If/when I get a NAS, I'll just store everything on that and not have to worry about my SSD filling up.