«

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

On Apr 7, 1:02*pm, Kai-Uwe Bux <jkherci...@gmx.net> 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

On Apr 8, 4:06*am, Brian <c...@mailvault.com> wrote:
> On Apr 7, 1:02*pm, Kai-Uwe Bux <jkherci...@gmx.net> 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

On 7 huhti, 20:30, Brian <c...@mailvault.com> 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.

On 7 Apr., 19:30, Brian <c...@mailvault.com> 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