Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > slightly OT question

Reply
Thread Tools

slightly OT question

 
 
Brian
Guest
Posts: n/a
 
      04-07-2010

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
 
Reply With Quote
 
 
 
 
Kai-Uwe Bux
Guest
Posts: n/a
 
      04-07-2010
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
 
Reply With Quote
 
 
 
 
Brian
Guest
Posts: n/a
 
      04-07-2010
On Apr 7, 1:02*pm, Kai-Uwe Bux <(E-Mail Removed)> 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
 
Reply With Quote
 
tonydee
Guest
Posts: n/a
 
      04-08-2010
On Apr 8, 4:06*am, Brian <(E-Mail Removed)> wrote:
> On Apr 7, 1:02*pm, Kai-Uwe Bux <(E-Mail Removed)> 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
 
Reply With Quote
 
Krice
Guest
Posts: n/a
 
      04-08-2010
On 7 huhti, 20:30, Brian <(E-Mail Removed)> 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.
 
Reply With Quote
 
peter koch
Guest
Posts: n/a
 
      04-08-2010
On 7 Apr., 19:30, Brian <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: slightly OT USB question pcbutts1 Computer Support 0 07-25-2005 01:05 PM
A Legal Question (slightly off-topic) PowerSlave2112 HTML 6 01-26-2005 06:01 AM
Slightly OT:question on communication El Durango Java 2 04-09-2004 09:38 PM
A slightly less advanced question... Tom C++ 5 11-28-2003 09:18 PM
plain paper for Canon i950 Re: slightly OT printer question what to do Digital Photography 1 07-11-2003 09:34 PM



Advertisments