array of reference?

[siddhu]

why can't we have array of references.

[terminator]

On Dec 7, 5:23 pm, James Kanze <james.ka...@gm ail.comwrote:

On Dec 7, 3:00 pm, "Alf P. Steinbach" <[e-mail] wrote:

* James Kanze:

On Dec 7, 4:06 am, "Alf P. Steinbach" <[e-mail] wrote:
>That said, using a hardware stack is the most common and today in
>practice the only implementation of the abstract machine's stack.
Sort of. In practice, except for Intel architecture (which is
notoriously poor in registers), I don't know of any case where
arguments are passed on the stack.

Recursion.

Even then, the *arguments* are passed in registers. (You can't
have the API of a function call depending on whether the
function is recursive or not.) Naturally, the function will
take whatever steps are necessary to avoid overwriting the value
(if it still needs it, of course) before placing the argument of
the next call in the register. On a Sparc, of course, nothing
is necessary; each function automatically gets a (partially) new
set of registers.

Some sort of storage with some size is essential to any none
resolvable parameter to a function (including references).But I
believe that in such case the size of storage cannot become less than
a complete pointer(segment , offset or whatever essential to uniquely
point to a specific memmory location).That is because generally it is
not predictable where the candidiate objects to be passed by ref are
to be stored.
That is what I had to write .
If I am wrong about the stack I do take it back.

regards,
FM.

[terminator]

On Dec 7, 7:23 pm, "Alf P. Steinbach" <[e-mail] wrote:

* James Kanze:

On Dec 7, 3:00 pm, "Alf P. Steinbach" <[e-mail] wrote:

* James Kanze:

>On Dec 7, 4:06 am, "Alf P. Steinbach" <[e-mail] wrote:

>>That said, using a hardware stack is the most common and today in
practice the only implementation of the abstract machine's stack.

>Sort of. In practice, except for Intel architecture (which is
notoriously poor in registers), I don't know of any case where
arguments are passed on the stack.

Recursion.

Even then, the *arguments* are passed in registers. (You can't
have the API of a function call depending on whether the
function is recursive or not.) Naturally, the function will
take whatever steps are necessary to avoid overwriting the value
(if it still needs it, of course) before placing the argument of
the next call in the register. On a Sparc, of course, nothing
is necessary; each function automatically gets a (partially) new
set of registers.

I fail to see how you can think that's anything but a hardware stack.

Maybe it is only my imagination ,but I can imagine a machine that just
does not have a push/pop pair and does not inc/dec a specific register
automatically and the call/ret code needs to handle it
manually ;something like this:

;//call:
move *SReg PC;//PC is the program counter
add SReg 1;
jump where;

;//ret:
sub SReg 1;
jump *SReg;

Regards,
FM.

[James Kanze]

On Dec 8, 8:16 pm, terminator <farid.mehr...@ gmail.comwrote:

On Dec 7, 7:23 pm, "Alf P. Steinbach" <[e-mail] wrote:

[...]

Even then, the *arguments* are passed in registers. (You can't
have the API of a function call depending on whether the
function is recursive or not.) Naturally, the function will
take whatever steps are necessary to avoid overwriting the value
(if it still needs it, of course) before placing the argument of
the next call in the register. On a Sparc, of course, nothing
is necessary; each function automatically gets a (partially) new
set of registers.

I fail to see how you can think that's anything but a hardware stack.

It's obviously a stack, but you don't pass arguments "on the
stack"; it all happens behind the scenes.

On the 8086, I also used a Pascal compiler which passed
arguments in a static area; saving it on the stack in case a
recursive call was detected. The arguments were never passed on
the stack, but the local context (including any arguments) were
copied onto the stack if necessary.

Maybe it is only my imagination, but I can imagine a machine that just
does not have a push/pop pair and does not inc/dec a specific register
automatically and the call/ret code needs to handle it
manually ;something like this:

;//call:
move *SReg PC;//PC is the program counter
add SReg 1;
jump where;

;//ret:
sub SReg 1;
jump *SReg;

It's not you imagination---I'd guess that this is the case for
most traditional hardware architectures. Even today, IBM
mainframes don't have a push and a pop, and don't save the
return address on the stack, but rather in a register.

Of the early machines, the Burroughs machines were stack based:
they didn't have registers, just top of stack. Other than such
special cases, however, I think that the PDP-11 was the first
machine which had a hardware stack (via auto-increment and
auto-decrement instructions).

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Dec 8, 8:06 pm, terminator <farid.mehr...@ gmail.comwrote:

