slightly OT question

[Brian]

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

 

[Kai-Uwe Bux]

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

 

[Brian]

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

 

[tonydee]

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

 

[Krice]

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.

 

[peter koch]

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