Object/variable scope problems (Linux and Win comparison)

Discussion in 'C++' started by Mark, Feb 28, 2011.

  1. Mark

    Mark Guest

    Hi all,

    I am making a program which will run on Linux/Unix and Win platforms.
    The Win part is completed (compiled with MinGW) and I am concentrating
    now on the *NIX one.
    I am trying to use standard library as much as possible, but as you
    may know there are specific tasks that relies only on OS capabilities.
    Basically, apart from main and various threads/child processes, the
    program consists of a few classes.
    Let's consider two of them and call them CControlClass and
    CLoggerClass.

    The implementation is very similar both in Win and *NIX.
    CControlClass incorporates CLoggerClass this way.
    *LoggerObj is declared as private member of CControlClass.
    (CLoggerClass *LoggerObj)

    CControlClass::CControlClass()
    { readConfFile("somefile.conf"); }

    int CControlClass::readConfFile(const char * somefile){
    //do some parsing
    LoggerObj=new CLoggerClass("some_log_file.log");
    LoggerObj->writeLog(some_const_int,some_char_array_or_stringstream)
    }

    int CControlClass::functionOne()
    {
    //something
    LoggerObj->writeLog(...,...)
    }
    //main.cpp
    int main(int argc, char** argv)
    {
    CControlClass *ControlObj=new CControlClass();
    ControlObj->functionOne();
    }

    In win environment, program runs really good.

    On Linux (g++ 4.1) it compiles, it will write the log related to
    readConfFile but when functionOne calls the Logger (called from main),
    a private variable of CLoggerClass (needed to tailor detalization of
    output) is not anymore referenced. That causes a segmentation fault.

    I was able to recover from SEGFAULT, putting LoggerObj=new
    CLoggerClass("some_log_file.log") into the constructor of
    ControlClass... but it will not write anything when called by
    functionOne,Two,Three... and when called by readConfFile, it will
    write the log into the configuration file

    Can you please explain what's the matter?
    I 'd like to understand why such a big difference exists in Linux and
    Win variable scope in Standard C++.

    Thanks,
    Mark
     
    Mark, Feb 28, 2011
    #1
    1. Advertising

  2. Mark

    SG Guest

    On 28 Feb., 13:39, Mark wrote:
    > [...]
    > The implementation is very similar both in Win and *NIX.
    > CControlClass incorporates CLoggerClass this way.
    > *LoggerObj is declared as private member of CControlClass.
    > (CLoggerClass *LoggerObj)
    >
    > CControlClass::CControlClass()
    > { readConfFile("somefile.conf"); }
    >
    > int CControlClass::readConfFile(const char * somefile){
    > //do some parsing
    > LoggerObj=new CLoggerClass("some_log_file.log");
    > LoggerObj->writeLog(some_const_int,some_char_array_or_stringstream)
    > }
    >
    > int CControlClass::functionOne()
    > {
    > //something
    > LoggerObj->writeLog(...,...)}
    >
    > //main.cpp
    > int main(int argc, char** argv)
    > {
    >  CControlClass *ControlObj=new CControlClass();
    > ControlObj->functionOne();
    > }


    btw, this looks like a Java/C# programmer is trying to import his
    programming style into C++. You know that there is no garbage
    collection in C++ and that you should delete the things you created
    with new, right? If not, stop immediately and get hold of a decent C++
    book. Forcing a Java/C# programming style in C++ won't do you any
    good. The languages are just too different.

    > In win environment, program runs really good.
    >
    > On Linux (g++ 4.1) it compiles, it will write the log related to
    > readConfFile but when functionOne calls the Logger (called from main),
    > a private variable of CLoggerClass (needed to tailor detalization of
    > output) is not anymore referenced. That causes a segmentation fault.
    >
    > I was able to recover from SEGFAULT, putting LoggerObj=new
    > CLoggerClass("some_log_file.log") into the constructor of
    > ControlClass... but it will not write anything when called by
    > functionOne,Two,Three... and when called by readConfFile, it will
    > write the log into the configuration file
    >
    > Can you please explain what's the matter?


    Sorry, I can't. Not with so little information. But you may want to
    simplify your code so you can show a short and complete example of the
    exact code that you tested and didn't work like intended. Chances are,
    you did something wrong and looking for the bug in the wrong place.

    Cheers!
    SG
     
    SG, Feb 28, 2011
    #2
    1. Advertising

  3. Mark

    jacob navia Guest

    Le 28/02/11 16:14, SG a écrit :
    > On 28 Feb., 13:39, Mark wrote:
    >> [...]
    >> The implementation is very similar both in Win and *NIX.
    >> CControlClass incorporates CLoggerClass this way.
    >> *LoggerObj is declared as private member of CControlClass.
    >> (CLoggerClass *LoggerObj)
    >>
    >> CControlClass::CControlClass()
    >> { readConfFile("somefile.conf"); }
    >>
    >> int CControlClass::readConfFile(const char * somefile){
    >> //do some parsing
    >> LoggerObj=new CLoggerClass("some_log_file.log");
    >> LoggerObj->writeLog(some_const_int,some_char_array_or_stringstream)
    >> }
    >>
    >> int CControlClass::functionOne()
    >> {
    >> //something
    >> LoggerObj->writeLog(...,...)}
    >>
    >> //main.cpp
    >> int main(int argc, char** argv)
    >> {
    >> CControlClass *ControlObj=new CControlClass();
    >> ControlObj->functionOne();
    >> }

    >
    > btw, this looks like a Java/C# programmer is trying to import his
    > programming style into C++. You know that there is no garbage
    > collection in C++ and that you should delete the things you created
    > with new, right? If not, stop immediately and get hold of a decent C++
    > book. Forcing a Java/C# programming style in C++ won't do you any
    > good. The languages are just too different.


    There is no point in deleting anything since it is the main() function
    and the OS will cleanup stuff anyway.
     
    jacob navia, Feb 28, 2011
    #3
  4. Mark

    Jonathan Lee Guest

    On Feb 28, 6:39 am, Mark <> wrote:
    > Can you please explain what's the matter?
    > I 'd like to understand why such a big difference exists in Linux and
    > Win variable scope in Standard C++.
    >
    > Thanks,
    > Mark



    My best guess is that CControlClass has a destructor that deletes
    LoggerObj. At some point, an instance of CControlClass gets copied
    which results in a copy of the LoggerObj pointer, but the destructor
    destroys the thing being pointed to. When you use the copy, LoggerObj
    doesn't exist anymore.

    Sometimes these objects will still sorta work, sometimes not. Depends
    how much of the destroyed object is "still around". They certainly
    aren't expected to work, but you can get this inconsistent behavior.

    --Jonathan
     
    Jonathan Lee, Feb 28, 2011
    #4
  5. Mark

    jacob navia Guest

    Le 28/02/11 16:46, Leigh Johnston a écrit :
    >> There is no point in deleting anything since it is the main() function
    >> and the OS will cleanup stuff anyway.

    >
    > Here are three adjectives that describe you as a programmer:
    >
    > 1) cowboy
    > 2) sloppy
    > 3) slapdash
    >
    > I will let you choose which one you want.
    >
    > /Leigh


    There are several memory management and memory use strategies. I have
    enumerated the most used ones in my tutorial (about the C language,
    not the C++ language) available here:

    http://www.cs.virginia.edu/~lcc-win32/

    Some of the principles there apply here, specifically the 'Never free()'
    strategy.

    This strategy avoids all problems associated with free() (in C++
    "delete") by never freeing or deleting any memory and allowing the
    OS to clean up everything much more efficiently.

    This strategy is indicated for transient programs, that allocate a
    lot of memory, and almost never release anything until they exit.

    A compiler system is such a transient program. It will start, gobble
    megabytes of memory for tables, (symbol tables, source file tables
    whatever) and will exit with most of the memory retained until the
    end. It is a waste of time to free() in this context, or to delete.
    The OS will cleanup probably in a OS specific manner in a very EFFICIENT
    way, so it is better to avoid any problems with delete
    and just keep all memory until the program exits.

    Another similar programs are utilities like "grep" for instance.
    They start, use some memory, then exit.

    Obviously you seem to think that the "never use delete" strategy
    is used only by "cowboys" or sloppy programmers. Please explain why.

    jacob
     
    jacob navia, Feb 28, 2011
    #5
  6. Mark

    SG Guest

    On 28 Feb., 16:42, jacob navia wrote:
    > Le 28/02/11 16:14, SG a crit :
    > > On 28 Feb., 13:39, Mark wrote:
    > >> [...]
    > >> The implementation is very similar both in Win and *NIX.
    > >> CControlClass incorporates CLoggerClass this way.
    > >> *LoggerObj is declared as private member of CControlClass.
    > >> (CLoggerClass *LoggerObj)

    >
    > >>    int CControlClass::readConfFile(const char * somefile){
    > >>      //do some parsing
    > >>      LoggerObj=new CLoggerClass("some_log_file.log");
    > >>      LoggerObj->writeLog(some_const_int,some_char_array_or_stringstream)
    > >>    }

    >
    > > btw, this looks like a Java/C# programmer is trying to import his
    > > programming style into C++. You know that there is no garbage
    > > collection in C++ and that you should delete the things you created
    > > with new, right? [...]

    >
    > There is no point in deleting anything since it is the main() function
    > and the OS will cleanup stuff anyway.


    *sigh*
    No, it's not restricted to the main function (see above). And it comes
    with mo surprize that anything one writes here is subject to
    nitpicking. I probably should have added a "generally" in there
    somewhere... If it makes you feel any better, I have no problem with
    you allocating memory once in a main function and not explicitly
    releasing it or any other popular singleton implementation strategy
    which does not destruct the object.

    Cheers!
    SG
     
    SG, Feb 28, 2011
    #6
  7. Mark

    itaj sherman Guest

    On Feb 28, 7:17 pm, jacob navia <> wrote:
    > Le 28/02/11 16:46, Leigh Johnston a crit :
    >
    > >> There is no point in deleting anything since it is the main() function
    > >> and the OS will cleanup stuff anyway.

    >


    >
    > Some of the principles there apply here, specifically the 'Never free()'
    > strategy.
    >
    > This strategy avoids all problems associated with free() (in C++
    > "delete") by never freeing or deleting any memory and allowing the
    > OS to clean up everything much more efficiently.
    >


    If you really mean it, it would need a more careful explanation than
    that.
    delete is destructor + deallocation.

    I would immediately agree that memory deallocation operations of
    objects can be skipped when you have a more global memory management.
    It could be the process ending, or it could be some memory pool
    library allocator or garbage collector library.
    However, claiming that you can skip destructors would need a more
    careful explanation. Even when I have some memory managment that
    collectes my memory garbage, I would keep away from skipping
    destructors, especially as a general notion.

    itaj
     
    itaj sherman, Feb 28, 2011
    #7
  8. Mark

    jacob navia Guest

    Le 28/02/11 19:19, itaj sherman a écrit :
    > On Feb 28, 7:17 pm, jacob navia<> wrote:
    >> Le 28/02/11 16:46, Leigh Johnston a crit :
    >>
    >>>> There is no point in deleting anything since it is the main() function
    >>>> and the OS will cleanup stuff anyway.

    >>

    >
    >>
    >> Some of the principles there apply here, specifically the 'Never free()'
    >> strategy.
    >>
    >> This strategy avoids all problems associated with free() (in C++
    >> "delete") by never freeing or deleting any memory and allowing the
    >> OS to clean up everything much more efficiently.
    >>

    >
    > If you really mean it, it would need a more careful explanation than
    > that.
    > delete is destructor + deallocation.
    >
    > I would immediately agree that memory deallocation operations of
    > objects can be skipped when you have a more global memory management.
    > It could be the process ending, or it could be some memory pool
    > library allocator or garbage collector library.
    > However, claiming that you can skip destructors would need a more
    > careful explanation. Even when I have some memory managment that
    > collectes my memory garbage, I would keep away from skipping
    > destructors, especially as a general notion.
    >
    > itaj
    >
    >


    It depends on what the destructor does. If the destructor starts just
    managing memory (for instance deletes embedded objects) it is not
    necessary to use it if the program is exiting anyway.

    Other stuff (like open files, for instance) are closed anyway
    automatically by the runtime, so it is not necessary to take care of
    that also.
     
    jacob navia, Feb 28, 2011
    #8
  9. Mark

    jacob navia Guest

    Le 28/02/11 18:31, Leigh Johnston a écrit :

    > One should get into the habit of always deleting what you new to avoid
    > memory leaks. Programs which allocate everything up front and require no
    > deallocations until program termination are few and far between;


    I mentioned two examples: a compiler and other command line utilities.

    In general all transient programs (i.e. those designed to do one task
    and exit immediately) can benefit from this strategy.

    > your
    > eschewing of deletes mostly smells of premature optimization which would
    > result in code that is a nightmare to maintain as you would have to
    > constantly worry if a particular allocation is a one-off or if leaked
    > would result in unacceptable increased memory usage during program run.
    >


    If your allocation concerns an important chunk of memory yes, you
    should delete it if you recycle objects. In many cases however
    (and in the case at hand in the example that started this discussion)
    there is no need to worry about it.

    > Perhaps you would prefer a garbage collected language such as Java?
    >


    My compiler system (lcc-win) offers in its standard distribution a
    garbage collector. It is used also in C++ programs. But obviously
    you think (as all those "language patriots" that C++is the best
    language on the world, and that Java is a kind of atrocious horror
    that will scare me (and others) if you just mention it.

    > Perhaps you would prefer a garbage collected language such as Java?
    >


    Perhaps I would prefer that C++ people would acknowledge this
    huge HOLE in their (so complicated) language and plug it some time...

    But what, learning from other languages and using the good features they
    have?

    NEVER. C++ is the best and there is nothing outside, only BAD languages.

    > Here are three adjectives which *still* describe you as a *C++* programmer:
    >
    > 1) cowboy
    > 2) sloppy
    > 3) slapdash
    >


    Yes, that is your opinion. Who cares about it? Surely not me.

    I know this kind of people that pontificate in newsgroups, distributing
    "good" or "bad" points without proposing any arguments really.

    Why would the absence of "delete" when the program is exiting be "bad"?

    And this strategy is very easy to maintain: Just plug in a garbage
    collector and you are done.

    jacob
     
    jacob navia, Feb 28, 2011
    #9
  10. Mark

    itaj sherman Guest

    On Feb 28, 8:44 pm, jacob navia <> wrote:
    > Le 28/02/11 19:19, itaj sherman a crit :
    >
    >
    >
    > > On Feb 28, 7:17 pm, jacob navia<> wrote:
    > >> Le 28/02/11 16:46, Leigh Johnston a crit :

    >
    > >>>> There is no point in deleting anything since it is the main() function
    > >>>> and the OS will cleanup stuff anyway.

    >
    > >> Some of the principles there apply here, specifically the 'Never free()'
    > >> strategy.

    >
    > >> This strategy avoids all problems associated with free() (in C++
    > >> "delete") by never freeing or deleting any memory and allowing the
    > >> OS to clean up everything much more efficiently.

    >
    > > If you really mean it, it would need a more careful explanation than
    > > that.
    > > delete is destructor + deallocation.

    >
    > > I would immediately agree that memory deallocation operations of
    > > objects can be skipped when you have a more global memory management.
    > > It could be the process ending, or it could be some memory pool
    > > library allocator or garbage collector library.
    > > However, claiming that you can skip destructors would need a more
    > > careful explanation. Even when I have some memory managment that
    > > collectes my memory garbage, I would keep away from skipping
    > > destructors, especially as a general notion.

    >
    > It depends on what the destructor does. If the destructor starts just
    > managing memory (for instance deletes embedded objects) it is not
    > necessary to use it if the program is exiting anyway.
    >


    Yes, in a single frase what I meant is: it depends on what the
    destructor does.

    Strictly speaking, "just managing memory" is not the same as "deletes
    embedded objects", for the same reason. The destructors of some
    embedded objects might release other resources (other than allocated
    memory), and you have to specify in some way what happens to them,
    just the same way you sepcify what happens to the memory allocations.
    I'd think someone has to be able to give a very good reason for
    choosing to go that path, it shouldn't be commented as a general
    notion (skipping destruction that is). That's what I meant by "more
    careful explanation".

    itaj
     
    itaj sherman, Feb 28, 2011
    #10
  11. Mark

    itaj sherman Guest

    On Feb 28, 8:47 pm, Leigh Johnston <> wrote:
    > On 28/02/2011 18:44, jacob navia wrote:
    >


    >
    > Another adjective for you:
    >
    > 4) shoddy
    >


    Even if you had something sensible to say, it's lost in your
    overwhelming waves of bad manners.

    itaj
     
    itaj sherman, Feb 28, 2011
    #11
  12. Mark

    jacob navia Guest

    Le 28/02/11 18:35, SG a écrit :
    >> There is no point in deleting anything since it is the main() function
    >> and the OS will cleanup stuff anyway.

    >
    > *sigh*
    > No, it's not restricted to the main function (see above). And it comes
    > with mo surprize that anything one writes here is subject to
    > nitpicking. I probably should have added a "generally" in there
    > somewhere... If it makes you feel any better, I have no problem with
    > you allocating memory once in a main function and not explicitly
    > releasing it or any other popular singleton implementation strategy
    > which does not destruct the object.
    >


    It is not nitpicking. It is an interesting strategy: always allocate
    and never free, that results in interesting discussions (see the answer
    of Mr Johnston).

    jacob

    P.S. I think that outside a conscious memory allocation strategy you
    are obviously RIGHT.
     
    jacob navia, Feb 28, 2011
    #12
  13. Mark

    jacob navia Guest

    Le 28/02/11 19:59, itaj sherman a écrit :
    > On Feb 28, 8:47 pm, Leigh Johnston<> wrote:
    >> On 28/02/2011 18:44, jacob navia wrote:
    >>

    >
    >>
    >> Another adjective for you:
    >>
    >> 4) shoddy
    >>

    >
    > Even if you had something sensible to say, it's lost in your
    > overwhelming waves of bad manners.
    >
    > itaj


    Good point. Let's try to discuss in a civilized manner, without
    just falling into a childish attitude of calling people names...
     
    jacob navia, Feb 28, 2011
    #13
  14. Mark

    Paul Guest

    "jacob navia" <> wrote in message
    news:ikgr4c$ig1$...
    > Le 28/02/11 18:31, Leigh Johnston a écrit :
    >
    >> One should get into the habit of always deleting what you new to avoid
    >> memory leaks. Programs which allocate everything up front and require no
    >> deallocations until program termination are few and far between;

    >
    > I mentioned two examples: a compiler and other command line utilities.
    >
    > In general all transient programs (i.e. those designed to do one task
    > and exit immediately) can benefit from this strategy.
    >
    >> your
    >> eschewing of deletes mostly smells of premature optimization which would
    >> result in code that is a nightmare to maintain as you would have to
    >> constantly worry if a particular allocation is a one-off or if leaked
    >> would result in unacceptable increased memory usage during program run.
    >>

    >
    > If your allocation concerns an important chunk of memory yes, you
    > should delete it if you recycle objects. In many cases however
    > (and in the case at hand in the example that started this discussion)
    > there is no need to worry about it.
    >
    >> Perhaps you would prefer a garbage collected language such as Java?
    >>

    >
    > My compiler system (lcc-win) offers in its standard distribution a
    > garbage collector. It is used also in C++ programs. But obviously
    > you think (as all those "language patriots" that C++is the best
    > language on the world, and that Java is a kind of atrocious horror
    > that will scare me (and others) if you just mention it.
    >
    > > Perhaps you would prefer a garbage collected language such as Java?
    > >

    >
    > Perhaps I would prefer that C++ people would acknowledge this
    > huge HOLE in their (so complicated) language and plug it some time...
    >
    > But what, learning from other languages and using the good features they
    > have?
    >
    > NEVER. C++ is the best and there is nothing outside, only BAD languages.
    >
    >> Here are three adjectives which *still* describe you as a *C++*
    >> programmer:
    >>
    >> 1) cowboy
    >> 2) sloppy
    >> 3) slapdash
    >>

    >
    > Yes, that is your opinion. Who cares about it? Surely not me.
    >
    > I know this kind of people that pontificate in newsgroups, distributing
    > "good" or "bad" points without proposing any arguments really.
    >
    > Why would the absence of "delete" when the program is exiting be "bad"?
    >
    > And this strategy is very easy to maintain: Just plug in a garbage
    > collector and you are done.
    >
    > jacob
    >

    Well put mate, you certainly put him in his proper place *thumbs up*
     
    Paul, Feb 28, 2011
    #14
  15. Mark

    jacob navia Guest

    Le 28/02/11 19:47, Leigh Johnston a écrit :
    >
    > Another adjective for you:
    >
    > 4) shoddy
    >
    > /Leigh


    Incredible deep argument Mr Johnston. It has really a lot of well
    thought principles in it.

    :)

    But maybe can you explain to a "shoddy" "cowboy" "sloppy" programmer
    why a program should waste time and resources cleaning up objects
    that are of no importance since it is going to exit anyway?

    I make the distinction between objects that NEED recycling (big objects
    for instance, that if maintained beyond their useful lifetime would
    provoke an out of memory condition), and small objects that could
    never provoke anything bad.

    This distinctions are not just empty words. A C++ program can spend
    a LOT of time cleaning up objects without any useful reason since
    it is done at program exit...

    That is my point.
     
    jacob navia, Feb 28, 2011
    #15
  16. Mark

    jacob navia Guest

    Le 28/02/11 20:22, Leigh Johnston a écrit :
    >
    > The point is that you are a shoddy C++ programmer if you genuinely
    > believe this crap you are posting. Stick to Java and its GC mate; C++ is
    > not for you.
    >



    Well Mister, apparently you can't discuss in a civilized manner without
    calling people names.

    And yes, if a customer pays me to program in Java I will program in
    Java without thinking that I am doing something awful, the same as in
    C++. Last september I had a contract to program in Visual Basic and
    Access data base. And I did it in Visual Basic and Access.

    Today I am programming in objective c and an iPhone. It is a very
    small language but is great. And there this strategy doesn't work
    very well, you have to release each piece of memory/resources you use.

    Applications never exit really in most cases, so a strategy like I am
    proposing here would be catastrophic. So I do not use it.

    Am I a "shoddy" programmer? (and all other "adjectives" you use)?

    For you, yes.

    But what *I* think is important is the opinion *my customers*
    have of me. Your opinion doesn't really count.

    So you can go on calling me with any adjectives you may want to use.

    :)

    Yours sincerely

    jacob
     
    jacob navia, Feb 28, 2011
    #16
  17. Mark

    Mark Guest

    On Feb 28, 2:36 pm, jacob navia <> wrote:
    > Le 28/02/11 20:22, Leigh Johnston a crit :
    >
    >
    >
    > > The point is that you are a shoddy C++ programmer if you genuinely
    > > believe this crap you are posting. Stick to Java and its GC mate; C++ is
    > > not for you.

    >
    > Well Mister, apparently you can't discuss in a civilized manner without
    > calling people names.
    >
    > And yes, if a customer pays me to program in Java I will program in
    > Java without thinking that I am doing something awful, the same as in
    > C++. Last september I had a contract to program in Visual Basic and
    > Access data base. And I did it in Visual Basic and Access.
    >
    > Today I am programming in objective c and an iPhone. It is a very
    > small language but is great. And there this strategy doesn't work
    > very well, you have to release each piece of memory/resources you use.
    >
    > Applications never exit really in most cases, so a strategy like I am
    > proposing here would be catastrophic. So I do not use it.
    >
    > Am I a "shoddy" programmer? (and all other "adjectives" you use)?
    >
    > For you, yes.
    >
    > But what *I* think is important is the opinion *my customers*
    > have of me. Your opinion doesn't really count.
    >
    > So you can go on calling me with any adjectives you may want to use.
    >
    > :)
    >
    > Yours sincerely
    >
    > jacob


    Sorry I didn't want to raise this confusion.
    FYI I have never programmed in Java, for my job I often use pure C,
    Perl and shell scripts, sometime python. Object programming is a thing
    I use very seldom and therefore I have problems even in the
    application's project phase.
    Anyway I found the stupid bug: simply I called the constructor of
    LoggerClass with an uninitialized variable. This was causing the
    misbehaviour.
    Sorry if I don't seem serious Leigh, but I do agree with Jacob Navia
    (on the last part of his 1st reply)

    >There is no point in deleting anything since it is the main() function
    >and the OS will cleanup stuff anyway.


    I have no problems related to memory limit. As the unix part will
    contain just 1 father and 1 or 2 children, a wait/waitpid are enough
    to ensure a proper cleanup of the heap when main exits.
    If you don't agree, please argue and demonstrate I am not right, but
    please in a civil manner.

    Mark.
     
    Mark, Feb 28, 2011
    #17
  18. On Feb 28, 10:56 am, jacob navia <> wrote:
    > Le 28/02/11 18:31, Leigh Johnston a crit :
    > > Perhaps you would prefer a garbage collected language such as Java?

    >
    > My compiler system (lcc-win) offers in  its standard distribution a
    > garbage collector. It is used also in C++ programs. But obviously
    > you think (as all those "language patriots" that C++is the best
    > language on the world, and that Java is a kind of atrocious horror
    > that will scare me (and others) if you just mention it.
    >
    >  > Perhaps you would prefer a garbage collected language such as Java?
    >  >
    >
    > Perhaps I would prefer that C++ people would acknowledge this
    > huge HOLE in their (so complicated) language and plug it some time...
    >
    > But what, learning from other languages and using the good features they
    > have?
    >
    > NEVER. C++ is the best and there is nothing outside, only BAD languages.


    Reasonable people will not argue that garbage collected systems are
    purely inferior to manual memory management systems. Having said that,
    it is rather difficult to mix implicit destructor calls and garbage
    collection. It is not a simple problem with simple answers.

    C++ has largely the same design goals as C, which is to be a portable
    assembly language, and to be cost competitive with assembly. Garbage
    collection simply does not fit this design paradigm of C++, especially
    when it's largely incompatible with implicit destructor calls - the
    heart of C++.
     
    Joshua Maurice, Mar 1, 2011
    #18
  19. SG <> wrote:
    > On 28 Feb., 13:39, Mark wrote:
    >> [...]
    >> The implementation is very similar both in Win and *NIX.
    >> CControlClass incorporates CLoggerClass this way.
    >> *LoggerObj is declared as private member of CControlClass.
    >> (CLoggerClass *LoggerObj)
    >>
    >> CControlClass::CControlClass()
    >> { readConfFile("somefile.conf"); }
    >>
    >> int CControlClass::readConfFile(const char * somefile){
    >> //do some parsing
    >> LoggerObj=new CLoggerClass("some_log_file.log");
    >> LoggerObj->writeLog(some_const_int,some_char_array_or_stringstream)
    >> }
    >>
    >> int CControlClass::functionOne()
    >> {
    >> //something
    >> LoggerObj->writeLog(...,...)}
    >>
    >> //main.cpp
    >> int main(int argc, char** argv)
    >> {
    >>  CControlClass *ControlObj=new CControlClass();
    >> ControlObj->functionOne();
    >> }

    >
    > btw, this looks like a Java/C# programmer is trying to import his
    > programming style into C++. You know that there is no garbage
    > collection in C++ and that you should delete the things you created
    > with new, right?


    In fact, why is he using 'new' at all? There's no need, and 'new' is
    only making the program less efficient than instantiating the objects
    on the stack.

    There's a reason C++ uses RAII. That fact should always be used to
    one's advantage.
     
    Juha Nieminen, Mar 1, 2011
    #19
  20. Mark

    SG Guest

    On 1 Mrz., 08:46, Juha Nieminen wrote:
    > SG <> wrote:
    > > [...]
    > > btw, this looks like a Java/C# programmer is trying to import his
    > > programming style into C++. You know that there is no garbage
    > > collection in C++ and that you should delete the things you created
    > > with new, right?

    >
    >   In fact, why is he using 'new' at all? There's no need, and 'new' is
    > only making the program less efficient than instantiating the objects
    > on the stack.


    Good point! I somehow forgot to mention this.

    Cheers!
    SG
     
    SG, Mar 1, 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. ARaman
    Replies:
    1
    Views:
    408
    Mike Wahler
    Oct 23, 2003
  2. Krist
    Replies:
    6
    Views:
    804
    Arne Vajhøj
    May 7, 2010
  3. David Filmer
    Replies:
    19
    Views:
    281
    Kevin Collins
    May 21, 2004
  4. Deepu
    Replies:
    1
    Views:
    267
    ccc31807
    Feb 7, 2011
  5. Andrew Falanga
    Replies:
    2
    Views:
    217
    Andrew Falanga
    Nov 22, 2008
Loading...

Share This Page