In article <20011010134539.22175.00000361@nso-mf.aol.com>,
transwarpt@aol.com (TransWarpT) wrote:
>... I have to ask what a system specific data structure has to do with
>references, or C++ in general?

I think you came into the discussions a little late:

In C++, a reference to a reference is treated as though it was a single
reference.

Then I discussed a runtime model in which by a "runtime reference" is
meant a method by which a runtime object can be accessed. Examples of such
runtime references are various OS links, like UNIX hard and soft links,
and MacOS "Finder" aliases. Then MacOS "Finder" aliases behave as C++
language references in the sense that a "reference to a reference" is
resolved to a single "reference". But this would not be true for say a
UNIX soft link.

I remarked that when passing to runtime objects and runtime references
then, it seems necessary to classify different types of references, being
similar to a C++ base class ref<T> with various derived classes
corresponding to different types of references. (Even though the
definition of "runtime reference" that I gave is more general than what is
attainable by the implementation of C++ classes.)

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <20011010134539.22175.00000361@nso-mf.aol.com>,
TransWarpT <transwarpt@aol.com> wrote:
>In article <remove.haberg-0610011345200001@du179-226.ppp.su-anst.tninet.se>,
>remove.haberg@matematik.su.se (Hans Aberg) wrote:
>>In article <20011005160648.18744.00000595@nso-cv.aol.com>,
>>transwarpt@aol.com (TransWarpT) wrote:
>>>When, prior to C99, did C have references?
>>
>>You seem to know it, right?
>>
>>--Then all problems with references is purely due to the C++ committee,
>>then
>
>I believe they were added to the language before standardization began.
>And I don't consider references to have "problems". But yes!

I think some clarification is necessary:  If we're talking
about something like "int &r", then C never had them,
not prior to C99, in C99, or since C99.   C++ of course
had them before it was standardized.
--
Greg Comeau         export ETA: December
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <9q8i2l$n4e$1@glue.ucr.edu>, thp@cs.ucr.edu wrote:
>: The connection with the C++ standard is that, first, BS announced (see
>: first post in the subject "C++0x" thread in this newsgroup) that should
>: support programming for distributed systems.
>
>What does "that" refer to?  I.e., what should support programming for
>distributed dystems?

The C++ standard. (The best way is probably to use say
http://www.dejanews.com to check the "C++0x" itself.)

>: And as it produces better support for producing runtime objects,
>
>What does "it" refer to?

The C++ standard.

>: it becomes necessary to have a  better model for such runtime objects.
>
>What does "such" refer to?

Those used in distributed and other types of dynamic programming.

>: So therefore I supplied input about my runtime model, as I think it will
>: work in a distributed system, even though I do not know what a C++ version
>: would look like.
>
>Normally, I would expect a model of computation to transcend the
>various languages that might get translated to it rather than having a
>version for each.

Of course, this is how I developed my ideas, but for optimization reasons
and other practical concerns, that may not be the case of a language like
C++.

>: I think that one will hit these type of questions when developing the
>: C++ standard,
>
>To what does "these" refer?

Those discussed in this thread in a dynamic setting.

>: even if one help dynamic programming such as introducing support for
>: implementing GC's.
>
>What does GC have to do with "dynamic programming"?

A conservative GC keeps track of dynamic references (or "bindings").

>To the following post:
...
>You replied:
...
>Are you claiming that I erroneously ...

Sorry, I am not into this kind of polemics. :-)

>Are you claiming that I erroneously interpreted you to say that the
>value of a literal must be represented by a runtime entity having an
>address?

But my runtime model does not deal with any language constructs as such
(except that common language constructs may have runtime analogues), and I
pointed out very clearly that a computer language in general and C++ in
particular need not translate any of its constructs into runtime object.

How you interpret it and questions of erroneousability is really up to you.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Hans Aberg" <remove.haberg@matematik.su.se> wrote in message
news:remove.haberg-3009011512410001@du128-226.ppp.su-anst.tninet.se...
> Also note that when using dynamic bindings, some uses of syntactic
> reference constructs in C++ become redundant: For example,
>   int x = 5;
>   int& y = x;
> In C++, this means that "y is a reference to x", and that "x has the value
> 5" or something. However, with dynamic bindings in place, one could let
> the assignment "=" mean "another reference. Then one would instead write
>   int x = 5;
>   int y = x; // Another reference to the object 5.
> If one would want to have an independent copy of 5, then one would have to
write
>   int z = clone(5);
>
> Strictly speaking, as cloning is sometimes faster than handing over a
> reference, I decided that
>   w = x;
> should mean that w is bound to a "copy" of the reference that x references
> to. Then, by a "copy" is meant either a clone (state independent copy) or
> a reference (address to the same object) in a manner determined by the
> object by which the assignment "=" refers to. So in the case of an "int",
> "copy" would probably mean to clone, whereas for a file, it would probably
> mean to hand over a reference (even though files can be cloned).
>
> If in addition references can be treated as objects, then if one want to
> have another reference to a file, one might perhaps write
>   ifstream u;
>   reference v;
>   ...
>   v = reference(u);
> This would mean that a reference object of the file u is created, and then
> this is assigned to v. The reference object may then be cloned or handed
> over as a reference by the "=" depending on how the "reference" objects
> are implemented, but in the end, v will reference the same file as u.
>
> On the other hand,
>   ifstream u;
>   ifstream w;
>   w = u;
> may either mean (depending on the semantic model chosen for files) that w
> is a reference to the same file as v or a clone. For files, the former
> seems to be more prudent, and one would have to write
>   w = clone(v);
> in order to get a state independent copy.
>

Well, is this thread isn't long enough, here's some more (but on a different
aspect)...


For years now, I've had this idea of  "Copy/Take/Share" as the 3 options for
assignment '='.
It seems most people pick one of these 3 when overriding operator=().

eg. the usual case being a class that contains a pointer to something:

"Copy" allocates new memory for a new thing and copies it in
operator=(const Foo &foo)
{
    if (ptr_t) delete ptr_t; // etc, blah, blah
    ptr_t = new T;
    *ptr_t = *foo.ptr_t;
    //or something like that, I'm sure I screwed up the syntax, but you get
the idea
}

"Take" - the example for this would be how auto_ptr implements '=' - the lhs
_takes_ the pointer away from the rhs, the rhs no longer owns it. (rhs does
a release.)

"Share" would have both pointers pointing to the same memory (and hopefully
doing reference counting, etc).
(you can actually go further and have "Share-ReadOnly", "Share-ReadWrite",
"CopyOnWrite", but anyhow....)

to translate to your terms:
"clone" is  "Copy"
"reference" is "Share"
and (I guess?) "=" is "Take"

So here's my big point:

I've often played around with the idea of having 3 different '=' symbols.
(Similar to the way that C was smart enough to have 2 different symbols for
'=' and '==', whereas some languages don't.)

like ':=' means copy, etc.  Whatever, make up something.  But at least I
could look at some code and know what the assignment was doing without
having to find out which way the class decided to implement '='.  I mean,
according to good design, I shouldn't have to look up how they did '+' - it
should work like expected.  But '=' is somewhat ambiguous (IMO, of course).

Obviously this is an incomplete idea, but I offer it up to the powers that
be, nonetheless :-)


---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <2dxy7.5133$PA.613651@news20.bellglobal.com>, "Gottlob Frege"
<gottlobfrege@hotmail.com> wrote:
>"Copy" allocates new memory for a new thing and copies it in
>operator=(const Foo &foo)
...
>"Take" - the example for this would be how auto_ptr implements '=' - the lhs
>_takes_ the pointer away from the rhs, the rhs no longer owns it. (rhs does
>a release.)
...
>"Share" would have both pointers pointing to the same memory (and hopefully
>doing reference counting, etc).
...
>to translate to your terms:
>"clone" is  "Copy"
>"reference" is "Share"
>and (I guess?) "=" is "Take"

The way I classified it, is that there is an operation (or request to the
object) "reference" that all objects have. Some object have an operation
"clone" which produces a state independent copy; some objects may not have
it, so that one have to throw an exception in a runtime system if one
tries to clone such an object.

In addition, I introduced an operation "copy" which for each object is a
choice between the two. This choice will depend on how one is used to
manipulate the object: For example, a file can be cloned, but the normal
thing is to only work with a reference to the same file copy. So for a
file, one would probably set "copy" to "reference".

For objects that have a "clone" also seem to be a correlation between
"pure" and "mutative" operators: For every mutative operator m, one can
get a corresponding pure operator by first cloning the object, and then
apply m to that. This way one get mutative-pure (m, p) operator pairs.

Then "=" and "clone" are somehow fundamental to this: "=" is fundamental
in telling how objects should be mutated, and "clone" how one should
attain a state independent copy (dynamic copy constructor).

As for your "Take", it seems to be just a way to keep track of runtime
references: With a conservative GC in place, there would be no need to
keep track of who owns a reference (as the GC does that for you). So I
think that "Take" operation will only fall away.