On Dec 7, 5:23 pm, James Kanze <james.ka...@gm ail.comwrote:

On Dec 7, 3:00 pm, "Alf P. Steinbach" <[e-mail] wrote:

* James Kanze:
On Dec 7, 4:06 am, "Alf P. Steinbach" <[e-mail] wrote:
That said, using a hardware stack is the most common and today in
practice the only implementation of the abstract machine's stack.
Sort of. In practice, except for Intel architecture (which is
notoriously poor in registers), I don't know of any case where
arguments are passed on the stack.
Recursion.

Even then, the *arguments* are passed in registers. (You can't
have the API of a function call depending on whether the
function is recursive or not.) Naturally, the function will
take whatever steps are necessary to avoid overwriting the value
(if it still needs it, of course) before placing the argument of
the next call in the register. On a Sparc, of course, nothing
is necessary; each function automatically gets a (partially) new
set of registers.

Some sort of storage with some size is essential to any none
resolvable parameter to a function (including references).

Some sort of storage is necessary any time there is state.
That's obvious. That doesn't mean that such state has size, in
the C++ sense---functions definitely require storage, but don't
have size either.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Jerry Coffin]

In article <4d2692d8-29f3-4246-bc88-
65**********@e4 g2000hsg.google groups.com>, ja*********@gma il.com says...

[ ... ]

Of the early machines, the Burroughs machines were stack based:
they didn't have registers, just top of stack. Other than such
special cases, however, I think that the PDP-11 was the first
machine which had a hardware stack (via auto-increment and
auto-decrement instructions).

http://www.ece.cmu.edu/~koopman/stac...ters/appa.html

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Andrey Tarasevich]

siddhu wrote:

why can't we have array of references.

Allowing arrays of references would introduce a number of rather convoluted
complications into language specification. I hope you know that arrays in C++
(inherited from C) are already rather strange objects possessing a number of
specific properties that make them stand out from other objects (like being
non-assignable, non-copy constructible, requiring dedicated initialization
syntax etc.) References are also tricky (non-objects as they are). Combining the
former and the latter together would lead to very complicated specification for
arrays. Apparently, the standardization committee decided to take the easy and
lazy way out and simply declare that you can't have arrays of references.

There was a number of technical reasons stated in this thread already (like
"references being non-objects" and "references having no size"), but in reality
no technical reason, of course, can be taken as a serious explanation. There's
no real technical difference in having references as members of arrays or having
references as members of any other aggregate type (members of a class). Yet it
is allowed to have class members of reference type in C++. This immediately
overthrows any technical reasoning against arrays of references, leaving us with
political explanations only.

Arrays, inherited from C, were seen as "broken beyond repair" in C++ from the
very beginning, so nobody wanted to spend too much time on creating an elaborate
specification for them. Any time any complications rose with any potential array
features, these feature were simply removed from the language. This is the real
answer to your question.

--
Best regards,
Andrey Tarasevich

[Abhishek Padmanabh]

On Dec 10, 7:48 am, Andrey Tarasevich <andreytarasev. [e-mail]>
wrote:

siddhu wrote:

why can't we have array of references.

Allowing arrays of references would introduce a number of rather convoluted
complications into language specification. I hope you know that arrays in C++
(inherited from C) are already rather strange objects possessing a number of
specific properties that make them stand out from other objects (like being
non-assignable, non-copy constructible, requiring dedicated initialization
syntax etc.) References are also tricky (non-objects as they are). Combining the
former and the latter together would lead to very complicated specification for
arrays. Apparently, the standardization committee decided to take the easy and
lazy way out and simply declare that you can't have arrays of references.

I don't think arrays being non-copyable, non-assignable could be a
reason for not having array of references. After all, references are
non-copyable/non-assignable. That would have been supportive as that
is more in line to the properties of arrays. Initialization is a
problem, but it is the (almost?) same as having an array of const
objects. The standard does not prohibit array of const objects. For
example, this is ok:

struct A{
A(int){}
};

int main()
{
const A array[2] = {A(1), A(2)};
}

The same could have been possible for references as well. Which brings
us to an interesting point: arrays in C++ decay to pointers. So, when
passing this array to a function, you would actually be having a array
that decayed to a pointer whose value would be the pointer to the
first element in the array: array, or &array[0]. And as per the
standards a pointer to a reference is not allowed. I think, this is
because of the very same reason that has been pointed out earlier -
that references need not have size. So, I think, the answer that
arrays are not objects/arrays need not have size is the actual reason
why there can't be array of references.

