«

a) pre vs post increment/decrement

I have read somewhere that:

“Prefer pre-increment and -decrement to postfix operators. Postfix
operators (i++) copy the existing value to a temporary object, increment
the internal value, and then return the temporary. Prefix operators
(++i) increment the value and return a reference to it. With objects
such as iterators, creating temporary copies is expensive compared to
built-in ints.”

A modern compiler wouldn’t make the optimization, so

i++;

and

++i;

would give the same instructions?


b) I find that realloc() calls sometimes take more time to complete than
malloc() calls. Is this the general case?


c) Why do some people declare all the variables at the start of each
function? And I mean ALL variables, including those that are nested in
deep fors and ifs... I don’t see any obvious performance gains - unless
they do it to remember what they are using...

Bruno Desthuilliers wrote:
> Papadopoulos Giannis wrote:
> (snip)
>
>>
>> c) Why do some people declare all the variables at the start of each
>> function? And I mean ALL variables, including those that are nested in
>> deep fors and ifs...
>
>
> Could it be possible that some people don't know that they can declare
> variables at the start of each *block* ?-)
>
> Bruno
>
Maybe.. But I find it often and I wonder...

Papadopoulos Giannis wrote:
(snip)
>
> c) Why do some people declare all the variables at the start of each
> function? And I mean ALL variables, including those that are nested in
> deep fors and ifs...

Could it be possible that some people don't know that they can declare
variables at the start of each *block* ?-)

Bruno

In article <bvbuvg$2pub$>,
Papadopoulos Giannis <> wrote:

> a) pre vs post increment/decrement
>
> I have read somewhere that:
>
> ³Prefer pre-increment and -decrement to postfix operators. Postfix
> operators (i++) copy the existing value to a temporary object, increment
> the internal value, and then return the temporary. Prefix operators
> (++i) increment the value and return a reference to it. With objects
> such as iterators, creating temporary copies is expensive compared to
> built-in ints.²

I bet you didn't read that in a book about C.

> b) I find that realloc() calls sometimes take more time to complete than
> malloc() calls. Is this the general case?

> c) Why do some people declare all the variables at the start of each
> function? And I mean ALL variables, including those that are nested in
> deep fors and ifs... I don¹t see any obvious performance gains - unless
> they do it to remember what they are using...

You worry too much about performance, and you worry too much about the
wrong kind of performance. First try to write code that is bug-free and
readable. That is the most important thing.

If there is need to make your code faster: First measure. Get yourself a
profiler, learn how to use it, learn how to interpret the numbers. Then
before trying to figure out how to make an operation faster that you do
a million times, figure out how to do it only 100,000 times or 1000
times. That's how you make a program fast.

Papadopoulos Giannis wrote:

> a) pre vs post increment/decrement
>
> I have read somewhere that:
>
> “Prefer pre-increment and -decrement to postfix operators. Postfix
> operators (i++) copy the existing value to a temporary object,
> increment the internal value, and then return the temporary.
> Prefix operators (++i) increment the value
> and return a reference to it. With objects such as iterators,
> creating temporary copies is expensive compared to built-in ints.”

This must be a reference to
overloaded increment and decrement operators in C++.

Favoring pre-decrement/increment over post decrement/increment
operators is a good habit for C programmers who must also
write C++ programs. Otherwise, it is a matter of style.

> A modern compiler wouldn’t make the optimization, so
>
> i++;
>
> and
>
> ++i;
>
> would give the same instructions?

Yes.

> b) I find that realloc() calls sometimes take more time to complete
> than malloc() calls. Is this the general case?

Typically, the difference is hard to measure except in contrived cases.

> c) Why do some people declare all the variables
> at the start of each function? And I mean *all* variables
> including those that are nested in deep for's and ifs...
> I don’t see any obvious performance gains -
> unless they do it to remember what they are using...

1. Some C programs are translations of Fortran programs.
2. Some C programs are written by Fortran programmers.
3. Early versions of C (before C 89) required this
according to Brian W. Kernighan and Dennis M. Ritchie
in "The C Programming Language",
Chapter 1: A Tutorial Introduction,
Section 2: Variables and Arithmetic, page 8:
"In C, /all/ variables must be declared before use, usually
at the beginning of a function before any executable statements."

On Thu, 29 Jan 2004 23:45:25 +0200, in comp.lang.c , Papadopoulos
Giannis <> wrote:

>a) pre vs post increment/decrement
>
>I have read somewhere that:
>
>“Prefer pre-increment and -decrement to postfix operators.

Yes, this is an old chestnut. I can find nothing to support it
nowadays, tho ICBW.
>i++;
>and
>++i;
>would give the same instructions?

AFAIK yes. Try it and see.

>b) I find that realloc() calls sometimes take more time to complete than
>malloc() calls. Is this the general case?

The standard doesn't say.

>c) Why do some people declare all the variables at the start of each
>function?

Until C99, you pretty much had to do it like that. Plus many people
consider it a good idea to keep your declarations in one place for
easier reference. Spraying declarations around through the body of
your code makes it a lot harder to follow.

