Storage class specifier of class members

[Sourabh Daptardar]

Why is register storage specifier not allowed for class member
variables?

<snip>
ISO standard : Section 9.2 ; point 6 :
-6- A member shall not be auto, extern, or register.
</snip>

I believe it is not related to object storage being contiguous,
discontiguous or contiguous with gaps.

Can some one throw light on this ?

Regards,
Sourabh

 

[Sourabh Daptardar]

Think about it... What would that mean if you declare one member
'register' and another member 'extern'? And if an instance of theclass
is declared 'static' (or simply outside of any function), what should
compiler do if any of the datamembersare declared 'auto'? Should it
ignore the specifiers? What's the point of allowing them, then?

Lets consider only the 'register' case.
When we use a register storage specifier for a non-member variable :

register int var;

It is a request ( which may not be honoured ) to the compiler to
assign a register for the variable -- it might speed up the
calculations.

Why is not allowed for class members ? If I there is a class member
variable which is going to be heavily used in calculations, it might
be worthwhile.

If we have one class member with register storage specifier and other
without it ; both are stored in the primary memory but only the first
one is brought in the register. On memory reference to that location
there will be a write-back.

Regards,
Sourabh

 

[Frank Birbacher]

Hi!

It is a request ( which may not be honoured ) to the compiler to
assign a register for the variable -- it might speed up the
calculations.

[snip]
But doesn't any
modern compiler know already enough how to do its job to not need our
hints about what to place where?

Right. The compiler always copies data from memory into registers.
Especially for heavy use. There is no need to and no gain from
specifying "register". Not even for local variables (anymore).

And if "register" would make a difference then this difference would be
too small for anyone to notice. Premature optimization is the root of
all evil!

Frank

 

[James Kanze]

Lets consider only the 'register' case.
When we use a register storage specifier for a non-member variable :

register int var;

It is a request ( which may not be honoured ) to the compiler to
assign a register for the variable -- it might speed up the
calculations.

Why is not allowed for class members ? If I there is a class
member variable which is going to be heavily used in
calculations, it might be worthwhile.

The lifetime of a class object may extend beyond the end of a
function. Where is the compiler to put the variable then?

More generally, register is no-op in almost all compilers
anyway. This was already the case when C++ was being
standardized; the keyword register is really only present for
reasons of backward compatibility with older C.

If we have one class member with register storage specifier
and other without it ; both are stored in the primary memory
but only the first one is brought in the register. On memory
reference to that location there will be a write-back.

Normally, if optimization is used, the compiler will keep
whatever variables are most used in a block of code in
registers, independantly of any keywords.

 

[James Kanze]

Victor Bazarov schrieb:

It is a request ( which may not be honoured ) to the compiler to
assign a register for the variable -- it might speed up the
calculations.

[snip]
But doesn't any
modern compiler know already enough how to do its job to not need our
hints about what to place where?

Right. The compiler always copies data from memory into
registers. Especially for heavy use. There is no need to and
no gain from specifying "register". Not even for local
variables (anymore).

And if "register" would make a difference then this difference
would be too small for anyone to notice.

Any effect would likely be negative. At different places in the
function, the compiler will keep different variables in
registers (including globals or class members); if register were
effective, it would reduce the number of registers the compiler
had at its disposition to do this.

Premature optimization is the root of all evil!

Especially when it actually results in pessimization (which
seems to frequently be the case).