>I've often played around with the idea of having 3 different '=' symbols.
>(Similar to the way that C was smart enough to have 2 different symbols for
>'=' and '==', whereas some languages don't.)

So I ended up with the operations "=" and "copy" which are the ones that
one would normally use, as the seems to define a runtime objects expected
behavior, and the "reference" and "clone" for specialty uses.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

<thp@cs.ucr.edu> wrote in message news:9pl2v9$h2l$1@glue.ucr.edu...
> : It can't return a value, because then it would be universally unique,
> : and could never be equal to any other 2 stored on the computer.

> Huh?  Two instances of the same bit pattern can be tested for equality
> without regard to the what those patterns represent.

Maybe; but how a sense has that, if the represenation does not exist?
In this case talking about "representation" and "bit pattern" is
nonsenseous.

> Functions return
> values by setting a given register per the bit pattern that represents
> that value.

Does the standard tell anything about "setting bit pattern" and
representations
of the *values* returned by the functions? How about the inline-called
functions,
which are not truely called and their returned values will be used in the
simplified expression and could not exist in the program run-time, because
this value is used only by the compiler in the mediate calculations?
You are too strongly bound to the assembly aspects of C++ program code.
The value has its representation only in case it IS an object. The value
itself never has any representation. The value *could be* taken from
the representation, but equally could not be present in any place in
the executable and its memory segments at running.

> The pattern in that register will test equal to instances
> of the same pattern in other registers.

If the equality-comparation is required, this '2' is translated to a
representation.
But this is an implementation detail. You can also translate both the
representation
and this '2' to another form and compare them as they are after this. This
also
will be proper.

--
Regards,
((
 ))



---
[ 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.research.att.com/~austern/csc/faq.html                ]

Barry Kelly <dynagen@eircom.net> wrote:
: I'm not going to respond to any responses to this message because I
: feel the discussion has reached the end of its useful life. However,
: there are a couple of points I'm going to make a final attempt to make
: clear.

: In article <9pl2v9$h2l$1@glue.ucr.edu>
:  thp@cs.ucr.edu wrote:
[...]
:> The number three is a perfectly good mathematical entity capable of
:> being represented by a bit pattern

: You've completely missed my point. '11' base 2 is not the number 3.
: The arabic numeral '3' is not the number 3. An encoding of the number
: 3, in any numerical base or intelligible format whatsoever, is *not*
: the number 3.

: They are all references to an idea.

It seems to me that they are encodings of an integer.

: The only purpose in pointing this out is to observe the chain of
: references implicit in C++, so that when the C++ jargon noun
: "reference" comes up we may have an improved vocabulary with which to
: make semantics clear.

You have posted in a forum dedicated to discussion of the C++
Standard.  In many technical forums, everyday terms acquire technical
meanings that are only vaguely or perhaps inconsistently defined.  It
can be helpful to try to clarify such notions.  It is not helpful to
insist on using them with their everyday meanings in such forums, and
to dismiss technical usage as jargon.

: As I said, you've failed to see my point. We aren't getting anywhere,
: so I've given up.
[...]
:> Huh?  Two instances of the same bit pattern can be tested for equality
:> without regard to the what those patterns represent.

: This isn't true in general for computer representation of numbers,
: because it's implementation dependant - you're aware of the +0 and -0
: disparity, for example.
[...]
: Again, when we are comparing, we are comparing what the bit patterns
: represent, not the bit patterns themselves.

In any resonable enconding of the integers there should be an algorithmic
process for comparing representation for equality of value.

Tom Payne



















---
[ 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.research.att.com/~austern/csc/faq.html                ]

remove.haberg@matematik.su.se (Hans Aberg) writes:

[...]

> >The integer three is a value.  So, what's its address in any context?  AFIK,
> >the experssion &3 is ill formed in C/C++.
>
> You need to separate out language constructs that have a runtime
> representation from those that do not:
>
> If "3" has a runtime representation, clearly it has an address, as it must
> be located somewhere in the computer.

No. If any object (say, an int object) has the value 3, then the
representation of the value 3 is stored at the address of the
object. But the value 3 as well as it's representation in a given type
is independent of any object having that value. For example, in a
8-bit char, the value 3 has the representation 00000011 even if
there's currently no variable with that value, this value is used
nowhere in the program, and no memory cell or register currently
contains that value. The runtime representation of 3 in type char,
00000011, therefore has no address, and doesn't need any address. Only
objects have addresses (and of course also some other things like
functions), and the object having a value means that the
representation of the value is stored at the address of the object.

Note that the fact that the value 3 is used in a program doesn't mean
that the runtime representation of 3 must appear anywhere in the code.

For example, a compiler for 16-bit x86 could compile the code

int a = 0, b = 1, c = 2, d = 3;

into

   xor ax, ax
   mov a, ax
   inc ac
   mov b, ax
   inc ax
   mov c, ax
   inc ax
   mov d, ax

and now the "representation of 3" is the fact that a value xor itsef
always gives zero, and the fact that between zeroing ax in the first
command and storing the value in d there are three increments done.

Now in a situation like

  int f()

the compiler surely will have to store the return value somewhere,
i.e. it will have to create a temporary object (most probably in a
register in this case), where the return value is stored. For objects
with member functions, you can access this temporary object directly
through the this pointer of the member function; for PODs without
members, the object itself is not accessible, but only it's value
(which itself has no address).

The concepts involved are:

- Value: Some abstract thing from the problem domain (e.g. an integral
  number).

- Representation: Some bit pattern, which is interpreted as a certain
  value. A representation always has a certain size. The same value
  may have many representations (f.ex. the char representation of the
  value -1 is typically different from the int representation of the
  value -1; also in one's-complement and sign-magnitude implementations,
  there are two representations for the value 0 even for the same type).

- Type: Mapping between values and representations. Under C++, all
  representations of one type have the same size. Each representation
  must map to exactly one value, but different representations may
  map to the same value.

- Object: Area of memory to be interpreted as representation of a value
  of a given type. An object, being an area of memory, has a certain
  address.

- Reference: Generally something which allows direct access to an
  object. This general case is called "lvalue" in C++. The term
  "reference" in C++ is restricted to explicitly declared (with "&")
  named references which are initialized with other lvalues (or, in
  the case of references to const, with rvalues) and cannot be
  reseated (made to refer to other objects) during their lifetime.

[...]

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Sun,  7 Oct 2001 16:39:54 CST, Sektor van Skijlen <sektor@spam-buffer.ald=
ec.com> pisze:

>>> C++ has a richer structure. Until you understand that C++ references =
are
>>> not hidden pointers (even though they can be implemented that way) bu=
t
>>> aliases for possibly already named objects you will continue to sow
>>> confusion in your thoughts.
>=20
>>What is the difference between "hidden pointer" and "alias"?
>=20
> For example, one could treat an alias being bound to the name of
> the variable or any way to access the object present at this alias
> initialization. For example:
>=20
> #define y (*(x))

Francis said that C++ references are aliases, not hidden pointers.
So he didn't mean this because references don't work that way.
I have no idea what he meant.

> Or there should be either more optimizations for constant poitners allo=
wed
> or more optimization restrictions for references.

I don't see a difference between optimizations allowed in these cases.
The only optimizations opportunities I am aware of result from lack
of reference equivalent of the null pointer.

> First the references can RETURN pointers and can GIVE pointes, so
> they also HAVE their appropriate pointers, but can't BE pointers. The
> main reason is that they are only the language term, which should
> not have any run-time meaning, which is true for pointers instead.

Sorry, I don't understand this. Surely references are distinguishable
from pointers; and surely a possible (and natural) implementation
can represent both in the same way.

>> Doesn't matter that there is no reference equivalent of the
>>null pointer
>=20
> WHAT?
> The reference is to an *object*. There is no sense to talk about the
> reference made from the non-dereferenceable pointer value.

That's almost what I said. But not as "there is no sense", but as "C++
chose to define it that way". It would be very easy to define C++
such that it made sense, and very easy for current implementations
to adapt to this.

You could as well say that a pointer can't point at no object, that
it makes no sense... Well, we have null pointers. If you can imagine
them, you can imagine hypothetical null references as well.

References are very *similar* to pointers. It's easier to list
differences than to define them independently from scratch.

--=20
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZAST=CAPCZA
QRCZAK

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Marcin 'Qrczak' Kowalczyk <qrczak@knm.org.pl> wrote:
: Sun,  7 Oct 2001 16:39:54 CST, Sektor van Skijlen <sektor@spam-buffer.aldec.com> pisze:

:>>> C++ has a richer structure. Until you understand that C++ references are
:>>> not hidden pointers (even though they can be implemented that way) but
:>>> aliases for possibly already named objects you will continue to sow
:>>> confusion in your thoughts.
:>
:>>What is the difference between "hidden pointer" and "alias"?
:>
:> For example, one could treat an alias being bound to the name of
:> the variable or any way to access the object present at this alias
:> initialization. For example:
:>
:> #define y (*(x))

: Francis said that C++ references are aliases,

Alias for what??  In the function  int& f(){ return *new int; }  the
reference returned by f() is not an alias for anything; rather, it is
the only grasp the program has on the new int.

: not hidden pointers.

"Hidden pointers"??  References are *essentially* equivalent to
"automatically dereferenced" pointers, i.e., pointers that undergo
reference-to-referent conversion at all occurrences (after
declaration).

: So he didn't mean this because references don't work that way.
: I have no idea what he meant.

Me either.

:> Or there should be either more optimizations for constant poitners allowed
:> or more optimization restrictions for references.

: I don't see a difference between optimizations allowed in these cases.
: The only optimizations opportunities I am aware of result from lack
: of reference equivalent of the null pointer.

More specifically, references are (de facto) const.  But const
pointers are subject to the same optimizations under the same
circumstances as references, namely the circumstances where their
referents are able to be determined at compile time.

:> First the references can RETURN pointers and can GIVE pointes, so
:> they also HAVE their appropriate pointers, but can't BE pointers. The
:> main reason is that they are only the language term, which should
:> not have any run-time meaning, which is true for pointers instead.

: Sorry, I don't understand this. Surely references are distinguishable
: from pointers; and surely a possible (and natural) implementation
: can represent both in the same way.

It is natural (but not necessary) to implement both via addresses and
to optimize wherever those addresses are known at compile time.

Tom Payne

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <slrn9s3pb8.6gg.qrczak@qrnik.zagroda>, Marcin 'Qrczak'
Kowalczyk <qrczak@knm.org.pl> writes
>Francis said that C++ references are aliases, not hidden pointers.
>So he didn't mean this because references don't work that way.
>I have no idea what he meant.

It is very hard to pin down exactly the differences between C++ and Java
in regards to 'reference'. In Java all UDT (i.e. class and array as
opposed to builtin ) variables are simply type IDs that have to be
initialised either to null or to a dynamically created anonymous object
of an acceptable type (has to include derived types and those that
implement interfaces).

C++ allows two main categories of object:

static/auto that have IDs and whose lifetime is the responsibility of
the compiler.

dynamic/temp that have no (known to the programmer) ID. dynamic objects
have a lifetime that is the responsibility of the programmer and temps
have a strictly defined lifetime. Unfortunately for our sanity, access
to dynamic objects is provided through a pointer, while we can bind
temps to const references. This makes talking about C++ references
rather difficult. This is compounded by the ability to return a
reference from a function which will be nameless (though it better be
bound to a name, either because it is a reference to a named object or
because the return value is itself bound to a name. references that fail
to be bound to a name by one of these two methods are strong indicators
of resource leaks.

Now the most important distinction between a plain type and a reference
type is that the former have dtors (at least conceptually) whilst the
latter do not. However both bind to an underlying object for their
lifetime (of the ID). This strong binding is important and contrasts
with the weak binding of Java IDs to objects which is more like the
binding between pointers and objects in C++.

Russell, Hoffstader (sorry, I think that is misspelt) et al. would warn
us of the dangers of mixing meta-levels in discussions. I think that
this thread is a good example. There is a sense in which values are
abstractions (twoness, threeness etc.) and the symbols we use are merely
references to these abstractions, but I do not find introducing such
meta concepts helpful in discussing C++ unless some form of
disambiguation (between meta-meanings) is introduced.


Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Tue,  9 Oct 2001 09:35:54 GMT, Francis Glassborow <francis.glassborow@ntl=
world.com> pisze:

> It is very hard to pin down exactly the differences between C++
> and Java in regards to 'reference'.

No, it's very easy. Java reference is similar to C++ pointer.
More similar to C++ pointer than to C++ reference - here is why.

Differences are in the syntax, that Java objects are automatically
destroyed when nothing refers to them, and that you don't have
operations like pointer arithmetic or reinterpret_cast.

In particular you can rebind a Java reference to another object and
you can rebind a C++ non-const pointer, but you can't rebind a C++
const pointer or C++ reference.

A Java reference can be null, like C++ pointer, unlike C++ reference.

> Now the most important distinction between a plain type and a
> reference type is that the former have dtors (at least conceptually)
> whilst the latter do not.

Well, it's because a reference just refers to an object which exist
by some other means. So of course there is nothing to destruct in
the case of a reference - just like in the case of a pointer.

A C++ reference is more similar to a pointer than to the object it
refers to. In particular it doesn't influence the lifetime of the
said object (with some exceptions when it's bound to a temporary)
and can be left dangling where the object is destroyed earlier.

I still don't know what do you mean by the statement that references
are more aliases than hidden pointers.

--=20
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZAST=CAPCZA
QRCZAK

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <9pre41$hfc$2@glue.ucr.edu>, thp@cs.ucr.edu wrote:

>You have claimed that values used in computations must have addresses.

No. I claimed that runtime objects must have addresses, otherwise they
cannot be accessed.

I think you by "value" mean some kind of language construct; what do you
mean by a "value", and what is its runtime model?

>But it is possible that conforming implemetations of C++ implement
>multiplication via non-contiguous sequences of shifts and adds.  I
>asked you where's the multiplier in such a case and you have evaded
>the question by answering that "the bit shift has to be located
>somewhere."

Once upon the time, a long time again, in the beginning of this thread, I
pointed out that language constructs may not have direct runtime
translations. For example the numbers in a conditional preprocessor
directive, or the those a part of a const C++ expression may not have such
translation.

But the runtime objects that one bothers translate must have such
addresses, otherwise they cannot be accessed.

So in the case above you are free to take the view that the multiplier has
no address, and the object you have created with an address is the one
that performs the whole multiplication.

There is not requirement that C++ always provides a runtime reference by
what I have said, even if the syntax is such that a runtime reference cane
be provided at need when called for, because that is question of how a
language translates into a runtime model. For example, (just hypothetical,
in order to illustrated the idea) one might have a syntax
    int& k = 3;
    int n = 0;
    n += 3;
    ...
    f(k);
Now if "f(k)" is not present, one may optimize away any runtime reference
to "3", but if it is present that it may not be the case.

But in both cases the runtime objects that one do bother translate into
will have runtime references, or they cannot be accessed. In the example,
if one does not do any further optimizations, the "n += 3" instruction
will have an address, and the "3" will have an address if it is
implemented as a runtime object.

I do not impose any condition on how small an atom object: You could
decide that only the whole function should be an atom. But then it will
have a reference, otherwise it cannot be runtime accessed.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Sektor van Skijlen <sektor@spam-buffer.aldec.com> wrote:

: <thp@cs.ucr.edu> wrote in message news:9pl2v9$h2l$1@glue.ucr.edu...
:> : It can't return a value, because then it would be universally unique,
:> : and could never be equal to any other 2 stored on the computer.
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

:> Huh?  Two instances of the same bit pattern can be tested for equality
:> without regard to the what those patterns represent.

: Maybe; but how a sense has that, if the represenation does not exist?
: In this case talking about "representation" and "bit pattern" is
: nonsenseous.

The integer two is a unique number, and it doesn't inhabit computer
storage.  So when Barry mentioned multiple instances of "2 stored on
the computer", I presume he was talking about multiple instances of
some computer representation for 2.

:> Functions return values by setting a given register per the bit pattern
:> that represents that value.

: Does the standard tell anything about "setting bit pattern" and
: representations of the *values* returned by the functions?

Of course not, but I'm replying to someone who says that, contrary to
the specification in the Standard, a function
  "can't return a value, because then it would be universally unique,
   and could never be equal to any other 2 stored on the computer."
To show that it can return a value, which can be compared to other
values, I have noted how this is don't in the most elementary
implementations.  I've made no claim that the Standard mandates this
implementation and/or that other implementations are not possible.

: How about the inline-called functions,
: which are not truely called and their returned values will be used in the
: simplified expression and could not exist in the program run-time, because
: this value is used only by the compiler in the mediate calculations?

How about them?

[...]
: The value has its representation only in case it IS an object.

Under the terminology of the Standard, each object HAS a value but is
not a value itself.  For instance, an expression can be an lvalue
(i.e., denote an object) or an rvalue (i.e., denote a value) but not
both.

: The value itself never has any representation.

How did you come up with that?

[...]
:> The pattern in that register will test equal to instances
:> of the same pattern in other registers.

: If the equality-comparation is required, this '2' is translated to a
: representation.
: But this is an implementation detail. You can also translate both the
: representation
: and this '2' to another form and compare them as they are after this. This
: also will be proper.

There are many ways to implement a program.  The point is that it is
possible to implement a function in such a way that, contrary to
Barry's claim, it can return a value and that value can be compared
for equality the value of other expressions.

Tom Payne





---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <9psg1f$5ru$1@news.tuwien.ac.at>, Christopher Eltschka
<celtschk@web.de> wrote:
>> If "3" has a runtime representation, clearly it has an address, as it must
>> be located somewhere in the computer.
>
>No. If any object (say, an int object) has the value 3, then the
>representation of the value 3 is stored at the address of the
>object. But the value 3 as well as it's representation in a given type
>is independent of any object having that value. For example, in a
>8-bit char, the value 3 has the representation 00000011 even if
>there's currently no variable with that value, this value is used
>nowhere in the program, and no memory cell or register currently
>contains that value. The runtime representation of 3 in type char,
>00000011, therefore has no address, and doesn't need any address.

You speak about an entirely different problem, namely how language
constructs should be translated into runtime objects. In C++, the
translation of "3" is ambiguous, because even when it is translated into a
runtime object, its type may vary.

Strictly speaking there is nothing like a runtime object "3" in the
typical C++ translation, but only a binary object; then that binary object
has an address (if has been translated into a runtime object, and not
optimized away).

If one should make it valid to speak about a runtime object "3", then also
its type should be made accessible, and the runtime object is the bit
pattern of "3" together with the information of its type. Then those
pieces of information need not be runtime available at the same location,
so I think therefore it is prudent to speak about a "reference" to the
runtime object "3" instead of an "address".

>Note that the fact that the value 3 is used in a program doesn't mean
>that the runtime representation of 3 must appear anywhere in the code.

This is also what I have pointed out: Runtime object must have runtime
references, but a computer language may or may not translate its language
constructs (or language "objects") into runtime objects.

>For example, a compiler for 16-bit x86 could compile the code
>
>int a = 0, b = 1, c = 2, d = 3;
>
>into
>
>   xor ax, ax
>   mov a, ax
>   inc ac
>   mov b, ax
>   inc ax
>   mov c, ax
>   inc ax
>   mov d, ax
>
>and now the "representation of 3" is the fact that a value xor itsef
>always gives zero, and the fact that between zeroing ax in the first
>command and storing the value in d there are three increments done.

In this case you have created a runtime object which makes use of a number
"3" internally. I do not have any requirements that the subparts of such
an object should be accessible. It is atomic, and in my model, the idea is
that atom objects should be examinable from the outside only, even though
in this case the code can be examined by a disassembler. But it perfectly
OK to me to not allow such examinations: A runtime "object" could be a
reference to another computer or a human for some binary information,
where that is not possible.

You could construct such examples also by
  int n = 3 + 4;
In this case, the compiler is allowed to first compute 3 + 4, and the code
will not contain a number "3" in any runtime representation.

>Now in a situation like
>
>  int f()
>
>the compiler surely will have to store the return value somewhere,
>i.e. it will have to create a temporary object (most probably in a
>register in this case), where the return value is stored. For objects
>with member functions, you can access this temporary object directly
>through the this pointer of the member function; for PODs without
>members, the object itself is not accessible, but only it's value
>(which itself has no address).

The view I would take on this is that (if f is not optimized away, as it
may), one creates a runtime object corresponding to f. In an application,
this runtime object is provided with a reference to its argument
(typically at the pointer on the parameter stack), plus the information
that it should execute. When the runtime object corresponding to f has
finished computing, it return a reference to an object (typically a
pointer on the parameter stack), the return value.

>The concepts involved are:
>
>- Value: Some abstract thing from the problem domain (e.g. an integral
>  number).

This is the language notion of "value". When I wanted to make a runtime
definition of a value, it is a runtime object that copies itself by
cloning, it seems.

So when the C++ function f returns a "value", the runtime object
corresponding to f returns a runtime reference to an object that is copied
by cloning. But when the C++ function returns a reference, the runtime
object corresponding to f returns a runtime reference to an object which
in the copyiing process merely constuties a reference to the original
object. (Unless the compiler is somehow able to avoid copying, thereby
optimizing it away.)

>- Representation: Some bit pattern, which is interpreted as a certain
>  value. A representation always has a certain size. The same value
>  may have many representations (f.ex. the char representation of the
>  value -1 is typically different from the int representation of the
>  value -1; also in one's-complement and sign-magnitude implementations,
>  there are two representations for the value 0 even for the same type).

So when I speak about runtime objects, then this only applies to what has
a translation into a bit pattern. Then C++ translates what it may consider
the same language value into several different runtime objects
representing different types of runtime objects.

This type of common C++ ambiguity one probably has to give a more careful
look at when strengthening the capability of C++ to create specific
runtime objects.

>- Type: Mapping between values and representations. Under C++, all
>  representations of one type have the same size. Each representation
>  must map to exactly one value, but different representations may
>  map to the same value.

Again this is the language definition of a (C++ or constant) type: In
traditional C/C++, all type information is thrown away in the translation
into a runtime model, as to create only binary objects, with no runtime
type information present.

This is not completely true, as one with C++ RTTI can create typed runtime
objects. If one should speak about typed runtime object, then I require
that also such runtime type information is available.

>- Object: Area of memory to be interpreted as representation of a value
>  of a given type. An object, being an area of memory, has a certain
>  address.

Again this is the C++ language definition. For a runtime object, I defined
it to be something that can be runtime referenced and accepts references
to objects as input, and to which such an input can respond, by means of
some process, a reference to an object as output. Even though this
information is binary, there is no requirement that the process itself
leading from the input to the output is defined by binary information or a
Turing machine or something like that: It can just as well be a human
entering information from a keyboard, a measuring devise of some sort, or
something.

>- Reference: Generally something which allows direct access to an
>  object. This general case is called "lvalue" in C++. The term
>  "reference" in C++ is restricted to explicitly declared (with "&")
>  named references which are initialized with other lvalues (or, in
>  the case of references to const, with rvalues) and cannot be
>  reseated (made to refer to other objects) during their lifetime.

Again this is the C++ language definition. For runtime objects, a runtime
reference is a means by which the runtime object can be accessed. This is
pretty much the C++ definition as you word it translated into dealing only
with runtime objects. But I do not have any requirements that a runtime
reference should have the simple structure that C++ references are usually
implemented with: In fact, it is quite difficult to get the C++ references
work with a conservative GC.

As for the runtime equivalents of l-value and r-value: If one should get
what corresponds to the r-value from a runtime object, one sends the
object a "get data" request, and gets a reference to its "value". If one
should alter what corresponds to the l-value of a runtime object, one
sends it a "set data" request together with a reference to the object that
should be used for the lateration of the value. Essentially, a r-value
corresponds to a "copy" request, whereas the l-value corresponds to an
"assignment" request, then, in such a runtime model.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow <francis.glassborow@ntlworld.com> wrote:
: In article <slrn9s3pb8.6gg.qrczak@qrnik.zagroda>, Marcin 'Qrczak'
: Kowalczyk <qrczak@knm.org.pl> writes
:>Francis said that C++ references are aliases, not hidden pointers.
:>So he didn't mean this because references don't work that way.
:>I have no idea what he meant.

: It is very hard to pin down exactly the differences between C++ and Java
: in regards to 'reference'.

In C++, all occurrences of a reference-valued expression (in effect)
undergo an implicit reference-to-referent conversion.  In some other
languages -- I don't know about Java -- such conversion occurs in
(most) rvalue contexts, but not in lvalue contexts.  One consequence
is such references can be redirected, while C++ references cannot.

In these other languages there is an inevitable question about whether
references should be dereferenced before a comparison for equality,
i.e., should references compare as equal only if they have the same
referent or should they compare as equal if their referents have
equivalent values?

: In Java all UDT (i.e. class and array as
: opposed to builtin ) variables are simply type IDs that have to be
: initialised either to null or to a dynamically created anonymous object
: of an acceptable type (has to include derived types and those that
: implement interfaces).

So, all UDT objects are dynamic in Java?

: C++ allows two main categories of object:

: static/auto that have IDs and whose lifetime is the responsibility of
: the compiler.

: dynamic/temp that have no (known to the programmer) ID. dynamic objects
: have a lifetime that is the responsibility of the programmer and temps
: have a strictly defined lifetime. Unfortunately for our sanity, access
: to dynamic objects is provided through a pointer,

IMHO that is an inconsequential holdover from C.  The idiom
   T& = *newT
can be used to instantly replace the pointer with a reference.

: while we can bind
: temps to const references. This makes talking about C++ references
: rather difficult. This is compounded by the ability to return a
: reference from a function which will be nameless (though it better be
: bound to a name, either because it is a reference to a named object or
: because the return value is itself bound to a name. references that fail
: to be bound to a name by one of these two methods are strong indicators
: of resource leaks.

Nameless entities must be indirectly accessible.  By design, C++ does
not allow indirect access to references, i.e., no references to
references and no pointers to references.  A reference can, however,
be stored in a member of a nameless instance of a class.

: Now the most important distinction between a plain type and a reference
: type is that the former have dtors (at least conceptually) whilst the
: latter do not.

I don't see how references differ from say pointers in this regard.

[...]
: Russell, Hoffstader (sorry, I think that is misspelt) et al. would warn
: us of the dangers of mixing meta-levels in discussions. I think that
: this thread is a good example. There is a sense in which values are
: abstractions (twoness, threeness etc.) and the symbols we use are merely
: references to these abstractions, but I do not find introducing such
: meta concepts helpful in discussing C++ unless some form of
: disambiguation (between meta-meanings) is introduced.

One of the problems with our terminology is that much of it is
metaphorical, the term "reference" being a case in point.  By
contrast, when mathematics co-opts an everyday term (e.g., "group")
the technical meaning is usually so far from the original meaning that
nobody mistakes the notions.

FWIW, Christopher Strachey was aware of this problem and explicitly
chose to use the term "L-value" in place of "reference" in his early
paper, "Fundamental Concepts in Programming Languages."
Unfortunately, the C/C++ community as taken the term "lvalue" to mean
something that is closely related to reference but somewhat different.
(Witness the title of this thread.)

Tom Payne

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Hans Aberg <remove.haberg@matematik.su.se> wrote:
: In article <9pre41$hfc$2@glue.ucr.edu>, thp@cs.ucr.edu wrote:

:>You have claimed that values used in computations must have addresses.

: No. I claimed that runtime objects must have addresses, otherwise they
: cannot be accessed.

Let me refresh your memory:

   In article <3bbd780c$0$186$4d4ebb8e@read.news.de.uu.net>, "Raoul Gough"
   <RaoulGough@my-deja.com> wrote:
   >I can give you an example where the literal is not contained in the
   >assemblycode.
   [...]

To that you replied:

   The main point is that it must be located somewhere, so it must have
   an address.

:>But it is possible that conforming implemetations of C++ implement
:>multiplication via non-contiguous sequences of shifts and adds.  I
:>asked you where's the multiplier in such a case and you have evaded
:>the question by answering that "the bit shift has to be located
:>somewhere."

[...]
: So in the case above you are free to take the view that the
: multiplier has no address,

Even if it is a literal?  ;-)

: and the object you have created with an address is the one that
: performs the whole multiplication.

I've created no such object.  I've simply scattered some shift
instructions and some add instructions at various non-contiguous
locations throughout the translated code.

Tom Payne






---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <9pvp7v$mq$1@glue.ucr.edu>, thp@cs.ucr.edu wrote:
>Let me refresh your memory:

Isn't better that you let me refesh my memory, which I have done in more
recent posts? -- I try to explain how the ides of a this runtime model
works, and at the time the question came up, I had not been worrying over
for some time.

Your replies seem to be directed in finding that something was wrong in
the statement of this or other post a long time ago, which is frequent in
the kind of informal discussions conducted in newsgroups like this, rather
that concentratiing on the correctness of this runtime model.

>: and the object you have created with an address is the one that
>: performs the whole multiplication.
>
>I've created no such object.  I've simply scattered some shift
>instructions and some add instructions at various non-contiguous
>locations throughout the translated code.

If you do not create a runtime object, it does not have a runtime reference.

If you create a runtime object, it must have something that makes it
accessible in order to be usable; are you contesting that?

Some compiler have a feature "check syntax" in which case no object code
at all is produced. But it is still true that all runtime objects created
have a runtime reference (as none was created).

And so a computer language in general need not translate its language
features, in whole or in part, to runtime objects.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <remove.haberg-0610011345200001@du179-226.ppp.su-anst.tninet.se>,
remove.haberg@matematik.su.se (Hans Aberg) wrote:

>In article <20011005160648.18744.00000595@nso-cv.aol.com>,
>transwarpt@aol.com (TransWarpT) wrote:
>>When, prior to C99, did C have references?
>
>You seem to know it, right?
>
>-- Then all problems with references is purely due to the C++ committee, then.

I believe they were added to the language before standardization began. And I
don't consider references to have "problems". But yes!

>>>The method of always resolving a reference to a reference to a reference
>>>is used by the MacOS, where it is called an "alias": Making an alias of an
>>>alias makes it point at the original object, not the alias is was aliased
>>>to. But it is still necessary sometimes to treat the alias as an object.
>>
>>The only MacOS "alias" that I know of is a HFS construct that has nothing to
do
>>with C++. Nor is it as simple as a reference to a reference to a reference.
And
>>just because accessing the second alias produces the original file doesn't
mean
>>it didn't go through the first alias.
>
>I would not real on Mac terminology for making any other universal
>terminology. :-)

Then I have to ask what a system specific data structure has to do with
references, or C++ in general?

>But the MacOS has in its windows manager called the "Finder" a type of
>links called "aliases", that when making the alias to an alias resolves to
>the original object pointed at (but these are not UNIX hard links). (There
>are also some kind of objects in the programming level of MacOS pre-X
>called "aliases" but I do not mean those.) Thus it resolves a "reference
>to a reference" into a reference, the new alias, but is not a reference to
>a reference to a reference (perhaps you did not read the sentence
>properly).

I do not know how to read the sentence given that my knowledge of MacOS aliases
contradicts the sentence.

Orson Bushnell
TransWarp Technologies, LP.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Hans Aberg <remove.haberg@matematik.su.se> wrote:
: In article <9pvp7v$mq$1@glue.ucr.edu>, thp@cs.ucr.edu wrote:
[...]
:>: and the object you have created with an address is the one that
:>: performs the whole multiplication.
:>
:>I've created no such object.  I've simply scattered some shift
:>instructions and some add instructions at various non-contiguous
:>locations throughout the translated code.

: If you do not create a runtime object, it does not have a runtime reference.

Exactly!

: If you create a runtime object, it must have something that makes it
: accessible in order to be usable;

Right.

: Some compiler have a feature "check syntax" in which case no object code
: at all is produced.

So?

: But it is still true that all runtime objects created
: have a runtime reference (as none was created).
                 ^^^^^^^^^
By which I assume you mean memory addresses, register indices, etc.

: And so a computer language in general need not translate its language
: features, in whole or in part, to runtime objects.

An *implementation* of a programming language need only produce the
specfied run-time behavior, plus whatever diagnostics are required.

My point is that under standard technology C++ implementations can do
produce that behavior without creating a run-time object for each
value, thereby contradicting your earlier assertion that a run-time
value must be somewhere that has a run-time "reference".

Tom Payne

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Hans Aberg wrote:
> In article <20011005160648.18744.00000595@nso-cv.aol.com>,
> transwarpt@aol.com (TransWarpT) wrote:
>>When, prior to C99, did C have references?
>
> You seem to know it, right?
>
> -- Then all problems with references is purely due to the C++ committee, then.
>
>>>The method of always resolving a reference to a reference to a reference
>>>is used by the MacOS, where it is called an "alias": Making an alias of an
>>>alias makes it point at the original object, not the alias is was aliased
>>>to. But it is still necessary sometimes to treat the alias as an object.
>>
>>The only MacOS "alias" that I know of is a HFS construct that has nothing to do
>>with C++. Nor is it as simple as a reference to a reference to a reference. And
>>just because accessing the second alias produces the original file doesn't mean
>>it didn't go through the first alias.
>
> I would not real on Mac terminology for making any other universal
> terminology. :-)
>
> But the MacOS has in its windows manager called the "Finder" a type of
> links called "aliases", that when making the alias to an alias resolves to
> the original object pointed at (but these are not UNIX hard links). (There
> are also some kind of objects in the programming level of MacOS pre-X
> called "aliases" but I do not mean those.) Thus it resolves a "reference
> to a reference" into a reference, the new alias, but is not a reference to
> a reference to a reference (perhaps you did not read the sentence
> properly).

Of topic I know, but just to make some things clear:

First, the Finder is a file manager, not a window manager; the
Finder is a normal application.

Second, as a file manager, the Finder lets you manage files,
including aliases. Aliases, under the MacOS file system (HFS),
are special files that points to others files. The Finder has
an 'Alias' command to create normal HFS aliases.

Unlike Unix links, MacOS aliases have a completely confused
semantic, that apparently no one really understands, so
comparing them with C++ language concepts hardly helps to
understand C++.

To give you a basic idea, an alias points to another file both
with address (that can become stale), and by relative name and
base address, by full path... To make things even more difficult,
there are two ways to create an alias to a file.

So you probably do not want to talk about HFS aliases here
anymore.

  --   VB


======================================= MODERATOR'S COMMENT:
 This post has been allowed in the hope that it will
bring the discussion of MacOS aliases to a close; any
followups should ensure that they are clearly on-topic.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <9q26tn$nc0$1@glue.ucr.edu>, thp@cs.ucr.edu wrote:
>My point is that under standard technology C++ implementations can do
>produce that behavior without creating a run-time object for each
>value, thereby contradicting your earlier assertion that a run-time
>value must be somewhere that has a run-time "reference".

I think you are mixing up "C++ values" with the "runtime values" I described:

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Hans Aberg <remove.haberg@matematik.su.se> wrote:
: In article <9q26tn$nc0$1@glue.ucr.edu>, thp@cs.ucr.edu wrote:
:>My point is that under standard technology C++ implementations can do
:>produce that behavior without creating a run-time object for each
:>value, thereby contradicting your earlier assertion that a run-time
:>value must be somewhere that has a run-time "reference".

: I think you are mixing up "C++ values" with the "runtime values" I
: described:

I know nothing about your "runtime values."  This is a forum for the
discussion of the semantics of C++ and its specification in the C++
Standard.  My example was intended only to refute your claim that a
C++ value, e.g. the value of a literal, must be represented by a
runtime entity that has a runtime address: "It must be somewhere ..."

Tom Payne

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <9q4gkp$ddf$1@glue.ucr.edu>, thp@cs.ucr.edu wrote:
>: I think you are mixing up "C++ values" with the "runtime values" I
>: described:
>
>I know nothing about your "runtime values."

As C++ is expected to produce runtime code, it is a good idea keeping
track of what it produces.

>  This is a forum for the
>discussion of the semantics of C++ and its specification in the C++
>Standard.

The connection with the C++ standard is that, first, BS announced (see
first post in the subject "C++0x" thread in this newsgroup) that should
support programming for distributed systems. And as it produces better
support for producing runtime objects, it becomes necessary to have a
better model for such runtime objects.

So therefore I supplied input about my runtime model, as I think it will
work in a distributed system, even though I do not know what a C++ version
would look like. I think that one will hit these type of questions when
developing the C++ standard, even if one help dynamic programming such as
introducing support for implementing GC's.

>  My example was intended only to refute your claim that a
>C++ value, e.g. the value of a literal, must be represented by a
>runtime entity that has a runtime address: "It must be somewhere ..."

I pointed out that languages in general do not have to translate its
language feature (as "values") into anything at all.

So I think this is an interpretation that you attach to my posts.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Hans Aberg <remove.haberg@matematik.su.se> wrote:
: In article <9q4gkp$ddf$1@glue.ucr.edu>, thp@cs.ucr.edu wrote:
:>: I think you are mixing up "C++ values" with the "runtime values" I
:>: described:
:>
:>I know nothing about your "runtime values."

: As C++ is expected to produce runtime code, it is a good idea keeping
: track of what it produces.

Right.  But keeping track of emitted code is quite distinct from
knowing about your model.

:>  This is a forum for the
:>discussion of the semantics of C++ and its specification in the C++
:>Standard.

: The connection with the C++ standard is that, first, BS announced (see
: first post in the subject "C++0x" thread in this newsgroup) that should
: support programming for distributed systems.

What does "that" refer to?  I.e., what should support programming for
distributed dystems?

: And as it produces better support for producing runtime objects,

What does "it" refer to?

: it becomes necessary to have a  better model for such runtime objects.

What does "such" refer to?

: So therefore I supplied input about my runtime model, as I think it will
: work in a distributed system, even though I do not know what a C++ version
: would look like.

Normally, I would expect a model of computation to transcend the
various languages that might get translated to it rather than having a
version for each.

: I think that one will hit these type of questions when developing the
: C++ standard,

To what does "these" refer?

: even if one help dynamic programming such as introducing support for
: implementing GC's.

What does GC have to do with "dynamic programming"?

:>  My example was intended only to refute your claim that a
:>C++ value, e.g. the value of a literal, must be represented by a
:>runtime entity that has a runtime address: "It must be somewhere ..."

: I pointed out that languages in general do not have to translate its
: language feature (as "values") into anything at all.

: So I think this is an interpretation that you attach to my posts.

To the following post:

  Typcially, the literal is synthesised in an intermediate register, but I
  don't see that this is an absolute requirement. It would certainly be
  reckless for the C++ standard to require this.
  [...]

You replied:

  The main point is that it must be located somewhere, so it must have an
  address.

Are you claiming that I erroneously interpreted you to say that the
value of a literal must be represented by a runtime entity having an
address?

Tom Payne

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <remove.haberg-0310012246240001@du142-226.ppp.su-
anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
>>No, many assemblers provide instruction for small numbers where the
>>small number is only part of the instruction (and modern long word
>>assemblers do so to an even greater extent)
>
>There is no difference between registers and memory addresses in this
>respect, even though that on computers with a short word length, the
>instructions referencing memory take up more than one word.
>
>> and programs often have no
>>way of accessing instruction storage.
>
>A type of program with that capacity is the assembler, and another is the
>debugger. Clearly, if not type of program had the capacity to use register
>addresses, it is not possible to manipulate register data. :-)
>
>> Not that attempts to do so will
>>cause program termination, stronger than that, an application program
>>cannot access its own program code.
>
>I figure that one reason one does not allow that is because it is not
>considered safe, and another that it is not very portable. But this does
>not mean that registers do not have addresses.

