Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #12435 > unrolled thread

include

Back to article view | Back to comp.lang.c++

Contents

  include ahso <ahso47@yahoo.com> - 2011-12-13 01:45 -0800
    Re: include Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-13 02:07 -0800
      Re: include Juha Nieminen <nospam@thanks.invalid> - 2011-12-13 12:44 +0000
        Re: include jacob navia <jacob@spamsink.net> - 2011-12-13 13:47 +0100
          Re: include Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-12-13 18:24 +0000
            Re: include jacob navia <jacob@spamsink.net> - 2011-12-13 19:30 +0100
            Re: include "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2011-12-13 18:38 +0000
              Re: include Leigh Johnston <leigh@i42.co.uk> - 2011-12-13 18:47 +0000
                Re: include jacob navia <jacob@spamsink.net> - 2011-12-13 20:14 +0100
                  Re: include Leigh Johnston <leigh@i42.co.uk> - 2011-12-13 19:31 +0000
                    Re: include jacob navia <jacob@spamsink.net> - 2011-12-13 21:10 +0100
                      Re: include Leigh Johnston <leigh@i42.co.uk> - 2011-12-13 20:17 +0000
                        Re: include Leigh Johnston <leigh@i42.co.uk> - 2011-12-13 20:18 +0000
                      Re: include Dombo <dombo@disposable.invalid> - 2011-12-14 19:56 +0100
                Re: include Ian Collins <ian-news@hotmail.com> - 2011-12-14 08:45 +1300
                  Re: include Leigh Johnston <leigh@i42.co.uk> - 2011-12-13 20:03 +0000
                    Re: include Leigh Johnston <leigh@i42.co.uk> - 2011-12-13 20:05 +0000
                    Re: include Ian Collins <ian-news@hotmail.com> - 2011-12-14 09:12 +1300
                Re: include Tobias Müller <troplin@bluewin.ch> - 2011-12-14 09:31 +0000
              Re: include Goran <goran.pusic@gmail.com> - 2011-12-14 07:06 -0800
                Re: include "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2011-12-14 15:35 +0000
                  Re: include Goran <goran.pusic@gmail.com> - 2011-12-14 23:19 -0800
                    Re: include "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2011-12-15 12:37 +0000
                      Re: include "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2011-12-15 12:38 +0000
                      Re: include Goran <goran.pusic@gmail.com> - 2011-12-15 06:12 -0800
                  Re: include Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-17 15:39 -0800
          Re: include Juha Nieminen <nospam@thanks.invalid> - 2011-12-14 08:42 +0000
            Re: include "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2011-12-14 09:02 +0000
              Re: include jacob navia <jacob@spamsink.net> - 2011-12-14 10:18 +0100
                Re: include "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2011-12-14 14:28 +0000
                  Re: include jacob navia <jacob@spamsink.net> - 2011-12-14 17:25 +0100
                    Re: include "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2011-12-14 17:43 +0000
            Re: include jacob navia <jacob@spamsink.net> - 2011-12-14 10:13 +0100
              Re: include Juha Nieminen <nospam@thanks.invalid> - 2011-12-14 09:37 +0000
        Re: include "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2011-12-13 12:50 +0000
          Re: include Juha Nieminen <nospam@thanks.invalid> - 2011-12-14 08:43 +0000
            Re: include "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2011-12-14 08:58 +0000
              Re: include Juha Nieminen <nospam@thanks.invalid> - 2011-12-14 09:23 +0000
                Re: include "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2011-12-14 14:31 +0000
                  Re: include Juha Nieminen <nospam@thanks.invalid> - 2011-12-14 17:55 +0000
                    Re: include "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2011-12-14 23:23 +0000
            Re: include "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2011-12-14 15:43 +0000
              Re: include Juha Nieminen <nospam@thanks.invalid> - 2011-12-14 18:01 +0000
                Re: include "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2011-12-15 00:34 +0000
                  Re: include Juha Nieminen <nospam@thanks.invalid> - 2011-12-15 09:46 +0000
                    Re: include "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2011-12-15 17:34 +0000
                      Re: include Leigh Johnston <leigh@i42.co.uk> - 2011-12-15 17:58 +0000
                        Re: include "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2011-12-15 19:56 +0000
                          Re: include Leigh Johnston <leigh@i42.co.uk> - 2011-12-15 21:08 +0000
                            Re: include "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2011-12-15 21:36 +0000
                              Re: include Leigh Johnston <leigh@i42.co.uk> - 2011-12-15 21:43 +0000
                                Re: include "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2011-12-15 22:23 +0000
                                  Re: include Leigh Johnston <leigh@i42.co.uk> - 2011-12-15 23:16 +0000
                                    Re: include "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2011-12-15 23:30 +0000
                                      Re: include Leigh Johnston <leigh@i42.co.uk> - 2011-12-15 23:38 +0000
                                        Re: include Juha Nieminen <nospam@thanks.invalid> - 2011-12-16 12:00 +0000
                                          Re: include gwowen <gwowen@gmail.com> - 2011-12-16 04:22 -0800
                                          Re: include 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-16 07:26 -0800
                                      Re: include Goran <goran.pusic@gmail.com> - 2011-12-15 23:48 -0800
                                        Re: include "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2011-12-16 07:59 +0000
                                          Re: include Goran <goran.pusic@gmail.com> - 2011-12-16 03:56 -0800
                                          Re: include Goran <goran.pusic@gmail.com> - 2011-12-16 04:04 -0800
                                            Re: include John Bokma <john@castleamber.com> - 2011-12-16 08:28 -0600
                                            Re: include Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-17 15:51 -0800
                                        Re: include gwowen <gwowen@gmail.com> - 2011-12-16 02:11 -0800
                                          Re: include Goran <goran.pusic@gmail.com> - 2011-12-16 03:59 -0800
                                        Re: include John Bokma <john@castleamber.com> - 2011-12-16 08:24 -0600
                                        Re: include Tobias Müller <troplin@bluewin.ch> - 2011-12-16 15:55 +0000
                      Re: include "Fred Zwarts \(KVI\)" <F.Zwarts@KVI.nl> - 2011-12-16 10:11 +0100
                        Re: include "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2011-12-16 14:10 +0000
                          Re: include Juha Nieminen <nospam@thanks.invalid> - 2011-12-16 16:00 +0000
                            Re: include "io_x" <a@b.c.invalid> - 2011-12-18 18:07 +0100
                              Re: include Leigh Johnston <leigh@i42.co.uk> - 2011-12-18 17:11 +0000
                      Re: include Juha Nieminen <nospam@thanks.invalid> - 2011-12-16 11:49 +0000
                        Re: include "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2011-12-16 14:04 +0000
                          Re: include Juha Nieminen <nospam@thanks.invalid> - 2011-12-16 16:19 +0000
                            Re: include "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2011-12-16 18:37 +0000
                              Re: include Juha Nieminen <nospam@thanks.invalid> - 2011-12-17 07:35 +0000
                                Re: include "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2011-12-17 14:34 +0000
                                  Re: include Leigh Johnston <leigh@i42.co.uk> - 2011-12-17 14:47 +0000
                                    Re: include "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2011-12-17 19:52 +0000
                                      Re: include Leigh Johnston <leigh@i42.co.uk> - 2011-12-17 20:03 +0000
                                        Re: include "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2011-12-17 23:11 +0000
                                  Re: include Juha Nieminen <nospam@thanks.invalid> - 2011-12-19 10:14 +0000
                                    Re: include "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2011-12-19 15:46 +0000

