kanze@gabi-soft.fr writes:

| gdr@cs.tamu.edu (Gabriel Dos Reis) wrote in message
| news:<m3zn4fom0v.fsf@merlin.cs.tamu.edu>...
| > kanze@gabi-soft.fr writes:
|
| > | brok@rubikon.pl (Bronek Kozicki) wrote in message
| > | news:<ead94$412bb80d$c3883115$15963@nf1.news-service-com>...
| > | > Bob Hairgrove wrote:
|
| > | > > "Whenever an lvalue appears in a context where an rvalue is
| > | > > expected, the lvalue is converted to an rvalue (...)". This
| > | > > would happen even if myInt were not const, of course.
|
| > | > I'm not sure what's signature of operator= for builtin types (I
| > | > could not find this info in clause 5 of the C++ standard),
|
| > | It takes an rvalue.  Thus, something that is neither const nor volatile.
|
| > | Actually, I suspect that it is a bit more complex.  C++ inherits
| > | rvalues and lvalues from C.
|
| > In C, an expression is an lvalue or is not.
|
| And all expressions are also rvalues.

Please, could you bring evidence (i.e. actual quote from the C
standard text) that C defines rvalue?

[...]

| > | In C, an rvalue is just a value, not an object; you can't do
| > | anything to it, so const and volatile are irrelevant.  In C++, this
| > | doesn't work, since you can call a member function on an rvalue,
|
| > I don't understand your statement.  In C, you can have rvalues of
                                                           ^^^^^^^
This should read "non-lvalue".

| > struct or union type and you can access data members of such things.
|
| So.  In C, rvalues do not have const and volatile attributes.  You can
| access data members of them, but such accesses also result in rvalues,
| without const and volatile attributes.


       6.5.2.3  Structure and union members
       [...]
       Semantics

       [#3]  A postfix expression followed by the . operator and an
       identifier designates a  member  of  a  structure  or  union
       object.   The  value  is that of the named member, and is an
       lvalue if the first expression is an lvalue.  If  the  first
       expression  has  qualified  type,  the  result  has  the so-
       qualified version of the type of the designated member.

I see no mention that, if the expression of structue type is not an
lvalue then the result has a non-qualified type.

Consider the following C program:

     struct S {
        const int ary[1];
     };

     extern struct S foo(void);
     extern int bhar(int*);

     int main(void)
     {
        return !sizeof(bhar(&foo().ary[0]));
     }


I assume we all agree that the expression f() is not an lvalue,
therefore the array f().ary is neither an lvalue.  So what do you
believe the type of the expression &foo().ary[0] should be?
In other words, do you think the above program C should be
accepted or rejected according to C definition?

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
  Texas A&M University -- Computer Science Department
 301, Bright Building -- College Station, TX 77843-3112

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

gdr@cs.tamu.edu (Gabriel Dos Reis) wrote in message
news:<m3zn4fom0v.fsf@merlin.cs.tamu.edu>...
> kanze@gabi-soft.fr writes:

> | brok@rubikon.pl (Bronek Kozicki) wrote in message
> | news:<ead94$412bb80d$c3883115$15963@nf1.news-service-com>...
> | > Bob Hairgrove wrote:

> | > > "Whenever an lvalue appears in a context where an rvalue is
> | > > expected, the lvalue is converted to an rvalue (...)". This
> | > > would happen even if myInt were not const, of course.

> | > I'm not sure what's signature of operator= for builtin types (I
> | > could not find this info in clause 5 of the C++ standard),

> | It takes an rvalue.  Thus, something that is neither const nor volatile.

> | Actually, I suspect that it is a bit more complex.  C++ inherits
> | rvalues and lvalues from C.

> In C, an expression is an lvalue or is not.

And all expressions are also rvalues.  So an expression is either an
rvalue, or both an rvalue and an lvalue at the same time.

> The C++ standard text formally "defines" the term rvalue.  The rules
> get complicated and obscure with clever uses and distinctions of what
> is lvalue or rvalue.

The rules mainly get complicated when dealing with user defined types.
You can call a member function of an rvalue of class type, for example,
which in turn means that the compiler is capable of taking its address.

For the built-in types, C and C++ do use different wording, but except
that some things are lvalues in C++, but not in C, the results are
pretty much the same.  Intentionally, I think.

> | In C, an rvalue is just a value, not an object; you can't do
> | anything to it, so const and volatile are irrelevant.  In C++, this
> | doesn't work, since you can call a member function on an rvalue,

> I don't understand your statement.  In C, you can have rvalues of
> struct or union type and you can access data members of such things.

So.  In C, rvalues do not have const and volatile attributes.  You can
access data members of them, but such accesses also result in rvalues,
without const and volatile attributes.  In C++, rvalues have const and
volatile attributes if (and only if) they are of class type.  In C++,
this distinction is largely necessitated by member functions; you can't
call a non-const member function on a const rvalue.

--
James Kanze           GABI Software         http://www.gabi-soft.fr
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <8b42afac.0408250431.3dfdf97f@posting.google.com>, James
Kuyper <kuyper@wizard.net> writes
>Because "integral type" is italicized in that clause, it constitutes a
>definition of "integral type", which therefore excludes enumerations.
>Footnote 43, which is attached right after the definition, says very
>explicitly that enumerations are not integral types.

And note that this is another of the differences between C and C++.
These differences in terminology can be very confusing and I think that
WG21 and WG14 could provide a service to the programming community by
examining all their language specific definitions and making a serious
effort to harmonise them.


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Bob Hairgrove wrote:

> "Whenever an lvalue appears in a context where an rvalue is expected,
> the lvalue is converted to an rvalue (...)". This would happen even if
> myInt were not const, of course.

I'm not sure what's signature of operator= for builtin types (I could
not find this info in clause 5 of the C++ standard), but if it takes
right operand of const lvalue type (not rvalue), then such conversion
does not take place and compilation error is ok.


B.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Wed, 25 Aug 2004 04:39:06 GMT, brok@rubikon.pl (Bronek Kozicki)
wrote:

>Bob Hairgrove wrote:
>
>> "Whenever an lvalue appears in a context where an rvalue is expected,
>> the lvalue is converted to an rvalue (...)". This would happen even if
>> myInt were not const, of course.
>
>I'm not sure what's signature of operator= for builtin types (I could
>not find this info in clause 5 of the C++ standard), but if it takes
>right operand of const lvalue type (not rvalue), then such conversion
>does not take place and compilation error is ok.

Well, initializing a const int variable with a non-const int variable
is not going to cause any problems. The error message shown indicates
that g++ doesn't want to convert "int" to a pointer without a cast.

According to my interpretation/understanding of the standard, this
assignment (int to pointer) should require a C-style cast or
reinterpret_cast only if the variable's value is not zero; otherwise,
it fulfils the requirement for being a null pointer constant as (quote
from 4.10): "(...) an integral constant expression (5.19) rvalue of
integer type that evaluates to zero." The standard could have stated
that it must use a literal, but the explicit use of the word "constant
expression" and the definition given in 5.19 are quite clear that this
includes variables as well.

As I see it, what we have is "an integral constant expression of
integer type" (is this redundant, or is it meant to explicitly exclude
other integral types?). By itself, the const int variable qualifies
only as an lvalue. The question remains whether it is OK to implicitly
convert it to an rvalue, as 3.10 suggests that it should, when used to
assign to a pointer.

