Returning values from a function

[Dan Pop]

The function's prototype clearly suggests that the function is using the
pointer in write mode.

I see no particular difference between

void func(int *item1, int *item2, int *item3);

void foo()
{
int i1, i2, i3;
func(&i1, &i2, &i3);
}

and

void func(int *arr);

void foo()
{
int arr[3];
func(arr);
}

I do: one is a clean design, the other is a quick and dirty hack.

at least noct to a degree to call the seond version "safer".

Who said it's safer?

So when I debug code and see the caller side I have to assume it is
correct to make a guess on how the function works?

I was NOT talking about *debugging* code, I was talking about reading or
maintaining code. If the code is known not to behave as intended, nothing
can be assumed to be correct.

And I was, obviously, not talking about trivial cases, as the ones shown
by you.

This is not different from the original proposal.


I thought your main point was that your solution makes checking the
definition unnecessary.

Checking the definition is necessary only if you want to know what
exactly gets stored in the array. But it is a safe bet that the original
contents will not survive the call.

I am still not convinced and still maintain that your solution is not
better than the original. But maybe I simply don't

Then, feel free to use the many pointers solution, any time you need to
return multiple values from a function. Hopefully, I won't have to
maintain your code.

Dan

 

[Gene Wirchenko]

Materialised wrote:

Sorry. Can't resist.
Why is it that newbies who are berely able to write a correct
program always care about efficiency.

Reword your question, and you have your answer: Why is it that
people who are barely competent in a field focus on part of it that
they can understand?

Nearly anyone understands that, all else equal, a more efficient
program is better.

To say it clearly: Forget about efficiency for now at this level.
Write your program correct, make it work. Then watch your
program. If it is fast enough: don't do anything. If not: profile!
and figure out where time is spent. Only after you know where your
program uses up the time you care about efficiency.

I noted this pattern years ago. It is quite understandable.
Your advice is correct as well.

Sincerely,

Gene Wirchenko

 

[=?iso-8859-1?Q?Andr=E9_P=F6nitz?=]

And I was, obviously, not talking about trivial cases, as the ones shown
by you.

This trivial case seems to be the OP's problem.

Then, feel free to use the many pointers solution, any time you need to
return multiple values from a function.

I rarely use C. I don't use pointers if not necessary.

Hopefully, I won't have to maintain your code.

Getting down to a personal level?

Andre'

 

[jeffc]

Sorry. Can't resist.
Why is it that newbies who are berely able to write a correct
program always care about efficiency.
To say it clearly: Forget about efficiency for now at this level.
Write your program correct, make it work. Then watch your
program. If it is fast enough: don't do anything.

I can't totally abide by that advice. In fact, I think you've got it
backwards to a certain extent! It's professionals who need to worry about
efficiency by finding bottlenecks when and if there are performance
problems. What programs "at this level" are ever too slow? Unless there's
an infinite loop, these programs are over practically by the time you hit
ENTER. At this point, he's *learning* about efficiency so he has some
knowledge to make that call later. I seriously doubt he's interested in
speeding up a throwaway program.

 

[E. Robert Tisdale]

I can't totally abide by that advice.
In fact, I think you've got it backwards to a certain extent!

No. Karl gives sound advice here.

It's professionals who need to worry about efficiency
by finding bottlenecks when and if there are performance problems.

Professional programmers look first for evidence that
there actually is a performance problem.
They run a profiler to find the "bottlenecks",
and fix the worst ones first.
They stop when performance is satisfactory.

What programs "at this level" are ever too slow?
Unless there's an infinite loop,
these programs are over practically by the time you hit ENTER.

Then you don't have a performance problem, do you?

At this point, he's *learning* about efficiency
so he has some knowledge to make that call later.
I seriously doubt he's interested in speeding up a throwaway program.

Premature optimization is a sin.
Write code that is easy to read, understand and maintain.
Exhaust your compiler's optimization options first.
Shop around for a better optimizing compiler second.
Only then should you run your profiler
and consider cobbling your code to make it run faster.

 