> And I mean ALL variables, including those that are nested in
>deep fors and ifs...

I agree, this is often a bad idea.

>I don’t see any obvious performance gains

Again, C doesn't say.

> unless they do it to remember what they are using...

Which may be a performance gain in itself of course

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

Christian Bau wrote:
> In article <bvbuvg$2pub$>,
> Papadopoulos Giannis <> wrote:
>
>
>>a) pre vs post increment/decrement
>>
>>I have read somewhere that:
>>
>>³Prefer pre-increment and -decrement to postfix operators. Postfix
>>operators (i++) copy the existing value to a temporary object, increment
>>the internal value, and then return the temporary. Prefix operators
>>(++i) increment the value and return a reference to it. With objects
>>such as iterators, creating temporary copies is expensive compared to
>>built-in ints.²
>
>
> I bet you didn't read that in a book about C.

This actually depends on the underlying chip architecture,
which is probably off-topic here.

>
>
>>b) I find that realloc() calls sometimes take more time to complete than
>>malloc() calls. Is this the general case?
>
>
>>c) Why do some people declare all the variables at the start of each
>>function? And I mean ALL variables, including those that are nested in
>>deep fors and ifs... I don¹t see any obvious performance gains - unless
>>they do it to remember what they are using...
>
>
> You worry too much about performance, and you worry too much about the
> wrong kind of performance. First try to write code that is bug-free and
> readable. That is the most important thing.

AMEN!

>
> If there is need to make your code faster: First measure. Get yourself a
^^^^
The key word is "need". What are the performance requirements? You
mean you didn't get any from the customer? Shame on you! This will
tell you how fast if MUST be in order to be acceptable.

> profiler, learn how to use it, learn how to interpret the numbers. Then
> before trying to figure out how to make an operation faster that you do
> a million times, figure out how to do it only 100,000 times or 1000
> times. That's how you make a program fast.

Agreed 1,000%! However, often after the developer has already
written code which uses foo() hundreds of thousands of times,
there is usually an emotional unwillingness to admit that a better
algorithm would do the trick and then they try to optimize foo(), even
if it's a standard library call. Start with requirements, as above,
design your algorithms, protoype and measure those which are going
to be invoked most often in order to find out if there will be
a problem. It's not just the efficiency (or lack thereof) in any
module, it's cpu-cost times frequency of use.

This holds for any language, not just C.
Sheesh, this IS [OT].

--
"It is impossible to make anything foolproof because fools are so
ingenious" - A. Bloch

E. Robert Tisdale wrote:

> Papadopoulos Giannis wrote:
>
>> a) pre vs post increment/decrement
>>
>> I have read somewhere that:
>>
>> “Prefer pre-increment and -decrement to postfix operators. Postfix
>> operators (i++) copy the existing value to a temporary object,
>> increment the internal value, and then return the temporary.
>> Prefix operators (++i) increment the value
>> and return a reference to it. With objects such as iterators,
>> creating temporary copies is expensive compared to built-in ints.”
>
>
> This must be a reference to
> overloaded increment and decrement operators in C++.
>
> Favoring pre-decrement/increment over post decrement/increment
> operators is a good habit for C programmers who must also
> write C++ programs. Otherwise, it is a matter of style.
>
>> A modern compiler wouldn’t make the optimization, so
>>
>> i++;
>>
>> and
>>
>> ++i;
>>
>> would give the same instructions?
>
>
> Yes.
>


For this trivial example, yes.

For the case of j = i++; vs. j = ++i;
(which are very different in intent), the
emitted code SHOULD be different,
unless you have a broken compiler.

The efficiency of the constructs to implement
these is a function of the underlying chip
architecture and not a language issue.

Mark McIntyre wrote:
> Papadopoulos Giannis <> wrote:
>
.... snip ...
>
> > b) I find that realloc() calls sometimes take more time to
> > complete than malloc() calls. Is this the general case?
>
> The standard doesn't say.

However, if you think about typical implementations, _sometimes_
it is necessary to allocate a whole new block of memory and copy
old data over to it. It will normally take longer to copy than to
not copy.

>
> > c) Why do some people declare all the variables at the start
> > of each function?
>
> Until C99, you pretty much had to do it like that. Plus many people
> consider it a good idea to keep your declarations in one place for
> easier reference. Spraying declarations around through the body of
> your code makes it a lot harder to follow.

IMO if those declarations are getting awkwardly far away from the
place they are used, you are writing overly large functions in the
first place.

--
Chuck F () ()
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

CBFalconer wrote:

> Mark McIntyre wrote:
>
>>Until C99, you pretty much had to do it like that. Plus many people
>>consider it a good idea to keep your declarations in one place for
>>easier reference. Spraying declarations around through the body of
>>your code makes it a lot harder to follow.
>
> IMO if those declarations are getting awkwardly far away
> from the place they are used,
> you are writing overly large functions in the first place.

I agree.
And moving the declarations closer to the point of first use
is the first step in decomposing the function
into a set of smaller functions
that the compiler can inline automatically.