5.19 states that "An integral constant expression can involve only
literals (2.13), enumerators, const variables or static data members
of integral or enumeration types initialized with constant expressions
(...)". Variables (at least const int variables) are therefore OK; as
to enums, I suppose the restriction of 4.10 might preclude using them
to initialize a pointer, as James Kanze already pointed out. However,
in an assignment (i.e. using operator=) I would think that enum would
implicitly be converted to int, i.e.:

  enum MyNull { null };
  MyType * p( null ); // error; initialization with enum
  MyType * p = null; // OK; enum implicitly converted to int

--
Bob Hairgrove
NoSpamPlease@Home.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://www.jamesd.demon.co.uk/csc/faq.html                       ]

kanze@gabi-soft.fr wrote in message news:<d6652001.0408240803.7ae89f80@posting.google.com>...
..
>    3.9.1/7:
>     Types bool, char, wchar_t, and the signed and unsigned integer types
>     are collectively called integral types.  A synonym for integral type
>     is integer type.
>
> I'm not 100% sur, but it doesn't seem as though enum's are integral (or
> integer) types, ...

Because "integral type" is italicized in that clause, it constitutes a
definition of "integral type", which therefore excludes enumerations.
Footnote 43, which is attached right after the definition, says very
explicitly that enumerations are not integral types.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

brok@rubikon.pl (Bronek Kozicki) wrote in message
news:<ead94$412bb80d$c3883115$15963@nf1.news-service-com>...
> Bob Hairgrove wrote:

> > "Whenever an lvalue appears in a context where an rvalue is
> > expected, the lvalue is converted to an rvalue (...)". This would
> > happen even if myInt were not const, of course.

> I'm not sure what's signature of operator= for builtin types (I could
> not find this info in clause 5 of the C++ standard),

