Convert degree to Radians effective way

Convert degree to Radians effective way

dthompson

Member #5,749

April 2005

bamccaig said:

It's far more readable if the human stores a pointer or reference along the way for a nested object/struct that is accessed more than once.

Do compilers generally figure out and optimise repeated dereferencing? ie.:

#SelectExpand
  1for(i = 0; i < PARTICLES_SIZE; i++)
  2{
  3  particles[i].x += particles[i].dx;
  4  particles[i].y += particles[i].dy;
  5  particles[i].life--;
  6}
  7
  8// would the above be effectively optimised into the below?
  9
 10PARTICLE* particle;
 11for(i = 0; i < PARTICLES_SIZE; i++)
 12{
 13  particle = &particles[i];
 14
 15  particle->x += particle->dx;
 16  particle->y += particle->dy;
 17  particle->life--;
 18}

I've unfortunately been in the habit of repeatedly dereferencing arrays since I began writing C, yet would never do it in any other language. ::)

______________________________________________________
Website. It was freakdesign.bafsoft.net.
_{This isn't a game!}

Peter Hull

Member #1,136

March 2001

dthompson said:

Do compilers generally figure out and optimise repeated dereferencing?

It seems that they can, see here.

dthompson

Member #5,749

April 2005

Awesome. That compiler explorer thing looks like a nice tool - interesting to see how compilation output differs between gcc and clang

______________________________________________________
Website. It was freakdesign.bafsoft.net.
_{This isn't a game!}

Audric

Member #907

January 2001

I've used such tools sometimes, but it can be hard to build a program that sets up a situation for what you want to test : if the compiler detects that your program is pointless (ie: you do computations, but the result goes nowhere), it can consider it dead code and scrap it entirely from the output.

Also, sample 5-lines programs are never a real-life situation, they're a fairyland where all data is on the same memory page, pipeline and registers are at your full disposal, and you're free to leave them in any state when you're done, as you're the last piece of code in the executable.
On the other hand, some optimization can be gotten ONLY when there is code beforehand : If the previous block was guaranteed to leave 0 in register EAX, you can re-use this register for a variable initialized to zero at no cost.

bamccaig

Member #7,536

July 2006

Audric said:

// I really don't think the following:
format(currentSite.Domain.Type, currentSite.Domain.Name, nextSite.Domain.Type, nextSite.Domain.Name);
// Should be rewritten as
Domain domainOfTheCurrentSite = currentSite.Domain;
Domain domainOfTheNextSite = nextSite.Domain;
format(domainOfTheCurrentSite.Type, domainOfTheCurrentSite.Name, domainOfTheNextSite.Type, domainOfTheNextSite.Name);

You seem to be choosing unnecessarily verbose names here. The references are literally right next to their definitions. They can be single letters or abbreviations for all intents and purposes without affecting readability.

// Easier to read IMO, but still results in a somewhat long
// statement that should be broken onto many lines.
Domain currentDomain = currentSite.Domain;
Domain nextDomain = nextSite.Domain;

format(currentDomain.Type, currentDomain.Name,
       nextDomain.Type, nextDomain.Name);

// Still easier to read IMO, but barely longer than the original.
Domain cd = currentSite.Domain;
Domain nd = nextSite.Domain;

format(cd.Type, cd.Name, nd.Type, nd.Name);

A couple of things that I want to point out: white-space is your friend. Adding a blank line between the variable definitions/assignments and the function call aides greatly in readability. Similarly, your original line is too damn long. I don't care if my monitor is that long. It's more efficient to read up and down instead of back and forth, up and down.

Also, I'm hoping this is Java or something with implicit references because otherwise we're probably copying the domain objects unnecessarily.

--
I mean the best with what I say. It doesn't always sound that way.

Kitty Cat

Member #2,815

October 2002

dthompson said:

Do compilers generally figure out and optimise repeated dereferencing?

It depends. There are what's known as aliasing rules. C, C++, and other languages say when it is or isn't possible for two separate pointers/references to refer to the same memory, and if you're writing to a pointer/reference than can potentially alias the same memory as you're reading from, regardless of whether or not they are actually aliasing, the compiler may be forced to generate less optimized code just in case. The compiler has to be able to prove to itself that the value can't change between multiple dereferences to optimize it. This can be helped by not using -fno-strict-aliasing (which disabled the stricter aliasing rules, in turn making the compiler assume more pointers/references may alias than are otherwise allowed to) and also proper use of the restrict keyword, which tells the compiler the given pointer/reference will not alias other memory being used during its lifetime.

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham