Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Effiiency of Variable definitions in loops

Reply
Thread Tools

Effiiency of Variable definitions in loops

 
 
Thomas Matthews
Guest
Posts: n/a
 
      08-21-2003
Hi,

While coding programs, I cam about a conundrum regarding
variables defined in an iterative loop.
The issue is whether it is more efficient to factor the
definition out of the loop or maintain encapsulation by
leaving it inside the loop?

Common stuff for examples:
class Data;
bool Is_Data_Valid(const Data &);
ifstream data_file;

Example 1: Definition inside loop:
Data my_datum;
while (data_file >> my_datum)
{
bool status; // *** Definition within loop. ***
status = Is_Data_Valid(my_datum);
if (!status)
return;
}

Example 2: Definition outside loop:
Data my_datum;
bool status; // *** Definition outside of loop ***
while (data_file >> my_datum)
{
status = Is_Data_Valid(my_datum);
if (!status)
return;
}


Reasonings:
1. In the first example, the variable is defined where
it is used. The variable is only used within the
scope of the loop.
2. The variable in the first example is created for
each iteration of the loop.
3. In the second example, the variable is available
outside of the loop (perhaps poor encapsulation).
4. However, the variable is only created once.

Any recommendations, or is this a religious issue?

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book

 
Reply With Quote
 
 
 
 
Agent Mulder
Guest
Posts: n/a
 
      08-21-2003
TM> The issue is whether it is more efficient to factor the
TM> definition out of the loop or maintain encapsulation by
TM> leaving it inside the loop?

With POD and simple objects I normally
create them in the loop. It allows syntax
like this

bool status=Is_Data_Valid(my_datum);

or even

if(!Is_Data_Valid(my_datum))return;

removing the need for the bool variable alltogether.
More complex objects that are more expensive to
create are created before the start of the loop, if not
as class members.

-X


 
Reply With Quote
 
 
 
 
Peter van Merkerk
Guest
Posts: n/a
 
      08-21-2003
"Thomas Matthews" <(E-Mail Removed)> wrote in
message news:4d61b.28625$(E-Mail Removed) gy.com...
> Hi,
>
> While coding programs, I cam about a conundrum regarding
> variables defined in an iterative loop.
> The issue is whether it is more efficient to factor the
> definition out of the loop or maintain encapsulation by
> leaving it inside the loop?
>
> Common stuff for examples:
> class Data;
> bool Is_Data_Valid(const Data &);
> ifstream data_file;
>
> Example 1: Definition inside loop:
> Data my_datum;
> while (data_file >> my_datum)
> {
> bool status; // *** Definition within loop. ***
> status = Is_Data_Valid(my_datum);
> if (!status)
> return;
> }
>
> Example 2: Definition outside loop:
> Data my_datum;
> bool status; // *** Definition outside of loop ***
> while (data_file >> my_datum)
> {
> status = Is_Data_Valid(my_datum);
> if (!status)
> return;
> }
>
> Reasonings:
> 1. In the first example, the variable is defined where
> it is used. The variable is only used within the
> scope of the loop.
> 2. The variable in the first example is created for
> each iteration of the loop.
> 3. In the second example, the variable is available
> outside of the loop (perhaps poor encapsulation).
> 4. However, the variable is only created once.
>
> Any recommendations, or is this a religious issue?


Primitive types like bool do not have construction/destruction overhead
(i.e.. the declaration itself costs nothing), so there is no performance
penalty by limiting its scope to inside the loop. It might even help the
optimizer if you make it explicit that the variable is only needed
inside the loop and its value does not need to be propagated to the next
iteration. But most likely it will not make a difference since a good
optimizers can come to that conclusion also if the variable were defined
outside the loop.

For classes with non-trivial constructors/destructors (e.g. std::string)
the story is different. They need to be constructed and destructed every
iteration of the loop, so there is a performance penalty.

My recommendation is to limit the variable to the smallest scope
possible, unless there is performance problem caused by the
construction/destruction overhead of that variable. Another
recommendation I have is to postpone variable definitions as long as
possible, so they can be immediately initialized. Instead of:

bool status;
...
status = Is_Data_Valid(my_datum);

use:
...
bool status = Is_Data_Valid(my_datum);

This style prevents accidental use of uninitialized variables and can be
more efficient with classes with non-trivial default constructors.
--
Peter van Merkerk
peter.van.merkerk(at)dse.nl



 
Reply With Quote
 
Jason
Guest
Posts: n/a
 
      08-21-2003
It's likely, in my opinion, not to affect it substantially in most cases, if
at all, since a compiler may well generate code to allocate space for all
local variables at the same time on entry to a function; no matter their
scope. It's only in the code that there is this thing we call "lexical
scope"


 
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
Ruby loops and definitions help? Bob Sanders Ruby 1 05-15-2009 09:45 AM
Loops with loops using html-template Me Perl Misc 2 01-12-2006 05:07 PM
preventing "duplicate" variable definitions Roedy Green Java 4 07-15-2005 09:03 AM
Multiple definitions of a variable in C++ not permitted Charles L C++ 5 02-08-2005 12:13 PM
Re: Variable definitions within a Case Statement Patrice ASP .Net 1 05-13-2004 06:21 PM



Advertisments