Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #14772 > unrolled thread

use of pointers

Back to article view | Back to comp.lang.c++

Contents

  use of pointers ahso <ahso47@yahoo.com> - 2012-03-06 02:54 -0800
    Re: use of pointers Marcel Müller <news.5.maazl@spamgourmet.com> - 2012-03-06 12:22 +0100
      Re: use of pointers nick_keighley_nospam@hotmail.com - 2012-03-07 00:32 -0800
        Re: use of pointers Juha Nieminen <nospam@thanks.invalid> - 2012-03-07 13:47 +0000
          Re: use of pointers nick_keighley_nospam@hotmail.com - 2012-03-07 07:06 -0800
            Re: use of pointers Juha Nieminen <nospam@thanks.invalid> - 2012-03-07 16:04 +0000
    Re: use of pointers Juha Nieminen <nospam@thanks.invalid> - 2012-03-06 12:29 +0000
      Re: use of pointers Victor Bazarov <v.bazarov@comcast.invalid> - 2012-03-06 08:04 -0500
        Re: use of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-03-06 14:05 +0000
          Re: use of pointers Victor Bazarov <v.bazarov@comcast.invalid> - 2012-03-06 11:25 -0500
            Re: use of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-03-06 20:56 +0000
        Re: use of pointers SG <s.gesemann@gmail.com> - 2012-03-06 06:27 -0800
          Re: use of pointers BGB <cr88192@hotmail.com> - 2012-03-06 13:05 -0700
          Re: use of pointers woodbrian77@gmail.com - 2012-03-07 05:38 -0800
        Re: use of pointers Rui Maciel <rui.maciel@gmail.com> - 2012-03-07 15:48 +0000
          Re: use of pointers BGB <cr88192@hotmail.com> - 2012-03-07 18:38 -0700
            Re: use of pointers Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-03-10 21:10 -0500
              Re: use of pointers Jeff Flinn <TriumphSprint2000@hotmail.com> - 2012-03-12 08:26 -0400
                Re: use of pointers Jeff Flinn <TriumphSprint2000@hotmail.com> - 2012-03-12 12:28 -0400
        Re: use of pointers Nobody <nobody@nowhere.com> - 2012-03-09 21:28 +0000
    Re: use of pointers Geoff <geoff@invalid.invalid> - 2012-03-06 21:31 -0800
      Re: use of pointers Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-03-07 11:26 +0000
        Re: use of pointers yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2012-03-07 13:56 +0000
          Re: use of pointers Maarten <maarten.sneep@knmi.nl> - 2012-03-07 06:14 -0800
            Re: use of pointers Rui Maciel <rui.maciel@gmail.com> - 2012-03-07 16:05 +0000
              Re: use of pointers yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2012-03-08 10:08 +0000
                Re: use of pointers Rui Maciel <rui.maciel@gmail.com> - 2012-03-08 21:17 +0000
              Re: use of pointers Maarten <maarten.sneep@knmi.nl> - 2012-03-08 04:55 -0800
            Re: use of pointers Nobody <nobody@nowhere.com> - 2012-03-09 21:45 +0000
          Re: use of pointers Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-03-07 20:08 +0000
        Re: use of pointers Nobody <nobody@nowhere.com> - 2012-03-09 21:50 +0000
          Re: use of pointers Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-03-09 22:37 +0000
    Re: use of pointers Rui Maciel <rui.maciel@gmail.com> - 2012-03-07 15:37 +0000

Page 2 of 2 — ← Prev page 1 [2]

#14793

On Tue, 6 Mar 2012 02:54:03 -0800 (PST), ahso <ahso47@yahoo.com>
wrote:

>Hi
>I want to rewrite a function as below to not use pointers:
>
>void NewPos(float angle, float speed, float *x, float *y){
>
>	angle = (angle-90.0)*0.0174532925199433;
>
>	*x = (cos(angle) * speed);
>	*y = (sin(angle) * speed);
>
>}
>
>I also don't know what this is doing exactly. Any explanations and
>also why this needs pointers?
>Many thanks