I think you are entirely missing the point. Assembler code does not go
into data registers. Suppose that I have an assembler code to represent
+n into the accumulator where n is in the range -128 to +127. Now I
write:

int i=0;
i += 3;
 What is the address of 3?

Now

int const val = 3;
int j = 0;
j += val;

Why should val have an address unless I do something that actually needs
it to have an address. Note this has nothing to do with storing values
in registers (in the sense in which computer languages mean) val truly
has no address, it is just part of an assembler instruction.

Now:

int const & val_ref = 3;
int k=0;
k += val_ref;

Why should val_ref have an address (be an lvalue)?

There is simply no way of getting access to the actual machine code on
many machines, none whatsoever unless your process has a rather high
level of privileges.

I will say it again, literals are values and there is no need for values
to have addresses. There is no need for literals to be stored in any
form of data storage as distinct from program memory. The only even
possible access you have to program memory is via function pointers and
you are not allowed to adjust those within C++, and the only legal way
to dereference a function pointer is by calling the function.



Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <SaJxahAZD5u7EwX0@ntlworld.com>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:
> Then it is not
>>exactly clear how C++ references relate to that, because when compiling,
>>sometimes references like
>>    int i;
>>    int& j = i;
>>like j is just another name for i, which exists only at compile time and
>>not at runtime.
>
>That is a Java/Python... view of names but it is not the C++ one. In C++
>i has type int, and j has type reference to int.

I think that C++ is confusing because "reference to T" can mean different
things:

In the example above, it is in effect merely a name for something else,
that is, a language construct which does not have any runtime equivalent,
as i and j will refer to the same location without themselves having a
runtime representation. But in say
    void f(int& x);
then there is a runtime implementation, say x will be implemented as a
pointer to the original object.

I think this might have happened in C++ because the first example above is
what originally appeared in C, and one found it convenient to extend it to
the other uses now present in C++.

I think though that this might be mistake, and it may happen that this
shows up as a serious problem when becoming more dynamic: Then one may
need to have different names for the two types of "&" references above.
(Or at least clearly separate the two different meanings.)

> One added feature is
>that there is no syntax for writing a reference to a reference, if you
>try to right it, it simply remains a reference.

So the reason that is so is that the purely language construct reference
above (with no runtime equivalent) does not admit this.

> We do not need to
>discuss what a reference to a reference means because we cannot write
>one:) the grammar does not support such a thing.

By contrast, when speaking about runtime references, a reference to a
reference is admitted. In addition, when I looked into this matter (in my
own runtime model), I felt it prudent to classify different types of
references:

For one type of references, a reference to a reference will behave just as
a pointer to a pointer. Another type of reference is when a reference to a
reference is resolved to a single reference to the original object.

The both types are useful in programming. For example an unresolved
reference to a reference is useful as a handle, in case when the last
reference may have to change without having to instruct all objects that
may reference this object. This is necessary if say the size of an object
needs to change.

The method of always resolving a reference to a reference to a reference
is used by the MacOS, where it is called an "alias": Making an alias of an
alias makes it point at the original object, not the alias is was aliased
to. But it is still necessary sometimes to treat the alias as an object.

So in part for such reasons, I think that one should classify the
references as runtime objects with "methods" describing their behavior.
Then C++ may need to somehow support such reference objects in its syntax
or via a library.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <remove.haberg-0410011109190001@du132-226.ppp.su-
anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
>So in part for such reasons, I think that one should classify the
>references as runtime objects with "methods" describing their behavior.
>Then C++ may need to somehow support such reference objects in its syntax
>or via a library.

It sort of does, they are called 'pointers'. Java only has pointers
(granted, without the dangers of pointer arithmetic) which it calls
references and then prevents you from having a reference to a reference.
C++ allows you both concepts, references that are effectively aliases,
and pointers that are references using a different syntax for access to
the referenced object.

Yes, there are a number of subtle issues that the jargon of programming
(and most particularly the jargon of specific program languages) make
hard to discuss. A C++ reference is effectively an alias while a Java
reference is not (consider writing a swap function in both languages)

Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Barry Kelly <dynagen@eircom.net> wrote:
[...]
: The value returned by f is a "reference to the concept of n-ness",
: where "n" is the integral value returned.

How do you know it doesn't return "n-ness" itself, or maybe the
"concept of n-ness", rather than a "reference to the concept of
n-ness"?  ;-)

: For example:

:   int f() { return 2; }

: is a function returning a reference to the Universal concept of "2".
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                     the int value 2

[...]
: Of course, we can't take the address of a Universal Concept, as it were.
                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                                       value

: Sorry for the high metaphysical content.

For making abstract notions precise, metamathematics would be the better
choice.

Tom Payne

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Hans Aberg" <remove.haberg@matematik.su.se> wrote in message
news:remove.haberg-0310012246280001@du142-226.ppp.su-anst.tninet.se...
> In article <9pf5cg$k4p$2@glue.ucr.edu>, thp@cs.ucr.edu wrote:
> >You previously noted that in certain cases, the syntax also aims at
> >securing a sufficiently long lifetime for the referents of those
> >references, i.e., that being a referent can have a statically
> >determined effect on the referent's lifetime.
>
> Aha, so now I see what you mean: My impression of C++ is that it secures a
> minimum life span in case one would bother to reference it, but this
> minimum life span is itself independent of whether somebody would actually
> reference it. But it is not extended by somebody referencing it.

Why not give up speculating and refer to the Standard instead?

12.2
4 There are two contexts in which temporaries are destroyed at a different
point than the end of the full-
expression. The first context is when an expression appears as an
initializer for a declarator defining an
object...
5 The second context is when a reference is bound to a temporary. The
temporary to which the reference is
bound or the temporary that is the complete object to a subobject of which
the temporary is bound persists
for the lifetime of the reference except as specified below...

so:

#include <iostream>
struct x
{
    x() { std::cout << "+" << std::hex << (unsigned long)this << "\n"; }
    ~x() { std::cout << "-" << std::hex << (unsigned long)this << "\n"; }
};

void g(x const&) {}

int main()
{
    std::cout << "#1:\n";
    g(x());
    std::cout << "#2:\n";

    x const& a = x();
    std::cout << "delayed destruction\n";

    return 0;
}

gives the output:

#1:
+12ff68
-12ff68
#2:
+12ff6c
delayed destruction
-12ff6c

--
===================================================
  David Abrahams, C++ library designer for hire
 resume: http://users.rcn.com/abrahams/resume.html

        C++ Booster (http://www.boost.org)
          email: david.abrahams@rcn.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.research.att.com/~austern/csc/faq.html                ]

Hans Aberg <remove.haberg@matematik.su.se> wrote:
: In article <9pf5cg$k4p$2@glue.ucr.edu>, thp@cs.ucr.edu wrote:
:>You previously noted that in certain cases, the syntax also aims at
:>securing a sufficiently long lifetime for the referents of those
:>references, i.e., that being a referent can have a statically
:>determined effect on the referent's lifetime.

: Aha, so now I see what you mean: My impression of C++ is that it secures a
: minimum life span in case one would bother to reference it, but this
: minimum life span is itself independent of whether somebody would actually
: reference it. But it is not extended by somebody referencing it.

:>I understood you to say that the variable i, declared via
:>                        int i;
:>*is* a reference, in your extended view of references.

: Not really: I work with a runtime model which only describes runtime
  ^^^^^^^^^^
So, i is not a reference, after all?

: semantics, and does not depend on any language constructs. Therefore one
: has to look at what the language translates into.

: Then
:     void f(int);
: will translate into a model where the int's are recopied without
: explicitly keeping track of the reference, whereas
:     void g(int&);
: will keep track of the address of the original object.

: And
:     int i;
: will be make "i" treated as different kinds of references, memory, stack
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
So i will be "treated as" a reference, even though it is not a reference?

: or register addresses, depending context and how the compiler decides to
: implement it.

:>: No, "process" is not the UNIX concept here (which I think would be better
:>: called a "program" as opposed to say "threads" and other computational
:>: processes), but refers to its usual semantics, a black box which one can
:>                                ^^^^^
:>                                 Huh?
:>: provide an input and the response will be an output.
:>
:>So, this time I have to ask, what isn't a "process" in this sense?  (sigh)

: Well, a reference isn't a process, unless one implements it as an object.

>From the above discussion of i, it appears that you treat objects as
references.

: A piece of data can be viewed as a process, as in order to access it, one
: has to send out a request (say by a CPU operation) in order to retrieve
: it. So computers are massively made up by processes it seems.

Three sentences above you talk about implementing references as
objects, which you now view as processes.

:>Please pick some well-recognized technical reference and stick to the
:>terminology therein.  In discussing abstract foundational matters, the
:>precise use of terminology is essential.

: I think that the word "process" that I use agrees with what is commonly
: used in science, or in dictionaries like Merriam "Webster's Third New
: International Dictionary"; a variation might be "a progressively
: continuing operation marked by a series of gradual changes that succeed
: another in a fixed way and lead toward a particular result or end". My
: thesaurus does not provide me with any good alternative word.

The C and C++ standards lack in clarity and/or conciseness in their
presentations of several fundamental notions such as "value",
"object", "reference", "lvalue", "rvalue", "volatile", etc.  Serious
discussion might help to improve the treatment of those notions and
lead to improvements in subsequent revision of those standards.  In
such discussion, Merriam Webster is about as applicable as it would
have been in clarifying the mathematical notion of "infinitesimal", a
notion which was used effectively for a couple centuries before it was
finally made precise in the 1960s.  Nor, do I expect an increase in
clarity to come from "treating" objects as references or "viewing"
objects as processes.

Tom Payne















---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <9phps5$3jq$1@bob.news.rcn.net>, "David Abrahams"
<david.abrahams@rcn.com> wrote:
>> Aha, so now I see what you mean: My impression of C++ is that it secures a
>> minimum life span in case one would bother to reference it, but this
>> minimum life span is itself independent of whether somebody would actually
>> reference it. But it is not extended by somebody referencing it.
>
>Why not give up speculating and refer to the Standard instead?

Thank you: The example you gave
  struct x { ... };

  int main() {
    x const& a = x();
    ...
   }
apparently contradicts what I said. My have a vague memory that what you
wrote would not have been allowed in earlier C++ versions; perhaps it has
changed then.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <4rgrGLA5jIv7EwIA@ntlworld.com>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:
>>Then C++ may need to somehow support such reference objects in its syntax
>>or via a library.
>
>It sort of does, they are called 'pointers'. Java only has pointers
>(granted, without the dangers of pointer arithmetic) which it calls
>references and then prevents you from having a reference to a reference.
>C++ allows you both concepts, references that are effectively aliases,
>and pointers that are references using a different syntax for access to
>the referenced object.

I think of pointers as a special way of implementing references: For
example, one can make use of a handle (pointer to a pointer) and still
treat that as a single reference.

In a program language with conservative GC, one can mix pointers (unboxed)
and handles (boxed) and just call the references: I think this is what
Java does, even though I am not programming in Java.

>Yes, there are a number of subtle issues that the jargon of programming
>(and most particularly the jargon of specific program languages) make
>hard to discuss. A C++ reference is effectively an alias while a Java
>reference is not (consider writing a swap function in both languages)

I thin that one also has to carefully separate the "references" that may
show up in a language syntax with the runtime reference that might be used
in the implementation. C++ seems to use a mixture of & references as
purely language constructs and as another way to express a pointer.
Perhaps one should call the language reference constructs that do not
cause a runtime implementation "synonyms" or something, and keep the word
"reference" for the what causes a runtime reference.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <remove.haberg-0410012340490001@du137-226.ppp.su-
anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
>I thin that one also has to carefully separate the "references" that may
>show up in a language syntax with the runtime reference that might be used
>in the implementation. C++ seems to use a mixture of & references as
>purely language constructs and as another way to express a pointer.
>Perhaps one should call the language reference constructs that do not
>cause a runtime implementation "synonyms" or something, and keep the word
>"reference" for the what causes a runtime reference.

Sorry, but I am rapidly losing interest because you seem to be just
playing word games, and much though I enjoy those, I think type theory
is complicated enough already.

Just for the record:

Python uses typeless names that acquire the type of the thing they
currently reference.

Java uses named value objects for built-ins and for UDTs and compound
types (arrays) it uses typed names that can be bound to the unnamed
objects that new creates (i.e. Java has only anonymous instances of
UDTs, it more or less has to be that way for GC to work)

BTW it is not an accident that new returns a pointer in C++, while it
returns a reference in Java.

C++ has a richer structure. Until you understand that C++ references are
not hidden pointers (even though they can be implemented that way) but
aliases for possibly already named objects you will continue to sow
confusion in your thoughts. To be metaphysical, you must distinguish
between an object and the name of an object and the name of the name of
an object etc. (Read Alice in Wonderland and Alice Through the Looking
Glass and recognise that they are a bit more than children's stories)



Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <i7AtCXA$+4u7Ewj0@ntlworld.com>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:
>I think you are entirely missing the point. Assembler code does not go
>into data registers. Suppose that I have an assembler code to represent
>+n into the accumulator where n is in the range -128 to +127. Now I
>write:
>
>int i=0;
>i += 3;
> What is the address of 3?

In this case, "i" typically read into a register first, say r1, and then
an instruction, say
    add 3, r1
performs the increment. Then this instruction typically first has as
address a memory address, but is then read into a special register of the
CPU before it is interpreted. So right before being interpreted, this
machine instruction has as address this special instruction register, and
the number "3" is a part of that object, the machine instruction. It is
treated as a "value" in view of that the original address is not kept
track of (as CPU's normally do not have that capacity). (And modern RISC
computers nowadays has several instruction registers computed in a pipe
when possible.)

In order to keep with the ideas of object orientation, I do not require
that the subparts of an object should be externally accessible unless the
object allows it. So the "3" may or may not be accessible, depending on
how one implements it.

>There is simply no way of getting access to the actual machine code on
>many machines, none whatsoever unless your process has a rather high
>level of privileges.

But is it not hard to get the CPU execute code it cannot get access to? :-)

>I will say it again, literals are values and there is no need for values
>to have addresses. There is no need for literals to be stored in any
>form of data storage as distinct from program memory.

I think that by "address" you mean something like "heap address". But
program memory is also memory and is addressable by addresses; usually
they are of the same type as the heap addresses. -- I think that is the so
called von Neumann model by which most computers are built up nowadays.

> The only even
>possible access you have to program memory is via function pointers and
>you are not allowed to adjust those within C++, and the only legal way
>to dereference a function pointer is by calling the function.

Right, within current C++ that is not possible, because experience has
that programs that allow such manipulations are fragile. But from the
general discussion we are having here (I hope), it does not mean that
program memory does not have addresses.

In fact, the requirement that every process (or whatever you want to call
it) has an address can be viewed as that it has a "cover". Then for that
to work safely, one probably has to require that objects are more advanced
than usual machine instructions so they do not break, for example being
functional closures of lambda calculus: This is in fact the context I was
interested in the topic.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <9pi759$k6p$2@glue.ucr.edu>, thp@cs.ucr.edu wrote:
>:>I understood you to say that the variable i, declared via
>:>                        int i;
>:>*is* a reference, in your extended view of references.
>
>: Not really: I work with a runtime model which only describes runtime
>  ^^^^^^^^^^
>So, i is not a reference, after all?

My view is only "extended" in that I view any address, not only heap
addresses, to be called "address". I thought this was the usual way of
thinking of addresses, but you say it is not, it seems.

As for C++, it makes use of "references" both as purely language
constructs which no bearing on the output code, and as a variation of
pointers, and I did not remember that at the time of the original
discussions.

So you need to refocus on the issue you have in your mind. By "reference",
I think one should only mean the runtime equivalent, and not the pure
language construct, but that is not how C++ does it, evidently.

Now take
  int i;
What is "i"? It is a language construct. So it is not a runtime reference.

>: And
>:     int i;
>: will be make "i" treated as different kinds of references, memory, stack
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>So i will be "treated as" a reference, even though it is not a reference?

The "i" is a language construct, and will be translated into some code.
Then that code will make use of different types of references. The "i" is
itself nothing but a symbol in a piece of C++ language code.

>>From the above discussion of i, it appears that you treat objects as
>references.

No, if say the object is a certain memory word, it has a memory address,
which would be its reference if one uses absolute addresses.

>Three sentences above you talk about implementing references as
>objects, which you now view as processes.

If you have say a pice of data in a memory word, and view that as an
object, then you can also view it as a process, in view of that in order
to make use of that piece of data, you have to send a request for it. Then
for that process to work, you need to know where to send the request to
the object, the address or reference of it. So if you want to know what is
in that memory location, you send a request "get data" to what is viewed
as the object, and it responds with the data in that location. In reality,
the request will happen centralized over the CPU, but it is possible to
take this view, because for one thing, it will work with any number of
CPU's present.

