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

[Victor Bazarov]

Sourabh Daptardar wrote:

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 ?

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

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Sourabh Daptardar]

On Jun 6, 12:52 am, Victor Bazarov <[e-mail]:

>
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

[Victor Bazarov]

Sourabh Daptardar wrote:

>
On Jun 6, 12:52 am, Victor Bazarov <[e-mail]:

>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.

At this point in hardware advancements, in compiler advancements, and
the desire to keep our source code portable, what meaning (to you or to
anyone else) would such a request have? If it may not be honoured, what
value does there exist to keep this in the language except to allow the
legacy programs that were written when those specifiers had meaning, to
still compile? Let's take the opposite situation; does the *absence* of
the specifier prevent the compiler from placing the variable in a
register to speed up calculations? No. What would then be the point?

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.

How can a member variable be placed in a register and the whole object
be placed elsewhere? For some local calculations, a _copy_ of the
member variable can certainly be placed in a register (and the compiler
will take care of updating the member as needed). So, what would the
"register" specifier do, what would its *purpose* be?

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.

Uh... Didn't you just say that "register" may not be honoured? Just
like "inline" (in this particular sense, we're not talking linkage
here), "register" would be but a hint to the compiler. But doesn't any
modern compiler know already enough how to do its job to not need our
hints about what to place where? Or are you proposing that for
stand-alone variables "register" is only a hint, but for data members
it's made a hard directive?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Frank Birbacher]

Hi!

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. Premature optimization is the root of
all evil!

Frank

[James Kanze]

On Jun 6, 8:06 pm, Sourabh Daptardar <[e-mail]>
wrote:

On Jun 6, 12:52 am, Victor Bazarov <[e-mail]:

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.

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 (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jun 7, 12:43 am, Frank Birbacher <[e-mail]:

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).

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]