include

[ahso]

Hi
very basic...I want to use a var from main.cpp in another cpp. now how
to declare to use in both files? I tried and moved all definitions to
a new main.h but I get weird errors.
Many thanks
Mcihael

 

[Nick Keighley]

very basic...I want to use a var from main.cpp in another cpp. now how
to declare to use in both files? I tried and moved all definitions to
a new main.h but I get weird errors.

globals.h (the very name should strike you with fear)
---------
// the usual include guards
extern int var; // declare var

another.cpp
-----------

#include "globals.h"

void f()
{
var = var + 1; // use var
}

main.cpp
--------
#include "globals.h"

int var; // define var



extern variables arn't really a good idea and their use should be
minimised

 

[Juha Nieminen]

extern variables arn't really a good idea and their use should be
minimised

The very need for a "main.h" should be a clear sign that something's
horribly wrong with the design of the program.

 

[jacob navia]

Le 13/12/11 13:44, Juha Nieminen a écrit :

The very need for a "main.h" should be a clear sign that something's
horribly wrong with the design of the program.

Why?

main.h would declare variables that should be visible from
main.c and submain.c and from no other file.

Why not?

submain.c needs to be independent from main.c since declares
stuff that is not needed in main.c. main.h has the common
subset of common symbols.

 

[Jorgen Grahn]

Le 13/12/11 13:44, Juha Nieminen a écrit :

Why?

main.h would declare variables that should be visible from
main.c and submain.c and from no other file.

Why not?

submain.c needs to be independent from main.c since declares
stuff that is not needed in main.c. main.h has the common
subset of common symbols.

"main.cpp" to me is something which only exposes one thing to the
outside: a main() function. If it exposes other things too, it needs a
more descriptive name IMO. Perhaps that is what Juha meant?

/Jorgen

 

[jacob navia]

Le 13/12/11 19:24, Jorgen Grahn a écrit :

"main.cpp" to me is something which only exposes one thing to the
outside: a main() function.

But it needs to share something with another file called

"init.c"

at least the prototype of the initialization function, and often much
more stuff. Hence "main.h" sometimes.


If it exposes other things too, it needs a

more descriptive name IMO.

No, or would you have a file called

main_and_netork_init_andvariable_init_and_dot_ini_file_reading.cpp

I like short names like

main.cpp, init.cpp, setup.cpp, net-init.cpp...


Perhaps that is what Juha meant?
Perhaps. He didn't answer, so let's not speculate.


jacob

 

[jacob navia]

Le 13/12/11 19:47, Leigh Johnston a écrit :

Professionally written software tends to employ decomposition resulting
in more rather than less TUs.

"main.cpp" is a present to the maintainer of the program (that in many
cases is me too ) when he/she starts:

sigh... ALL this stuff???

Where does it start?
Where is the main() function?

Having a "main.cpp" makes it at least a little bit easier.
Having a "setup.cpp", and many other common names helps
a lot and shows organized software.

 

[Ian Collins]

Having a single TU (main.cpp) that contains all of a program's "main
algorithms" sounds so wrong that if you were to weigh the wrongness it
would be off the scale. Group by functionality not by whether something
is considered "main" or not. What the hell is a "main algorithm" any way?

Professionally written software tends to employ decomposition resulting
in more rather than less TUs.

You'd be surprised how much "professionally written software" uses one
file for all. One OS I work with has a single file for most command
line utilities. The one I was working on last week has almost 10,000 lines!

 

[jacob navia]

Le 13/12/11 20:31, Leigh Johnston a écrit :

Whenever I have a TU called "main.cpp" all it would contain would be
main() function and not a lot else and the main function itself would be
as short as possible (it is just the entry point after all).

Parsing the command line arguments should go into
another TU?

YES!!!!

You have just CONFIRMED THEN the need for main.h

 

[Ian Collins]

Advocating more rather than less TUs it not the same as advocating that
TUs must be small.

These utility files all include their main() function. That was my
point: "professionally written software" is often written with
everything in one source file.

 

[Juha Nieminen]

Why?

main.h would declare variables that should be visible from
main.c and submain.c and from no other file.

You got it backwards. If you have a separate module that needs variables
visible to the outside, in this case your "submain", then you create a
"submain.h" header file that declares those variables (and which you then
include in main.c), not the other way around.

(This even not going into the fact that "submain" is a horribly
non-descriptive module name, or even that global variables are generally
speaking not a good idea.)

"main.h" would only make sense if you need to call the main() function
from somewhere else, which is not the case basically ever.

 

[Juha Nieminen]

The very need for this post is a clear sign that something is horribly worng
with your brain.

I pwnd you with your "exe files can be run directly" and now you are seeking
childish revenge?

 

[jacob navia]

Le 14/12/11 09:42, Juha Nieminen a écrit :

You got it backwards. If you have a separate module that needs variables
visible to the outside, in this case your "submain", then you create a
"submain.h" header file that declares those variables (and which you then
include in main.c), not the other way around.

(This even not going into the fact that "submain" is a horribly
non-descriptive module name, or even that global variables are generally
speaking not a good idea.)

"main.h" would only make sense if you need to call the main() function
from somewhere else, which is not the case basically ever.

Traditionally, main.cpp contains command line parsing. You have the
argv, argc data, and it is the right place to do that.

Now, init.cpp where program's initialization is done, can use some
of the data gathered by main.cpp's command line parsing. For instance
a command line switch must be turned on or off and it commands the
ìnitialization of some data to some value or not.

Of course you can pass the argc,argv values to the init function, and
main.cpp does nothing but be an empty call to init, then run, what
makes simply for another module whose existence is not that justified.

In my opinion.

