»

[Jose]

Arggg... I just spent 10 {bleep}ing minutes typing and it was gone!

Anyway...

struct MajorArrayElement
{ LONG 2ndArrayOffset;
LONG 2ndArrayNrElements;
LONG *2ndArrayPointer;
}*MajorArrayElementPtr;

I want to avoid having to use double indirection everytime I access an element of the 2ndArray:
*(MajorArrayElementPtr->2ndArrayPointer++)
or
MajorArrayPtr->2ndArrayPointer[nr.]

Both use MajorArrayPtr unnecessaryly.
I solved this by using another pointer that would be passed the adress of the 2ndArray's first element and then incremented(++) after each 2ndArray's element access.
But is there another way without using this? In assembler it's more easy but I want to keep my code portable and use the structre facilities of C.

Ahh, and DONT't tell me the compiler optimizes this and I shouldn't care 8-)

[Trev]

I think we need a little more information. This:

struct MajorArrayElement
{
LONG 2ndArrayOffset;
LONG 2ndArrayNrElements;
LONG *2ndArrayPointer;
}*MajorArrayElementPtr;

creates an lvalue called MajorArrayElementPtr that is a pointer to a 'struct MajorArrayElement'. It's not initialized, so the value of MajorArrayElementPtr is undefined.

Ummm, you have to reference a structure's elements using the name of the structure, so you're stuck with MajorArrayElementPtr->element. (Forget about C++ and static members for a moment.) I'm assuming that MajorArrayElementPtr contains a valid pointer.

Compiler optimizations aren't really relevent. You're just dealing with standard C. Storing an element's value in a temporary variable may prevent the compiler from optimizing references to MajorArrayElementPtr and its elements (i.e. it now has to track three pointers instead of two). I suppose it depends on the compiler.

Trev

[Jose]

"Storing an element's value in a temporary variable may prevent the compiler from optimizing references to MajorArrayElementPtr and its elements ..."

That's precisely the contrary of what I want to achieve. I want to know ways of optimizing it the mostly possible, not cripple the compiler's own optimization.
Basically I just though using a 3rd pointer was the best method to use to avoid using double indirection when a pointer is in some place pointed to by another pointer. I suppose some compilers optimize it when they see the number of accesses justify it but we don't have any control over it do we?
And if I use a 3rd pointer I'm actually making use of unecessary mem space, so more stack pushes and pulls and/or more address registers used.
I think I'm gonna let the compilers memory management handle it instead of writing obfuscated code. Someone must have already though about this.

[Trev]

Yeah, it's probably a good idea to leave some of the optimization up to the compiler. Of course, you'll want to write your code in a way that can be optimized, and that requires reading the compiler documentation. Both gcc and VBCC have pretty good documentation about how their optimizations work.

Really though, your code should be written for readability and debugging, e.g. use

(EDIT: removed dumb example, replaced with something more relevant, added "however")

MajorArrayElementPtr->2ndArrayPointer[i];

However, if you're working with 2ndArrayPointer in a loop, then using a temporary variable is probably more efficient:

/* initialize array that's already allocated */

{
LONG i;
LONG * p = MajorArrayElementPtr->2ndArrayPointer;

for (i = MajorArrayElementPtr->2ndArrayNrElements; i > 0; i--)
*(++p) = 0;
}

Trev