It's using pointers because it needs to return more than one value and
since it's old C it was probably the simplest way to do it at the
time.

What is it doing? It's resolving a velocity vector. It's decomposing a
velocity vector of angle angle and scalar speed into its components in
x and y. (polar to Cartesian coordinate conversion)

Presumably, the caller is calling NewPos cyclically and adding the x,y
values to some current_position value to compute a new position based
on the instantaneous speed and angle.

[toc] | [prev] | [next] | [standalone]

#14798

On Wed, 2012-03-07, Geoff wrote:
> On Tue, 6 Mar 2012 02:54:03 -0800 (PST), ahso <ahso47@yahoo.com>
> wrote:
>
>>Hi
>>I want to rewrite a function as below to not use pointers:
>>
>>void NewPos(float angle, float speed, float *x, float *y){
>>
>>	angle = (angle-90.0)*0.0174532925199433;
>>
>>	*x = (cos(angle) * speed);
>>	*y = (sin(angle) * speed);
>>
>>}
>>
>>I also don't know what this is doing exactly. Any explanations and
>>also why this needs pointers?
>>Many thanks
>
> It's using pointers because it needs to return more than one value and
> since it's old C it was probably the simplest way to do it at the
> time.

Probably not the /only/ way though -- returning structs has been
possible in C for ~25 years now. I always believed it was expensive,
but I suspect that at some point it became cheaper with popular
compilers.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#14804

In article <slrnjlehf7.1ls.grahn+nntp@frailea.sa.invalid>,
Jorgen Grahn  <grahn+nntp@snipabacken.se> wrote:
>On Wed, 2012-03-07, Geoff wrote:
>> On Tue, 6 Mar 2012 02:54:03 -0800 (PST), ahso <ahso47@yahoo.com>
>> wrote:
>>
>>>Hi
>>>I want to rewrite a function as below to not use pointers:
>>>
>>>void NewPos(float angle, float speed, float *x, float *y){
>>>
>>>	angle = (angle-90.0)*0.0174532925199433;
>>>
>>>	*x = (cos(angle) * speed);
>>>	*y = (sin(angle) * speed);
>>>
>>>}
>>>
>>>I also don't know what this is doing exactly. Any explanations and
>>>also why this needs pointers?
>>>Many thanks
>>
>> It's using pointers because it needs to return more than one value and
>> since it's old C it was probably the simplest way to do it at the
>> time.
>
>Probably not the /only/ way though -- returning structs has been
>possible in C for ~25 years now. I always believed it was expensive,
>but I suspect that at some point it became cheaper with popular
>compilers.

Sounds like old-style C programmer: "I believe it is too expensive".
One really should either test or if the effort of testing is
considered not worth it, use the most readable, most useable and less
bug prone technique.  Never use a less readable technique because it
is "believed" to be less CPU expensive.

// common header
struct Point { float x; float y };  
Point NewPos(float angle, float speed);

// User code
Point somePoint = NewPos(someAngle, someSpeed);

vs:

// common header
void NewPos(float angle, float speed, float *x, float *y);
// All the rest of the code can refer to the point as a single entity

// user code:
float x = 0;
float y = 0;
NewPos(someAngle, someSpeed, &x, &y);
// all the rest of the code need to handle x and y separately even if
// they are non-sensical separately

The former is much cleaner, the second form should only be used if it
can be demonstrated that the first form is definitely not suitable.

Yannick

[toc] | [prev] | [next] | [standalone]

#14805

On Wednesday, March 7, 2012 2:56:46 PM UTC+1, none wrote:

> Sounds like old-style C programmer: "I believe it is too expensive".
> One really should either test or if the effort of testing is
> considered not worth it, use the most readable, most useable and less
> bug prone technique.  Never use a less readable technique because it
> is "believed" to be less CPU expensive.

As Donald Knuth once put it: "There is no doubt that the grail 
of efficiency leads to abuse. Programmers waste enormous amounts 
of time thinking about, or worrying about, the speed of noncritical 
parts of their programs, and these attempts at efficiency actually 
have a strong negative impact when debugging and maintenance are 
considered. We should forget about small efficiencies, say about 
97% of the time: premature optimization is the root of all evil."

Only start optimizing once you have tested your code, and are 
satisfied that it is correct. And only start to optimize when 
you have seen that there is a performance issue, and have 
pinpointed the issue with a profiler. 

Yes, Donald Knuth leaves you 3% where it does matter. But he 
also states that you should only worry about that after you 
have identified that code.

Article can be found from 
http://en.wikipedia.org/wiki/Program_optimization

Maarten

[toc] | [prev] | [next] | [standalone]

#14811

Maarten wrote:

> As Donald Knuth once put it: "There is no doubt that the grail
> of efficiency leads to abuse. Programmers waste enormous amounts
> of time thinking about, or worrying about, the speed of noncritical
> parts of their programs, and these attempts at efficiency actually
> have a strong negative impact when debugging and maintenance are
> considered. We should forget about small efficiencies, say about
> 97% of the time: premature optimization is the root of all evil."
> 
> Only start optimizing once you have tested your code, and are
> satisfied that it is correct. And only start to optimize when
> you have seen that there is a performance issue, and have
> pinpointed the issue with a profiler.
> 
> Yes, Donald Knuth leaves you 3% where it does matter. But he
> also states that you should only worry about that after you
> have identified that code.
> 
> Article can be found from
> http://en.wikipedia.org/wiki/Program_optimization

Knuth's quote tends to be abused a bit.  Some individuals employ it to, 
under Knuth's authority, imply that any attention to efficiency, however 
remote it might be, is also evil, and therefore no attention whatsoever 
should be ever paid to it.  This may pose a serious problem in applications 
which do need to run efficiently, as it isn't possible to fix performance 
problems caused by fundamental design decisions by postponing any attention 
to the application's efficiency to a testing stage.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#14828

In article <jj80vp$ogr$1@speranza.aioe.org>,
Rui Maciel  <rui.maciel@gmail.com> wrote:
>Maarten wrote:
>
>> As Donald Knuth once put it: "There is no doubt that the grail
>> of efficiency leads to abuse. Programmers waste enormous amounts
>> of time thinking about, or worrying about, the speed of noncritical
>> parts of their programs, and these attempts at efficiency actually
>> have a strong negative impact when debugging and maintenance are
>> considered. We should forget about small efficiencies, say about
>> 97% of the time: premature optimization is the root of all evil."
>> 
>> Only start optimizing once you have tested your code, and are
>> satisfied that it is correct. And only start to optimize when
>> you have seen that there is a performance issue, and have
>> pinpointed the issue with a profiler.
>> 
>> Yes, Donald Knuth leaves you 3% where it does matter. But he
>> also states that you should only worry about that after you
>> have identified that code.
>> 
>> Article can be found from
>> http://en.wikipedia.org/wiki/Program_optimization
>
>Knuth's quote tends to be abused a bit.  Some individuals employ it to, 
>under Knuth's authority, imply that any attention to efficiency, however 
>remote it might be, is also evil, and therefore no attention whatsoever 
>should be ever paid to it.  This may pose a serious problem in applications 
>which do need to run efficiently, as it isn't possible to fix performance 
>problems caused by fundamental design decisions by postponing any attention 
>to the application's efficiency to a testing stage.

The key is the difference between premature optimization and premature
pessimization.  Sutter/Alexandrescu did follow their "Don't optimize
prematurely" with a "Don't pessimize prematurely".  They were also
careful to define premature optimization as making code more complex
and less readable when it is not justified by a *proven* performance
need (my emphasis).

however, all other things being equal, you should know more efficient
patterns and use them naturally if there are no negative cost to using
them. This may be as simple as passing read-only parameters as const
reference rather than by value and forcing a copy. OTOH, manually
implementing a ring buffer and maniplulating internal data with
pointer arithmetic because one believe that std::vector might not be
as fast is not justfiable without measurements.

Yannick

[toc] | [prev] | [next] | [standalone]

#14838

none wrote:

> The key is the difference between premature optimization and premature
> pessimization.  Sutter/Alexandrescu did follow their "Don't optimize
> prematurely" with a "Don't pessimize prematurely".  They were also
> careful to define premature optimization as making code more complex
> and less readable when it is not justified by a proven performance
> need (my emphasis).

Indeed, and surely the reason behind this need to clarify what Knuth said is 
due to the level of abuse that Knuth's quote has been subjected since it 
first appeared.  After all, is it really reasonable to quote Knuth when 
discussing stuff such as passing objects by value/reference? 


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#14829

On Wednesday, March 7, 2012 5:05:15 PM UTC+1, Rui Maciel wrote:
> Maarten wrote:
> 
> > As Donald Knuth once put it: "There is no doubt that the grail
> > of efficiency leads to abuse. Programmers waste enormous amounts
> > of time thinking about, or worrying about, the speed of noncritical
> > parts of their programs, and these attempts at efficiency actually
> > have a strong negative impact when debugging and maintenance are
> > considered. We should forget about small efficiencies, say about
> > 97% of the time: premature optimization is the root of all evil."
> > 
> > Only start optimizing once you have tested your code, and are
> > satisfied that it is correct. And only start to optimize when
> > you have seen that there is a performance issue, and have
> > pinpointed the issue with a profiler.
> > 
> > Yes, Donald Knuth leaves you 3% where it does matter. But he
> > also states that you should only worry about that after you
> > have identified that code.
> > 
> > Article can be found from
> > http://en.wikipedia.org/wiki/Program_optimization
> 
> Knuth's quote tends to be abused a bit.  

Which is why I looked it up, and used a slightly longer quotation. The 
rest of the article is rather interesting.

> Some individuals employ it to, 
> under Knuth's authority, imply that any attention to efficiency, however 
> remote it might be, is also evil, and therefore no attention whatsoever 
> should be ever paid to it.  This may pose a serious problem in applications 
> which do need to run efficiently, as it isn't possible to fix performance 
> problems caused by fundamental design decisions by postponing any attention 
> to the application's efficiency to a testing stage.

Do things in the right order:

* Use an appropriate algorithm. This is where the greatest improvements 
  can be made. This is at the design-stage, not at the programming stage.
  No optimization can dig you out of the hole created by picking the wrong 
  algorithm. 
  
  But on the other hand, spend your time wisely. Initialization is run only 
  once, a loop multiple times. While you may be able to make initialization 
  faster by 90%, on the overall run time the effect may be negligible. 
  Improve the code within a loop by 10%, and you might gain a lot. 

* Get something that is producing the correct results. Make sure the code 
  is readable at this stage. Low-hanging fruit can be harvested, say by 
  removing calculations from a loop that produce constant results. 
  Do not worry about the relative efficiency of 'a != 0' vs 'a > 0'.

* Run the code, and see if performance is an issue. If not: you're done, 
  and you have readable code. If more performance is needed, start your profiler
  and start optimizing from there.

I believe that Knuth was talking about discussion as to whether 'a != 0' 
or 'a > 0' is faster. On that I agree with him. Somehow I think he would 
agree with me on picking the right algorithm, and spending your time there.

Maarten

[toc] | [prev] | [next] | [standalone]

#14856

On Wed, 07 Mar 2012 06:14:02 -0800, Maarten wrote:

> Only start optimizing once you have tested your code, and are 
> satisfied that it is correct. And only start to optimize when 
> you have seen that there is a performance issue, and have 
> pinpointed the issue with a profiler. 

The main problem there is that changing interfaces at a late stage can
require rewriting a substantial amount of code.

An important part of the programmer's art is knowing which bridges you'll
have to cross before you get to them, avoiding the need to dig yourself
out of holes by not climbing into them in the first place.

[toc] | [prev] | [next] | [standalone]

#14816

On Wed, 2012-03-07, yatremblay@bel1lin202.(none) (Yannick Tremblay) wrote:
> In article <slrnjlehf7.1ls.grahn+nntp@frailea.sa.invalid>,
> Jorgen Grahn  <grahn+nntp@snipabacken.se> wrote:
>>On Wed, 2012-03-07, Geoff wrote:
...
>>> It's using pointers because it needs to return more than one value and
>>> since it's old C it was probably the simplest way to do it at the
>>> time.
>>
>>Probably not the /only/ way though -- returning structs has been
>>possible in C for ~25 years now. I always believed it was expensive,
>>but I suspect that at some point it became cheaper with popular
>>compilers.
>
> Sounds like old-style C programmer: "I believe it is too expensive".

Of course. What I wrote was meant as an example of how C programmers
tend to think, not as a recommendation.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#14857

On Wed, 07 Mar 2012 11:26:33 +0000, Jorgen Grahn wrote:

> Probably not the /only/ way though -- returning structs has been
> possible in C for ~25 years now. I always believed it was expensive,
> but I suspect that at some point it became cheaper with popular
> compilers.

For functions with external linkage, the compiler doesn't have much
choice, as the platform's ABI will normally dictate how structures are
returned.

[toc] | [prev] | [next] | [standalone]

#14858

On Fri, 2012-03-09, Nobody wrote:
> On Wed, 07 Mar 2012 11:26:33 +0000, Jorgen Grahn wrote:
>
>> Probably not the /only/ way though -- returning structs has been
>> possible in C for ~25 years now. I always believed it was expensive,
>> but I suspect that at some point it became cheaper with popular
>> compilers.
>
> For functions with external linkage, the compiler doesn't have much
> choice, as the platform's ABI will normally dictate how structures are
> returned.

Yeah, but is that inefficient for any decent platforms?  I don't see
why it would have to be. One which seems reasonable is:

- Less than 32 bits? Dump it in register FOO.
- More? Room has been made available on the stack <here>.

I don't see how this would make returning structs expensive, if that's
what you're trying to convey.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#14808

ahso wrote:

> Hi
> I want to rewrite a function as below to not use pointers:
> 
> void NewPos(float angle, float speed, float *x, float *y){
> 
> angle = (angle-90.0)*0.0174532925199433;
> 
> *x = (cos(angle) * speed);
> *y = (sin(angle) * speed);
> 
> }
> 
> I also don't know what this is doing exactly. Any explanations and
> also why this needs pointers?
> Many thanks

I agree with Marcel Müller: it does look like C code. Or, better yet, it 
looks like the C way of passing arguments by reference.  

So, here is the breakdown of this function:

- It basically it performs a coordinate transformation on a 2D vector from 
polar coordinates (angle, magnitude) to rectangular coordinates.  So, it 
takes two pairs of parameters: a couple of floats used to represent a vector 
described in polar coordinates (angle, speed) and a couple of pointers to 
floats intended to describe a vector in rectangular coordinates (x, y).
- the "angle" parameter is defined in degrees, but the trigonometric 
functions require that the angle is described in radians.  This requires a 
conversion from degrees to radians.  The "angle" parameter is subjected to a 
translation (angle - 90).
- the function was written so that the result of this vector transformation 
was stored in a couple of objects which are passed as parameters (i.e., 
float x and float y).  To be able to do that with the C programming 
language, we need to pass pointers which point to the address of those 
objects. By doing this, it becomes possible to set the value of those 
objects by dereferencing the pointers to them.


Hope this helps,
Rui Maciel

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c++

csiph-web