>:>Please pick some well-recognized technical reference and stick to the
>:>terminology therein.  In discussing abstract foundational matters, the
>:>precise use of terminology is essential.
...
>The C and C++ standards lack in clarity and/or conciseness in their
>presentations of several fundamental notions such as "value",
>"object", "reference", "lvalue", "rvalue", "volatile", etc.  Serious
>discussion might help to improve the treatment of those notions and
>lead to improvements in subsequent revision of those standards.  In
>such discussion, Merriam Webster is about as applicable as it would
>have been in clarifying the mathematical notion of "infinitesimal", a
>notion which was used effectively for a couple centuries before it was
>finally made precise in the 1960s.

When I use the word "infinitesimal", I either think of it in the form a
differential on a differential manifold (19th century) or the value at the
stalk of a sheaf (1940-50'ies), but I would not use say the Robinson
definition from the 1960'ies, and physicists would not even today use any
of those mathematical notions in a rigorous way (which is often confusing
when one studies say so called "inertial frames" in general relativity).
So what is so final about the word "infinitesimal"?

Returning to the original question, one could not say that the definition
of "process" in UNIX or "reference" in C++ is universal to all technical
literature. I just happened to be interested in the description of runtime
objects, and I found that terminology useful, because I know the word from
other contexts. I have never seen any description in computer literature
of such massively dynamic structures, and I think the reason is that
dynamic implementations become slow, so that computer scientists usually
avoid them. But we are heading that direction, in view of that computer
become more powerful.

The reason I got interested in that is that I, as a mathematician, want
things to be sufficiently general. So if every expression has a runtime
equivalent, then that is more general. Now computers, as opposed to math,
are dynamic, or has a causality (things evolve in "processes"), so the
natural thing is to look for "closures" that can be treated as
"processes"; a "closure" is a form of "object". Therefore I landed on this
picture.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <9pgq13$6bu$3@glue.ucr.edu>
 thp@cs.ucr.edu wrote:

> Barry Kelly <dynagen@eircom.net> wrote:
> [...]
> : The value returned by f is a "reference to the concept of n-ness",
> : where "n" is the integral value returned.
>
> How do you know it doesn't return "n-ness" itself, or maybe the
> "concept of n-ness", rather than a "reference to the concept of
> n-ness"?  ;-)

This is getting very philosophical! Our notion of equality is based on
something being the 'same'; if we are to talk of two values being
equal - yet being stored in different locations - it makes more sense
to refer to them as references to something else, which is the unique
thing to which sameness refers.

> : For example:
>
> :   int f() { return 2; }
>
> : is a function returning a reference to the Universal concept of "2".
>                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>                                      the int value 2

It can't return a value, because then it would be universally unique,
and could never be equal to any other 2 stored on the computer.

That's why I chose the wording I did.

Please keep in mind that I only brought this up in order to get away
from C++ for a moment, so that - with a little abstraction - we might
see a little more clearly. If we can only disagree on minutiae of C++
jargon, then my effort was wasted.

> [...]
> : Of course, we can't take the address of a Universal Concept, as it were.
>                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>                                                        value

I was trying to make something clear by exposition. Again, this comes
down to the idea that all values are unique, and that any talk of a
'value' in a computer representation can only be a reference to a
concept outside the computer.

> : Sorry for the high metaphysical content.
>
> For making abstract notions precise, metamathematics would be the better
> choice.

I agree. I'll leave you to it, then.

-- Barry

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Hans Aberg" <remove.haberg@matematik.su.se> wrote in message
news:remove.haberg-0310011258420001@du130-226.ppp.su-anst.tninet.se...
> In article <5p7L2JAQiau7EwAF@ntlworld.com>, Francis Glassborow
> <francisG@robinton.demon.co.uk> wrote:
> >>If "3" has a runtime representation, clearly it has an address, as it
must
> >>be located somewhere in the computer.
> >
> >I think this is false. Clearly '3' is somehow represented but it can be
> >as part of an assembler instruction for which there is no address from
> >the programmer's perspective. And, unless the programmer does something
> >that explicitly requires '3' occupy data storage, there is no
> >requirement that it has an address.
>
> I guess that the assembler instruction containing the "3" must be located
> somewhere, and thus can be treated as a data object. In pseudo-C++, it
> would correspond to a
>   class assembler_instruction {
>     int n;
>   ...
>     void evaluate();
>   };
> where evaluate() is used by the CPU to activate the instruction.

I can give you an example where the literal is not contained in the assembly
code. I once worked with a guy who had the mixed blessing of having to write
some assembly code for the (then) Digital Alpha processor. IIRC, the tricky
thing about literals on the Alpha is that every instruction has a fixed
size, lets say 64 bits. So the question is, how can you have a 64 bit
instruction that itself contains a 64 bit literal? The answer is that you
can't do it. The 64 bit literal has to be synthesised by (up to a few)
intructions involving smaller constants.

Typcially, the literal is synthesised in an intermediate register, but I
don't see that this is an absolute requirement. It would certainly be
reckless for the C++ standard to require this. You might have a situation
where x += BIGNUMBER is better implemented by instructions that each deal
with parts of BIGNUMBER and never actually store the entire number (unless x
happened to be zero initially).

Regards,
Raoul Gough.

--
Don't bother trying the deja return address. You could try the same username
"at" knuut.de or via Hotmail if I've moved home address.


---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <g+u9jUAA8Nv7Ew6D@ntlworld.com>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:
>>I thin that one also has to carefully separate the "references" that may
>>show up in a language syntax with the runtime reference that might be used
>>in the implementation. C++ seems to use a mixture of & references as
>>purely language constructs and as another way to express a pointer.
>>Perhaps one should call the language reference constructs that do not
>>cause a runtime implementation "synonyms" or something, and keep the word
>>"reference" for the what causes a runtime reference.
>
>Sorry, but I am rapidly losing interest

That is OK. :-)

> because you seem to be just
>playing word games,

Not really: Using you terminology are "semantic games". Or rather, I want
to separate what has a runtime representation from what does not.

> and much though I enjoy those, I think type theory
>is complicated enough already.

For example, there is a difference between data types that can be runtime
identified (via RTTI) and those that are not.

As for the C++ references, the ones of the type
    int& j = i;
will not have any runtime equivalent, because the compiler will merely
translate it so that whatever use of j is replaced by what i represents.
By contrast, if one writes
    void f(int& x) { ... }
then in effect x will have to be implemented as a pointer referenced in
special way.

IN the first case, one cannot treat a reference to a reference any other
than a single reference, because it is not a runtime object, but in the
latter case it is. So there is a semantically incompatible difference
between C++ references that can have a runtime representation and those
that cannot.

>BTW it is not an accident that new returns a pointer in C++, while it
>returns a reference in Java.

This is just the difference of having a conservative GC maintaining the
pointer or not: In C++, if you write
  T& f() { return *new T(); }
there is no way to know whether this is a references or a pointer, and it
is therefore not possible to know when to remove it.

It is not possible to get around this in C++, and it has (I think) to do
in part that the copy constructor T::T(T&) is not called as expected, that
is, even if it is explicitly written, in it will not be called suitably.

>C++ has a richer structure. Until you understand that C++ references are
>not hidden pointers (even though they can be implemented that way) but
>aliases for possibly already named objects you will continue to sow
>confusion in your thoughts.

I try to say that the references should not be a variation of (memory)
pointers, because there are many ways to implement references: For
example, they can be handles or references to a register, or something.

But one should carefully separate what is pure language constructs and
what is runtime references.

> To be metaphysical, you must distinguish
>between an object and the name of an object and the name of the name of
>an object etc.

The objects I spoke about are "runtime objects", so they do not normally
have any name, but in order to access them one needs a reference
(address). -- The names are usually thrown away in the compilation
procedure. One can implement so that names are used as runtime references
(like in a lookup table), but that is not normally the case.

