Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > include

Reply
Thread Tools

include

 
 
Juha Nieminen
Guest
Posts: n/a
 
      12-14-2011
jacob navia <(E-Mail Removed)> wrote:
>> 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.


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.
 
Reply With Quote
 
 
 
 
Juha Nieminen
Guest
Posts: n/a
 
      12-14-2011
"Paul" <pchrist <nospam>(E-Mail Removed)> wrote:
>
> "Juha Nieminen" <(E-Mail Removed)> wrote in message
> news:4ee748a5$0$4378$(E-Mail Removed)...
>> Nick Keighley <(E-Mail Removed)> 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.

>
> 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?
 
Reply With Quote
 
 
 
 
jacob navia
Guest
Posts: n/a
 
      12-14-2011
Le 14/12/11 09:42, Juha Nieminen a écrit :
> jacob navia<(E-Mail Removed)> wrote:
>>> 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.

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


 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      12-14-2011
Le 14/12/11 10:02, Paul <pchrist a écrit :
> "Juha Nieminen"<(E-Mail Removed)> wrote in message
>>
>> "main.h" would only make sense if you need to call the main() function
>> from somewhere else, which is not the case basically ever.

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



 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      12-14-2011
"Paul" <pchrist <nospam>(E-Mail Removed)> wrote:
> 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.
 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      12-14-2011
jacob navia <(E-Mail Removed)> wrote:
> 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.)
 
Reply With Quote
 
Goran
Guest
Posts: n/a
 
      12-14-2011
On Dec 13, 7:38*pm, "Paul" <pchrist<nospam>(E-Mail Removed)> wrote:
> "Jorgen Grahn" <(E-Mail Removed)> wrote in message
>
> news:(E-Mail Removed). ..
>
>
>
>
>
>
>
>
>
> > On Tue, 2011-12-13, jacob navia wrote:
> >> Le 13/12/11 13:44, Juha Nieminen a écrit :
> >>> Nick Keighley<(E-Mail Removed)> *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.
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      12-14-2011
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...


 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      12-14-2011
"Paul" <pchrist <nospam>(E-Mail Removed)> wrote:
>
> "Juha Nieminen" <(E-Mail Removed)> wrote in message
> news:4ee86b0b$0$2772$(E-Mail Removed)...
>> "Paul" <pchrist <nospam>(E-Mail Removed)> wrote:
>>> 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

>
> <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.
 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      12-14-2011
"Paul" <pchrist <nospam>(E-Mail Removed)> wrote:
> 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?...ldid=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).
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
/* #include <someyhing.h> */ => include it or do not include it?That is the question .... Andreas Bogenberger C Programming 3 02-22-2008 10:53 AM
#include headers that include this header Aguilar, James C++ 2 07-16-2004 05:56 PM
Re: the use of #include <a_file.h> v/s #include"a_file.cpp" Elie Nader C++ 1 11-28-2003 03:12 PM
Re: the use of #include <a_file.h> v/s #include"a_file.cpp" Rolf Magnus C++ 2 11-28-2003 12:26 PM
#include "bar" negates #include <string> ; how to fix? Danny Anderson C++ 5 08-15-2003 06:38 PM



Advertisments