why can't we have array of references.
31  3173 
siddhu wrote:
why can't we have array of references.
References are not objects.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
On Dec 5, 2:25 am, siddhu <siddharth....@gmail.comwrote:
why can't we have array of references.
Reference is just an alias to the variable, no memory is allocated
for a reference. In fact, we can't have a reference to a reference or
a pointer to a reference. Hope it clarifies.
On Dec 5, 12:32 am, "Alf P. Steinbach" <al...@start.nowrote:
* siddhu:
why can't we have array of references.
A reference is not an object, it has no size.
it has a size usually equal to that of a pointer in case of usage an
argument to a none inlined function.
On Dec 5, 12:25 am, siddhu <siddharth....@gmail.comwrote:
why can't we have array of references.
why don`t use array of const pointers?
class A * const ptrArr[size_enum];
regards,
FM.
terminator wrote:
On Dec 5, 12:32 am, "Alf P. Steinbach" <al...@start.nowrote:
>* siddhu:
>>why can't we have array of references.
A reference is not an object, it has no size.
it has a size usually equal to that of a pointer in case of usage an
argument to a none inlined function.
And when the size isn't equal to that of a pointer, what is it?
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
terminator <fa***********@gmail.comwrote in news:b2d73c27-cfd5-42ee-ae2d- 2b**********@s36g2000prg.googlegroups.com:
On Dec 5, 12:32 am, "Alf P. Steinbach" <al...@start.nowrote:
>* siddhu:
why can't we have array of references.
A reference is not an object, it has no size.
it has a size usually equal to that of a pointer in case of usage an
argument to a none inlined function.
No, references don't even have to have a physical representation.
Analogous to typedef, a reference only introduces a new name for an object.
It turns out that usually memory for an address is allocated for reference
parameters and reference object members, but it would be a pretty poor
compiler that allocated anything at all for a local reference.
joe
On Dec 5, 2:32 am, "Alf P. Steinbach" <al...@start.nowrote:
* siddhu:
why can't we have array of references.
A reference is not an object, it has no size.
If by size you mean storage, it is *unspecified* that they have
storage or not. So, saying they have no size would be incorrect.
Chapter and verse: 8.3.2 (4) (2007-06-25 draft). :)
Abhishek Padmanabh wrote:
On Dec 5, 2:32 am, "Alf P. Steinbach" <al...@start.nowrote:
>* siddhu:
>>why can't we have array of references.
A reference is not an object, it has no size.
If by size you mean storage, it is *unspecified* that they have
storage or not. So, saying they have no size would be incorrect.
Chapter and verse: 8.3.2 (4) (2007-06-25 draft). :)
The more proper way of answering the original question would then
be "becuase the Standard says so in [dcl.ref]/4".
However, if it's unspecified whether they have storage or not, it
usually means that in a general case they do NOT have storage, and
hence they do NOT have size.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
On Dec 5, 2:25 am, siddhu <siddharth....@gmail.comwrote:
why can't we have array of references.
Arrays of references are not possible because they may or may not
require storage (implemented as to have size or not). In the cases
(implementations) when they won't have a size, arrays of them won't be
possible. References are not considered as objects by the standards.
They are just aliases. In next standards revision, there might be a
reference_wrapper added that can be used instead of plain references
wherever you need to make arrays of them or use them with standard
containers.
On Dec 6, 6:47 pm, Joe Greer <jgr...@doubletake.comwrote:
terminator <farid.mehr...@gmail.comwrote in news:b2d73c27-cfd5-42ee-ae2d-
2b5790802...@s36g2000prg.googlegroups.com:
On Dec 5, 12:32 am, "Alf P. Steinbach" <al...@start.nowrote:
* siddhu:
why can't we have array of references.
A reference is not an object, it has no size.
it has a size usually equal to that of a pointer in case of usage an
argument to a none inlined function.
No, references don't even have to have a physical representation.
Analogous to typedef, a reference only introduces a new name for an object.
It turns out that usually memory for an address is allocated for reference
parameters and reference object members, but it would be a pretty poor
compiler that allocated anything at all for a local reference.
joe
I said in case of usage as **an argument to a none inlined function**.
On Dec 6, 12:41 am, "Alf P. Steinbach" <al...@start.nowrote:
* terminator:
On Dec 5, 12:32 am, "Alf P. Steinbach" <al...@start.nowrote:
* siddhu:
>why can't we have array of references.
A reference is not an object, it has no size.
it has a size usually equal to that of a pointer in case of usage an
argument to a none inlined function.
Sorry, that's incorrect. Or not even wrong. If you want to make an
argument, cough up chapter and verse from the standard.
I do not get it:
void f(int& iref);
can you explain how 'iref ' is passed to 'f' if it is not inlined?
The simplest way is to implement it as a pointer ,so stack register
will be decreased sizeof(int*) for passing 'iref'.
regards,
FM.
On Dec 6, 12:35 am, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:
terminator wrote:
On Dec 5, 12:32 am, "Alf P. Steinbach" <al...@start.nowrote:
* siddhu:
>why can't we have array of references.
A reference is not an object, it has no size.
it has a size usually equal to that of a pointer in case of usage an
argument to a none inlined function.
And when the size isn't equal to that of a pointer, what is it?
Nothing,A pseudo C++ instruction, not even some gaseus.when not an
argument to out of line functions it is resolved at compile time.
regards,
FM.
terminator <fa***********@gmail.comwrote in
news:e7**********************************@e10g2000 prf.googlegroups.com:
On Dec 6, 6:47 pm, Joe Greer <jgr...@doubletake.comwrote:
>terminator <farid.mehr...@gmail.comwrote in
news:b2d73c27-cfd5-42ee-ae2d-
2b5790802...@s36g2000prg.googlegroups.com:
On Dec 5, 12:32 am, "Alf P. Steinbach" <al...@start.nowrote:
* siddhu:
why can't we have array of references.
>A reference is not an object, it has no size.
it has a size usually equal to that of a pointer in case of usage
an argument to a none inlined function.
No, references don't even have to have a physical representation.
Analogous to typedef, a reference only introduces a new name for an
object. It turns out that usually memory for an address is allocated
for reference parameters and reference object members, but it would
be a pretty poor compiler that allocated anything at all for a local
reference.
joe
I said in case of usage as **an argument to a none inlined function**.
Sadly (or is it gladly? Depends upon the topic and POV.) you don't
really have any control over that. Some of today's modern compilers can
inline in the linker stage. Some classes with reference member
variables can also be unrolled and inlined during compilation.
Therefore, it's hard to make any flat statement about the storage of
references other than they don't require any.
joe
Alf P. Steinbach wrote:
>it has a size usually equal to that of a pointer in case of usage an
argument to a none inlined function.
Sorry, that's incorrect. Or not even wrong. If you want to make an
argument, cough up chapter and verse from the standard.
He said "usually", which I understand to mean "in practice with
current compilers and architectures".
On Dec 6, 5:52 pm, terminator <farid.mehr...@gmail.comwrote:
On Dec 6, 12:41 am, "Alf P. Steinbach" <al...@start.nowrote:
* terminator:
On Dec 5, 12:32 am, "Alf P. Steinbach" <al...@start.nowrote:
>* siddhu:
>>why can't we have array of references.
>A reference is not an object, it has no size.
it has a size usually equal to that of a pointer in case
of usage an argument to a none inlined function.
Sorry, that's incorrect. Or not even wrong. If you want to
make an argument, cough up chapter and verse from the
standard.
I do not get it:
void f(int& iref);
can you explain how 'iref ' is passed to 'f' if it is not
inlined? The simplest way is to implement it as a pointer ,so
stack register will be decreased sizeof(int*) for passing
'iref'.
First, inlining or not is irrelevant. The standard specifically
states that inlining has no effect on a function, so it can't
possibly the size of an argument to the function can't possibly
depend on that. Second, how the compiler passes arguments with
reference type is it's business, not mine. My compiler
certainly doesn't pass them on the stack; it puts them in a
register. A 64 bit register, even when I'm compiling in 32 bit
mode (where pointers are 32 bits). And on my compiler, the
actual memory space used by a reference in a structure will
depend on what is in front of and behind the reference. (The
same is true of pointers, of course.)
What is relevant is that the compiler says that sizeof( char& )
== 1, and sizeof( T& ) == sizeof( T ), regardless of the size of
a pointer. A reference doesn't have size. At least not of its
own. A reference is an other name for a variable or a value,
and its "size" is the size of whatever it names.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Dec 7, 4:06 am, "Alf P. Steinbach" <al...@start.nowrote:
* terminator:
I do not get it:
void f(int& iref);
can you explain how 'iref ' is passed to 'f' if it is not inlined?
The simplest way is to implement it as a pointer ,so stack register
will be decreased sizeof(int*) for passing 'iref'.
First, note that there may not be a stack register.
The C++ abstract machine implicitly defines a logical stack, a
LIFO queue, for automatic variables and function arguments,
but that does not mean that it depends on a stack register at
the hardware level or hardware support for a call stack.
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. They're passed in registers.
On a modern Sun Sparc (v9 or later), those registers are always
64 bits: 8 bytes. So a reference will be passed in 8 bytes. As
will a char, a short, an int, a long or a long long, all
pointers (even in 32 bit mode, where a pointer is normally only
4 bytes), and all enums. (None of which has anything to do with
the size of the type in the C++ sense, but I'm sure you know
that already.)
Also, in addition to a stack register, the Sparc has a register
stack. When you call a function, it is shifted down 192 bytes,
regardless of the number and types of the arguments. Does this
mean that if I call a function with one reference argument, the
size of the reference is 192, but if I call it with 2, the size
is 96?
[...]
Common to all these cases is that because references do not
have size at the abstract machine level, and are not objects
at the abstract machine level, the compiler is free to
optimize or do anything.
Note that unless you actually output the value of a pointer,
that's fairly true for pointers as well. All the actual machine
has to do is ensure that the observable behavior is the same as
one possible instantiation of the abstract machine.
All the compiler needs to do -- barring use of
compiler-specific language extensions -- is to make sure the
requirements of the abstract machine are fulfilled, treating
the reference as an alias.
Just to add to the confusion: according to the standard,
references do have size, since sizeof( T& ) is a perfectly
legal, well defined instruction. And a reference to a pointer
does have the size of a pointer. Just as a reference to an int
has the size of an int, and a reference to a double has the size
of a double. And on my machine, a reference to an int[1000000]
has a size of 8000000---good thing pointers aren't that big.
Also, C++ guarantees that a[i] is the same as *(a + i), and that
if a has type T[] (or T*), (char*)a + sizeof(T)*i == &a[i]. Now
explain what that last expression does where T is a reference.
(I think new T[n] would also be a bit of a problem if T could
have a reference type. Or even simply new T---which guarantees
that operator new( sizeof( T ) ) will be called.)
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Dec 6, 5:48 pm, terminator <farid.mehr...@gmail.comwrote:
On Dec 6, 6:47 pm, Joe Greer <jgr...@doubletake.comwrote:
terminator <farid.mehr...@gmail.comwrote in news:b2d73c27-cfd5-42ee-ae2d-
2b5790802...@s36g2000prg.googlegroups.com:
On Dec 5, 12:32 am, "Alf P. Steinbach" <al...@start.nowrote:
>* siddhu:
why can't we have array of references.
>A reference is not an object, it has no size.
it has a size usually equal to that of a pointer in case of usage an
argument to a none inlined function.
No, references don't even have to have a physical
representation. Analogous to typedef, a reference only
introduces a new name for an object. It turns out that
usually memory for an address is allocated for reference
parameters and reference object members, but it would be a
pretty poor compiler that allocated anything at all for a
local reference.
I said in case of usage as **an argument to a none inlined
function**.
Which is a pretty meaningless statement. With Sun CC, on a
Sparc, when I call something like f(int&), the compiler
decrements the stack pointer by 192. What does this tell us
about the size of a reference, or the size of the return value,
or anything else?
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Dec 7, 3:00 pm, "Alf P. Steinbach" <al...@start.nowrote:
* James Kanze:
On Dec 7, 4:06 am, "Alf P. Steinbach" <al...@start.nowrote:
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.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Dec 6, 6:47 pm, Joe Greer <jgr...@doubletake.comwrote:
terminator <farid.mehr...@gmail.comwrote in news:b2d73c27-cfd5-42ee-ae2d-
2b5790802...@s36g2000prg.googlegroups.com:
On Dec 5, 12:32 am, "Alf P. Steinbach" <al...@start.nowrote:
* siddhu:
why can't we have array of references.
A reference is not an object, it has no size.
it has a size usually equal to that of a pointer in case of usage an
argument to a none inlined function.
No, references don't even have to have a physical representation.
Analogous to typedef, a reference only introduces a new name for an object.
It turns out that usually memory for an address is allocated for reference
parameters and reference object members, but it would be a pretty poor
compiler that allocated anything at all for a local reference.
joe
that is just what I wrote.maybe I am so bad a composer.
regards,
FM.
On Dec 7, 5:23 pm, James Kanze <james.ka...@gmail.comwrote:
On Dec 7, 3:00 pm, "Alf P. Steinbach" <al...@start.nowrote:
* James Kanze:
On Dec 7, 4:06 am, "Alf P. Steinbach" <al...@start.nowrote:
>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.
On Dec 7, 7:23 pm, "Alf P. Steinbach" <al...@start.nowrote:
* James Kanze:
On Dec 7, 3:00 pm, "Alf P. Steinbach" <al...@start.nowrote:
* James Kanze:
>On Dec 7, 4:06 am, "Alf P. Steinbach" <al...@start.nowrote:
>>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.
On Dec 8, 8:16 pm, terminator <farid.mehr...@gmail.comwrote:
On Dec 7, 7:23 pm, "Alf P. Steinbach" <al...@start.nowrote:
[...]
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 objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Dec 8, 8:06 pm, terminator <farid.mehr...@gmail.comwrote:
On Dec 7, 5:23 pm, James Kanze <james.ka...@gmail.comwrote:
On Dec 7, 3:00 pm, "Alf P. Steinbach" <al...@start.nowrote:
* James Kanze:
On Dec 7, 4:06 am, "Alf P. Steinbach" <al...@start.nowrote:
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 objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
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
On Dec 10, 7:48 am, Andrey Tarasevich <andreytarasev...@hotmail.com>
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.
Abhishek Padmanabh 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'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.
--
Best regards,
Andrey Tarasevich
On Dec 10, 8:36 pm, Andrey Tarasevich <andreytarasev...@hotmail.com>
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.
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_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.
--
Best regards,
Andrey Tarasevich
On Dec 10, 4:36 pm, Andrey Tarasevich <andreytarasev...@hotmail.com>
wrote:
Abhishek Padmanabh wrote:
[...]
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.
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.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
In article <e6cf020e-348c-4f3f-ac4f- 12**********@a35g2000prf.googlegroups.com>, ja*********@gmail.com
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.
--
Later,
Jerry.
The universe is a figment of its own imagination. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Nico |
last post by:
Hello folks,
I am currently storing a set of objects inside an array,
$itemlist = array();
$itemlist = new item("myitem");
//...
and I am looking to develop a search function, which...
|
by: Kaptain524 |
last post by:
Hello,
I am using PHP 5.0.4 with Apache 2, on WinXP Pro. This behavior
appears to be fundamental however, and should not be affected by
platform.
It would seem that there is some kind of bug...
|
by: Sam Collett |
last post by:
How do I remove an item with a specified value from an array?
i.e. array values 1,2,2,5,7,12,15,21
remove 2 from array would return
1,5,7,12,15,21
(12 and 21 are NOT removed, duplicates are...
|
by: Mike S. Nowostawsky |
last post by:
I tried using the "toUpperCase()" property to change the value of an array
entity to uppercase BUT it tells me that the property is invalid. It seems
that an array is not considered an object when...
|
by: jr |
last post by:
Sorry for this very dumb question, but I've clearly got a long way to go!
Can someone please help me pass an array into a function. Here's a starting
point.
void TheMainFunc()
{
// Body of...
|
by: Fraser Ross |
last post by:
I need to know the syntax for writing a reference of an array. I haven't
seen it done often. I have a class with a member array and I want a member
function to return an reference to it. ...
|
by: Kevin |
last post by:
Help!
Why are none of these valid?
var arrayName = new Array();
arrayName = new Array('alpha_val', 1);
arrayName = ;
I'm creating/writing the array on the server side from Perl, but I
|
by: Joe Rattz |
last post by:
Hmmm, I wrote the following code. I want an array of bools and I want to
intialize them to false.
bool bits = new bool;
foreach(bool bit in bits)
{
bit = false;
}
The compiler complains...
|
by: Frederick Gotham |
last post by:
Inspired by page 219 of Nicolai M. Josuttis's book, I set out to write a
class for an intrinsic array which would behave, to as far an extent as
possible, like a container. Also though, I wanted no...
|
by: Abhi |
last post by:
I wrote a function foo(int arr) and its prototype
is declared as foo(int arr); I modify the values of the array in the
function and the values are getting modified in the main array which
is...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
| |