[Eric Sosman]

I can't totally abide by that advice. In fact, I think you've got it
backwards to a certain extent! It's professionals who need to worry about
efficiency by finding bottlenecks when and if there are performance
problems. What programs "at this level" are ever too slow? Unless there's
an infinite loop, these programs are over practically by the time you hit
ENTER. At this point, he's *learning* about efficiency so he has some
knowledge to make that call later. I seriously doubt he's interested in
speeding up a throwaway program.

He's interested in speeding up a function that calls
time() once, srand() once, and rand() three times. It's
hard to imagine wanting to keep such a thing.

An old boss of mine gave the advice this way: "First,
make it work. Then make it robust. Finally, make it fast."
The O.P. is still at (or even before!) the first step.

 

[jeffc]

He's interested in speeding up a function that calls
time() once, srand() once, and rand() three times. It's
hard to imagine wanting to keep such a thing.

An old boss of mine gave the advice this way: "First,
make it work. Then make it robust. Finally, make it fast."
The O.P. is still at (or even before!) the first step.

Well that is my point. "Your boss" implies that you were actually working
somewhere, professionally. Presumably, you were not getting paid to write
10 line programs. You said he's interested in speeding up his function. I
disagree. I think he's interested in knowing *how* to speed up his program,
so that when his boss, one day, tells him, "finally, make it fast", he will
know how. Why would anyone be interested in speeding up a toy program?

 

[Jeremy Yallop]

I think he's interested in knowing *how* to speed up his program,
so that when his boss, one day, tells him, "finally, make it fast", he will
know how.

If that's the case then he'll probably be disappointed. Optimization
strategies don't scale in that way. The changes that will make a toy
program faster are likely to be of an entirely different nature from
those that will make a large program faster.

Jeremy.

 

[jeffc]

Then you don't have a performance problem, do you?

Obviously not. The OP never said he did.

Premature optimization is a sin.

We're not talking about premature optimization. We're talking about a
simple question regarding efficiency. He is not working in a professional
environment, so your point is moot.

 

[jeffc]

If that's the case then he'll probably be disappointed. Optimization
strategies don't scale in that way. The changes that will make a toy
program faster are likely to be of an entirely different nature from
those that will make a large program faster.

The OP asked a completely legitimate question regarding efficiency, not
performance tuning. Y'all lighten up now.

 

[Gavin Deane]

We're not talking about premature optimization. We're talking about a
simple question regarding efficiency. He is not working in a professional
environment, so your point is moot.

Given the number of inexperienced programmers (here and in the Real
World) who focus on efficiency, I think Gene Wirchenko's point, that
efficiency is a focus because it's a simple concept, is very well
made.

If an inexperienced programmer asks about efficiency, as the OP did, I
think it is valuable to point out that their main concern should be
other things. Many will not know this - I didn't know it until the
first time someone told me. If the OP comes back and says "Yes, I know
that, but I want to learn about enhancing performance for when it is
necessary" then fine. But I've never seen that happen here so I expect
in most cases people are focusing on efficiency for the wrong reasons
and hopefully benefit from the advice. The point made elsethread that
optimising techniques are unlikely to scale from toy programs to large
programs is also important.

GJD

 

[Karl Heinz Buchegger]

I'm not saying technical details can't make a difference, just that they
are in the order of a few percent most of the time.