Page 1 of 5  [1] 2 3 4 5  Next page →

#12435 — 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

[toc] | [next] | [standalone]

#12436

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

[toc] | [prev] | [next] | [standalone]

#12442

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.

[toc] | [prev] | [next] | [standalone]

#12443

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.

[toc] | [prev] | [next] | [standalone]

#12457

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   .

[toc] | [prev] | [next] | [standalone]

#12459

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

[toc] | [prev] | [next] | [standalone]

#12460

"Jorgen Grahn" <grahn+nntp@snipabacken.se> wrote in message 
news:slrnjef625.q8l.grahn+nntp@frailea.sa.invalid...
> 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?
>

Many programs don't have a main function.
main.cpp could contain the programs' main algorithms, its just a file name. 
If you have some kind of unwritten rule that a main.cpp file must always 
contain a main function thats all fine for you but please don't support 
Juha's statement that anything else is horribly wrong . If anything is 
horribly wrong its that attitude and you will usually find that people who 
have that attitude are usually wrong about most things.



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#12461

On 13/12/2011 18:38, Paul <pchrist wrote:
> "Jorgen Grahn"<grahn+nntp@snipabacken.se>  wrote in message
> news:slrnjef625.q8l.grahn+nntp@frailea.sa.invalid...
>> 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?
>>
>
> Many programs don't have a main function.
> main.cpp could contain the programs' main algorithms, its just a file name.
> If you have some kind of unwritten rule that a main.cpp file must always
> contain a main function thats all fine for you but please don't support
> Juha's statement that anything else is horribly wrong . If anything is
> horribly wrong its that attitude and you will usually find that people who
> have that attitude are usually wrong about most things.

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.