It takes an rvalue.  Thus, something that is neither const nor volatile.

Actually, I suspect that it is a bit more complex.  C++ inherits rvalues
and lvalues from C.  In C, an rvalue is just a value, not an object; you
can't do anything to it, so const and volatile are irrelevant.  In C++,
this doesn't work, since you can call a member function on an rvalue,
and const and volatile are needed for function overload resolution, if
nothing else.  In the section on lvalue to rvalue conversion, it states
that the conversion removes const-ness for non class types.  However, it
does so in a way that sort of suggests that the const and volatile are
still part of the type system being used.  In C, it isn't so much that
an rvalue is not const, but that const is irrelevant to rvalues --
rvalues only use a subset of the type system.  I'm pretty sure that the
intent is that C++ act exactly like C for non class types, but the
wording isn't always as clear or as coherent as one might like.

> but if it takes right operand of const lvalue type (not rvalue), then
> such conversion does not take place and compilation error is ok.

I'm not sure what you are trying to say here.  Could you explain.

For the rest,    3.10/7 does seem to say that an lvalue should always be
converted into an rvalue, which would mean that g++ does have a bug.
But then, why does the definition of a null pointer constant in    4.10/1
insist on it being an rvalue?  I'm pretty confused, to put it mildly.

(There's also the question as to why enum {myNull} isn't a null pointer
constant in C++, while it is in C.  The arguments brought up against
((void*)0) don't apply.  Vive N1601.)

--
James Kanze           GABI Software         http://www.gabi-soft.fr
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

kanze@gabi-soft.fr wrote:
>>but if it takes right operand of const lvalue type (not rvalue), then
>>such conversion does not take place and compilation error is ok.
>
> I'm not sure what you are trying to say here.  Could you explain.

I was thinking that when using lvalue in context where lvalue is
expected, and there's no builtin conversion that could produce temporary
rvalue, then conversion to rvalue does not take place, thus there's no
null pointer value (as it must be an rvalue) and what we have left is
trying to assign integer lvalue to pointer - which is ill-formed.


B.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

francis@robinton.demon.co.uk (Francis Glassborow) wrote in message
news:<4fshZ8Ew7YLBFwBK@robinton.demon.co.uk>...
> In article <8b42afac.0408250431.3dfdf97f@posting.google.com>, James
> Kuyper <kuyper@wizard.net> writes
> >Because "integral type" is italicized in that clause, it constitutes
> >a definition of "integral type", which therefore excludes
> >enumerations.  Footnote 43, which is attached right after the
> >definition, says very explicitly that enumerations are not integral
> >types.

> And note that this is another of the differences between C and C++.
> These differences in terminology can be very confusing and I think
> that WG21 and WG14 could provide a service to the programming
> community by examining all their language specific definitions and
> making a serious effort to harmonise them.

I second this.  Note that in this case, the difference results in a
pratical difference as well -- in C, "enum { myNull }" defines a null
pointer constant, in C++, no.  While I understand the historical reasons
for the difference concerning ((void*)0), I don't see any reason for a
difference here.

In fact, why the complications in the C++ definition of a null pointer
constant?  Why not just "a null pointer constant is an integral constant
expression evaluating to 0", and let it go at that?  Why add "rvalue of
integer type"?  Either the "rvalue" means nothing, or something like:
    int const myNull = 0 ;
is not a null pointer constant (and I don't think that I am the only one
who would be surprised to learn that it isn't).  And why exclude enum's?

--
James Kanze           GABI Software         http://www.gabi-soft.fr
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

invalid@bigfoot.com (Bob Hairgrove) wrote in message
news:<kgpoi0dhibgjkurv2uhp23spfpo537glhh@4ax.com>...

    [...]
> As I see it, what we have is "an integral constant expression of
> integer type" (is this redundant, or is it meant to explicitly exclude
> other integral types?).

The actual text is "an integral constant expression rvalue of integer
type".  Whatever.  The "of integer type" definitly excludes enum's, and
some compilers refuse them.  So we have:

    int const myNull = 0 ;  //  null pointer constant in C++, not in C
    enum { muNull } ;       //  null pointer constant in C, not in C++

> By itself, the const int variable qualifies only as an lvalue. The
> question remains whether it is OK to implicitly convert it to an
> rvalue, as 3.10 suggests that it should, when used to assign to a
> pointer.

> 5.19 states that "An integral constant expression can involve only
> literals (2.13), enumerators, const variables or static data members
> of integral or enumeration types initialized with constant expressions
> (...)". Variables (at least const int variables) are therefore OK; as
> to enums, I suppose the restriction of 4.10 might preclude using them
> to initialize a pointer, as James Kanze already pointed out. However,
> in an assignment (i.e. using operator=) I would think that enum would
> implicitly be converted to int, i.e.:

>   enum MyNull { null };
>   MyType * p( null ); // error; initialization with enum
>   MyType * p = null; // OK; enum implicitly converted to int

Some compilers reject enum's, others accept them.  G++ rejects the
const int, but it is alone in this.

Does anyone know what the real intention was?

--
James Kanze           GABI Software         http://www.gabi-soft.fr
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

invalid@bigfoot.com (Bob Hairgrove) writes:

[...]

| Seems to me that this is definitely not conforming behavior according
| to the current standard. "int const MyNull" is definitely a constant
| integral value (see 5.9 and 4.10 of the standard), and the lvalue
| should be implicitly converted to an rvalue here (see 3.10).

You're right.  The behaviour seen in GCC is not an intentional
behaviour.  It is a regression that was carelessly introduced.
It is already fixed in GCC-3.4.2.

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
  Texas A&M University -- Computer Science Department
 301, Bright Building -- College Station, TX 77843-3112

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

kanze@gabi-soft.fr writes:

| An interesting question has come up in the German newsgroup, and to be
| frank, I'm not sure of the correct answer.  Is:
|     int const myNull =3D 0 ;
| a null pointer constant?

Yes.

|  I had always supposed it was, but careful
| reading of the standard (=A74.10/1) says that "A null pointer constant =
is
| an integral constant expression rvalue of integer type that evaluates t=
o
| zero." Given the above, "myNull" is not an rvalue, and so not a null
| pointer constant.  According to other posters, most compilers, includin=
g
| Comeau, accept it; I seem to have read somewhere that Stroustrup says
| it's one somewhere as well.  On the other hand, g++ (3.4.0) rejects it,
| and the standard does say rvalue, which would seem to support g++.

That is a bug in GCC and I reported that a while ago -- thanks to Bjarne
who brought the question to my attention.  The bug is fixed in the
forthcoming GCC-3.4.2.

--=20
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
  Texas A&M University -- Computer Science Department
 301, Bright Building -- College Station, TX 77843-3112

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

kanze@gabi-soft.fr writes:

| brok@rubikon.pl (Bronek Kozicki) wrote in message
| news:<ead94$412bb80d$c3883115$15963@nf1.news-service-com>...
| > Bob Hairgrove wrote:
|
| > > "Whenever an lvalue appears in a context where an rvalue is
| > > expected, the lvalue is converted to an rvalue (...)". This would
| > > happen even if myInt were not const, of course.
|
| > I'm not sure what's signature of operator= for builtin types (I could
| > not find this info in clause 5 of the C++ standard),
|
| It takes an rvalue.  Thus, something that is neither const nor volatile.
|
| Actually, I suspect that it is a bit more complex.  C++ inherits rvalues
| and lvalues from C.

In C, an expression is an lvalue or is not.  The C++ standard text
formally "defines" the term rvalue.  The rules get complicated and
obscure with clever uses and distinctions of what is lvalue or rvalue.

| In C, an rvalue is just a value, not an object; you
| can't do anything to it, so const and volatile are irrelevant.  In C++,
| this doesn't work, since you can call a member function on an rvalue,

I don't understand your statement.  In C, you can have rvalues of
struct or union type and you can access data members of such things.

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
  Texas A&M University -- Computer Science Department
 301, Bright Building -- College Station, TX 77843-3112

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

An interesting question has come up in the German newsgroup, and to be
frank, I'm not sure of the correct answer.  Is:
    int const myNull = 0 ;
a null pointer constant?  I had always supposed it was, but careful
reading of the standard (   4.10/1) says that "A null pointer constant is
an integral constant expression rvalue of integer type that evaluates to
zero." Given the above, "myNull" is not an rvalue, and so not a null
pointer constant.  According to other posters, most compilers, including
Comeau, accept it; I seem to have read somewhere that Stroustrup says
it's one somewhere as well.  On the other hand, g++ (3.4.0) rejects it,
and the standard does say rvalue, which would seem to support g++.

Am I overlooking something?  And if not, is it intentional?

(Also, while I'm at it: can an integral constant expression not have
integer type?)

--
James Kanze           GABI Software         http://www.gabi-soft.fr
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

<kanze@gabi-soft.fr> wrote...
> [..]
> (Also, while I'm at it: can an integral constant expression not have
> integer type?)

It can have a char type.  It can have wchar_t type.  It can have bool
type.  All of those are not integer, but still integral.  See 3.9.1.

Victor

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Tue, 24 Aug 2004 02:47:07 GMT, kanze@gabi-soft.fr wrote:

>An interesting question has come up in the German newsgroup, and to be
>frank, I'm not sure of the correct answer.  Is:
>    int const myNull =3D 0 ;
>a null pointer constant?  I had always supposed it was, but careful
>reading of the standard (=A74.10/1) says that "A null pointer constant i=
s
>an integral constant expression rvalue of integer type that evaluates to
>zero." Given the above, "myNull" is not an rvalue, and so not a null
>pointer constant.  According to other posters, most compilers, including
>Comeau, accept it; I seem to have read somewhere that Stroustrup says
>it's one somewhere as well.  On the other hand, g++ (3.4.0) rejects it,
>and the standard does say rvalue, which would seem to support g++.
>
>Am I overlooking something?  And if not, is it intentional?
>
>(Also, while I'm at it: can an integral constant expression not have
>integer type?)

If myNull is used on the right-hand side of an assignment, it is
implicitly converted to an rvalue according to 3.10, paragraph 7:
"Whenever an lvalue appears in a context where an rvalue is expected,
the lvalue is converted to an rvalue (...)". This would happen even if
myInt were not const, of course.

What is the error shown by g++ 3.4.0 and the context in which it
happens?

--
Bob Hairgrove
NoSpamPlease@Home.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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Bob Hairgrove wrote:
>
> What is the error shown by g++ 3.4.0 and the context in which it
> happens?

$ cat 0.cxx
int const myNull = 0;
void const* pv = myNull;
double* pd     = myNull;
void (*pf)()   = myNull;

$ g++ --version
g++ (GCC) 3.3.3 (cygwin special)
Copyright (C) 2003 Free Software Foundation, Inc.
[snip]

$ g++ -c 0.cxx
0.cxx:2: error: invalid conversion from `int' to `const void*'
0.cxx:3: error: invalid conversion from `int' to `double*'
0.cxx:4: error: invalid conversion from `int' to `void (*)()'
$

Same problem for "powerpc-rtems-g++ (GCC) 3.2.3". However,
it compiles without problems on g++ 2.95.4 and 3.0.4 under Linux.
I have no access to g++ 3.4.0.

Falk

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

v.Abazarov@comAcast.net ("Victor Bazarov") wrote in message
news:<XwyWc.300205$a24.171563@attbi_s03>...
> <kanze@gabi-soft.fr> wrote...
> > [..]
> > (Also, while I'm at it: can an integral constant expression not have
> > integer type?)

> It can have a char type.  It can have wchar_t type.  It can have bool
> type.  All of those are not integer, but still integral.  See 3.9.1.

   3.9.1/7:
    Types bool, char, wchar_t, and the signed and unsigned integer types
    are collectively called integral types.  A synonym for integral type
    is integer type.

I'm not 100% sur, but it doesn't seem as though enum's are integral (or
integer) types, although an integral constant expression can have an
enum type.  So this would apparently exclude such things as:

    enum { myNull } ;
    char* p = myNull ;