In a german magazine (c't) there was a comparison of C#, Java and C++
in the last issue. They compared (basically) the same program (some tree
operations on strings) to test the languages capability on working
with objects, but when doing the C++ port, the authors showed
such less C++ qualification, that they came to the wrong conclusion.
Their benchmark showed C++ nearly 2 times slower then C# or Java and
the conclusion was ... (well, I think you can imagine what it was)

Doing a few simple modifications (pass per const reference instead
of pass per value, using += instead of +, using std::string instead
of some homegrown string class) speeded the program significantly
such that it was faster then either of the other 2 languages.

Moral: While not caring for technical details is a good habit, one
nevertheless has to know his toolkit, to select the right tool for
the right job. And of course: knowing typical idioms helps.

But in the OP's case, I expect no critical speed difference at all.

 

[Dan Pop]

I'ld always do this as

void randomise(int *array, int size);

There is very little point in doing this, as long as the size of the
array is constant all over the program. Simply hide the size behind a
macro and use the macro in all the relevant places.

Dan

 

[Gene Wirchenko]

[snip]

I'ld always do this as

void randomise(int *array, int size);

There is very little point in doing this, as long as the size of the
array is constant all over the program. Simply hide the size behind a
macro and use the macro in all the relevant places.

And should this change, it can get messy. I would prefer to save
trouble, so I would do what Martijn suggests.

Sincerely,

Gene Wirchenko

 

[Gene Wirchenko]

A mortal sin.

Given the number of inexperienced programmers (here and in the Real
World) who focus on efficiency, I think Gene Wirchenko's point, that
efficiency is a focus because it's a simple concept, is very well
made.

Thank you.

If an inexperienced programmer asks about efficiency, as the OP did, I
think it is valuable to point out that their main concern should be
other things. Many will not know this - I didn't know it until the
first time someone told me. If the OP comes back and says "Yes, I know
that, but I want to learn about enhancing performance for when it is
necessary" then fine. But I've never seen that happen here so I expect
in most cases people are focusing on efficiency for the wrong reasons
and hopefully benefit from the advice. The point made elsethread that

How does one compute digital sums?

You can follow the method implied by the definition: computing
sum of digits and using that as the new number until you get a
single-digit result. You can focus on coding something that very
efficiently performs this algorithm.

Or you could use different algorithm. Digital sum is little more
than a wrapper around a single modulo 9 division.

You are rather less likely to come up with the second method
unless you know your tools.

optimising techniques are unlikely to scale from toy programs to large
programs is also important.

Yes.

Some of my "toy programs" are very inefficient, because I apply
techniques of organisation that are really not suitable until dealing
with a larger system. I sacrifice some efficiency for the
organisation.

Why?

1) So that my program reflects RW conditions as much as possible.
"It worked in the lab." is not a nice thing to hear. 2) I am
experimenting, and my code is liable to be rather less than polished.
Anything that helps me keep things organised (so I can focus on the
matter at hand) is a benefit.

Sincerely,

Gene Wirchenko

 

[Robby C.H.S.]

To be more clear, I'm talking about returning back scalar information to
the caller. It is perfectly OK to do it for arrays. So, in the case of
the OP, another valid solution would be

void randomise(int *array);

where the caller is passing the address of the first int in an array
of three int's.

And how do you tell on the caller side that the function
(a) does not use the values in *array, *(array + 1), *(array + 2)
(b) puts something in there
(c) uses three items?

The function's prototype clearly suggests that the function is using the
pointer in write mode.

I see no particular difference between

void func(int *item1, int *item2, int *item3);

void foo()
{
int i1, i2, i3;
func(&i1, &i2, &i3);
}

and

void func(int *arr);

void foo()
{
int arr[3];
func(arr);
}

I do: one is a clean design, the other is a quick and dirty hack.

at least noct to a degree to call the seond version "safer".

Who said it's safer?

So when I debug code and see the caller side I have to assume it is
correct to make a guess on how the function works?

I was NOT talking about *debugging* code, I was talking about reading or
maintaining code. If the code is known not to behave as intended, nothing
can be assumed to be correct.

And I was, obviously, not talking about trivial cases, as the ones shown
by you.

This is not different from the original proposal.


I thought your main point was that your solution makes checking the
definition unnecessary.

Checking the definition is necessary only if you want to know what
exactly gets stored in the array. But it is a safe bet that the original
contents will not survive the call.