> (Read Alice in Wonderland and Alice Through the Looking
>Glass and recognise that they are a bit more than children's stories)

I know that the author also had a penchant for photographing little girls
naked (after permission from their parents); should I do that as well?

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Hans Aberg <remove.haberg@matematik.su.se> wrote:
: In article <i7AtCXA$+4u7Ewj0@ntlworld.com>, Francis Glassborow
: <francisG@robinton.demon.co.uk> wrote:
:>I think you are entirely missing the point.
[...]
:> The only even
:>possible access you have to program memory is via function pointers and
:>you are not allowed to adjust those within C++, and the only legal way
:>to dereference a function pointer is by calling the function.

There are also labels and switch statements, but except in certain
extensions (e.g., g++) labels are not data, and in any case they cannot
be used to fetch values.

: Right, within current C++ that is not possible, because experience has
: that programs that allow such manipulations are fragile. But from the
: general discussion we are having here (I hope), it does not mean that
: program memory does not have addresses.

: In fact, the requirement that every process (or whatever you want to call
: it) has an address can be viewed as that it has a "cover". Then for that
: to work safely, one probably has to require that objects are more advanced
: than usual machine instructions so they do not break, for example being
: functional closures of lambda calculus: This is in fact the context I was
: interested in the topic.

How general do you want to be?  Even Turing machines do not provide
read access to their instructions (quintuples, or whatever).  By a
factor of 100-to-1, most current computers are embedded controlers and
there are embedded-controller architectures that support
implementations of both C++ and lambda calculus but do not provide any
sequence of instrutions that will copy an instruction into data space.

It might be worth noting that there are diagonal arguments (see
Kleene's second recursion theorem) by which one can generate programs
that will place a copy of themselves into memory on Turing machines
and then go on to do whatever computations.

Tom Payne

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <3bbd780c$0$186$4d4ebb8e@read.news.de.uu.net>, "Raoul Gough"
<RaoulGough@my-deja.com> wrote:
>I can give you an example where the literal is not contained in the assembly
>code. I once worked with a guy who had the mixed blessing of having to write
>some assembly code for the (then) Digital Alpha processor. IIRC, the tricky
>thing about literals on the Alpha is that every instruction has a fixed
>size, lets say 64 bits. So the question is, how can you have a 64 bit
>instruction that itself contains a 64 bit literal? The answer is that you
>can't do it. The 64 bit literal has to be synthesised by (up to a few)
>intructions involving smaller constants.
>
>Typcially, the literal is synthesised in an intermediate register, but I
>don't see that this is an absolute requirement. It would certainly be
>reckless for the C++ standard to require this. You might have a situation
>where x += BIGNUMBER is better implemented by instructions that each deal
>with parts of BIGNUMBER and never actually store the entire number (unless x
>happened to be zero initially).

The main point is that it must be located somewhere, so it must have an address.

Further, when I speak about "runtime objects", I rather deliberately do
not impose any particular conditions on _how_ it should be represented,
say in contiguous memory or something, because that is rather irrelevant
from the semantic point of view.

If the CPU only has assembler instructions
    add n, r
where n is added to register r, and one wants to be able to reference the
"n" and later compute the instruction, then one way to do it is to define
a new object that combines the n and r into a new instruction "add n, r",
and then executes it. This is clearly going to be slow, but an assembler
can do it. One can design such new runtime objects if they are needed.

If an implementation only supports
    add n, r
objects with no direct external access to n and r, then I would call that
an atom object, as it is not decomposable into smaller entities, and as
opposed to other objects that would be composed. I think it is important
to design a good set of such atom objects, as from the practical point of
view objects that are too primitive become fragile, and the execution
becomes slow. An atom could be say a full program, if you so want.

As for C++, it needs both to be able to get down to a lower level, so that
one better can specify the underlying binary model, and to be able to
better programing when designing runtime objects. For example, GCC already
has special features that allows one to reserve registers for special
purposes (but I do not know exactly how that works, only that it is used
by the Haskell compiler GHC). My guess is that C++ can only admit such
features if they are reasonably portable (roughly, if it is possible to
detect on a platform that the feature is usable).

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Thu,  4 Oct 2001 22:33:33 GMT, Francis Glassborow <francis.glassborow@ntl=
world.com> pisze:

> C++ has a richer structure. Until you understand that C++ references ar=
e
> not hidden pointers (even though they can be implemented that way) but
> aliases for possibly already named objects you will continue to sow
> confusion in your thoughts.

What is the difference between "hidden pointer" and "alias"?

IMHO references can be treated as hidden pointers without additional
problems. Doesn't matter that there is no reference equivalent of the
null pointer - I'm not saying that an arbitrary pointer may be hidden
that way.

--=20
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZAST=CAPCZA
QRCZAK

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Hans Aberg <remove.haberg@matematik.su.se> wrote:
: In article <9pi759$k6p$2@glue.ucr.edu>, thp@cs.ucr.edu wrote:
:>:>I understood you to say that the variable i, declared via
:>:>                        int i;
:>:>*is* a reference, in your extended view of references.
:>
:>: Not really: I work with a runtime model which only describes runtime
:>  ^^^^^^^^^^
:>So, i is not a reference, after all?

: My view is only "extended" in that I view any address, not only heap
: addresses, to be called "address".

Then call it an "address", not a "reference".  But, that said, i isn't
an address either.  At run time it will *have* an address and will be
represented via its address, but it still won't *be* an address.
(Similarly, it will have a value, but it won't *be* its value.)

[...]
: As for C++, it makes use of "references" both as purely language
: constructs which no bearing on the output code, and as a variation of
: pointers, and I did not remember that at the time of the original
: discussions.

The latter view is completely general.

: So you need to refocus on the issue you have in your mind.  By "reference",
: I think one should only mean the runtime equivalent, and not the pure
: language construct, but that is not how C++ does it, evidently.

All C++ references can correctly be viewed as automatically
dereferenced pointers.  That view, however, glosses over a few details
regarding the PODness of structs and the automatic creation of
temporaries when const references are initialized with rvalues, and so
on.

References are de facto immutable and their addresses cannot be
determined.  When the value of reference is known at compile time, the
as-if rule allows it to be optimized away in the output code.  But the
same holds for any immutable pointer whose address isn't determined.

: Now take
:   int i;
: What is "i"? It is a language construct. So it is not a runtime reference.

Nor is it a a reference in the sense sense of the C++ standard.  So, can we
finally agree that variables are *not* references?

:>: And
:>:     int i;
:>: will be make "i" treated as different kinds of references, memory, stack
:>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
:>So i will be "treated as" a reference, even though it is not a reference?

: The "i" is a language construct, and will be translated into some code.

Program get translates machine code.  The state of a variable gets
represented somehow at runtime.  How it gets represented.  It might be
represented differently at different points in the program.  In some
portions of the program, the state of the variable might be
determinable at compile time, in which case it might not occupy even a
register but simply get represented as an immediate operand of certain
instructions.  In fact, if the known state of an integer variable is
four, and we multiply by it, that state might be represented by two
not-necessarily-consecutive one-bit shift instructions.  In that case
the value has no run-time location.

: Then that code will make use of different types of references.

Or possibly none at all.  (See the example above.)

: The "i" is itself nothing but a symbol in a piece of C++ language code.

Certainly.  Also it's the ninth letter of the alphabet.  So what?

:>>From the above discussion of i, it appears that you treat objects as
:>references.

: No, if say the object is a certain memory word, it has a memory address,
: which would be its reference if one uses absolute addresses.

But, at run time, not all objects occupy memory words.

:>Three sentences above you talk about implementing references as
:>objects, which you now view as processes.

: If you have say a pice of data in a memory word, and view that as an
: object, then you can also view it as a process, in view of that in order
: to make use of that piece of data, you have to send a request for it. Then
: for that process to work, you need to know where to send the request to
: the object, the address or reference of it. So if you want to know what is
: in that memory location, you send a request "get data" to what is viewed
: as the object, and it responds with the data in that location. In reality,
: the request will happen centralized over the CPU, but it is possible to
: take this view, because for one thing, it will work with any number of
: CPU's present.

Many views and many treatments are possible.  The question is which
ones are accurate and helpful.  IMHO, treating variables as
references, either C++ reference or run-time addresses is misleading.
Viewing them as processes is unhelpful.

:>:>Please pick some well-recognized technical reference and stick to the
:>:>terminology therein.  In discussing abstract foundational matters, the
:>:>precise use of terminology is essential.
: ...
:>The C and C++ standards lack in clarity and/or conciseness in their
:>presentations of several fundamental notions such as "value",
:>"object", "reference", "lvalue", "rvalue", "volatile", etc.  Serious
:>discussion might help to improve the treatment of those notions and
:>lead to improvements in subsequent revision of those standards.  In
:>such discussion, Merriam Webster is about as applicable as it would
:>have been in clarifying the mathematical notion of "infinitesimal", a
:>notion which was used effectively for a couple centuries before it was
:>finally made precise in the 1960s.

: When I use the word "infinitesimal", I either think of it in the form a
: differential on a differential manifold (19th century) or the value at the
: stalk of a sheaf (1940-50'ies), but I would not use say the Robinson
: definition from the 1960'ies, and physicists would not even today use any
: of those mathematical notions in a rigorous way (which is often confusing
: when one studies say so called "inertial frames" in general relativity).
: So what is so final about the word "infinitesimal"?

In any case, you don't appeal to Merriam Webster as a "well-recognized
technical reference" on the matter.

: Returning to the original question, one could not say that the definition
: of "process" in UNIX or "reference" in C++ is universal to all technical
: literature.

Exactly.  That's why I invited you to pick any well-recognized technical
reference as a way to pin down the meanings of technical terms and get
past all this HumptyDumptyism.

: I just happened to be interested in the description of runtime
: objects, and I found that terminology useful, because I know the word from
: other contexts. I have never seen any description in computer literature
: of such massively dynamic structures, and I think the reason is that
: dynamic implementations become slow, so that computer scientists usually
: avoid them. But we are heading that direction, in view of that computer
: become more powerful.

There was a very clear 1969 paper by Strachey on many of these issues.
I'll see if I can find a reference it.

: The reason I got interested in that is that I, as a mathematician, want
: things to be sufficiently general.

The first requirement for such generality is precise terminology.

: So if every expression has a runtime equivalent, then that is more general.

Not imposing such a requirement is even more general.

Tom Payne











---
[ 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.research.att.com/~austern/csc/faq.html                ]

Fri,  5 Oct 2001 16:00:38 GMT, Hans Aberg <remove.haberg@matematik.su.se>=
 pisze:

> As for the C++ references, the ones of the type
>     int& j =3D i;
> will not have any runtime equivalent, because the compiler will merely
> translate it so that whatever use of j is replaced by what i represents.

The compiler can do it, but it doesn't need to perform this optimization.

> By contrast, if one writes
>     void f(int& x) { ... }
> then in effect x will have to be implemented as a pointer referenced in
> special way.
>=20
> IN the first case, one cannot treat a reference to a reference any othe=
r
> than a single reference, because it is not a runtime object, but in the
> latter case it is.

No, there is no essential difference between these cases. The
compiler could construct a reference to a reference in both cases,
and it doesn't because no C++ language construct tells it to do so.

You could as well say that you can't form a reference to
    const int i =3D 5;
because the compiler will replace i with 5 through the code. Well,
it may replace it, but it doesn't prevent i from having a physical
representation as well.

> I try to say that the references should not be a variation of (memory)
> pointers, because there are many ways to implement references: For
> example, they can be handles or references to a register, or something.

It applies to other types as well. It's right that references can be
implemented differently, but it's nothing wrong with thinking about
references as something fundamentally different. C++ references really
behave as kind of pointers with some limitations and some extra rules.

> But one should carefully separate what is pure language constructs
> and what is runtime references.

The standard doesn't tell how things are represented in runtime.
But you can safely think of references as always having a runtime
representation. The compiler can then transform the code to another
version with the same behavior, as usual.

--=20
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZAST=CAPCZA
QRCZAK

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Hans Aberg <remove.haberg@matematik.su.se> wrote:
: In article <3bbd780c$0$186$4d4ebb8e@read.news.de.uu.net>, "Raoul Gough"
: <RaoulGough@my-deja.com> wrote:
:>I can give you an example where the literal is not contained in the assembly
:>code. I once worked with a guy who had the mixed blessing of having to write
:>some assembly code for the (then) Digital Alpha processor. IIRC, the tricky
:>thing about literals on the Alpha is that every instruction has a fixed
:>size, lets say 64 bits. So the question is, how can you have a 64 bit
:>instruction that itself contains a 64 bit literal? The answer is that you
:>can't do it. The 64 bit literal has to be synthesised by (up to a few)
:>intructions involving smaller constants.
:>
:>Typcially, the literal is synthesised in an intermediate register, but I
:>don't see that this is an absolute requirement. It would certainly be
:>reckless for the C++ standard to require this. You might have a situation
:>where x += BIGNUMBER is better implemented by instructions that each deal
:>with parts of BIGNUMBER and never actually store the entire number (unless x
:>happened to be zero initially).

: The main point is that it must be located somewhere, so it must have an
: address.

No!  It need not be located anywhere.  I can multiply by two by
executing a one-bit shift.  Where's two?  I can multiply by four by
executing two one-bit shifts.  (For the sake of overlapped execution
on a multi-issue architecture, they would not likely be consecutive
instructions.)  Now, where's four?

Language specifications should not unnecessarily constrain the options
available to implementers.

Tom Payne




























---
[ 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.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow <francis.glassborow@ntlworld.com> wrote:
[...]
: C++ has a richer structure. Until you understand that C++ references are
: not hidden pointers (even though they can be implemented that way) but
: aliases for possibly already named objects you will continue to sow
: confusion in your thoughts. To be metaphysical, you must distinguish
: between an object and the name of an object and the name of the name of
: an object etc. (Read Alice in Wonderland and Alice Through the Looking
: Glass and recognise that they are a bit more than children's stories)

In thinking about what C++ references are and are not, it is very helpful
to keep the following example in mind:

                  int& f(){ return *new int; }

(1) It dispells the common misconception that references are names
(i.e., occurrences of identifiers), because the only name in sight is
"f" and it identifies something else.

(2) It also dispells the common misconcepton that references are
aliases for something else, because after f() returns the only grasp
the program has on the newly created int is the reference to it that
has been returned by f().


For people who understand pointers, usually helpful helpful to think
of references as automatically dereferenced pointers.  That view is
accurate and about 90% complete.  The other 10% can be summarized on a
single page.  This view has to do with semantic specifications, not
implementation.  Pointers and references may or may not be implemented
in distinct ways.  Each independently may or may not be implemented
as addresses.

Tom Payne

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Barry Kelly <dynagen@eircom.net> wrote:
: In article <9pgq13$6bu$3@glue.ucr.edu>
:  thp@cs.ucr.edu wrote:

:> Barry Kelly <dynagen@eircom.net> wrote:
:> [...]
:> : The value returned by f is a "reference to the concept of n-ness",
:> : where "n" is the integral value returned.
:>
:> How do you know it doesn't return "n-ness" itself, or maybe the
:> "concept of n-ness", rather than a "reference to the concept of
:> n-ness"?  ;-)

: This is getting very philosophical! Our notion of equality is based on
: something being the 'same'; if we are to talk of two values being
: equal - yet being stored in different locations - it makes more sense
: to refer to them as references to something else, which is the unique
: thing to which sameness refers.

The number three is a perfectly good mathematical entity capable of
being represented by a bit pattern under any given encoding of a
finite initial segment of the non-negative integers.  If a variable
contains the bit pattern that represents the value three, why should
anyone accept that instead it contains a representation of "a
reference to the the concept of 3-ness."

:> : For example:
:>
:> :   int f() { return 2; }
:>
:> : is a function returning a reference to the Universal concept of "2".
:>                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
:>                                      the int value 2

: It can't return a value, because then it would be universally unique,
: and could never be equal to any other 2 stored on the computer.

Huh?  Two instances of the same bit pattern can be tested for equality
without regard to the what those patterns represent.  Functions return
values by setting a given register per the bit pattern that represents
that value.  The pattern in that register will test equal to instances
of the same pattern in other registers.

: That's why I chose the wording I did.

: Please keep in mind that I only brought this up in order to get away
: from C++ for a moment, so that - with a little abstraction - we might
: see a little more clearly.

That can be useful, but it would be helpful to distinguish between
abstraction and vagueness.  For a somewhat precise and early (1967)
treatment of these matters I might suggest "Fundamental Concepts in
Programming Languages" by Christopher Strachey, reprinted in
Higher-Order and Symbolic Computation (13, 11-49).

Tom Payne

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <remove.haberg-0410011109190001@du132-226.ppp.su-anst.tninet.se>,
remove.haberg@matematik.su.se (Hans Aberg) wrote:

>In article <SaJxahAZD5u7EwX0@ntlworld.com>, Francis Glassborow
><francisG@robinton.demon.co.uk> wrote:
>> Then it is not
>>>exactly clear how C++ references relate to that, because when compiling,
>>>sometimes references like
>>>    int i;
>>>    int& j = i;
>>>like j is just another name for i, which exists only at compile time and
>>>not at runtime.
>>
>>That is a Java/Python... view of names but it is not the C++ one. In C++
>>i has type int, and j has type reference to int.
>
>I think that C++ is confusing because "reference to T" can mean different
>things:
>
>In the example above, it is in effect merely a name for something else,
>that is, a language construct which does not have any runtime equivalent,

The standard neither requires nor prevents references from having runtime
equivalents. It is common to implement references as pointers, in which case
there would be a runtime equivalent.

>as i and j will refer to the same location without themselves having a
>runtime representation. But in say
>    void f(int& x);
>then there is a runtime implementation, say x will be implemented as a
>pointer to the original object.
>
>I think this might have happened in C++ because the first example above is
>what originally appeared in C, and one found it convenient to extend it to
>the other uses now present in C++.

When, prior to C99, did C have references?

>I think though that this might be mistake, and it may happen that this
>shows up as a serious problem when becoming more dynamic: Then one may
>need to have different names for the two types of "&" references above.
>(Or at least clearly separate the two different meanings.)
>
>> One added feature is
>>that there is no syntax for writing a reference to a reference, if you
>>try to right it, it simply remains a reference.
>
>So the reason that is so is that the purely language construct reference
>above (with no runtime equivalent) does not admit this.

The standard specifically states it, regardless of the existence of a runtime
equivalent.

[snip]
>The method of always resolving a reference to a reference to a reference
>is used by the MacOS, where it is called an "alias": Making an alias of an
>alias makes it point at the original object, not the alias is was aliased
>to. But it is still necessary sometimes to treat the alias as an object.

The only MacOS "alias" that I know of is a HFS construct that has nothing to do
with C++. Nor is it as simple as a reference to a reference to a reference. And
just because accessing the second alias produces the original file doesn't mean
it didn't go through the first alias.

Orson Bushnell
TransWarp Technologies, LP.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

<thp@cs.ucr.edu> wrote in message news:9p9jpk$qoj$2@glue.ucr.edu...
> :>IMHO, the problem is that the C/C++ policy of using the same type name
> :>to designate both values and objects breaks down when it comes to
> :>references.  Note for example that in
> :>
> :>           int f();
> :>
> :>the function f is said to return an int, while in
> :>
> :>           int i;
> :>
> :>the variable i is said to be an int.  But f returns something quite
> :>different from what i is; for instance, i has an address, but not so
> :>for entity returned by f.
>
> : So in this case, one is merely dealing with different types of
references.
>
> Hmmmm.  f returns an *int value*, while i is an *int object*.  Neither of
> them is a reference in the sense of C++.

Not so fast...
What do you mean that "f is" and the "i is"? In which aspect?
In the sense of C++ that depends on how it's treated, in other words,
how it is treated in the expression. What's the type of the subexpression
these 'f' and 'i' are. For example:

    i = f();

Here you have:
1. an assignment to 'i'; operator= called for an int *object*.
2. a function call; there is an operator () called for the function
reference.

Now, the matter is about which types have the 'i' and 'f' in this
expression.
They are:

f - has type: int (&f)();
i - has type: int&

The names are references. You can in this case take an address: with &f and
&i.
You can do it, because 'f' and 'i' are references. In case they are not, it
would be unable.
So why they are references?

1. 'f' is a reference, because each function name is a reference. This is
implied
by the condition, that you can take an address of any function (with some
restrictions
I don't remember now; in this case their names won't be references)

2. 'i' is a reference, because it's bound to a created object by the
language construct.
But remember: the 'i' name IS a reference in the expression shown above.

So remember: 'i' is not an object. 'i' is a reference with a local object
bound to.
You can also create another reference:

int& x = i;

which in this case is BOUND to the same object as 'i' (NOT "to 'i' ").

And in this case, the 'x' and 'i' are the same in any expression. This is
true in each case, because you can't rebind these names.

i = f();
x = f(); // the same

int f( int& );
...
f( i );
f( x ); // the same

They are the same, because the types in these expressions are the same
and they have the same object bound to.

If you would treat the 'i' as an "int value" then you could mean, that
"f( i )" makes a conversion from 'int' to 'int&'. Such a conversion is
not allowed (for any type) unless you are calling a method for 'i'.

> : Also note that when using dynamic bindings, some uses of syntactic
> : reference constructs in C++ become redundant: For example,
> :   int x = 5;
> :   int& y = x;
> : In C++, this means that "y is a reference to x", and that "x has the
value
> : 5" or something. However, with dynamic bindings in place, one could let
> : the assignment "=" mean "another reference. Then one would instead write
> :   int x = 5;
> :   int y = x; // Another reference to the object 5.

This is false. The "int x = 5" declaration makes a new local *object*
initialized to '5'.
Because 'x' becomes an object, the declaration of 'y' makes a new name for
this local object. Not for "5" object; the "5" is a syntactic initializer
(or "a value"),
not an object. Objects have also run-time meaning, while the 'value' is
expression
characteristic.

> : If one would want to have an independent copy of 5, then one would have
to write
> :   int z = clone(5);

You probably think about the sharing and the lazy copying, called also
"copy-on-write".

> That sounds similar to the so-called "reference semantics" that found
> in various languages other than C++.

It's not a problem to implement them in such a way. Choosen automatically
without using this "clone".

> (I've wondered whether it might
> be possible to define a template class ref<T> that behaved somewhat
> like the references in say Java.)

Do you mean something like that:

template <class T>
class ref
{
    T* ins;
public:
    ref( T& x ) { ins = &x; }
    friend void set_reference( ref<T>& ins, T& x ) { ins = &x; }
    ref& operator=( T x ) { *ins = x; return *this; }
    operator T&() { return *ins; }
    T* operator->() { return ins; }
};

With the exception, that it's unable to access the T's members with the '.'
operator,
therefore there is -> operator provided. There is also no
garbage-collection. ;)

--
Regards,
((
 )) ektor


---
[ 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.research.att.com/~austern/csc/faq.html                ]

I'm not going to respond to any responses to this message because I
feel the discussion has reached the end of its useful life. However,
there are a couple of points I'm going to make a final attempt to make
clear.

In article <9pl2v9$h2l$1@glue.ucr.edu>
 thp@cs.ucr.edu wrote:
> Barry Kelly <dynagen@eircom.net> wrote:
> : In article <9pgq13$6bu$3@glue.ucr.edu>
> :  thp@cs.ucr.edu wrote:
>
> :> Barry Kelly <dynagen@eircom.net> wrote:
> :> [...]
> :> : The value returned by f is a "reference to the concept of n-ness",
> :> : where "n" is the integral value returned.
> :>
> :> How do you know it doesn't return "n-ness" itself, or maybe the
> :> "concept of n-ness", rather than a "reference to the concept of
> :> n-ness"?  ;-)
>
> : This is getting very philosophical! Our notion of equality is based on
> : something being the 'same'; if we are to talk of two values being
> : equal - yet being stored in different locations - it makes more sense
> : to refer to them as references to something else, which is the unique
> : thing to which sameness refers.
>
> The number three is a perfectly good mathematical entity capable of
> being represented by a bit pattern

You've completely missed my point. '11' base 2 is not the number 3.
The arabic numeral '3' is not the number 3. An encoding of the number
3, in any numerical base or intelligible format whatsoever, is *not*
the number 3.

They are all references to an idea.

The only purpose in pointing this out is to observe the chain of
references implicit in C++, so that when the C++ jargon noun
"reference" comes up we may have an improved vocabulary with which to
make semantics clear.

As I said, you've failed to see my point. We aren't getting anywhere,
so I've given up.

> :> : For example:
> :>
> :> :   int f() { return 2; }
> :>
> :> : is a function returning a reference to the Universal concept of "2".
> :>                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> :>                                      the int value 2
>
> : It can't return a value, because then it would be universally unique,
> : and could never be equal to any other 2 stored on the computer.
>
> Huh?  Two instances of the same bit pattern can be tested for equality
> without regard to the what those patterns represent.

This isn't true in general for computer representation of numbers,
because it's implementation dependant - you're aware of the +0 and -0
disparity, for example.

Thus, it isn't useful for you to state this. Again, when we are
comparing, we are comparing what the bit patterns represent, not the
bit patterns themselves.

You've missed my point again.

> : Please keep in mind that I only brought this up in order to get away
> : from C++ for a moment, so that - with a little abstraction - we might
> : see a little more clearly.
>
> That can be useful, but it would be helpful to distinguish between
> abstraction and vagueness.

Am I still vague?

No matter - I've given up.

-- Barry

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <9pkgbv$b0g$1@glue.ucr.edu>, thp@cs.ucr.edu wrote:
>: In fact, the requirement that every process (or whatever you want to call
>: it) has an address can be viewed as that it has a "cover". Then for that
>: to work safely, one probably has to require that objects are more advanced
>: than usual machine instructions so they do not break, for example being
>: functional closures of lambda calculus: This is in fact the context I was
>: interested in the topic.
>
>How general do you want to be?

They way I developed this idea, one is only developing certain high level
objects, which has references. For example, I implemented the lambda
calculus this way, and then the "lambda" itself appears as a certain
runtime object which is the constructor of runtime lambda expressions.
This is a difference between functional languages then, because the lambda
is usually not made available as a runtime object.

Also, if one views a program as a runtime object, then the requirement
that runtime objects should have references means that there should be a
reference to this program. And this is of course made available via the
OS. So if say C++ should require that programs be treated as runtime
objects, one should add feature that allows one to reference programs from
C++ code.

>...    By a
>factor of 100-to-1, most current computers are embedded controlers and
>there are embedded-controller architectures that support
>implementations of both C++ and lambda calculus but do not provide any
>sequence of instrutions that will copy an instruction into data space.

On the lowest level, you do not get away from the traditional architecture
separating say heap and program memory, as that is typically hardwired.

But if one starts building such runtime objects, they will in effect
behave as though the program and memory aspects are integrated, even
though in the computer hardware architecture they are split onto different
parts: Each object can respond to a sequence of requests, which will be
implemented as function pointers.

So the way I implemented it, an execution of a request to an object will
jump over a data part in say heap memory to the execution of some function
pointers (in program memory), produce say a new object in the heap, and
return a reference to that. The code cannot break, because an illegal
request will generate an exception. But this is viewed as only one object.

This is a very time consuming implementation, but the model still applies
to more primitive objects. And I think one might "compile" a compound
object into an atom, and thereby speed it up.

>Even Turing machines do not provide
>read access to their instructions (quintuples, or whatever).
...
>It might be worth noting that there are diagonal arguments (see
>Kleene's second recursion theorem) by which one can generate programs
>that will place a copy of themselves into memory on Turing machines
>and then go on to do whatever computations.

I think that a Turing machine might be viewed as being able to executes
its own instructions: The fixed states of the Turning machine corresponds
to the hard wiring of the CPU, and the actual instructions are those on
the data strip.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <9pklhh$cs8$1@glue.ucr.edu>, thp@cs.ucr.edu wrote:
>: My view is only "extended" in that I view any address, not only heap
>: addresses, to be called "address".

>...at run time it will *have* an address and will be
>represented via its address, but it still won't *be* an address.

Right, a runtime object will have an address, but it is not that address:
The address is used to access the runtime object.

But one can also implement special runtime objects representing addresses,
which then will be object with new addresses.

>(Similarly, it will have a value, but it won't *be* its value.)

In this runtime model, I decide to entirely skip over the notion of
"value": Instead the "value" of a container will be represented by the
reference one gets on a "get data" request.

The computer language construct "value" (as in C++) corresponds to runtime
object that copies themselves by making a clone of themselves.

...
>Then call it an "address", not a "reference".

I like the terminology "reference" better than "address", because an
address seems to imply a passive location, whereas a reference is just a
component by which the object can be accessed. For example, if one has an
address to an address, that can be still be viewed as a single reference,
especially when one implements references as runtime objects.

>All C++ references can correctly be viewed as automatically
>dereferenced pointers.  That view, however, glosses over a few details
>regarding the PODness of structs and the automatic creation of
>temporaries when const references are initialized with rvalues, and so
>on.

>References are de facto immutable and their addresses cannot be
>determined.

I think this view will break down when adding a conservative GC, because
then objects may move around. Thus, some components of the references will
certainly mutate. And a similar thing may happen when adding distributed
programming.

>  When the value of reference is known at compile time, the
>as-if rule allows it to be optimized away in the output code.  But the
>same holds for any immutable pointer whose address isn't determined.

This is what I also think should be the correct view: That runtime data is
optimized away when static data is available.

Then the difference might be that C++ does not have any construct that
ensures that one can treat references as runtime data (in which case it
will have no runtime reference).

>Program get translates machine code.  The state of a variable gets
>represented somehow at runtime.  How it gets represented.  It might be
>represented differently at different points in the program.  In some
>portions of the program, the state of the variable might be
>determinable at compile time, in which case it might not occupy even a
>register but simply get represented as an immediate operand of certain
>instructions.

All you say here is that there is an ambiguity here in the translation of
a computer language into its runtime model. All it means that the
particular representation will vary in the sense that the same language
constructs may have several different representations in the machine code.

But in each single case, the translated representation will have an
address, even though the underlying object will vary.

>:>Three sentences above you talk about implementing references as
>:>objects, which you now view as processes.
>
>: If you have say a pice of data in a memory word, and view that as an
>: object, then you can also view it as a process, in view of that in order
>: to make use of that piece of data, you have to send a request for it. Then
>: for that process to work, you need to know where to send the request to
>: the object, the address or reference of it. So if you want to know what is
>: in that memory location, you send a request "get data" to what is viewed
>: as the object, and it responds with the data in that location. In reality,
>: the request will happen centralized over the CPU, but it is possible to
>: take this view, because for one thing, it will work with any number of
>: CPU's present.
>
>Many views and many treatments are possible.  The question is which
>ones are accurate and helpful.  IMHO, treating variables as
>references, either C++ reference or run-time addresses is misleading.
>Viewing them as processes is unhelpful.

Of course, the "variables" you are speaking about I figure are language
constructs, not runtime objects, as I was describing.

>: When I use the word "infinitesimal",
...
>In any case, you don't appeal to Merriam Webster as a "well-recognized
>technical reference" on the matter.

If you look up that dictionary for the definition of "infinitesimal", you
will find that it is pretty much what physicists use. In fact, if you look
into the newsgroup sci.physics.research you will find that there is a
thread "Definitions of physics" (which I did not start), departing from
general meanings of word.

So you seem to say that computer science does not follow the rules of all
other known sciences in this respect.

>: Returning to the original question, one could not say that the definition
>: of "process" in UNIX or "reference" in C++ is universal to all technical
>: literature.
>
>Exactly.  That's why I invited you to pick any well-recognized technical
>reference as a way to pin down the meanings of technical terms and get
>past all this HumptyDumptyism.

Does it not suffice with that I give my own definitions, in the case that
no other have been studied the things that I do?

I mean, the way I defined "process", UNIX processes are an example of a
process, but not every process is a UNIX process. It seems a very
acceptable use of words.

In the case of "references", C++ does not have a well focused runtime
notion of references, so it therefore I still think the word is fine for
use with runtime objects.

>: I just happened to be interested in the description of runtime
>: objects, and I found that terminology useful, because I know the word from
>: other contexts. I have never seen any description in computer literature
>: of such massively dynamic structures, and I think the reason is that
>: dynamic implementations become slow, so that computer scientists usually
>: avoid them. But we are heading that direction, in view of that computer
>: become more powerful.
>
>There was a very clear 1969 paper by Strachey on many of these issues.
>I'll see if I can find a reference it.

Any inputs are welcome.

>: The reason I got interested in that is that I, as a mathematician, want
>: things to be sufficiently general.
>
>The first requirement for such generality is precise terminology.

I think the problem is rather that the usual way to express semantics is
via a computer language, not via specifications on the runtime model. If
one is used to that former picture, it is confusing thinking about runtime
objects alone.

>: So if every expression has a runtime equivalent, then that is more general.
>
>Not imposing such a requirement is even more general.

By "general", I mean the capacity of being to maniupulate it in a
computer. So if there is not runtime of an expression, the expression
cannot be manipulated as an object, and it thus becomes more special.

For example, if one implements the lambda calculus in the form of a
functional language, then there is no way one can manipulate the lambda as
an object; this only becomes possible if the lambda calculus itself is
implemented as a runtime object.

Mathematicians arrive at this generality by treating structures as
objects: For example, first one discovers the natural integers, and later
one introduces a symbol N for them. Then N can be manipulated as an
object.

In a computer this corresponds to finding a representation for the natural
numbers, and then later introducing the N as a runtime object as well:
Then it can be manipulated as a runtime object.

So this way one can climb similar hierarchies of abstractions as in mathematics.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <9pku5m$fag$2@glue.ucr.edu>, thp@cs.ucr.edu wrote:
>: The main point is that it must be located somewhere, so it must have an
>: address.
>
>No!  It need not be located anywhere.  I can multiply by two by
>executing a one-bit shift.  Where's two?

The instruction that performs the bitshift must still be located somewhere:

The view of runtime objects that I have is that you have one object x
representing the number to be multiplied by two, and another object y with
the capacity of multiplying the number with two. Then one combines these
objects as y(x) or y(x) (depending on how one views the request to be
moved) to produce a references to an object with the value multiplied by
two. (I skip the details, because the a sequence of instructions can be
performed by special sequence objects.)

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> wrote in message
news:slrn9rqnjo.77j.qrczak@qrnik.zagroda...
>Thu,  4 Oct 2001 22:33:33 GMT, Francis Glassborow
<francis.glassborow@ntlworld.com> pisze:

>> C++ has a richer structure. Until you understand that C++ references are
>> not hidden pointers (even though they can be implemented that way) but
>> aliases for possibly already named objects you will continue to sow
>> confusion in your thoughts.

>What is the difference between "hidden pointer" and "alias"?

For example, one could treat an alias being bound to the name of
the variable or any way to access the object present at this alias
initialization. For example:

#define y (*(x))

Then this 'y' is an alias to '*x' no matter about what's pointed by 'x'.
This is totally different thing than the hidden pointer.

And the second thing -- if there is a reference to const, this pointer
could not exist at all if the object has local scope and you won't take
an address of it.

>IMHO references can be treated as hidden pointers without additional
>problems.

Maybe you're right, but I think this would enter some limitations in C++.
Or there should be either more optimizations for constant poitners allowed
or more optimization restrictions for references. First the references
can RETURN pointers and can GIVE pointes, so they also HAVE
their appropriate pointers, but can't BE pointers. The main reason
is that they are only the language term, which should not have any
run-time meaning, which is true for pointers instead.

> Doesn't matter that there is no reference equivalent of the
>null pointer

WHAT?
The reference is to an *object*. There is no sense to talk about the
reference made from the non-dereferenceable pointer value.
This is just simply invalid.

 - I'm not saying that an arbitrary pointer may be hidden
>that way.

A reference is not an arbitrary pointer. The reference is taken
from the pointer, which points to an object. If it's created
by dereferencing the non-dereferenceable pointer value,
this reference is invalid. But invalid is this *dereferencing*
of the pointer, not *using* this invalid reference.

--
((
 ))


---
[ 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.research.att.com/~austern/csc/faq.html                ]

Sun,  7 Oct 2001 11:41:13 GMT, Sektor van Skijlen <sektor@spam-buffer.aldec.com> pisze:

>     i = f();

> Now, the matter is about which types have the 'i' and 'f' in this
> expression.
> They are:
>
> f - has type: int (&f)();

No, f has type int()() or int() (it's not clear how to write it because
description of such type never occurs in C++ source in isolation) -
a function with no parameters returning int.

In most contexts this type promoted to int(*)(), with the exception of
the argument unary &, sizeof, and perhaps something other.

> i - has type: int&

It's not currently described that way (but perhaps could).
i is an lvalue of type int.

> The names are references. You can in this case take an address:
> with &f and &i.

f is certainly not a reference. It's explicitly said in [dcl.fct]
that the type of such identifier is a function of something returning
something, not a reference.

> 1. 'f' is a reference, because each function name is a reference.

Where the standard says this?

--
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZAST   PCZA
QRCZAK

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Sektor van Skijlen <sektor@spam-buffer.aldec.com> wrote:

: <thp@cs.ucr.edu> wrote in message news:9p9jpk$qoj$2@glue.ucr.edu...
[...]
:> Hmmmm.  f returns an *int value*, while i is an *int object*.  Neither of
:> them is a reference in the sense of C++.

: Not so fast...
: What do you mean that "f is" and the "i is"? In which aspect?
: In the sense of C++ that depends on how it's treated, in other words,
: how it is treated in the expression. What's the type of the subexpression
: these 'f' and 'i' are. For example:

:     i = f();

: Here you have:
: 1. an assignment to 'i'; operator= called for an int *object*.
: 2. a function call; there is an operator () called for the function
: reference.

: Now, the matter is about which types have the 'i' and 'f' in this
: expression.
: They are:

: f - has type: int (&f)();
: i - has type: int&

Say what?  The example we're discussing is:

     int f();
     int i;

In particular, i has been declared to be of type int, not int&.

: The names are references.

They are not references under the terminology of the C++ standard, and
they are not references in the sense of say Algol 68 literature, which
as far as I can tell uses the term "reference" with exactly the same
meaning as "object" in C/C++ literature.  So, I'm not sure what you
mean by "reference."

: You can in this case take an address: with &f and &i.
: You can do it, because 'f' and 'i' are references.
: In case they are not, it would be unable.

Perhaps you can cite where it says so.

: So why they are references?

: 1. 'f' is a reference, because each function name is a reference. This is
: implied
: by the condition, that you can take an address of any function (with some
: restrictions
: I don't remember now; in this case their names won't be references)

Citation please.

: 2. 'i' is a reference, because it's bound to a created object by the
: language construct.

AFIK, 'i' is an identifier, not a reference.  Nor, does it denote a reference.

: But remember: the 'i' name IS a reference in the expression shown above.

I don't recall it having been established that 'i' is a reference.

: So remember: 'i' is not an object. 'i' is a reference with a local object
: bound to.

Per the terminology of the C++ standard, 'i' is an identifier that designates
a particular object.  It is most definitely not a reference.

: You can also create another reference:

: int& x = i;

: which in this case is BOUND to the same object as 'i' (NOT "to 'i' ").

Correct.

: And in this case, the 'x' and 'i' are the same in any expression.

No.  It's quite possible for i to go out of scope while x is still within
scope.

[...]
: If you would treat the 'i' as an "int value" then you could mean, that
: "f( i )" makes a conversion from 'int' to 'int&'. Such a conversion is
: not allowed (for any type) unless you are calling a method for 'i'.

Lvalue-to-rvalue conversion allows i to be treated as an int value in
any context where an int value is appropriate.

Tom Payne

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Hans Aberg <remove.haberg@matematik.su.se> wrote:
: In article <9pku5m$fag$2@glue.ucr.edu>, thp@cs.ucr.edu wrote:
:>: The main point is that it must be located somewhere, so it must have an
:>: address.
:>
:>No!  It need not be located anywhere.  I can multiply by two by
:>executing a one-bit shift.  Where's two?

: The instruction that performs the bitshift must still be located somewhere:

: The view of runtime objects that I have is that you have one object x
: representing the number to be multiplied by two, and another object y with
: the capacity of multiplying the number with two. Then one combines these
: objects as y(x) or y(x) (depending on how one views the request to be
: moved) to produce a references to an object with the value multiplied by
: two. (I skip the details, because the a sequence of instructions can be
: performed by special sequence objects.)

You have claimed that values used in computations must have addresses.
But it is possible that conforming implemetations of C++ implement
multiplication via non-contiguous sequences of shifts and adds.  I
asked you where's the multiplier in such a case and you have evaded
the question by answering that "the bit shift has to be located
somewhere."

Tom Payne













---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <20011005160648.18744.00000595@nso-cv.aol.com>,
transwarpt@aol.com (TransWarpT) wrote:
>When, prior to C99, did C have references?

You seem to know it, right?

-- Then all problems with references is purely due to the C++ committee, then.

>>The method of always resolving a reference to a reference to a reference
>>is used by the MacOS, where it is called an "alias": Making an alias of an
>>alias makes it point at the original object, not the alias is was aliased
>>to. But it is still necessary sometimes to treat the alias as an object.
>
>The only MacOS "alias" that I know of is a HFS construct that has nothing to do
>with C++. Nor is it as simple as a reference to a reference to a reference. And
>just because accessing the second alias produces the original file doesn't mean
>it didn't go through the first alias.

I would not real on Mac terminology for making any other universal
terminology. :-)

But the MacOS has in its windows manager called the "Finder" a type of
links called "aliases", that when making the alias to an alias resolves to
the original object pointed at (but these are not UNIX hard links). (There
are also some kind of objects in the programming level of MacOS pre-X
called "aliases" but I do not mean those.) Thus it resolves a "reference
to a reference" into a reference, the new alias, but is not a reference to
a reference to a reference (perhaps you did not read the sentence
properly).

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Barry Kelly" <dynagen@eircom.net> wrote in message
news:7h1mrt09an7jsqr9h8ou5jp0piouaa64te@4ax.com...
> > AFIK, the int value returned by f and the int object i are not:
> >   - memory addresses (absolute or relative)
> >   - URLs
> >   - symbolic links.
>
> The value returned by f is a "reference to the concept of n-ness",
> where "n" is the integral value returned.
>
> For example:
>
>   int f() { return 2; }
>
> is a function returning a reference to the Universal concept of "2".

You are superfluously creating a new term, which is not needed in any
language. C++ has simple terms and they can become more simple.
That's why I felt able to say something.

This something, which is returned by 'f', is a VALUE. There's no other
term needed to name it. In case you have:

inline int f() { return 1 }

Is there any object created here to store the '1 value? Maybe it is,
but this object can be represented in any way towards the implementation.
So this "Universal concept" is an abstract term. Of course, you can
use references to abstract types, but using references to something
implies, that there is an object, which "somewhere" exists. If this '1
won't exist, this term loses its sense. In the case above, this expression:

int x = z + f();

can be compiled to the 'inc' assembler command on Intels, not to
any call and any value reading. As the value is known, it's used.
Values are not something existing at run-time. So you should not
be able to take an address from "value" (this would be implied,
if this '1' is a reference to anything).

Note, that the references to constant object could return an invalid
address, which using with legal methods won't imply any problems,
but would imply them if it's used beyond the language rules (for
example, when trying to const_cast it, this address will be an address
of not allocated memory).

> > The integer three is a value.  So, what's its address in any context?
AFIK,
> > the experssion &3 is ill formed in C/C++.

Of course it's ill-formed, because you can't use & with (int). You can
use it only for (T&) typed expressions, where T is any typename.
This '3' is an (int) typed expression, which can't be converted to int&.

> Of course, we can't take the address of a Universal Concept, as it
> were.

Is it not beter to state, that the & operator must take an expression
with 'T&' type ?

> Sorry for the high metaphysical content.

I prefer simple and strict definitions.

--
Regards,
((
 )) ektor


---
[ 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.research.att.com/~austern/csc/faq.html                ]

There is in the C++ standard many rules about lvalues and rvalues. I think
it's possible to make it short
and then easy to read and understand. For example:

1. Lvalue is a reference (T&). The reference type depends on object type in
declaration [e.g. can be const or volatile etc.]
2. Rvalue can (but need not to) have its reference [the class types, for
example should have them, because they can be
converted to lvalue -- see below; but this should not order each class
object to have a reference; only in case it is used.]
3. An lvalue can be converted to an rvalue. When a lvalue is of T& type,
then this rvalue is of T type.
4. An rvalue can be converted to an lvalue. In most cases, a T rvalue is
converted to an lvalue of 'const T&' type.
    When a method is called for an rvalue of type T (which can be 'X' or
'const X' or 'volatile X'), then inside this method
    this rvalue is converted to an lvalue of T& type.

There could remain some rules about the requirement and return values of
function, but it's all based on these rules above.
So this can be described in 6 to 10 (in worst case) points, instead of 20 or
more.

--
Regards,
((
 )) ektor


---
[ 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.research.att.com/~austern/csc/faq.html                ]

Sektor van Skijlen <sektor@spam-buffer.aldec.com> wrote:
: There is in the C++ standard many rules about lvalues and rvalues. I think
: it's possible to make it short
: and then easy to read and understand. For example:

: 1. Lvalue is a reference (T&).

Almost.  An lvalue is a certain kind of expression, namely one that
denotes an object, which means an expression is a syntactic entity, a
well-formed string of characters.

The Standards committee seems not to have figured out what references
are.  Everyone seems to agree that they are semantic entities that
refer to objects.  Some say they are names.  Some say they are
aliases.  Most agree that they aren't objects.  Most agree that if f
is declared

   int& f();

then f returns something that is different from a string of
characters, so it can't be an expression and it can't be a name (if
names are identifiers, as Stroustrup says they are).

: The reference type depends on object type in
: declaration [e.g. can be const or volatile etc.]

: 2. Rvalue can (but need not to) have its reference [the class types, for
                                           ^^^^^^^^^
Do you mean "address", which is a related but distinct notion.

: example should have them, because they can be
: converted to lvalue -- see below; but this should not order each class
: object to have a reference; only in case it is used.]

: 3. An lvalue can be converted to an rvalue. When a lvalue is of T& type,
: then this rvalue is of T type.

Consider the above declaration of f.  So, what is the type of a
subsequent occurrence of "f()"?  I think it starts out as an rvalue of
type int&, which becomes an lvalue of type int, which converts to an
int rvalue in rvalue contexts.  (But I'm not confident of that.)

: 4. An rvalue can be converted to an lvalue. In most cases, a T rvalue is
: converted to an lvalue of 'const T&' type.

You are probably referring to rvalue arguments for const-reference
parameters.  That's the only place I know of that happening.

:     When a method is called for an rvalue of type T (which can be 'X' or
: 'const X' or 'volatile X'), then inside this method
:     this rvalue is converted to an lvalue of T& type.

I presume that X is a class or struct type.  Then the object that the
rvalue designates will have a this-pointer and an address and will
appear as an object to its methods.  (Which is pretty much what you
said.)

: There could remain some rules about the requirement and return values of
: function, but it's all based on these rules above.
: So this can be described in 6 to 10 (in worst case) points, instead of 20 or
: more.

I agree that the C and C++ standards lack in consistency and
conciseness in their treatments of "lvalue", "rvalue", "object",
"value", "reference", etc.

Tom Payne




---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <9p0sf4$56i$1@glue.ucr.edu>, thp@cs.ucr.edu wrote:
>The Standards committee seems not to have figured out what references
>are.  Everyone seems to agree that they are semantic entities that
>refer to objects.  Some say they are names.  Some say they are
>aliases.  Most agree that they aren't objects.  Most agree that if f
>is declared
>
>   int& f();
>
>then f returns something that is different from a string of
>characters, so it can't be an expression and it can't be a name (if
>names are identifiers, as Stroustrup says they are).

My impression is that the C++ reference is a certain simple type of
binding: Roughly, (automatic) runtime objects are expected to have a
certain life-time, closely related to its syntactic definition in the
original C++ code. One can then reference an object during its so fixed
lifetime by means of some C++ constructs, but this referencing does not
change the life time of an object.

One should be aware of that this picture will change radically when
introducing a conservative GC (garbage collector) (like say a ref count):
Then one has a runtime system keeping track of the lifetime of objects, so
that they are alive as long as somebody bothers referencing them.

It is also possible to treat references as objects: Think for example of a
URL, which is a type of distributed reference. Then it is convenient to
allow the runtime system to treat URL's as objects.

So when C++ (as expected) adds support for conservative GC's and
distributed programming, its syntax must be changed accordingly to reflect
that.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Hans Aberg <remove.haberg@matematik.su.se> wrote:
[...]
: My impression is that the C++ reference is a certain simple type of
: binding: Roughly, (automatic) runtime objects are expected to have a

AFIK, "bindings" are not among the kinds of entities that the C++
standard recognizes.  I don't have my copy of the standard here, but
IIRC there is a list of about ten kinds of entities somewhere in the
first few pages.

: certain life-time, closely related to its syntactic definition in the
: original C++ code.

References have the same lifetimes as similarly declared objects, but
I have it on good authority that references are not objects.

: One can then reference an object during its so fixed
: lifetime by means of some C++ constructs, but this referencing does not
: change the life time of an object.

It might for certain temporaries.

[...]
: It is also possible to treat references as objects: Think for example of a
: URL, which is a type of distributed reference. Then it is convenient to
: allow the runtime system to treat URL's as objects.

: So when C++ (as expected) adds support for conservative GC's and
: distributed programming, its syntax must be changed accordingly to reflect
: that.

The standard argument against references being objects is that it is
(de facto) impossible to determine their addresses.  Of course, when a
function returns a pointer, that pointer doesn't have an address
either, in spite of the fact that K&R and Stroustrup state (in effect)
that pointers are address-valued objects.

The fact that we have working compilers shows that it is possible to
eventually makes sense out of the standard's specifications for
references.  In fact, if you think of references as automatically
dereferenced pointers, you have about 95% of the picture, and the rest
consists of exceptions and details.

IMHO, the problem is that the C/C++ policy of using the same type name
to designate both values and objects breaks down when it comes to
references.  Note for example that in

           int f();

the function f is said to return an int, while in

           int i;

the variable i is said to be an int.  But f returns something quite
different from what i is; for instance, i has an address, but not so
for entity returned by f.

This value/object ambiguity in type names is relatively harmless until
we get to object-valued objects, i.e., references.  Then it seems to
introduce a lot of confusion.  That confusion is surmountable, since
the standard handles the operational details of how references work.
But the conceptual confusion takes a toll on many of those who attempt
to understand the language.

IMHO, the lack of consistency and conciseness with which the standards
covers such matters are reflected in the introductory books on C++,
and the resulting confusion accounts in large part for the mass
defections to Java.  (Yes, I realize that Sun's hype was also at
work.)

Tom Payne

---
[ 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.research.att.com/~austern/csc/faq.html                ]

<thp@cs.ucr.edu> wrote in message news:9p3t8q$3vr$1@glue.ucr.edu...
> AFIK, "bindings" are not among the kinds of entities that the C++
> standard recognizes.  I don't have my copy of the standard here, but
> IIRC there is a list of about ten kinds of entities somewhere in the
> first few pages.

The matter is about the references being bindings. Not being something
existing in the memory.

> : certain life-time, closely related to its syntactic definition in the
> : original C++ code.
>
> References have the same lifetimes as similarly declared objects, but
> I have it on good authority that references are not objects.

What d'U mean "objects"? Is the object something that MUST exist
inside the memory? Or this is a strict, logical language-defined
creature, which has its sense only on the language level rather
than physical one. If you thing about object like the first one,
then you mean, that each object is of reference type and
in the same way, each object is lvalue.

In another way, if you mean object a language-defined creature,
then references can also be objects and this fact does not
imply their in-memory existence. In this order, that also does not
imply them to have... references. As you know, you can't create
a reference to a reference, so it's obvious that references
themselves are just simply not lvalues. Which fact does not
imply them not to be objects. They are always rvalues.

When a function returns a reference, it returns rvalue.
But this one the function returns is an object. But the role
of this object is only to redirect each request into an
object it refers to. That's the way you can't think about
the C++ objects as any creatures existing in memory.
They are only language creatures. You can't also,
because some objects can be optimized out by
the compiler ;)

Getting an address of reference variables is also impossible.
So, according to standard, are the reference variables lvalues?

int x;
int& r = x;
r = 12;

Can you in this case think about the reference variable as an object?
It's obvious, that's tight.
But can you think about it as the lvalue?

Hmm... this is not so simple. If you mean just simply the 'r' name,
then this 'r' is really not an lvalue; it's only just a reference.
But each use of 'r' is the same as use if 'x' with a precondition
that both 'r' and 'x' won't change their bindings.

So, what's the difference here between 'r' and 'x'?

Sad, but true answer: there's NO difference (but the name).
The 'x' declaration creates a local object and gives it a binder
named 'x'. The declaration of 'r' uses ALREADY EXISTING
REFERENCE to do the same thing (the reference constructor
takes only another reference as an argument, which should be
of the compatible type; no other constructor for it is
avaiable). One characteristic thing about 'x' is that its presistence
(or lifetime as you said) is the same as the object it's bound to.

So, what's returned in this case:

int& f();

There's returned a rvalue (because functions can't return lvalues),
which is a reference bound to some lvalue. So accessing
this rvalue means accessing the lvalue this reference is bound to.
In a shortcut, you can say just simply "function returns lvalue".
AFAIR, the standard also uses such a statement.

> : One can then reference an object during its so fixed
> : lifetime by means of some C++ constructs, but this referencing does not
> : change the life time of an object.
>
> It might for certain temporaries.

In fact, the reference object persistence does not imply a persistence
for the object it's bound to. It's true only for several cases. For example:

int x; // x has the same persistence as an object it refers to

X f();
const int X& x = f(); // the temporary object gets the x's persistence

const X& f();
const int X& x = f(); // the reference persistence overrides the object
persistence
And in this case, after this statement is finished, the 'x' reference is
invalid,
because the object it's bound to, does not exist.

So, as you see, only automatic objects (local, global, a structure field)
have references persistence bound to an object persistence. But in
general, there's no rule about this persistence binding.

> The standard argument against references being objects is that it is
> (de facto) impossible to determine their addresses.

But what IYO will this fact imply? You can't call methods for references,
so there's no possibility to convert T to T& when T is X&. You can
convert T to const T&, but this can pass only if you call a function
requiring this argument type and you pass a reference; of course
it's a defect, but there's a proposition to glue multiple &'s into
one, which will be probably added.

> Of course, when a
> function returns a pointer, that pointer doesn't have an address
> either, in spite of the fact that K&R and Stroustrup state (in effect)
> that pointers are address-valued objects.

Not in each case. They are objects if you treat them as object,
in other words (taking your meaning about objects), they are
"forced" to have a reference. But it's NOT possible to force
ANY object to have a reference but calling a method for it.
You can't call a method for a pointer object, so you can't
convert it to a reference type. Only to a const reference.
Of course, this won't disallow you to take an address from:

K* f();

const K*& k = f();
K** p = &k;

Yes, that's true, but this is possible only because you
can take an address from this object. Reference objects
are not possible to that. So there's do dillema, what will
imply the fact that references (as rvalues) will be objects.

> The fact that we have working compilers shows that it is possible to
> eventually makes sense out of the standard's specifications for
> references.  In fact, if you think of references as automatically
> dereferenced pointers, you have about 95% of the picture, and the rest
> consists of exceptions and details.

I don't understand. Is that wrong? I think it's a good meaning about
references. But I'd rather think about a reference being in each
case an interface to an existing object and being in fact a value,
which is effected by dereferencing a pointer.

> IMHO, the problem is that the C/C++ policy of using the same type name
> to designate both values and objects breaks down when it comes to
> references.

That's not true at all.

>  Note for example that in
>
>            int f();
>
> the function f is said to return an int, while in
>
>            int i;
>
> the variable i is said to be an int.

YES. The VARIABLE 'i' is of 'int' type, but the type of the
expression written as 'i' is int&, not 'int'. This is not C ;)

> But f returns something quite
> different from what i is; for instance, i has an address, but not so
> for entity returned by f.

Yes. This is the difference. The difference is in the type of an expression.
For variables it's NOT the same as the type of a variable. The variable
type is a type of its VALUE, which means, what type will be received
if this variable will be read. Not just simply "accessed". Because
accessing can be performed also with the assignment operator
and in this case it will have an 'int&' type.

By the way -- some time ago I tried to tell about the conversion
from T to T& inside a method call, which is a weird exception
for rvalue -> lvalue conversions, which in most cases can be
perforned only from T to const T&.
It's possible for class objects such a thing:

T f();

f() = T();

where the = operator is defined in the right, standard way,
without const, returning T& and receiving const T&.
When you try that with POD types, this will effect an error,
because the returned value is an rvalue. That's right.
But the assignment operator is a method for class objects.
So for class objects it's possible to assign even if they
are... rvalues! This is implied by the rule, that rvalues of T
can be converted to lvalues of T& inside a method.
Assigment operator IS such a thing EVEN you won't
declare it. ;)

This is an inconsistence; C won't let you assign in any
case for this example. C++ won't let you assign for
POD types, also for enum types, but will let you
for any structural type.

One interresting thing more: you can return 'const T'
instead of 'T'. In this case you'll prevent converting
the result to T&. And, which also can be interresting,
it's the only difference between const T and T in function
return (because const has an importance only for references).

> This value/object ambiguity in type names is relatively harmless until
> we get to object-valued objects, i.e., references.  Then it seems to
> introduce a lot of confusion.  That confusion is surmountable, since
> the standard handles the operational details of how references work.
> But the conceptual confusion takes a toll on many of those who attempt
> to understand the language.

And that's the reason I think about making these terms and rules
simple, strict and consistent.

> IMHO, the lack of consistency and conciseness with which the standards
> covers such matters are reflected in the introductory books on C++,
> and the resulting confusion accounts in large part for the mass
> defections to Java.  (Yes, I realize that Sun's hype was also at
> work.)

You know, I think C++ is possible to become more consistent,
because it has definitions, which can drive it to (references
are an example). For Java it's not possible, because the people
creating and developing it did not understand the C++ terms
and system at all. Yes, I know it's not so simple (trying to read
the standard rules), but in this case the unknown C++ effected
a language, which's less complicated at sight and in terms
and rules more complicated, exceptioned, and defected.

--
Best regards,
((
 )) ektor



---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Sektor van Skijlen" <sektor@spam-buffer.aldec.com> writes:

| > : certain life-time, closely related to its syntactic definition in the
| > : original C++ code.
| >
| > References have the same lifetimes as similarly declared objects, but
| > I have it on good authority that references are not objects.
|
| What d'U mean "objects"? Is the object something that MUST exist
| inside the memory? Or this is a strict, logical language-defined
| creature, which has its sense only on the language level rather
| than physical one. If you thing about object like the first one,
| then you mean, that each object is of reference type and
| in the same way, each object is lvalue.

The meaning of "object" is precisely defined by C++.  See
'1.8 The C++ object model'. Among other things, it says

   An object is a region of storage.

And the same document implies that "references are not objects".

[...]

|  For Java it's not possible, because the people
| creating and developing it did not understand the C++ terms
| and system at all.

On a technical forum such as this, a statement like the above should
be backed up by *facts*.  Do you have facts to support your claims?

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <9p3t8q$3vr$1@glue.ucr.edu>, thp@cs.ucr.edu wrote:
>AFIK, "bindings" are not among the kinds of entities that the C++
>standard recognizes.  I don't have my copy of the standard here, but
>IIRC there is a list of about ten kinds of entities somewhere in the
>first few pages.

The C++ references are quite primitive: There are some syntactic
constructs which aims at making sure that the objects are alive as long as
one is able to reference it, but I do not think that is completely true.
So they do not "bind" if that is meant that the objects by the binding
should be kept alive.

>: One can then reference an object during its so fixed
>: lifetime by means of some C++ constructs, but this referencing does not
>: change the life time of an object.
>
>It might for certain temporaries.

I think that the C++ standard tries to ensure that the temporaries live
sufficiently long for references to be valid, but that is all. There is no
way to affect the lifetime of an object by a reference.

>The standard argument against references being objects is that it is
>(de facto) impossible to determine their addresses.  Of course, when a
>function returns a pointer, that pointer doesn't have an address
>either, in spite of the fact that K&R and Stroustrup state (in effect)
>that pointers are address-valued objects.
>
>The fact that we have working compilers shows that it is possible to
>eventually makes sense out of the standard's specifications for
>references.  In fact, if you think of references as automatically
>dereferenced pointers, you have about 95% of the picture, and the rest
>consists of exceptions and details.

I have developed a model (not directly related to the C++ paradigm) which
gives a dynamic treatment of concepts like "object" and "reference":

Then an _object_ is defined to something that can be addressed. A
_reference_ merely means that the address somehow, explicitly or
implicitly, is known.

Of course, and address need not be a hexadecimal style machine address (a
hard link), but could say be a URL or a soft link. One then needs to
classify different types of addresses, that is different methods of
referencing objects.

>IMHO, the problem is that the C/C++ policy of using the same type name
>to designate both values and objects breaks down when it comes to
>references.  Note for example that in
>
>           int f();
>
>the function f is said to return an int, while in
>
>           int i;
>
>the variable i is said to be an int.  But f returns something quite
>different from what i is; for instance, i has an address, but not so
>for entity returned by f.

So in this case, one is merely dealing with different types of references.

Also note that when using dynamic bindings, some uses of syntactic
reference constructs in C++ become redundant: For example,
  int x = 5;
  int& y = x;
In C++, this means that "y is a reference to x", and that "x has the value
5" or something. However, with dynamic bindings in place, one could let
the assignment "=" mean "another reference. Then one would instead write
  int x = 5;
  int y = x; // Another reference to the object 5.
If one would want to have an independent copy of 5, then one would have to write
  int z = clone(5);

Strictly speaking, as cloning is sometimes faster than handing over a
reference, I decided that
  w = x;
should mean that w is bound to a "copy" of the reference that x references
to. Then, by a "copy" is meant either a clone (state independent copy) or
a reference (address to the same object) in a manner determined by the
object by which the assignment "=" refers to. So in the case of an "int",
"copy" would probably mean to clone, whereas for a file, it would probably
mean to hand over a reference (even though files can be cloned).

If in addition references can be treated as objects, then if one want to
have another reference to a file, one might perhaps write
  ifstream u;
  reference v;
  ...
  v = reference(u);
This would mean that a reference object of the file u is created, and then
this is assigned to v. The reference object may then be cloned or handed
over as a reference by the "=" depending on how the "reference" objects
are implemented, but in the end, v will reference the same file as u.

On the other hand,
  ifstream u;
  ifstream w;
  w = u;
may either mean (depending on the semantic model chosen for files) that w
is a reference to the same file as v or a clone. For files, the former
seems to be more prudent, and one would have to write
  w = clone(v);
in order to get a state independent copy.

(Also, some object cannot be cloned, so in a runtime system, one would
have to throw an exception in case one attempts to clone such an object.)

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Hans Aberg <remove.haberg@matematik.su.se> wrote:
: In article <9p3t8q$3vr$1@glue.ucr.edu>, thp@cs.ucr.edu wrote:
[...]
: I think that the C++ standard tries to ensure that the temporaries live
: sufficiently long for references to be valid, but that is all. There is no
: way to affect the lifetime of an object by a reference.

These two sentences seem to contradict each other.

[...]
:>IMHO, the problem is that the C/C++ policy of using the same type name
:>to designate both values and objects breaks down when it comes to
:>references.  Note for example that in
:>
:>           int f();
:>
:>the function f is said to return an int, while in
:>
:>           int i;
:>
:>the variable i is said to be an int.  But f returns something quite
:>different from what i is; for instance, i has an address, but not so
:>for entity returned by f.

: So in this case, one is merely dealing with different types of references.

Hmmmm.  f returns an *int value*, while i is an *int object*.  Neither of
them is a reference in the sense of C++.

: Also note that when using dynamic bindings, some uses of syntactic
: reference constructs in C++ become redundant: For example,
:   int x = 5;
:   int& y = x;
: In C++, this means that "y is a reference to x", and that "x has the value
: 5" or something. However, with dynamic bindings in place, one could let
: the assignment "=" mean "another reference. Then one would instead write
:   int x = 5;
:   int y = x; // Another reference to the object 5.
: If one would want to have an independent copy of 5, then one would have to write
:   int z = clone(5);

That sounds similar to the so-called "reference semantics" that found
in various languages other than C++.  (I've wondered whether it might
be possible to define a template class ref<T> that behaved somewhat
like the references in say Java.)

Tom Payne






















---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <9p9jpk$qoj$2@glue.ucr.edu>, thp@cs.ucr.edu wrote:
>: I think that the C++ standard tries to ensure that the temporaries live
>: sufficiently long for references to be valid, but that is all. There is no
>: way to affect the lifetime of an object by a reference.
>
>These two sentences seem to contradict each other.

If your mind gets confused and you do not explain why, it is hard to
provide a proper response. :-)

