Oh God not references again...

[Mathias Gaunard]

What I mean is that it makes no sense for a language to have 2 similar
constructs for (almost) the same underlying concept.

There is absolutely no acceptable way to do unification.
Each are needed for different reasons.

The only way to do an unification would be to turn pointers and
references into Java references.
Which we don't want, because we don't want to pay for what we don't use.

Yes, but PHP5 also breaks PHP4 code.

First, C++ is not PHP. PHP is a very high-level language, which isn't
even a generalistic one, and that has lots of memory related issues.
PHP also was never carefully designed but more hacked as time passed,
adding features from other languages, and doesn't go through the process
of standardization.

And second, this isn't even true. It's fully compatible unless relying
on old bugs. There is switch allowing you to choose whether you want
objects to have copy or reference semantics.

If you insist that a new language
version must be a superset of the current then no real evolution is
possible.

Evolution is possible. But only in the sense that you get stuff added,
not removed.

 

[Roland Pibinger]

There is absolutely no acceptable way to do unification.
Each are needed for different reasons.

Just look at contemporary languages other than C++.

The only way to do an unification would be to turn pointers and
references into Java references.
Which we don't want, because we don't want to pay for what we don't use.

We don't think we agree here.

And second, this isn't even true.

Ok, replace the example with Ruby or Python.

Evolution is possible. But only in the sense that you get stuff added,
not removed.

Why not change the language? Some reptiles evolved into birds and took
off. Other reptiles just added stuff and became dinosaurs.

Best wishes,
Roland Pibinger

 

[kwikius]

[..pointers hold addresses, references are addresses..]
Now are you agreeing in that last paragraph or just being sarcastic?

Neither. References are not addresses. Nothing sarcasting about it.

Sure they are. Variables have two parts, address and value. Reference
represents the address:

T x;
T& y = x;

y = T();

Sure dont represent the value.(cant assign to a value) There is no
magic.

You're trying to define an abstract concept with concrete content.
Don't.

I dont know what that means but I'll do as I please thanks!

What's a class? Is it data or is it something that holds

data? Is it a set of functions or is it something that holds the
set of functions?

Whoa Lets not go off the subject...

References do not exist in run-time.

Sure they do... see below code...

Just like

classes. You can't compare pointers, which are objects, with other
element of the universe that isn't an object.

Well what about this,

1) runtime
2) compare pointer with something not an object.

#include <iostream>
int main()
{
int x;
int& y = x;

std::cout << " address of y is " << (&y == &x?"equal":"not equal")

<< " to address of x\n";

}

Nah nah nah!


Reference is like

a typedef. Are typedefs types or do they hold types? Neither.

typedef Is a name for a type:

typedef struct {int x; int y; int z;} theAndyType;

"Quibbling"?

means arguing.

What I said seems good to me. [..]

Whatever.

Yeah whatever...

reagrds
Andy Little

 

[Andre Kostur]

kwikius wrote:

[snip]

Just like
classes. You can't compare pointers, which are objects, with other
element of the universe that isn't an object.

Well what about this,

1) runtime
2) compare pointer with something not an object.

#include <iostream>
int main()
{
int x;
int& y = x;

std::cout << " address of y is " << (&y == &x?"equal":"not equal")

<< " to address of x\n";

}

Nah nah nah!

Huh? You compared a pointer with a pointer. I fail to see what this
proves. (And doing &y doesn't get you the address of the reference, it
gets you the address of what it refers to, in this case x.)

 

[Bo Persson]

[..pointers hold addresses, references are addresses..]
Now are you agreeing in that last paragraph or just being
sarcastic?

Neither. References are not addresses. Nothing sarcasting about
it.

Sure they are. Variables have two parts, address and value.
Reference represents the address:

No they have three parts, name, address, and value. (and type. Variables
have four parts...).

The reference is another *name* for the variable, not an address.

T x;
T& y = x;

y = T();

Sure dont represent the value.(cant assign to a value) There is no
magic.

So y is another name for x, so x is assigned a value.


