Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C++ (http://www.velocityreviews.com/forums/f39-c.html)
-   -   include (http://www.velocityreviews.com/forums/t806887-include.html)

ahso 12-13-2011 09:45 AM

include
 
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 12-13-2011 10:07 AM

Re: include
 
On Dec 13, 9:45*am, ahso <ahs...@yahoo.com> wrote:

> 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 12-13-2011 12:44 PM

Re: include
 
Nick Keighley <nick_keighley_nospam@hotmail.com> wrote:
> 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 12-13-2011 12:47 PM

Re: include
 
Le 13/12/11 13:44, Juha Nieminen a écrit :
> Nick Keighley<nick_keighley_nospam@hotmail.com> wrote:
>> 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.


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 12-13-2011 06:24 PM

Re: include
 
On Tue, 2011-12-13, jacob navia wrote:
> Le 13/12/11 13:44, Juha Nieminen a écrit :
>> Nick Keighley<nick_keighley_nospam@hotmail.com> wrote:
>>> 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.

>
> 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

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

jacob navia 12-13-2011 06:30 PM

Re: include
 
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 12-13-2011 07:14 PM

Re: include
 
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 12-13-2011 07:45 PM

Re: include
 
On 12/14/11 07:47 AM, Leigh Johnston wrote:
>
> 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!

--
Ian Collins

jacob navia 12-13-2011 08:10 PM

Re: include
 
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 12-13-2011 08:12 PM

Re: include
 
On 12/14/11 09:03 AM, Leigh Johnston wrote:
> On 13/12/2011 19:45, Ian Collins wrote:
>> On 12/14/11 07:47 AM, Leigh Johnston wrote:
>>>
>>> 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!

>
> 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.

--
Ian Collins


All times are GMT. The time now is 02:45 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.