HTH.

/Leigh

[toc] | [prev] | [next] | [standalone]

#12462

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.

[toc] | [prev] | [next] | [standalone]

#12463

On 13/12/2011 19:14, jacob navia wrote:
> 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.

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

/Leigh

[toc] | [prev] | [next] | [standalone]

#12468

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

:-)
	

[toc] | [prev] | [next] | [standalone]

#12471

On 13/12/2011 20:10, jacob navia wrote:
> 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

Why?

main.cpp:

#include "cmdargs.h"
#include "foo.h"

int main(int argc, char* argv[])
{
	foo myApp(command_arguments(argc, argv));
	return myApp.run();	
}

/Leigh

[toc] | [prev] | [next] | [standalone]

#12472

On 13/12/2011 20:17, Leigh Johnston wrote:
> On 13/12/2011 20:10, jacob navia wrote:
>> 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
>
> Why?
>
> main.cpp:
>
> #include "cmdargs.h"
> #include "foo.h"
>
> int main(int argc, char* argv[])
> {
> foo myApp(command_arguments(argc, argv));
> return myApp.run();
> }
>

If you were picking up on my abuse of the term "TU" then I apologize for 
the noise.

/Leigh

[toc] | [prev] | [next] | [standalone]

#12510

Op 13-Dec-11 21:10, jacob navia schreef:
> 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
>
> :-)

Why would need a main.h? If command line parsing goes in another TU I 
would expect something like command_line_parser.h, not main.h. After all 
the main() function would call the command line parser, not visa versa.

[toc] | [prev] | [next] | [standalone]

#12465

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

[toc] | [prev] | [next] | [standalone]

#12466

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.  The largest TU in my GUI lib is 1,843 lines last 
count (window.cpp implementation for window class).

/Leigh

[toc] | [prev] | [next] | [standalone]

#12467

On 13/12/2011 20:03, 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. The largest TU in my GUI lib is 1,843 lines last
> count (window.cpp implementation for window class).

Actually I am abusing the term TU here as a TU also includes all 
included header files; I should have used the term "file" like you did.

/Leigh

[toc] | [prev] | [next] | [standalone]

#12469

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

[toc] | [prev] | [next] | [standalone]

#12491

Leigh Johnston <leigh@i42.co.uk> 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.
> 
> HTH.
> 
> /Leigh

What has the name of a single file to do with use of more/less TUs?
If you have (for whatever reason) a class called Main, then why not have a
main.h and main.cpp file?

I agree however, that this is not really what people /expect/ to see in a
main.cpp file.

Personally, I tend to name the file containing the main function of program
"exampletool" exampletool.cpp and not main.cpp. I usually work on more than
just one program and this helps me to navigate in my open files.

Tobi

[toc] | [prev] | [next] | [standalone]

#12498

On Dec 13, 7:38 pm, "Paul" <pchrist<nospam>o...@yahoo.co.uk> wrote:
> "Jorgen Grahn" <grahn+n...@snipabacken.se> wrote in message
>
> news:slrnjef625.q8l.grahn+nntp@frailea.sa.invalid...
>
>
>
>
>
>
>
>
>
> > On Tue, 2011-12-13, jacob navia wrote:
> >> Le 13/12/11 13:44, Juha Nieminen a écrit :
> >>> Nick Keighley<nick_keighley_nos...@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?
>
> 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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.c++

csiph-web