(Some compilers accept it, others reject it.)

--
James Kanze           GABI Software         http://www.gabi-soft.fr
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Tue, 24 Aug 2004 20:08:41 GMT, falk.tannhauser@crf.canon.fr (Falk
Tannh=E4user) wrote:

>Bob Hairgrove wrote:
>>=20
>> What is the error shown by g++ 3.4.0 and the context in which it
>> happens?
>
>$ cat 0.cxx
>int const myNull =3D 0;
>void const* pv =3D myNull;
>double* pd     =3D myNull;
>void (*pf)()   =3D myNull;
>
>$ g++ --version
>g++ (GCC) 3.3.3 (cygwin special)
>Copyright (C) 2003 Free Software Foundation, Inc.
>[snip]
>
>$ g++ -c 0.cxx
>0.cxx:2: error: invalid conversion from `int' to `const void*'
>0.cxx:3: error: invalid conversion from `int' to `double*'
>0.cxx:4: error: invalid conversion from `int' to `void (*)()'
>$=20
>
>Same problem for "powerpc-rtems-g++ (GCC) 3.2.3". However,
>it compiles without problems on g++ 2.95.4 and 3.0.4 under Linux.
>I have no access to g++ 3.4.0.
>
>Falk

Seems to me that this is definitely not conforming behavior according
to the current standard. "int const MyNull" is definitely a constant
integral value (see 5.9 and 4.10 of the standard), and the lvalue
should be implicitly converted to an rvalue here (see 3.10).

--
Bob Hairgrove
NoSpamPlease@Home.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://www.jamesd.demon.co.uk/csc/faq.html                       ]