Jack Klein wrote:
>
> It seems to me that there is a problem with the definition of the
> register keyword and storage class in the standard.
>
> My line of reasoning is as follows:
>
> 1.  ANSI/ISO C90 states that taking the address of a register variable
> is a constraint violation, thus requiring a diagnostic and
> legitimately allowing the compiler to halt the translation (6.3.3.2).
>
> 2.  The C++ standard follows the C standard except where it explicitly
> says otherwise.

No, that is not correct. The C standard is a reference document,
and portions of it are explicitly included. Refer to 1.2 paragraph 1,
first sentence.

In the portions of the C standard that are explicitly included, the
C++ standard follows follows C unless it says otherwise. The C library
is included by reference, but little (if any) of the basic language
part of the C standard is explicitly included.

--
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <1vBuOOVM1uQtn9e+1Ke7XSWi3aOt@4ax.com>, Jack Klein
<jackklein@att.net> writes
>2.  The C++ standard follows the C standard except where it explicitly
>says otherwise.  Therefore taking the address of a register variable
>is a constraint violation unless the C++ standard specifically states
>that it is not.

But 7.1.1 para 3 requires register storage class objects to have the
same semantics as auto storage class objects.  Hence the only effect of
register is to suggest that the compiler provide fast access storage
(cache etc.) where it has a choice.  However, in C++, the storage must
be addressable unless the compiler can prove that its address will not
be used (actually not that difficult but it does need the compiler to
examine the entire block before deciding).

Now someone save me the trouble of looking it up,  are we allowed to
have register qualified data members of a UDT?  If so I think the
compiler will almost certainly have to ignore it (even if all the member
functions are defined in class, I think there are still problems)





Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jack Klein wrote in message <1vBuOOVM1uQtn9e+1Ke7XSWi3aOt@4ax.com>...
>
>It seems to me that there is a problem with the definition of the
>register keyword and storage class in the standard.
> ...
>Frankly I am a bit surprised at the "most implementations" wording,
>which states that an implementation that allows the address of a
>register variable to be taken is conforming, but does not require all
>implementations to do so.  It is unusual for the standard to comment
>on what "some" or "most" implementations do.

Look at the non-note part of 7.1.1/3.  It says that register has the same
semantics as auto.  A conforming implementation may only refuse to allow the
address of a register variable to be taken if it would also refuse to allow
the address of an auto variable to be taken (say because of a private
operator&()).
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jack Klein wrote:

> [specific references to taking the address of a register variable deleted
> for brevity]

> Frankly I am a bit surprised at the "most implementations" wording,
> which states that an implementation that allows the address of a
> register variable to be taken is conforming, but does not require all
> implementations to do so.  It is unusual for the standard to comment
> on what "some" or "most" implementations do.

register is a recommendation to the compiler.  The compiler does not have to
place the variable into a register.  Also, some architectures will actually
return an address of a register.  I remember the TI 9900 all it's registers
were in memory and some other architectures also would give some special
memory address for registers.

> If I am missing or overlooking something, please point it out to me.

I hope this addresses your issue.

Michael
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jack Klein <jackklein@att.net> writes:

> 1.  ANSI/ISO C90 states that taking the address of a register variable
> is a constraint violation, thus requiring a diagnostic and
> legitimately allowing the compiler to halt the translation (6.3.3.2).

I don't have the a copy of C90, but an earlier C99 draft says

# The operand of the unary & operator shall be either a function
# designator, the result of a [] or unary * operator, or an lvalue
# that designates an object that is not a bitfield and is not
# declared with the register storage-class specifier.


> 2.  The C++ standard follows the C standard except where it explicitly
> says otherwise.  Therefore taking the address of a register variable
> is a constraint violation unless the C++ standard specifically states
> that it is not.

The C++ standard most certainly says otherwise explicitly. 5.3.1,
[expr.unary.op]/2 says

# The result of the unary & operator is a pointer to its operand. The
# operand shall be an lvalue or a qualified=ADid.

Since a register variable is an lvalue, it is certainly legal as an
argument to the & operator.

Regards,
Martin
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote in message ...

>Now someone save me the trouble of looking it up,  are we allowed to
>have register qualified data members of a UDT?

Register may only be applied to parameters and to things declared in a
block.  Members aren't declared in a block.

Well, I suppose you can declare an entire UDT in a block, but you certainly
can't declare members directly in a block.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

It seems to me that there is a problem with the definition of the
register keyword and storage class in the standard.

My line of reasoning is as follows:

1.  ANSI/ISO C90 states that taking the address of a register variable
is a constraint violation, thus requiring a diagnostic and
legitimately allowing the compiler to halt the translation (6.3.3.2).

2.  The C++ standard follows the C standard except where it explicitly
says otherwise.  Therefore taking the address of a register variable
is a constraint violation unless the C++ standard specifically states
that it is not.

3.  Notes (like the one in 7.1.1 paragraph 3) are NOT normative, and
this is the only place where the C++ standard mentions taking the
address of a register value.  Thus there is no normative wording in
the standard which overrides the C standard's prohibition against
taking the address of a register variable.

4.  The note itself states that "...in most implementations it will be
ignored if the address of the object is taken."  This clearly implies
that an implementation is NOT required to ignore the register keyword
just because the program also attempts to take the address of the
object.

Frankly I am a bit surprised at the "most implementations" wording,
which states that an implementation that allows the address of a
register variable to be taken is conforming, but does not require all
implementations to do so.  It is unusual for the standard to comment
on what "some" or "most" implementations do.

This implies to me that both of the following can be strictly
conforming:

A.  A compiler which ignores the register keyword if the address of
the variable is taken, silently converts the storage class to auto,
and allows the taking of the address.

B.  A compiler which does not ignore the register keyword in the
definition and considers the attempt to take the address a constraint
violation.

Since the actual behavior is not guaranteed, nor is it mentioned as
implementation-defined, it would seem that the result of taking the
address of a register variable is undefined or must fit into the C99
of "unspecified".

If I am missing or overlooking something, please point it out to me.

Jack Klein
--
Home: http://jackklein.home.att.net


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]