I am still not convinced and still maintain that your solution is not
better than the original. But maybe I simply don't

Then, feel free to use the many pointers solution, any time you need to
return multiple values from a function. Hopefully, I won't have to
maintain your code.

Dan

I think I have the safer and more readable solution if you want to use
array only as input parameter.

void func(const int arr[]); /* func can't write array arr */

void foo()
{
int arr[3] = { 1, 2, 3 };
func(arr);
}

 

[jeffc]

A mortal sin.

On the other hand, many programmers never learn basic efficient techniques.
(Why do we pass parameters as const reference? This is simply "accepted C++
technique" and is not "premature optimization". It is simply optimization.)
There are reasons for the code bloat and general sluggishness of many of
today's programs, and some of it is due to the fact that some programmers
simply don't get it. I repeat: one does not need to be involved in
"performance tuning" to be interested in generic efficiency. And I know
most readers agree with me too, whether that admit it or not - most
solutions here are relatively efficient, even when less efficient answers
would work.

 

[CBFalconer]

In a german magazine (c't) there was a comparison of C#, Java and
C++ in the last issue. They compared (basically) the same program
(some tree operations on strings) to test the languages capability
on working with objects, but when doing the C++ port, the authors
showed such less C++ qualification, that they came to the wrong
conclusion. Their benchmark showed C++ nearly 2 times slower then
C# or Java and the conclusion was ... (well, I think you can
imagine what it was)

Doing a few simple modifications (pass per const reference
instead of pass per value, using += instead of +, using
std::string instead of some homegrown string class) speeded the
program significantly such that it was faster then either of
the other 2 languages.

Moral: While not caring for technical details is a good habit,
one nevertheless has to know his toolkit, to select the right
tool for the right job. And of course: knowing typical idioms
helps.

But in the OP's case, I expect no critical speed difference at
all.

This is reminiscent of the fairly famous BWK "Why Pascal is not my
Favorite Language" essay, which is also seriously flawed. Such
comparisons should only be done by farming out each language
implementation to someone who is truly expert in that language.
BWK was adequate, but not expert, in Pascal, unlike his
capabilities in C, and was frustrated by inabilities to map Cisms
into Pascal.

 

[Gene Wirchenko]

[snip]

This is reminiscent of the fairly famous BWK "Why Pascal is not my
Favorite Language" essay, which is also seriously flawed. Such
comparisons should only be done by farming out each language
implementation to someone who is truly expert in that language.
BWK was adequate, but not expert, in Pascal, unlike his
capabilities in C, and was frustrated by inabilities to map Cisms
into Pascal.

Pah! I was not a C programmer when I read it, and I found it
echoed my problems.

Standard Pascal, at least at the time of BWK's article, was very
weak. Note that BWK clearly stated he was looking for portability.
That is not something only of interest to C programmers.

Sincerely,

Gene Wirchenko

 

[Gene Wirchenko]

[snip]

A mortal sin.

On the other hand, many programmers never learn basic efficient techniques.
(Why do we pass parameters as const reference? This is simply "accepted C++
technique" and is not "premature optimization". It is simply optimization.)

No, it is doing things properly.

There is little decision that needs to be made. How is the
formal parameter used? That determines the declaration. Where is the
optimisation?

OTOH, figuring out which algorithm is the best choice for a
particular application could be much more involved. (A bubble sort is
sometimes a better choice than a quicksort. (For one, it preserves
any existing key-independent ordering.))

There are reasons for the code bloat and general sluggishness of many of
today's programs, and some of it is due to the fact that some programmers
simply don't get it. I repeat: one does not need to be involved in
"performance tuning" to be interested in generic efficiency. And I know
most readers agree with me too, whether that admit it or not - most
solutions here are relatively efficient, even when less efficient answers
would work.

Oh, I agree with you. I just draw a finer distinction.

Sincerely,

Gene Wirchenko