You see, what bothers me is not your opinions, that could be even right,
but your "webcasting" of your opinions as absolute truths in the
implied meaning of

"horribly wrong"

instead of

"in my opinion doing something in the main function is wrong".

I do not see it that way. I do not see why the "main" function shouldn't
do actually work and be forced to pass its data to some other function
in another module.

In most of my programs main does call a function to parse the arguments
but it is in the same module as main.cpp, and it stores the results in
a global variable and NO it IS thread safe since there are NO THREADS
yet, since the main function is running you see?

And I used "submain" as a "module name" in a general sense of "SOME
MODULE" not that I have ever used that name in my software.

 

[jacob navia]

Le 14/12/11 10:02, Paul <pchrist a écrit :

You only make sense if all files named "main.cpp" are reserved for a main()
function only. This is not the case in the big world however, only in your
little bubble.

WAIT....

I would *expect* that "main.cpp" contains the main function...

If you write software where "main.cpp" is the exit of the
program I would just rename that to something else and try to avoid
your software as much as I can.

 

[Juha Nieminen]

People like you who've been pwned and don't even realise it are just
brilliant.

I have mild curiosity to know whether you have this behavioral attitude
because you find extreme trolling so amusing, or whether it's because of
a pathological personality disorder that makes it impossible for you to
admit your mistakes, which could be considered a psychological phobia.
(Of course pathological trolling is also a personality disorder, but a
slightly different one.)

Most people here think that you are simply a troll, ie. someone who
deliberately creates flamewars for their own perverse amusement, not because
you *really* think like that. However, I am quite open to the possiblity
that it really is a personality disorder of the latter kind, as I have some
personal experience of that myself.

You most probably don't act in real life like this (at least not very
often), but the anonymity of the internet triggers the behavior in your
brain. It's too easy to spout whatever comes to your mind, and then it's
too easy to start defending your mistakes rather than just quietly dropping
the subject or, heaven forbid, write something like "ah, you are right,
I didn't know this".

I have recommended you in the past a way to better yourself. It doesn't
surprise me that you didn't take it into consideration at all, but I'm
still hoping that in 5 to 10 years you might start considering limiting
your behavior in the ways I described. It may be hard at first, but with
time it will become easier, and you'll be glad that you did.

 

[Juha Nieminen]

Traditionally, main.cpp contains command line parsing. You have the
argv, argc data, and it is the right place to do that.

If the complexity of the command line parsing is relatively simple
(personally I would put a limit of about 100-300 lines of code) then
that's indeed the case.

However, if and when the values that got parsed need to be transferred
to other modules, you either give these values to those modules when you
call them, or if this results in too much complexity with some of the
values (usually because they are needed by a large amount of separate
independent modules, many of them not called directly from main()),
you create a separate module for these system-wide settings, and pass
the command line values to that. (Obviously it's this system-wide settings
module which has a public interface, declared in its own header file.)

The simplest and most straightforward way of implementing the latter
is to simply have, for example, a header file named like Settings.hh
which contains either a namespace or a class named 'Settings', which
contains these system-wide values. The main function (or whatever function
parses the command line in main.cc) can pass the necessary values to this
'Settings' modules, from which other modules can then read them.

The reason why having a "main.h" file should intuitively feel wrong is
that it usually creates circular dependencies (ie. the 'main' module
depends on another module, which in turn depends on "main.h"). If you
have a separate "Settings" module, no circular dependencies are formed.

(And with "circular dependencies" I'm not talking about complications
in getting the program to compile. That's not the issue. I'm talking about
program design. While circular dependencies between modules is not something
to religiously avoid, they should nevertheless be minimized if possible.
It keeps the design simpler and the modules more independent.)

 

[Goran]

Many programs don't have a main function.

In this newsgroup, there's no C++ program without main().

main.cpp could contain the programs' main algorithms, its just a file name.

So what? It's pretty improbable that OP's main.cpp hasn't got main()
in it.

You missed the target time for your medication. Go have some.

 

[jacob navia]

Le 14/12/11 15:28, Paul <pchrist a écrit :

I wouldn't *expect* to see anything in a file named "main.cpp", expect valid
C++ code.

You are right "in principle" but actually, naming sgtuff is important.

This is legal C++

sum = a - b;

but a better name would be "difference" in my opinion.

The same is valid for module names. Yes, you can name "main.cpp"
a module that calculates the FFT of the data but it would be
a VBI (tm): a Very Bad Idea...

 

[Juha Nieminen]

<snip>

Wow totally pwned!!

Your behavior is sometimes just outright bizarre. (I assume it's because
you have no actual response to what I wrote.) However, I hope that I might
have planted a seed of reason that might produce some beneficial results
in the long run.

 

[Juha Nieminen]

And by the way, an executable file is run directly on most systems,
whatever its file extensions is.
A dynamic linker is typically used to link a DLL to an already running
process.

Which is incorrect, as I already demonstrated in the other thread.
Please read this:

http://en.wikipedia.org/w/index.php?title=Portable_Executable&oldid=464930661

An exe file cannot be run directly without any modification. An exe
file does not contain pure machine code.

It would also be very easy for you to prove me wrong: Just open any
exe file with a hex editor, and report what you find at the beginning.
If you find machine code, then you are correct and I'm wrong. If you
find non-machine code (namely the id "MZ" followed by header and relocation
data for the dynamic linker) then you are wrong.

Of course you won't do that, because then you would find yourself in
a difficult position: You can't admit being wrong, yet you can't lie even
to yourself that you were right. Thus it's better for your sanity to *not*
read that article nor check an exe file with a hex editor, and instead live
in the illusion that you are right because you say so.

Looks like you don't have a clue what you are talking about.

This is called psychological projection (look it up).