include

Discussion in 'C++' started by ahso, Dec 13, 2011.

  1. ahso

    ahso Guest

    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
     
    ahso, Dec 13, 2011
    #1
    1. Advertising

  2. On Dec 13, 9:45 am, ahso <> 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
     
    Nick Keighley, Dec 13, 2011
    #2
    1. Advertising

  3. Nick Keighley <> 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.
     
    Juha Nieminen, Dec 13, 2011
    #3
  4. ahso

    jacob navia Guest

    Le 13/12/11 13:44, Juha Nieminen a écrit :
    > Nick Keighley<> 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.
     
    jacob navia, Dec 13, 2011
    #4
  5. ahso

    Jorgen Grahn Guest

    On Tue, 2011-12-13, jacob navia wrote:
    > Le 13/12/11 13:44, Juha Nieminen a écrit :
    >> Nick Keighley<> 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 .
     
    Jorgen Grahn, Dec 13, 2011
    #5
  6. ahso

    jacob navia Guest

    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, Dec 13, 2011
    #6
  7. ahso

    jacob navia Guest

    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.
     
    jacob navia, Dec 13, 2011
    #7
  8. ahso

    Ian Collins Guest

    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
     
    Ian Collins, Dec 13, 2011
    #8
  9. ahso

    jacob navia Guest

    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

    :)
     
    jacob navia, Dec 13, 2011
    #9
  10. ahso

    Ian Collins Guest

    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
     
    Ian Collins, Dec 13, 2011
    #10
  11. jacob navia <> 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.
     
    Juha Nieminen, Dec 14, 2011
    #11
  12. "Paul" <pchrist <nospam>> wrote:
    >
    > "Juha Nieminen" <> wrote in message
    > news:4ee748a5$0$4378$...
    >> Nick Keighley <> 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? ;)
     
    Juha Nieminen, Dec 14, 2011
    #12
  13. ahso

    jacob navia Guest

    Le 14/12/11 09:42, Juha Nieminen a écrit :
    > jacob navia<> 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.
     
    jacob navia, Dec 14, 2011
    #13
  14. ahso

    jacob navia Guest

    Le 14/12/11 10:02, Paul <pchrist a écrit :
    > "Juha Nieminen"<> 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.
     
    jacob navia, Dec 14, 2011
    #14
  15. "Paul" <pchrist <nospam>> 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.
     
    Juha Nieminen, Dec 14, 2011
    #15
  16. jacob navia <> 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.)
     
    Juha Nieminen, Dec 14, 2011
    #16
  17. ahso

    Goran Guest

    On Dec 13, 7:38 pm, "Paul" <pchrist<nospam>> wrote:
    > "Jorgen Grahn" <> wrote in message
    >
    > news:...
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > > On Tue, 2011-12-13, jacob navia wrote:
    > >> Le 13/12/11 13:44, Juha Nieminen a écrit :
    > >>> Nick Keighley<>  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.
     
    Goran, Dec 14, 2011
    #17
  18. ahso

    jacob navia Guest

    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...
     
    jacob navia, Dec 14, 2011
    #18
  19. "Paul" <pchrist <nospam>> wrote:
    >
    > "Juha Nieminen" <> wrote in message
    > news:4ee86b0b$0$2772$...
    >> "Paul" <pchrist <nospam>> 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.
     
    Juha Nieminen, Dec 14, 2011
    #19
  20. "Paul" <pchrist <nospam>> 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?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).
     
    Juha Nieminen, Dec 14, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Danny Anderson
    Replies:
    5
    Views:
    523
    Victor Bazarov
    Aug 15, 2003
  2. Rolf Magnus
    Replies:
    2
    Views:
    623
    Karl Heinz Buchegger
    Nov 28, 2003
  3. Elie Nader
    Replies:
    1
    Views:
    659
  4. Aguilar, James
    Replies:
    2
    Views:
    718
    Aguilar, James
    Jul 16, 2004
  5. Andreas Bogenberger
    Replies:
    3
    Views:
    975
    Andreas Bogenberger
    Feb 22, 2008
Loading...

Share This Page