I think that the standard says how long a temporary must live, and the
rules for C++ "&" references are such that the temporaries should be alive
during the time one may bother to reference them. -- But I am not sure
this is always true, that is, sometimes one may bind to a temporary
object, the temporary object dies, and one ends up with an invalid
reference, even though I cannot recall any immediate examples.

By contrast, in a conservative GC system, one knows that the binding a
reference does affect the life time of the object: Namely as long there is
a binding, the runtime system will make sure the object is alive.

>:>in
>:>           int f();
>:>the function f is said to return an int, while in
>:>           int i;
>:>the variable i is said to be an int.  But f returns something quite
>:>different from what i is; for instance, i has an address, but not so
>:>for entity returned by f.

>: So in this case, one is merely dealing with different types of references.

>Hmmmm.  f returns an *int value*, while i is an *int object*.  Neither of
>them is a reference in the sense of C++.

I said I did not use C++ terminology: A "reference" is a form of address
(absolute or relative memory address, URL, symbolic link, etc.).

A value is, the way I defined it, an object whose address and addressing
is implicitly known in the given context. This should correspond to the
traditional use of "value" in languages like C++.

Typically the object is recopied, and what one knows is that one gets a
copy of the original object.

In the case of
    int f();
the return value does have an address, namely typically the location on
the parameter stack. This is not a regular absolute memory address though,
as opposed to the case of
    int i;
