slightly OT question

Discussion in 'C++' started by Brian, Apr 7, 2010.

  1. Brian

    Brian Guest

    Shalom

    When I change this:

    File fl(fileName);
    outputFiles_.push_back(fl);

    to this:

    outputFiles_.push_back(File(fileName));

    my executable grows 576 bytes. I'm using gcc 4.4.2 with -O2
    and am comparing stripped executables. outputFiles_ is a
    std::vector<File>. I'd like to know why the change has such a
    negative effect on things. Does the punishment fit the crime?
    Thanks.

    Brian Wood
    http://webEbenezer.net
    (651) 251-9384
     
    Brian, Apr 7, 2010
    #1
    1. Advertising

  2. Brian

    Kai-Uwe Bux Guest

    Brian wrote:


    > When I change this:
    >
    > File fl(fileName);
    > outputFiles_.push_back(fl);
    >
    > to this:
    >
    > outputFiles_.push_back(File(fileName));
    >
    > my executable grows 576 bytes. I'm using gcc 4.4.2 with -O2
    > and am comparing stripped executables. outputFiles_ is a
    > std::vector<File>. I'd like to know why the change has such a
    > negative effect on things. Does the punishment fit the crime?


    I don't know about the inner workings of gcc, but the formal difference
    between the two snippets is the point where the file is destructed. If it is
    created as a temporary, the temporary has to be destroyed at the end of the
    full expression. In the first case, fl is destructed when it goes out of
    scope. If the destructor for File is not trivial, maybe destruction at the
    end of scope allows the compiler to fold some code (maybe other File objects
    are also destructed at that point). However, this remains total speculation
    for (a) we don't know the rest of the code and (b) optimizing compilers can
    perform very radical changes, which are hard to understand and much much
    harder to predict.


    Best

    Kai-Uwe Bux
     
    Kai-Uwe Bux, Apr 7, 2010
    #2
    1. Advertising

  3. Brian

    Brian Guest

    On Apr 7, 1:02 pm, Kai-Uwe Bux <> wrote:

    >
    > I don't know about the inner workings of gcc, but the formal difference
    > between the two snippets is the point where the file is destructed. If it is
    > created as a temporary, the temporary has to be destroyed at the end of the
    > full expression. In the first case, fl is destructed when it goes out of
    > scope. If the destructor for File is not trivial, maybe destruction at the
    > end of scope allows the compiler to fold some code (maybe other File objects
    > are also destructed at that point). However, this remains total speculation
    > for (a) we don't know the rest of the code and (b) optimizing compilers can
    > perform very radical changes, which are hard to understand and much much
    > harder to predict.
    >



    File's destructor isn't trivial. The class has a flex_string
    member.
    There aren't any other File objects in the function, but I think
    there's another flex_string that goes out of scope. Perhaps the
    576 bytes is from inlining the destructor.

    Brian Wood
     
    Brian, Apr 7, 2010
    #3
  4. Brian

    tonydee Guest

    On Apr 8, 4:06 am, Brian <> wrote:
    > On Apr 7, 1:02 pm, Kai-Uwe Bux <> wrote:
    >
    >
    >
    > > I don't know about the inner workings of gcc, but the formal difference
    > > between the two snippets is the point where the file is destructed. If it is
    > > created as a temporary, the temporary has to be destroyed at the end of the
    > > full expression. In the first case, fl is destructed when it goes out of
    > > scope. If the destructor for File is not trivial, maybe destruction at the
    > > end of scope allows the compiler to fold some code (maybe other File objects
    > > are also destructed at that point). However, this remains total speculation
    > > for (a) we don't know the rest of the code and (b) optimizing compilers can
    > > perform very radical changes, which are hard to understand and much much
    > > harder to predict.

    >
    > File's destructor isn't trivial.  The class has a flex_string
    > member.
    > There aren't any other File objects in the function, but I think
    > there's another flex_string that goes out of scope.   Perhaps the
    > 576 bytes is from inlining the destructor.


    You might get some more clues from running "size" (or non-UNIX
    equivalent) on your executable, finding out what type of content's
    increasing....

    Cheers,
    Tony
     
    tonydee, Apr 8, 2010
    #4
  5. Brian

    Krice Guest

    On 7 huhti, 20:30, Brian <> wrote:
    > my executable grows 576 bytes. I'm using gcc 4.4.2 with -O2
    > and am comparing stripped executables.


    Just a hunch, but try it with less optimization or without it.
     
    Krice, Apr 8, 2010
    #5
  6. Brian

    peter koch Guest

    On 7 Apr., 19:30, Brian <> wrote:
    > Shalom
    >
    > When I change this:
    >
    > File fl(fileName);
    > outputFiles_.push_back(fl);
    >
    > to this:
    >
    > outputFiles_.push_back(File(fileName));
    >
    > my executable grows 576 bytes.  I'm using gcc 4.4.2 with -O2
    > and am comparing stripped executables.  outputFiles_ is a
    > std::vector<File>.  I'd like to know why the change has such a
    > negative effect on things.  Does the  punishment fit the crime?
    > Thanks.


    I do not believe it is so relevant to compare the size of the
    executables. More relevant would be to compare the generated code. Ask
    for assembly output and look at that code.

    /Peter
     
    peter koch, Apr 8, 2010
    #6
    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. El Durango
    Replies:
    2
    Views:
    333
    Roedy Green
    Apr 9, 2004
  2. PowerSlave2112

    A Legal Question (slightly off-topic)

    PowerSlave2112, Jan 25, 2005, in forum: HTML
    Replies:
    6
    Views:
    501
    Starshine Moonbeam
    Jan 26, 2005
  3. Tom
    Replies:
    5
    Views:
    339
  4. Urs Beeli
    Replies:
    5
    Views:
    366
    Urs Beeli
    Mar 10, 2006
  5. 2b|!2b==?

    memcpy question (slightly OT)

    2b|!2b==?, Apr 25, 2007, in forum: C++
    Replies:
    2
    Views:
    280
    Gianni Mariani
    Apr 25, 2007
Loading...

Share This Page