Bo Persson

 

[kwikius]

kwikius wrote:

[snip]

Just like
classes. You can't compare pointers, which are objects, with other
element of the universe that isn't an object.

Well what about this,

1) runtime
2) compare pointer with something not an object.

#include <iostream>
int main()
{
int x;
int& y = x;

std::cout << " address of y is " << (&y == &x?"equal":"not equal")

<< " to address of x\n";

}

Nah nah nah!

Huh? You compared a pointer with a pointer. I fail to see what this
proves.

I'm not trying to prove anything, except to demonstrate that references
arent some magical abstract concept. They aint the same as typedefs and
they occur in runtime expressions

(And doing &y doesn't get you the address of the reference, it

gets you the address of what it refers to, in this case x.)

Are you making out I said otherwise ? If so your statement seems
misleading to my discredit. Is that the intent? If so that aint very
nice now is it?

regards
Andy little

 

[Kai-Uwe Bux]

kwikius wrote:
[..pointers hold addresses, references are addresses..]
Now are you agreeing in that last paragraph or just being
sarcastic?

Neither. References are not addresses. Nothing sarcasting about
it.

Sure they are. Variables have two parts, address and value.
Reference represents the address:

No they have three parts, name, address, and value. (and type. Variables
have four parts...).

The reference is another *name* for the variable, not an address.

Where in the standard do you find that a reference is another name for a
variable?

Consider:

template < typename T >
bool same_object ( T const & a, T const & b ) {
return ( &a == &b );
}

For which objects are a and b other names? It is tempting to answer: for
the ones passed as parameters, but that would be false: the following code
is not guaranteed to print 1:

#include <iostream>

int main ( void ) {
int i = 5;
std::cout << same_object( i, i ) << '\n';
}


The standard does not say what a reference is. It only specifies how
references behave and thereby allows to argue about the observable behavior
of code involving references. (And the precise rules of how objects bind to
references make the above program exhibit implementation defined behavior,
which would be weird if references just introduced new names.) The question
as to what a reference is cannot be answered in general other than by
saying "an entity of reference type".

So y is another name for x, so x is assigned a value.

No, y is not a name (and not an address either). The identifier "y" is a
name (the name of the reference y). What y is? It is reference bound to the
object x. That is all the standard has to say about this. Everything else
is metaphysics or psychology.


Best

Kai-Uwe Bux

 

[kwikius]

kwikius wrote:
[..pointers hold addresses, references are addresses..]
Now are you agreeing in that last paragraph or just being
sarcastic?

Neither. References are not addresses. Nothing sarcasting about
it.

Sure they are. Variables have two parts, address and value.
Reference represents the address:

No they have three parts, name, address, and value. (and type. Variables
have four parts...).

The reference is another *name* for the variable, not an address.

T x;
T& y = x;

y = T();

Sure dont represent the value.(cant assign to a value) There is no
magic.

So y is another name for x, so x is assigned a value.

You have some point on the type, though in case of a reference its the
type of the variable , . As for name:

int & f()
{
static int count = 0;
return *new int(count++);
}

not strictly necessary.

regards
Andy Little

 

[kwikius]

No, y is not a name (and not an address either).

Nevertheless in all cases where the variables are ( after
optimisations) in memory and need to be accessed via references, this
access can only be by knowing the variables address ( direct or
indexed), though this may often be hard coded index in an instruction
rather than put in memory which is beneficial for reducing memory
accesses, register use and so on. The rules re not rebinding and
"guaranteed" initialisation to a "good" state provide some help both to
the compiler and to the programmer too which makes references
preferable to pointers where possible IMO.

In worst case from observation, a reference is implemented exactly as a
pointer, best case the fact that a reference must be initialised and
cant be rebound enables compiler to optimise it superior to a pointer
and this can lead to further optimisations. The "guarantee" that
reference is in a good state will also affect the design of the high
level code, so errors might use exceptions rather than requiring user
to null check pointers, which makes source code design cleaner.

regards
Andy little