So both are references, only that the type of reference, or address is
different.

>: However, with dynamic bindings in place, one could let
>: the assignment "=" mean "another reference. Then one would instead write
>:   int x = 5;
>:   int y = x; // Another reference to the object 5.
>: If one would want to have an independent copy of 5, then one would have
>to write
>:   int z = clone(5);

>That sounds similar to the so-called "reference semantics" that found
>in various languages other than C++.  (I've wondered whether it might
>be possible to define a template class ref<T> that behaved somewhat
>like the references in say Java.)

I do build such objects corresponding to a ref<T> class. The classes are
in a polymorphic hierarchy though, so I do not need to make use of
templates.

Also, one may make use of more than one type of reference, for example,
"unboxed" (no extra pointer, or no handle) and "boxed" (one extra pointer,
using a handle). If objects should vary in size, then if they should grow,
one must use one extra pointer so that the reference can mutate. However,
as this is slower, for small objects (below a certain fixed size), one may
use without an handle (if the data can fit into the handle itself).

So for such reasons, it is best to pass to a more abstract concept of a
"reference" which takes into account that there are many ways to reference
an computer object.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Sektor van Skijlen <sektor@spam-buffer.aldec.com> wrote:
: <thp@cs.ucr.edu> wrote in message news:9p3t8q$3vr$1@glue.ucr.edu...
:> AFIK, "bindings" are not among the kinds of entities that the C++
:> standard recognizes.  I don't have my copy of the standard here, but
:> IIRC there is a list of about ten kinds of entities somewhere in the
:> first few pages.

: The matter is about the references being bindings.

I understood the matter to be about "lvalues == references", which naturally
raises questions about what lvalues and references are.

: Not being something existing in the memory.

It makes a difference whether lvalues and/or references can or must
exist in memory.

:> : certain life-time, closely related to its syntactic definition in the
:> : original C++ code.
:>
:> References have the same lifetimes as similarly declared objects, but
:> I have it on good authority that references are not objects.

: What d'U mean "objects"?  Is the object something that MUST exist
: inside the memory?  Or this is a strict, logical language-defined
: creature, which has its sense only on the language level rather
: than physical one.

AFIK, the version of "object" described in the C++ standard is an
attempt to specify at the language level those properties that one
normally expects from a segment of memory that contains a data value.

: If you thing about object like the first one,
: then you mean, that each object is of reference type and
: in the same way, each object is lvalue.

Huh?  Certainly an int variable is not of reference type, even though
it is an object.

: In another way, if you mean object a language-defined creature,
: then references can also be objects and this fact does not
: imply their in-memory existence.

Many members of the committee that designed and specified the C++
language have insisted in this newsgroup that "references are not
objects."  If we believe that "object" is a language-defined notion,
then we should take their word for it.

: In this order, that also does not imply them to have... references.

I'm not sure what it means for an object to "have a reference."  Of
course, every object has an *address*, but that's another notion.  An
object may or may not be the referent of a reference.

: As you know, you can't create
: a reference to a reference, so it's obvious that references
: themselves are just simply not lvalues. Which fact does not
: imply them not to be objects. They are always rvalues.

: When a function returns a reference, it returns rvalue.
: But this one the function returns is an object. But the role
: of this object is only to redirect each request into an
: object it refers to.


That's where the normal rvalue/lvalue paradigms start to break down.
A value of a reference type *is* (or spontaneously converts into) an
object of the referent type.

Consider the function int& f(){ return i; }.  Obviously i is an object
and the experssion "f()" is an lvalue denoting that object.  It is
correct to say that "f returns a reference to an int object", or that
"f returns an int object by reference", or more simply that "f return
an int object".  It is not correct, however, to say that "f returns
a reference object".

: That's the way you can't think about
: the C++ objects as any creatures existing in memory.
: They are only language creatures. You can't also,
: because some objects can be optimized out by
: the compiler ;)

The as-if rule allows such optimization, in either case.

: Getting an address of reference variables is also impossible.
: So, according to standard, are the reference variables lvalues?

: int x;
: int& r = x;
: r = 12;

: Can you in this case think about the reference variable as an object?

Of course I can.  In fact, I do.  But the committee members say that's
at odds with (the intent of) the standard.

: It's obvious, that's tight.
: But can you think about it as the lvalue?

: Hmm... this is not so simple. If you mean just simply the 'r' name,
: then this 'r' is really not an lvalue;

An occurrence of "r" is an lvalue that designates an int object, not a
reference object.

: it's only just a reference.
: But each use of 'r' is the same as use if 'x' with a precondition
: that both 'r' and 'x' won't change their bindings.

: So, what's the difference here between 'r' and 'x'?

: Sad, but true answer: there's NO difference (but the name).
: The 'x' declaration creates a local object and gives it a binder
: named 'x'. The declaration of 'r' uses ALREADY EXISTING
: REFERENCE to do the same thing (the reference constructor
: takes only another reference as an argument, which should be
: of the compatible type; no other constructor for it is
: avaiable). One characteristic thing about 'x' is that its presistence
: (or lifetime as you said) is the same as the object it's bound to.

There can be considerable difference between a reference and its
referent.  For example, they may have distinct lifetimes, and references
can dangle just like pointers.

: So, what's returned in this case:

: int& f();

: There's returned a rvalue (because functions can't return lvalues),
: which is a reference bound to some lvalue. So accessing
: this rvalue means accessing the lvalue this reference is bound to.
: In a shortcut, you can say just simply "function returns lvalue".

I agree, but with the following caution: you are using the terms
"rvalue" and "lvalue" in the sense in which they are used in the
programming-languages community at large, not in the syntactic sense
that is used by the C/C++ community.

: AFAIR, the standard also uses such a statement.

I suspect/hope that the standard is consistent in its view that
rvalues and lvalues are expressions, not values.

:> : One can then reference an object during its so fixed
:> : lifetime by means of some C++ constructs, but this referencing does not
:> : change the life time of an object.
:>
:> It might for certain temporaries.

: In fact, the reference object persistence does not imply a persistence
: for the object it's bound to. It's true only for several cases.

Exactly as I said.

: For example:

: int x; // x has the same persistence as an object it refers to

In C/C++ terminology, x is not a reference but rather an int object.
You seem to have slipped into the Algol 68 paradigm, where "reference"
means the same thing that "object" means in C/C++.

: X f();
: const int X& x = f(); // the temporary object gets the x's persistence

Good example.

: const X& f();
: const int X& x = f(); // the reference persistence overrides the object
: persistence
: And in this case, after this statement is finished, the 'x' reference is
: invalid,
: because the object it's bound to, does not exist.

: So, as you see, only automatic objects (local, global, a structure field)
: have references persistence bound to an object persistence. But in
: general, there's no rule about this persistence binding.

Huh?

:> The standard argument against references being objects is that it is
:> (de facto) impossible to determine their addresses.

: But what IYO will this fact imply? You can't call methods for references,
: so there's no possibility to convert T to T& when T is X&. You can
: convert T to const T&, but this can pass only if you call a function
: requiring this argument type and you pass a reference; of course
: it's a defect, but there's a proposition to glue multiple &'s into
: one, which will be probably added.

:> Of course, when a
:> function returns a pointer, that pointer doesn't have an address
:> either, in spite of the fact that K&R and Stroustrup state (in effect)
:> that pointers are address-valued objects.

: Not in each case. They are objects if you treat them as object,
: in other words (taking your meaning about objects), they are
: "forced" to have a reference.

Do you mean "address" or "reference"?  Those are different notions.

Tom Payne

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Hans Aberg <remove.haberg@matematik.su.se> wrote:
: In article <9p9jpk$qoj$2@glue.ucr.edu>, thp@cs.ucr.edu wrote:
:>: I think that the C++ standard tries to ensure that the temporaries live
:>: sufficiently long for references to be valid, but that is all. There is no
:>: way to affect the lifetime of an object by a reference.
:>
:>These two sentences seem to contradict each other.

: If your mind gets confused and you do not explain why, it is hard to
: provide a proper response. :-)

The first sentence seems to say that certain temporaries live longer
if they are the referent of a reference.  The second sentence seems to
say that being the referent of a reference has no effect on the
lifetime of an object.  You can't have it both ways.

[...]
:>:>in
:>:>           int f();
:>:>the function f is said to return an int, while in
:>:>           int i;
:>:>the variable i is said to be an int.  But f returns something quite
:>:>different from what i is; for instance, i has an address, but not so
:>:>for entity returned by f.

:>: So in this case, one is merely dealing with different types of references.

:>Hmmmm.  f returns an *int value*, while i is an *int object*.  Neither of
:>them is a reference in the sense of C++.

: I said I did not use C++ terminology: A "reference" is a form of address
: (absolute or relative memory address, URL, symbolic link, etc.).

AFIK, the int value returned by f and the int object i are not:
  - memory addresses (absolute or relative)
  - URLs
  - symbolic links.
Algol68 uses "reference" as a synonym for what C/C++ calls "object", so
from that perspective i is a reference to an integer.

: A value is, the way I defined it, an object whose address and addressing
: is implicitly known in the given context.
: This should correspond to the traditional use of "value" in languages like
: C++.

The integer three is a value.  So, what's its address in any context?  AFIK,
the experssion &3 is ill formed in C/C++.

: Typically the object is recopied, and what one knows is that one gets a
: copy of the original object.

: In the case of
:     int f();
: the return value does have an address, namely typically the location on
: the parameter stack.

What if it's returned in a register, and registers don't have addresses?

: This is not a regular absolute memory address though,
: as opposed to the case of
:     int i;
: So both are references, only that the type of reference, or address is
: different.

I guess I need to ask, what isn't a reference under this model?

Tom Payne



























---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <9pai96$6cs$2@glue.ucr.edu>, thp@cs.ucr.edu wrote:
>:>: I think that the C++ standard tries to ensure that the temporaries live
>:>: sufficiently long for references to be valid, but that is all. There is no
>:>: way to affect the lifetime of an object by a reference.
>:>
>:>These two sentences seem to contradict each other.

>The first sentence seems to say that certain temporaries live longer
>if they are the referent of a reference.

Right.

>  The second sentence seems to
>say that being the referent of a reference has no effect on the
>lifetime of an object.

Right.

>  You can't have it both ways.

Sure: The syntax of C++ tries to make sure that references are not used in
a way that they become invalid in the runtime model. But if you decide to
introduce a C++ "&" reference or not will not affect the life-time of the
temporary.

>:>:>           int f();
>:>:>           int i;

>AFIK, the int value returned by f and the int object i are not:
>  - memory addresses (absolute or relative)
>  - URLs
>  - symbolic links.

The return value of f is typically put onto the parameter stack for the
next function to operate on it. So it does have an address relative to the
stack pointer. Similarly, "i", depending whether it is put onto the stack
or the heap will have a location relative the stack pointer or the heap
pointer or an absolute memory address.

>Algol68 uses "reference" as a synonym for what C/C++ calls "object", so
>from that perspective i is a reference to an integer.

I decided that "object" is a process with an input and output. In this
model, also the behavior under copying is included.

So the main point is not (the way I see it) in the difference between the
Algol68 and C++ of references as address, but in how you decide to copy
the object: In C++, a "value" refers to an object that is cloned.

>The integer three is a value.  So, what's its address in any context?  AFIK,
>the experssion &3 is ill formed in C/C++.

You need to separate out language constructs that have a runtime
representation from those that do not:

If "3" has a runtime representation, clearly it has an address, as it must
be located somewhere in the computer.

>What if it's returned in a register, and registers don't have addresses?

All objects in a computer must have some kind of address, otherwise they
cannot be accessed, right? :-) The CPU knows how to manipulate the
registers, so it must be able to address those registers.

The question is really what type of addresses that should be made
explicitly available via language constructs in C++:

For example, it is convenient to speak about "values", which are objects
whose addresses never are made explicit, because there is an efficient
computer implementation for handling those. The same applies to registers.

If one should go to the extreme that references of objects can always be
done, then one should have special language constructs for that. C++
already does that, in the difference between
    void f(int);
and
    void g(int&);
In the first case, one merely recopies the object at need, and by the
language construct one has said that one will not bother about the address
of the original object, as opposed to the second case, where one has said
that one will bother about its address. One does, however, not know what
kind of address this is, if it is on the stack or heap, or whatever.

