Re: Are literals objects?
On Apr 6, 12:04 pm, "Alf P. Steinbach" <a...@start.no> wrote:
* James Kanze:
On Apr 6, 4:27 am, "Alf P. Steinbach" <a...@start.no> wrote:
[...]
On the other hand, the literal 7, if used in a program, might not even
exist in the machine code, because the compiler might generate machine
code that produces the same effect as using the number would have had.
Formally, that's true for objects as well.
Not really, no: with regard to what I intended to convey, you're
confusing existential quantifier with universal quantifier.
If you start using that kind of language, I will be confused.
All I meant to say is that the compiler can eliminate objects
(i.e. they won't exist in the machine code) if doing so has no
effect on the observable behavior of the program. Referring to
machine code isn't really an appropriate way to discuss what the
standard says, unless the machine in question is the abstract
machine referred to in =A71.9/1 (in which case, I don't think you
can talk about machine code).
[snip]
According to the standard, string literals are objects, and
other literals aren't.
Chapter & verse for the "other literals arent't", please.
=A75.1 and =A73.10. According to =A75.1/2, "A string literal is an
lvalue; all other literals are rvalues." And =A73.10/1 says that
"An lvalue refers to an object or function. Some rvalue
expressions---those of (possibly cv-qualified) class or array
type---also refer to objects."
And where it doesn't matter, it depends much on the compiler.
The standard defines very clearly what it means by object.
No, it doesn't define the notion of object clearly, at all.
First, the general definition of object lists the ways to create objects
as definitions, new-expressions and temporaries, which would exclude
string literals, which have static storage duration.
Second, it doesn't define "region" and is a bit inconsistent with regard
to how scattered in bits & pieces an object may be. Instead of simply
and clearly defining "region" as a contiguous sequence of bytes, and
adding suitable wording to the definition of object, it attempts to use
the usual meaning of "region" in general but hold the door open for
non-contiguous region. It's very, very, very silly & unclear.
I don't know. It seems clear to me. Clearer than most things
in the standard, anyway. (And it obviously has to hold the door
open for non-contiguous regions, since sub-objects are objects,
and a sub-object which contains a virtual base class will
typically not be contiguous.)
It
also states explicitly that lvalues designate objects, and
rvalues don't, unless they have class type.
That seems to contradict earlier statement of string literals as object;
consider
int main() { &"Hello"; }
I'm just noting the apparent contradiction.
Regarding whether the code above /should/ compile, Comeau accepts it.
I fail to see where the problem is. String literals are
objects. They are also lvalues. They most definitly occupy a
region of storage. And you can certainly take their address.
Where is any contradiction, apparent or real?
It also states that
when binding an rvalue to a const reference, the compiler
creates a temporary object with the correct value (and that
attempting to modify that temporary object, except for mutable
fields in an object of class type, is undefined behavior).
Well, "creates a temporary": ITYM "any number of temporaries".
It must create a (one) temporary. Depending on the context, I
guess, it might create more.
But as I
understand it that rule will be changed in C++0x to allow temporaries of
class with no copy constructor to be passed to reference to const formal
argument. Which is generally nice.
Agreed, sort of... I do want it made clear that this means that
enclosing objects will also have their lifetime extended:
struct A {} ;
struct B { A a ; } ;
B f() ;
A const& refA = f().a ;
I forget the details right now (and it's late, and I don't feel
like looking them up), but in the current standard, it's either
unclear whether the lifetime of the temporary B object returned
from f is extended, or (which is what I recall), it is
positively forbidden to extend the lifetime of the B object. If
A does not have a copy constructor, and no copy is allowed, it
becomes necessary to extend the lifetime of the B object
returned by f().
(FWIW: I can't think of a realistic case where it would matter.
But a standard should be precise in such matters.)
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34