[Andrey Tarasevich]

Abhishek Padmanabh wrote:

>>why can't we have array of references.

Allowing arrays of references would introduce a number of rather convoluted
complication s into language specification. I hope you know that arrays in C++
(inherited from C) are already rather strange objects possessing a number of
specific properties that make them stand out from other objects (like being
non-assignable, non-copy constructible, requiring dedicated initialization
syntax etc.) References are also tricky (non-objects as they are). Combining the
former and the latter together would lead to very complicated specification for
arrays. Apparently, the standardization committee decided to take the easy and
lazy way out and simply declare that you can't have arrays of references.

I don't think arrays being non-copyable, non-assignable could be a
reason for not having array of references. After all, references are
non-copyable/non-assignable.

That's actually what I'm saying. There's no prohibitive technical reason for not
having arrays of references. Any technical problems could've been overcome with
more elaborate specification. The decision not to have arrays of references is
purely political.

The same could have been possible for references as well. Which brings
us to an interesting point: arrays in C++ decay to pointers.
...
And as per the
standards a pointer to a reference is not allowed.

It's nothing more that just another technical obstacle. For example, in C++ a
pointer to a POD-struct object converted by 'reinterpret_ca st' to type 'T*',
where 'T' is the type of the first field of that POD-struct, is guaranteed to
point to that first field. Does that mean that you can't have a reference as a
first member in a struct in C++? No it doesn't. And you can. It's just that the
struct with a reference member will no longer be a POD by definition.

I think, this is
because of the very same reason that has been pointed out earlier -
that references need not have size.

No. Any problems this could introduce could've been easily dealt with by
introducing extra restriction/exceptions into the language specification. Just
like the one above with pointers to struct members.

So, I think, the answer that
arrays are not objects/arrays need not have size is the actual reason
why there can't be array of references.

I don't understand what you are trying to say in that last sentence. Arrays are
objects in C++ and they do have size.

--
Best regards,
Andrey Tarasevich

[Abhishek Padmanabh]

On Dec 10, 8:36 pm, Andrey Tarasevich <andreytarasev. [e-mail]>
wrote:

Abhishek Padmanabh wrote:

So, I think, the answer that
arrays are not objects/arrays need not have size is the actual reason
why there can't be array of references.

I don't understand what you are trying to say in that last sentence. Arrays are
objects in C++ and they do have size.

Aah.. that was a typo. I meant references.

[Andrey Tarasevich]

Victor Bazarov wrote:

>...
Arrays are objects in C++ and they do have size.

But references don't. So, how would you define the size of an array
of refernces?

What's the problem? How do you "define" the size of a class that has a
member of reference type? The answer: normally the language simply says
that a class has _some_ size (which is what is returned by 'sizeof'),
but doesn't attempt to establish the relationship between the size of
the class and the size of its members. The result: the problem simply
does not exist.

Note, that with arrays the problem is not that they have sizes. The
problem with arrays is that the language goes on step further: it
postulates an additional relationship between the size of the array and
the size of the array element: sizeof(array) = sizeof(element) *
number_of_eleme nts. That's the problem. How can we deal with that?
Simple. For example, extend the concept of POD type to arrays, say that
arrays of references are not POD and that the aforementioned size
relationship applies only to POD arrays. For non-POD arrays the size is
unspecified. I.e. they have sizes, which can only be obtained from
'sizeof', but cannot be calculated in any other way. That's it.

Of course, then we'd have to deal with other complications, like what
these arrays should decay to (if at all) and so on. As I said before,
we'd end up with rather complicated specification for arrays. And all
these complications would have been caused by a feature of very limited use.

I don't believe it's totally impossible to solve some
"political" problems (as you put it) using some technical means, but
I don't think we should complain about it unless we're ourselves have
attempted it and succeeded. And even then there is no need to simply
complain. Just wrap your solution in a proposal and post to the
'comp.std.c++' newsgroup...

I don't really propose anything like that. The real root of the issue
here is not this particular mix of arrays and references. It's just
arrays themselves. They are broken. The problems with "arrays of
references" are just a logical consequence of C arrays' "brokenness ",
just like many other (non reference-related) problems stemming from the
same root. There's been lots of proposals to fix arrays, I'm sure. And
the committee already made a decision not to fix them. Coming up with a
proposal to enable "arrays of references" would be a futile attempt to
cure a symptom, instead of targeting the real problem, which in the end
would only try to make the arrays even more broken than they are already.

--
Best regards,
Andrey Tarasevich