>I guess I need to ask, what isn't a reference under this model?

Well, an object is not a reference: It is some piece of data that sits
somewhere and can respond to inputs by outputs. The same object can
several different references, as well as several different types of
references. And one may implementations for references as objects.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <remove.haberg-0210011202200001@du142-226.ppp.su-
anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
>If "3" has a runtime representation, clearly it has an address, as it must
>be located somewhere in the computer.

I think this is false. Clearly '3' is somehow represented but it can be
as part of an assembler instruction for which there is no address from
the programmer's perspective. And, unless the programmer does something
that explicitly requires '3' occupy data storage, there is no
requirement that it has an address.

Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Hans Aberg <remove.haberg@matematik.su.se> wrote:
: In article <9pai96$6cs$2@glue.ucr.edu>, thp@cs.ucr.edu wrote:
[...]
:>The first sentence seems to say that certain temporaries live longer
:>if they are the referent of a reference.

: Right.
[...]
: But if you decide to introduce a C++ "&" reference or not will not affect
: the life-time of the temporary.

Either living longer is an effect or it isn't.

:>:>:>           int f();
:>:>:>           int i;

:>AFIK, the int value returned by f and the int object i are not:
:>  - memory addresses (absolute or relative)
:>  - URLs
:>  - symbolic links.

: The return value of f is typically put onto the parameter stack for the
: next function to operate on it. So it does have an address relative to the
: stack pointer.

: Similarly, "i", depending whether it is put onto the stack
: or the heap will have a location relative the stack pointer or the heap
: pointer or an absolute memory address.

So what?  Having an address and being an address are quite distinct
notions.

:>Algol68 uses "reference" as a synonym for what C/C++ calls "object", so
:>from that perspective i is a reference to an integer.

: I decided that "object" is a process with an input and output.

And, references are PIDs?  ;-)

[...]
:>What if it's returned in a register, and registers don't have addresses?

: All objects in a computer must have some kind of address, otherwise they
: cannot be accessed, right? :-) The CPU knows how to manipulate the
: registers, so it must be able to address those registers.

Generally CPUs access registers via uniquely assigned bit strings, but
those bit strings are not "addresses" in the sense in which the term
is used in architecture and programming languages -- there is no way
to use a bit string in the data space to access the corresponding
register.

: The question is really what type of addresses that should be made
: explicitly available via language constructs in C++:

: For example, it is convenient to speak about "values", which are objects
                                                                   ^^^^^^^
The C++ standard uses the word "entity".  In C/C++ terminology, an
object is a special kind of entity, i.e., a data entity having an
address in the conventional sense.  (I don't necessarily like that
terminology, but in a technical forum where terms have been given
somewhat precise definitions by official documents, one should try to
avoid avoid alternate uses of those terms.)

Tom Payne






















---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <5p7L2JAQiau7EwAF@ntlworld.com>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:
>>If "3" has a runtime representation, clearly it has an address, as it must
>>be located somewhere in the computer.
>
>I think this is false. Clearly '3' is somehow represented but it can be
>as part of an assembler instruction for which there is no address from
>the programmer's perspective. And, unless the programmer does something
>that explicitly requires '3' occupy data storage, there is no
>requirement that it has an address.

I guess that the assembler instruction containing the "3" must be located
somewhere, and thus can be treated as a data object. In pseudo-C++, it
would correspond to a
  class assembler_instruction {
    int n;
  ...
    void evaluate();
  };
where evaluate() is used by the CPU to activate the instruction.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <9pcphq$rtm$1@glue.ucr.edu>, thp@cs.ucr.edu wrote:

>Hans Aberg <remove.haberg@matematik.su.se> wrote:
>: In article <9pai96$6cs$2@glue.ucr.edu>, thp@cs.ucr.edu wrote:
>[...]
>:>The first sentence seems to say that certain temporaries live longer
>:>if they are the referent of a reference.
>
>: Right.
>[...]
>: But if you decide to introduce a C++ "&" reference or not will not affect
>: the life-time of the temporary.
>
>Either living longer is an effect or it isn't.

Sorry, the first "right" was wrong; it should be "wrong" :-) :

My impression is that in C++, binding to reference does not extend the
lifetime of an object, because the syntax aims at securing a sufficiently
long lifetime for the references that are possible. By contrast, when
using objects maintained by a conservative GC, it does not matter how
objects are bound, because the GC will only remove objects with no
reference bound.

For example, in C++ the following should be illegal
    A& f() { return A(); }
because there is no way to ensure that the returned A& lives sufficiently
long by syntactic means alone. But with a conservative GC in place, this
is no problem.

>So what?  Having an address and being an address are quite distinct
>notions.

I really do not understand what you mean here, because I say that objects
have addresses, or references, but they are not themselves addresses: One
can implement addresses as objects, but that is not always the case.

>: I decided that "object" is a process with an input and output.
>
>And, references are PIDs?  ;-)

No, "process" is not the UNIX concept here (which I think would be better
called a "program" as opposed to say "threads" and other computational
processes), but refers to its usual semantics, a black box which one can
provide an input and the response will be an output. Use a different name
than "process" if you want to want avoid confusion with the UNIX concept.

>: All objects in a computer must have some kind of address, otherwise they
>: cannot be accessed, right? :-) The CPU knows how to manipulate the
>: registers, so it must be able to address those registers.
>
>Generally CPUs access registers via uniquely assigned bit strings, but
>those bit strings are not "addresses" in the sense in which the term
>is used in architecture and programming languages -- there is no way
>to use a bit string in the data space to access the corresponding
>register.

I think by an "address" you tacitly mean a "memory address", but I am not
sure that is an assumption one always can make even in hardware design.

Clearly, CPU registers have (register) addresses, or a "designation of a
place" as my dictionary defines it. Then one has to make a difference
between the _address_, that is, the place designation, and the
_addressing_, how to manipulate what resources made available in that
location.

You are saying that registers are not having addresses, because the only
way they are made available are via assembler instructions with the
addresses embedded. But there is no difference between memory addresses
and register addresses in this respect: Just as one can create a memory
location, or a data type, referring to memory addresses, one can create
data types referring to register locations, if one so want. Then the CPU
hardware architecture sets the limits as to what manipulations are
possible of those objects.

>: For example, it is convenient to speak about "values", which are objects
>                                                                   ^^^^^^^
>The C++ standard uses the word "entity".  In C/C++ terminology, an
>object is a special kind of entity, i.e., a data entity having an
>address in the conventional sense.

So the terminology I use is to expect those C++ "entities" to be "objects"
by not restricting "address" meaning solely "memory address".

>I don't necessarily like that
>terminology, but in a technical forum where terms have been given
>somewhat precise definitions by official documents, one should try to
>avoid avoid alternate uses of those terms.

I explicitly indicated that the terminology may or may not agree with C++
usage. It is of course important to clearly separate what is C++
terminology and what is not. But it is also hard to see that the C++
terminology should be used as definitions in contexts not within the scope
of that standard: Clearly, if the C++ terminology is wrong or too limited
relative other usages, then one may consider changing the C++ terminology.

For example, the C++ concept of a "byte" does not agree with contemporary
usage, as nowadays (even not the case in the past) a byte always has 8
bits, whereas in C++ it is whatever the compiler defines it to be.

So I explained the terminology that I used for the investigation of the
dynamics of runtime objects, and I provided that as an input. I do not
think that there is so a big difference with the C++ terminology, only
that I go much further by allowing objects to be massively dynamic, as
opposed to the rather static nature of C++.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <remove.haberg-0310011258420001@du130-226.ppp.su-
anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
>>I think this is false. Clearly '3' is somehow represented but it can be
>>as part of an assembler instruction for which there is no address from
>>the programmer's perspective. And, unless the programmer does something
>>that explicitly requires '3' occupy data storage, there is no
>>requirement that it has an address.
>
>I guess that the assembler instruction containing the "3" must be located
>somewhere, and thus can be treated as a data object. In pseudo-C++, it
>would correspond to a
>  class assembler_instruction {
>    int n;
>  ...
>    void evaluate();
>  };
>where evaluate() is used by the CPU to activate the instruction.

No, many assemblers provide instruction for small numbers where the
small number is only part of the instruction (and modern long word
assemblers do so to an even greater extent) and programs often have no
way of accessing instruction storage. Not that attempts to do so will
cause program termination, stronger than that, an application program
cannot access its own program code.



Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Hans Aberg <remove.haberg@matematik.su.se> wrote:
: In article <9pcphq$rtm$1@glue.ucr.edu>, thp@cs.ucr.edu wrote:

:>Hans Aberg <remove.haberg@matematik.su.se> wrote:
:>: In article <9pai96$6cs$2@glue.ucr.edu>, thp@cs.ucr.edu wrote:
:>[...]
:>:>The first sentence seems to say that certain temporaries live longer
:>:>if they are the referent of a reference.
:>
:>: Right.
:>[...]
:>: But if you decide to introduce a C++ "&" reference or not will not affect
:>: the life-time of the temporary.
:>
:>Either living longer is an effect or it isn't.

: Sorry, the first "right" was wrong; it should be "wrong" :-) :

: My impression is that in C++, binding to reference does not extend the
: lifetime of an object, because the syntax aims at securing a sufficiently
: long lifetime for the references that are possible.

You previously noted that in certain cases, the syntax also aims at
securing a sufficiently long lifetime for the referents of those
references, i.e., that being a referent can have a statically
determined effect on the referent's lifetime.

[...]
:>So what?  Having an address and being an address are quite distinct
:>notions.

: I really do not understand what you mean here, because I say that objects
: have addresses, or references, but they are not themselves addresses: One
: can implement addresses as objects, but that is not always the case.

I understood you to say that the variable i, declared via
                        int i;
*is* a reference, in your extended view of references.

:>: I decided that "object" is a process with an input and output.
:>
:>And, references are PIDs?  ;-)

: No, "process" is not the UNIX concept here (which I think would be better
: called a "program" as opposed to say "threads" and other computational
: processes), but refers to its usual semantics, a black box which one can
                                ^^^^^
                                 Huh?
: provide an input and the response will be an output.

So, this time I have to ask, what isn't a "process" in this sense?  (sigh)

Please pick some well-recognized technical reference and stick to the
terminology therein.  In discussing abstract foundational matters, the
precise use of terminology is essential.

Tom Payne













---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article
<remove.haberg-0210011202200001@du142-226.ppp.su-anst.tninet.se>
 remove.haberg@matematik.su.se (Hans Aberg) wrote:

> >I guess I need to ask, what isn't a reference under this model?
>
> Well, an object is not a reference: It is some piece of data that sits
> somewhere and can respond to inputs by outputs.

I must disagree. When, in a computer model of a problem domain, there
exists a piece of data that's trying to emulate value semantics, it is
a reference to a single member of the set of all possible values of
that type.

A 'int i;' isn't an integer; it's a reference to a reference to an
integer.

'6' isn't an integer either, it's a reference to the concept of
6-ness, just like http://www.microsoft.com isn't Microsoft's web site,
but a reference to it. For shorthand, we imply a dereference when we
use the symbol.

The notion of equality, and what it means to copy, is intimately tied
up with all this stuff. It simply isn't

Apologies for the metaphysical quotient.

-- Barry

--
  If you're not part of the solution, you're part of the precipitate.
Team JEDI: http://www.delphi-jedi.org
NNQ - Quoting Style in Newsgroup Postings
  http://web.infoave.net/~dcalhoun/nnq/nquote.html

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <4r1mrtslcpmaojesrdj4qphmd8tb40mdrr@4ax.com>, Barry Kelly
<dynagen@eircom.net> wrote:
>> an object is not a reference: It is some piece of data that sits
>> somewhere and can respond to inputs by outputs.
>
>I must disagree. When, in a computer model of a problem domain, there
>exists a piece of data that's trying to emulate value semantics, it is
>a reference to a single member of the set of all possible values of
>that type.

The object itself is not a reference, but any (runtime) reference must
somehow represented as data, that is, an object of some type.

Then the question is how much of this nature of references as runtime
object should be made form within the language. C++ usually do not make
that accessible: The best correspondence would be a class ref<T>, from
which the various types of references are represented by derived classes.

>A 'int i;' isn't an integer; it's a reference to a reference to an
>integer.

I get confused when think about this case, because I try to think of
references as runtime objects, not language constructs. Then it is not
exactly clear how C++ references relate to that, because when compiling,
sometimes references like
    int i;
    int& j = i;
like j is just another name for i, which exists only at compile time and
not at runtime.

>'6' isn't an integer either, it's a reference to the concept of
>6-ness, just like http://www.microsoft.com isn't Microsoft's web site,

I always become suspicious when that name comes up. :-)

>but a reference to it. For shorthand, we imply a dereference when we
>use the symbol.

Again, in C++, "6" can have different meaning, depending on context: In
the preprocessor conditional macro, it will have no representation in the
object code. And elsewhere, it (or an algebraic expression it is a part
of) will be translated into a bit pattern which will have a runtime
reference. If I write
  void f() {
    int i = 6;
    ...
  }
then "i" will be a name for a reference to this bit pattern representing
"6", but one will not know whether this reference is to a CPU register, or
to a location on the parameter stack.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <AjilkLA2bwu7EwHt@ntlworld.com>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:
>No, many assemblers provide instruction for small numbers where the
>small number is only part of the instruction (and modern long word
>assemblers do so to an even greater extent)

There is no difference between registers and memory addresses in this
respect, even though that on computers with a short word length, the
instructions referencing memory take up more than one word.

> and programs often have no
>way of accessing instruction storage.

A type of program with that capacity is the assembler, and another is the
debugger. Clearly, if not type of program had the capacity to use register
addresses, it is not possible to manipulate register data. :-)

> Not that attempts to do so will
>cause program termination, stronger than that, an application program
>cannot access its own program code.

I figure that one reason one does not allow that is because it is not
considered safe, and another that it is not very portable. But this does
not mean that registers do not have addresses.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <9pai96$6cs$2@glue.ucr.edu>
 thp@cs.ucr.edu wrote:

> [...]
> :>:>in
> :>:>           int f();
> :>:>the function f is said to return an int, while in
> :>:>           int i;
> :>:>the variable i is said to be an int.  But f returns something quite
> :>:>different from what i is; for instance, i has an address, but not so
> :>:>for entity returned by f.
>
> :>: So in this case, one is merely dealing with different types of references.
>
> :>Hmmmm.  f returns an *int value*, while i is an *int object*.  Neither of
> :>them is a reference in the sense of C++.
>
> : I said I did not use C++ terminology: A "reference" is a form of address
> : (absolute or relative memory address, URL, symbolic link, etc.).
>
> AFIK, the int value returned by f and the int object i are not:
>   - memory addresses (absolute or relative)
>   - URLs
>   - symbolic links.

The value returned by f is a "reference to the concept of n-ness",
where "n" is the integral value returned.

For example:

  int f() { return 2; }

is a function returning a reference to the Universal concept of "2".

> : A value is, the way I defined it, an object whose address and addressing
> : is implicitly known in the given context.
> : This should correspond to the traditional use of "value" in languages like
> : C++.
>
> The integer three is a value.  So, what's its address in any context?  AFIK,
> the experssion &3 is ill formed in C/C++.

Of course, we can't take the address of a Universal Concept, as it
were.

Sorry for the high metaphysical content.

-- Barry

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <9pf5cg$k4p$2@glue.ucr.edu>, thp@cs.ucr.edu wrote:
>You previously noted that in certain cases, the syntax also aims at
>securing a sufficiently long lifetime for the referents of those
>references, i.e., that being a referent can have a statically
>determined effect on the referent's lifetime.

Aha, so now I see what you mean: My impression of C++ is that it secures a
minimum life span in case one would bother to reference it, but this
minimum life span is itself independent of whether somebody would actually
reference it. But it is not extended by somebody referencing it.

>I understood you to say that the variable i, declared via
>                        int i;
>*is* a reference, in your extended view of references.

Not really: I work with a runtime model which only describes runtime
semantics, and does not depend on any language constructs. Therefore one
has to look at what the language translates into.

Then
    void f(int);
will translate into a model where the int's are recopied without
explicitly keeping track of the reference, whereas
    void g(int&);
will keep track of the address of the original object.

And
    int i;
will be make "i" treated as different kinds of references, memory, stack
or register addresses, depending context and how the compiler decides to
implement it.

>: No, "process" is not the UNIX concept here (which I think would be better
>: called a "program" as opposed to say "threads" and other computational
>: processes), but refers to its usual semantics, a black box which one can
>                                ^^^^^
>                                 Huh?
>: provide an input and the response will be an output.
>
>So, this time I have to ask, what isn't a "process" in this sense?  (sigh)

Well, a reference isn't a process, unless one implements it as an object.

A piece of data can be viewed as a process, as in order to access it, one
has to send out a request (say by a CPU operation) in order to retrieve
it. So computers are massively made up by processes it seems.

>Please pick some well-recognized technical reference and stick to the
>terminology therein.  In discussing abstract foundational matters, the
>precise use of terminology is essential.

I think that the word "process" that I use agrees with what is commonly
used in science, or in dictionaries like Merriam "Webster's Third New
International Dictionary"; a variation might be "a progressively
continuing operation marked by a series of gradual changes that succeed
another in a fixed way and lead toward a particular result or end". My
thesaurus does not provide me with any good alternative word.

As for computer lingo, when looking into the book "Programming Under Mach"
by Boykin et al, the UNIX "process" is under Mach called a "task". So it
seems that there is no universal definition of what a "process" might be:
The Mach developers probably realized that the UNIX terminology was not
good, in view of that a computer will host many types of processes.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <remove.haberg-0310012246320001@du142-226.ppp.su-
anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
>I get confused when think about this case, because I try to think of
>references as runtime objects, not language constructs. Then it is not
>exactly clear how C++ references relate to that, because when compiling,
>sometimes references like
>    int i;
>    int& j = i;
>like j is just another name for i, which exists only at compile time and
>not at runtime.

That is a Java/Python... view of names but it is not the C++ one. In C++
i has type int, and j has type reference to int. One added feature is
that there is no syntax for writing a reference to a reference, if you
try to right it, it simply remains a reference. We do not need to
discuss what a reference to a reference means because we cannot write
one:) the grammar does not support such a thing.

Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article
<remove.haberg-0310012246320001@du142-226.ppp.su-anst.tninet.se>
 remove.haberg@matematik.su.se (Hans Aberg) wrote:

> In article <4r1mrtslcpmaojesrdj4qphmd8tb40mdrr@4ax.com>, Barry Kelly
> <dynagen@eircom.net> wrote:
> >> an object is not a reference: It is some piece of data that sits
> >> somewhere and can respond to inputs by outputs.
> >
> >I must disagree. When, in a computer model of a problem domain, there
> >exists a piece of data that's trying to emulate value semantics, it is
> >a reference to a single member of the set of all possible values of
> >that type.
>
> The object itself is not a reference, but any (runtime) reference must
> somehow represented as data, that is, an object of some type.

I was trying to get away from C++ a little, to see the lie of the land
without getting stuck in a local valley, as it were. (I didn't finish
my last message, hit the send instead of save. Sorry about that.).

My point is that the object itself *is* a reference; it's a reference
to a concept outside the computer.

> >A 'int i;' isn't an integer; it's a reference to a reference to an
> >integer.
>
> I get confused when think about this case, because I try to think of
> references as runtime objects, not language constructs. Then it is not
> exactly clear how C++ references relate to that, because when compiling,
> sometimes references like
>     int i;
>     int& j = i;
> like j is just another name for i, which exists only at compile time and
> not at runtime.

Here,

  i is a reference to
    a compiled (i.e. run-time) reference to
      a bit pattern which is a reference to
        some number (in the Universe)

In this case, the compiled, runtime reference is either the name of a
register or an address location.

'j' fits in just here:

  i is a reference to
j >>>>>>>> is a reference to
    a compiled reference to
      a bit pattern which is a reference to
        some number (in the Universe)

Hopefully with the more abstract and slightly more powerful vocabulary
we have with our metaphysical 'reference', you can more clearly see
what's referencing what.

The value that got 'assigned' in the '=' initializer is the run-time,
compiled reference. The compiler's able to figure everything out at
compile time, of course, so essentially it's just new name.

> >but a reference to it. For shorthand, we imply a dereference when we
> >use the symbol.
>
> Again, in C++,

I know you want to keep everything on the ground, but perhaps if we
lift above that for short bit, we'll see a little more clearly.

> "6" can have different meaning, depending on context: [...] it [...]
> will be translated into a bit pattern which will have a runtime
> reference.

The bit pattern may be stored in any of several places, and to talk
about a run-time reference,

> If I write
>   void f() {
>     int i = 6;
>     ...
>   }
> then "i" will be a name for a reference to this bit pattern representing
> "6", but one will not know whether this reference is to a CPU register,
> or to a location on the parameter stack.

Exactly:

  i is a lexical, compile-time reference to
    the compiled, run-time reference to
      the bit pattern 6 which is a reference to
        the concept of 6-ness.

Now, the compiled, run-time reference may or may not have an address
(depending on whether it's in a register); however, that shouldn't
muddy our concept of a C++ reference, as long as we are clear where in
the chain the C++ reference gets 'linked in'.

What we have to find where in the chain of references does our concept
of 'location' fall apart; When things are broken down like this, I
think it's a little easier to work out meaningful semantics. That was
the sole purpose in me bringing this up.

-- Barry

--
  If you're not part of the solution, you're part of the precipitate.
Team JEDI: http://www.delphi-jedi.org
NNQ - Quoting Style in Newsgroup Postings
  http://web.infoave.net/~dcalhoun/nnq/nquote.html

---
[ 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.research.att.com/~austern/csc/faq.html                ]