Re: string literal is an lvalue; other literals are rvalues.
From: David Harmon (source_at_netcom.com)
Date: 04/12/04
- Next message: Alf P. Steinbach: "Re: Birthday Problem"
- Previous message: David Harmon: "Re: Birthday Problem"
- In reply to: Steven T. Hatton: "Re: string literal is an lvalue; other literals are rvalues."
- Next in thread: Steven T. Hatton: "Re: string literal is an lvalue; other literals are rvalues."
- Reply: Steven T. Hatton: "Re: string literal is an lvalue; other literals are rvalues."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 12 Apr 2004 19:03:52 GMT
On Mon, 12 Apr 2004 10:58:47 -0400 in comp.lang.c++, "Steven T. Hatton"
<susudata@setidava.kushan.aa> wrote,
>If I have a literal 5 in my source code it begins life as an ascii
>character.
That may be, but there is no requirement in C++ that the source
character set in which your program is written is ASCII. The C++
standard turns backflips to ensure that it does not specify more than is
necessary for a proper implementation of C++, and thereby impose
unnecessary restrictions on portability and efficiency. If you wish to
think about standard portable C++, you must likewise abandon many
assumptions about implementation.
A good one to start with is guesswork about what things do or do not
occupy what memory. Especially consts and temporaries.
>E.g.,
>
>const int x = 5 * 125; // 5 is consumed and forgotten
5 is neither consumed nor forgotten. 5 is eternal and unchanging.
The 5 you know is the same one Euclid knew.
But, C++ requires that the above has the same effect as
const int x = 625;
>const int y = 5; // 5 lives a long and significant life
No, you are thinking of the lifetime of y. y is "alive" in whatever
part of your program that declaration is visible. But y might never
occupy run-time memory, if the generated code has no need to make it do
so, ie. if you never take the address of y.
>int f(const int& n){
> return 5 * n; // 5 has to stick around in the shadows somewhere
>}
This might possibly for instance be implemented by something resembling
return (n << 2) + n;
>I will grant that I know of no way to specify the location of 5 in the
>functon f above, but it has to have some kind of representaton in runtime
>storage.
I suppose the representation of 5 in runtime storage in ((n << 2) + n)
is implicit in the sequence of some machine instructions in the
generated code. It certainly does not _have to_ correspond to a
location in memory with the value 5 in it, it is a rvalue.
Is that what you are trying to say?
- Next message: Alf P. Steinbach: "Re: Birthday Problem"
- Previous message: David Harmon: "Re: Birthday Problem"
- In reply to: Steven T. Hatton: "Re: string literal is an lvalue; other literals are rvalues."
- Next in thread: Steven T. Hatton: "Re: string literal is an lvalue; other literals are rvalues."
- Reply: Steven T. Hatton: "Re: string literal is an lvalue; other literals are rvalues."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|