array of reference?

[James Kanze]

[ ... ]

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/stack_computers/appa.html

Interesting, for two reasons. The first is that pre-1970, the
few stack based machines seemed to be very much oriented to
executing Algol. (Burroughs was the first, and the only one
which had any commercial success. If you can count Burroughs as
a commercial success---although if I'm not mistaken, Unisys only
dropped the architecture in the last four or five years.) And
secondly, while the PDP-11 may have been the first general
purpose machine with a hardware stack (and one notes the lack of
any of its major competitors, like DG or Prime), it actually
didn't precede the Intel 8008 by any significant amount of time.
(But would the 8008 count: it had a stack, but I think it could
only be used for return addresses---and was limited to 8
entries.)

There are also cases where I don't know whether to count them or
not. The TI 9900 kept its "registers" in main memory, and one
form of the call instruction remapped them, putting a pointer to
the previous set in one of the registers. Which certainly acts
like a stack, even if there was no push or pop.

 

[James Kanze]

On Dec 9, 6:05 pm, James Kanze <[email protected]> wrote:

[...]

Yeah, but which clause? What is it that you are violating?

The requires clause of accumulate (§26.6.1/2): "In the range
[first,last], binary_op shall neither modify elements nor
invalidate iterators or subranges." (Hmmm. I'm not so sure
now. What I modify is the accumulator, not an element of the
sequenece. On the other hand, I see no guarantee that the
implementation uses a single accumulator, either. Not that I
can think of any reason why it wouldn't, I suppose that it could
alternate, doing something along the lines of accu1 = bin_op(
accu2, *it ) and accu2 = bin_op( accu1, *it ).)

It certainly doesn't correspond to the *intent* (which is
clearly that the binary operator act something like +, and not
like +=). On the other hand, it does work in practice, and in
my tests, the resulting code runs 8 times faster.

 

[Andrey Tarasevich]

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_cast' 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.

 

[Victor Bazarov]

I don't understand what you are trying to say in that last sentence.
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? 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...

The main problem here is the need. Arrays of constant pointers do
exist and while there is a need to check those for being null, they
are not impossible to use as a poor man's substitution for arrays of
references. If there were a problem that cannot be solved without
arrays of references, they would already exist, no?

V

 

[Abhishek Padmanabh]

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]

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_elements. 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.

 

[James Kanze]

Abhishek Padmanabh wrote:

[...]

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.

Anything can be overcome if you're willing to pay the price.
And all decisions are "political", in the sense that they
involve weighing the cost vs. the benefits. In this case, the
cost would involve introducing all sorts of special cases and
complexity, for pretty much no benefit. The cost-benefits
analysis is clear.

Obviously, if you think that the rules involving C style arrays
are too simple as is, and you really feel that C++ needs extra
complexity, then the analysis will give different results.

 

[Jerry Coffin]

(e-mail address removed)>, (e-mail address removed)
says...

[ ... ]

Interesting, for two reasons. The first is that pre-1970, the
few stack based machines seemed to be very much oriented to
executing Algol.

That, in itself, doesn't surprise me much. Pre-1970, an awful lot of
programming was done in FORTRAN and COBOL, both of which were designed
so neither a stack nor any other form of dynamically allocated memory
was needed.

The other part of the equation is that while that web site lists a
number of machines, it's certainly not exhaustive. Just for one more
example, the GE-645 was designed to support Multics, and it had hardware
support for a stack as well. See:

http://www.multicians.org/daley-dennis.html

if you feel like reading a bit about what Multics and the GE-645
supported for memory addressing and such. Note that while this paper was
written in 1968, the design dates from about 1965. Like almost
everything related to Multics, its hardware stack support was more
comprehensive (and complex) than almost anything before or since.

 

[Alf P. Steinbach]

* James Kanze:

[...]

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.

It seems I haven't replied to this (but my news-server is unreliable).

Anyway, given that you know admit that it's a stack, and a hardware
stack, the only thing left to comment on is your alleged quote about
passing arguments "on the stack".

I didn't write that, and as far as I can see nobody but you did; in
fact, my article up-thread started with "first, note that there may not
be a stack register", which is in the opposite direction of the points
of view I'm being associated with in your responses.


Cheers, & hth.,

- Alf