P
Paul
Why is it wrong?Jens Thoms Toerring said:
If I have an array of floats then thte ype of the arrray is surely float,
what other type could it possibly be?
If I have an array of floats then thte ype of the arrray is surely float,
what other type could it possibly be?
J
Jens Thoms Toerring
Paul said:
The *elements* of the array have type 'float', but the array
as a whole - as an object of its own - has a different type.
In the above case its 'array-of-16-floats'. If the array also
would have type 'float' you could compare it to a float vari-
able, using the '==' operator like in
if ( arr == 3.14159265 ) ...
But if you try that the compiler complains and tell you that
you're trying to compare apples to bananas - or to be precise
it might tell you, if you're using g++,
error: invalid operands of types ‘float [16]’ and ‘float’ to
binary ‘operator==’
So, the compiler obviously doesn't subscribe to your POV. It
does not even consider the types to be similar enough to try
to make sense out of it - as it does when you try to compare
e.g. a float to an int by converting the int to float and then
doing the comparison. You can't convert an array to a float or
a float to an array, those types are too different. Now try ar-
guing with the compiler;-)
If you have ten pennies would you consider this set of ten
pennies to be a penny? No, it's obviously something rather
different, a collection of 10 pennies. You will handle it
differently from a single penny and if you buy something
with that set of ten pennies you will get more than for a
single penny. You wouldn't consider them, even for a second,
to be the same kind of thing.
P
Paul
Obviously you dont tell the compiler which element to compare, It can'tJens Thoms Toerring said:
compare all elements in one statement. This is wherer you seem to have
strange idea about arrays. You cannot access the whole array in one
expression, an array is a sequence of objects.
Its not my POV , its how the C++ language works.
You cannot access an array, as a whole , in one big chunk. Maybe in future
quantum computers will allow this but at the present time this cannot be
done.
J
Jens Thoms Toerring
Paul said:
Have you bothered to read the error message the compiler
issues? Does it complain that I didn't tell it which ele-
ment to compare to the float value? Please have another
look and try not to miss the word "types", which is then
followed by the names of the types the compiler was asked
to compare, both stated in single quotes. Do you notice any
difference between the two? (Hint: in one of them the word
'float' is followed by '[16]' while in the other it isn't.)
Does that look as if the compiler thinks that an array of
16 floats has type 'float'? If not, what conclusions do you
draw from this? That the compiler does not understand the
C++ language? If that's the case I guess you should send
the GCC maintainers a bug report. And while you're at it you
also might notify all other C++ and C compiler writers, you
will rather likely find that they all make the same mistake.
P
Paul
Jens Thoms Toerring said:
When we have a pointer to something that pointer, when dereferenced, must
access whatever it points to.
An array of chars when accessed must access a char, you cannot access the
whole array of chars in one operation , unless it is very small.
char arr[64];
The above is an array of char-type objects.
The array identifier is of type char[64].
You cannot get a computer system that addresses unlimited amount of memory,
therefore there are no pointers that can point to a complete array, as a
whole.
There is only one type of pointer that can point to the array(NOT point to
array TYPE) and that is char*.
Now all this is fine because I am talking about pointing to an array ( NOT
pointing to an array TYPE), the array is an array of char-types so the
pointer used is a char*
The pointer-type char (*)[64], when dereferenced does not access the array.
This is a pointer to an array TYPE, not a pointer to "AN ARRAY" of objects.
Now I hope you can see the difference between
a) pointer to AN ARRAY.
b) pointer to an array TYPE.
A pointer to an array, when dereferneced accesses the array.
A pointer to an array-type , when dereferenced, accesses an object that
references an array.
..
J
Jens Thoms Toerring
Paul said:
I have no big trouble with that sentence (I would prefer something
else for "access", like "when dereferenced you get the object poin-
ted to" but I guess I get the meaning and we can agree).
Now things get hairy. What means "An array of chars when accessed
must access a char." Since it's immediately following the first
sentence I guess it was meant to be "An array of chars when derefe-
renced must access a char". Is that what you meant? If yes, then
it's wrong;-) And the reason is that you seem to labour under the
misconception that an array is more or less a pointer and vice
versa. But they aren't. They are completely different things.
Unfortunately, some design decision, probably made rather early
in the development of C, has led a lot of people to make this
mis-assumption.
In C all objects can be copied with the '=' operator, with two
exceptions. One is rather obvious, you can't copy a function. But
the second exception is arrays. Arrays in C don't have a value that
you could copy with '='. And since they have no value you also
can't pass an array to a function by value, nor can you return an
array from a function. That makes arrays kind of "second-class
citizens" of C (and thus also of C++).
Compare that to structures that, as far as I know, were introduced
much later. You can copy structures using '=', you can pass and
return them from functions like any other object (except functions
and arrays). So they have a "value".
The reason behind this early design decision probably was that
computers tended to have only small amounts of memory back in
the time when C was developed. And arrays tend to hold rather
large amounts of data. Thus you avoided to copy arrays anyway.
And passing an array to a function (or back from it) by value
would have required a copy each time, something that no-one in
his right mind would have done anyway.
Now, since an array can't be passed by value it must be passed by
reference. Unfortunately, the syntax for pointers to array objects
is a bit awkward. Without the "decaying" rule the only way to pass
an array (by reference) would have been something like this:
#include <stdio.h>
void f( int ( *ap )[ ] )
{
printf( "%d\n", ( *ap )[ 3 ] );
}
int main( void )
{
int a[ 5 ] = { 1, 2, 3, 4, 5 };
f( &a );
return 0;
}
While this is perfectly legal C it definitely isn't what you'd want
to see in a language each time you have to pass an array to a func-
tion. And thus someone clever came up with the idea of the "decaying"
arrays in value context: whenever an array object is found where a
value is needed (e.g. when used as an argument to a function,) the
compiler automatically converts it to a pointer to the first element
of that array and passes this as the value to the function - instead
of throwing a tantrum that an array has no value and thus can't be
passed to the function.
This now allows to write 'f(a);' even though 'a' has no value -the
compiler does it's magic and inserts some code that instead passes
the pointer to the first element. And the function f() itself can
then be simplified to
void f( int *ap )
{
printf( "%d\n", ap[ 3 ] );
}
And now everything looks a lot nicer. Also memory allocation
looks a lot simpler than, for example, with
int ( *ip )[ ] = malloc( 5 * sizeof **ip );
One, probably unintended, side effect of this was that people
now started to consider an array as a kind of pointer since in
a lot of places where an array is used it's converted without
any ado by the compiler to a pointer to its first first element.
Add to that that the real pointer-to-array syntax is rather awk-
ward, nearly never used and also has no real advantages and you
have a nice recipe for confusion.
But in another respect there's no deviation from a systematic
approach in C and that is when it comes to pointers to objects.
Even though rarely used, you get a pointer to an array object
when you put the '&' operator in front of it, like for any
other object (with a bit of extra syntax irregularity for
functions since the name of a function in value context is
already treated as a pointer to the function and putting a '&'
in front of the name also results in a pointer to it).
So, the whole "mess" in the end is a result of arrays in some
respect being "second-class" elements in C (and thus in the
languages directly derived from C like C++) and having no values
like other objects. But the type system works for arrays exactly
the same as for other objects, it's just not very useful at the
moment.
Complete agreement here with both statements.
That's were you wander in the wrong direction. First of all, an
array never has unlimited amounts of memory. The size of each
array is fixed at the moment of its creation (you can't create
an array with an unspecified number of arguments and you can't
change its size afterwards). And there are other compound objects
like structures that can require large amounts of storage and you
probably will agree that there's no problem obtaining and using
pointers to structures.
So, obviously the address of a compound object as a whole
can be defined and stored in a pointer. You use it everyday
with structure pointers. The convention in C is that this
address is taken to be the one of the very first byte of the
compound object in memory. While this is an obvious choice
it would in principle as well have been possible to use some-
thing else, like the address of e.g. the middle of that object
(or one before if the object has odd size). It's just a matter
of coming up with a useful definition of what the address of a
compound obkject is and then stick to it.
And for that reason there is no problem in getting the address
of an array as a whole - like in the case of the structure the
first byte in memory of the array is used (contributing perhaps
a bit to the confusion due to the "decaying" of arrays since the
first byte of the memory of the array is also the address of the
first element of the array).
And if there wouldn't be the syntactic sugar that you can use
something like 'sp->x' to access the member 'x' of a structure
pointed to by 'sp' you'd be using the rather ugly syntax of
'(*sp).x' everywhere. If you compare that to an element access
via an array pointer the similarities becomes rather obvious:
int a[ 4 ] -> element access with 'a[2]' ('[] operator)
struct S s -> member access with 's.x' ('.' operator
int ( *ap )[ 4 ] -> element access with (*ap)[2] ('[]' operator)
struct S *sp -> member access with (*sp).x ('.' operator)
Luckily, you can write '(*sp).x' instead as 'sp->x', but this
syntactic sugar was only implemented for structure pointers,
but not also for the nearly never used array pointers, so you
can't write e.g. 'ap->3'. And nobody complained because nobody
(or hardy anyome) actually was using array pointers.
Sorry, you lost me here a bit. The term "pointer to an array TYPE"
is rather strange - a type is an abstract concept and you can't
point to types, you can only point to concrete things like objects.
It does. It "accesses" the array as a whole - like a structure
pointer, when dereferenced, "accesses" the whole structure (per-
haps know my unhapppiness with the term "access" becomes clearer).
With both you then need to write something more (use the '.' or
'[]' operator) to get at the members/elements.
That's not correct. What you are calling "pointer to an arrayTYPE"
is *the* the pointer to the array object. And if you dereference
it you get the whole array object - to which you then canapply the
'[]' operator to get at the elements. And what you call "pointer to
AN ARRAY" is just a pointer to its first element, as it typically
is generated in situations where an array is used in a context where
a value is required. If you'd replace 'array' by 'structure' every-
where in what you write you'd notice that your resulting statements
aren't true anymore. And an array is, like a structure, just a com-
pound object that can be pointed to.
I guess you made a big step in accepting that there are two types
of pointers (whatever you call them). Now you only have to get rid
of the mis-conceptions regarding C's ability to point to compound
objects when it comes to arrays. And that step is the smaller one
since I'm sure the concept is well-known and -understood by you in
the case of structures. Just think of an array as a funny kind of
structure and disregard for a moment that for some purely histo-
rical reasons an array as a whole has no "value" and you're there.
Just try to keep in mind that an array isn't a pointer of any kind
and that an array always has a fixed size (like a structure).
(I actually have my problems in seeing a structure as a "value",
but then they are treated everywhere in C as having a "value",
so I've got to accept that. But if I can accept that it becomes
more mysterious why an array didn't got one, that seems to be
unfair to arrays, especially given that they are used much more
often;-)
P
Paul
Well what would you prefer?Jens Thoms Toerring said:
You don't always GET the object pointed to , often when dereferencing a
pointer you are allocating.
I think "accessing" the memory is as good as is gets for terminoloogy.
Another acceptable term is referencing , which is often avoided because of
the clash with a C++ reference type object.
What I mean is....If you reference an array of T's you can only reference a
T type object. For example you cannot technically reference 500 T's, it''s
simply impossible with todays computers.
But I disagree with you here, because an array is simply a pointer under the
hood.
I don't know what you think an array is but for example and array of int's
is simply a contiguous sequence of int objects. There is no special
array-type object that can address a complete array in one operation, for
example:
int arr1[4] = {1,2,3,4};
int arr2[4] = {0};
In C++ you cannot directly copy arr1 to arr2, an array is not a copyable
object its a sequence of objects.
An array-type object is not an array, its just a fancy pointer to an array.
Yes this is a similar tone to what I expressed above.
An array is an array objects, the type of an array of ints is an int for
example:
int arr[64];
This is an array of int objects, it does not have some fancy type like
int(*)[64], this pointer-type is simply a pointer with a extra level of
indirection.
It is usefull for converting a pointer to an array into a reference , but it
does not point directly to an array, it points to whatever you get when you
derefernece it, which is basically another pointer with some type info.
A structure is a differnet beast altogether because we can create a pointer
to a struct, as a whole.
It still the same , even with a quantum computer , I think , touching on
debatable shit now with quantum computers in your garden shed.
..
AN array is a sequnce of objects , you cannot have a pointer to say 500 int
objects.
The pointer to the array is of type int because when dereferenced it
accessess one object within the array.
Its totally fuckin impossible to have a pointer to the array that , when
dereferenced, accesses the whole array in a oner.
Well an array can be passed by value but its unrealistic if the array is say
500 objects or so.
This is old C, I dont remember this kinda stuff but I try to follow your
code without having to refernece stuff.
standard input/output is what it means to me .
Ok you pass the address of an array to a function, What is the address of an
array? It is basically a pointer to a pointer. Why do you need to take the
address of an array, when an array is an address already?
When you pass an array as a pointer you must understand the array-to-pointer
conversion.
An array is basically a pointer, but in C++ we have soem additional type
info, so its an array-type.
If you have an arreay of ints, the type of the array is int, the array-type
is some C++ pointer -type.
No , Nobody clever came up with this idea. This is simply how computers
access memory.
The clever people have no choice, an array of ints cannot be some fancy type
that addresses say 500 ints. An array of ints can only ever address one
single int.
If you do not address an int then you are not addresing the array of ints.
TBH you have lost me because I think you have gone off in a diffeerent
direction.
As I have said an array-type in C++ is not the same as an array of X's
You can have a pointer to an array-type that doesn't even point to an array,
for example:
int (*p)[45] =0;
This pointer points to (excuse the french ) **** all.
I don't give a **** what type it is, what it points to is exactly **** all.
The pointer-type does not define what is pointed to. The object, or array of
objectsd allocated defines what is pointed to , not a pointer that points to
it.
I think you are thinking of an arrray as some kind of special C++ type andf
converting that into an entitiy.
An array is not addressable in one whole chunk, it must be addressed in
sizeof(typeof array objects)
A pointer to array -type in C++ does not address an array , it addresses an
object that is basically a pointer to the array under the hood.
Yes obviously you cannot allocate an unspecified amout of memory.
But Im talking about addressing an array.
If you have an array of 500 ints how do you address such an array?
Its impossible to address the array as a whole. You can only address one
element at a time.
There is no other option, this is he only way you can make a pointer to an
array.
What do you mean by getting the address of an array as a whole?
An address is a pointer to a location.There is no type that, when
dereferenced, accesses a whole array of memory.
It is (excuse the french but neccessarry for emphasis) fuckin impossible.
Even with a quantum computer.
I hate the term syntax sugar, ffs give me a break I am only concereced with
asolute efficiency.
I do not even use the STD lib becuase its syntaxically extra code. But
processing speed is my my perogative, so I would use the libs if they were
good for the job.
Dam ofc I would use vector if it fitted the bill , but if I could use an
array of 20 chars I would definately prefer to use the more simpler array
than some lib code.
Do you even have the mathematical know-how to transpose a vector? I admit I
struggle with this level of mathematics, yes I can transpose a matirx but
only as a exercise. using it as an everyday tool is a different level.
Lets be clear , what do you use an array for ?
If it is nothing more than a string of chars then does it really matter?
If you are 3d programmer who transposes matixes on a daily basis then its a
different subject.
I'm more interested in the maths that the C or C++ lang TBH , and as far as
I can see there is too much focus about types that what the actuall thing
represents.
Whether one is right or wrong I do not care, but I do care if somebody is
trying to make a statement of fact=that is actually incorrect.I am
mathematically minded and 1+1=2 , if you try to say 1+1=11. I will argue
with you becuase I do not accept nonsensical bullshit.
J
Jens Thoms Toerring
Paul said:
I guess you mean the term "referencing" as meaning the opposite
of "dereferencing", i.e. as applying the '&' operator to get an
objects address. And, with todays computers (and those from lots
of years back) you can "reference" (in the sense of "taking" the
address") all kinds of objects, be it simple objects like POD,
structures, arrays or classes - even functions!
If you can do
struct S {
int a[ 500 ];
double b[ 1000 ];
} s;
S *sp = s;
why should it be impossible to do
int ( *ip )[ 500 ] = &s.a;
Now you have a nice simple pointer named 'ip' that points to an
array of 500 int elements. Arrays are no different at all from
structures (or other type of objects) in that respect. Apply the
'&' operator to an object and you get a pointer to that object.
It's an array of 64 int objects. If you call that fancy or not
is your choice. And a pointer to that compoud object is pointer-
to-array-of-64-ints.
It's a pointer of type pointer-to-array-of-64-ints. If you
dereference it you get back the whole array object. To then
get at the inidvidual array elements you need to apply the
'[]' operator. You don't "dereference an array" to get at
it's elements, you apply the '[]' operator.
That you think that you could "dereference an array" is
exactly the point were you are confused due to the "array
decays to a pointer to the first element of the array in
certain situations". I already see you screeming: "but
arr[ i ] = * ( arr + i )
and proves my point". But in reality things are different:
the compiler starts with the 'a+i' bit. Now it says to it-
self "I got two values to add. But the left one is nothing
I know how to get a value for, that looks badly wrong. But
stop, is this an array object? Well, in that case I have this
strange rule that when I need a value but find an array I',
supposed to replace it by a pointer to the first element of
the array. Ok let's try that. Wow, now I have a pointer and
I know how to add an integer to a pointer, I've got to ad-
vance the address by as many bytes as the product of the
number and the size of what the pointer is pointing to. Fine,
that gives me another pointer." And then, in the next step
it does the dereferencing, arriving at the value of arr.
Otherwise there's no difference to e.g. a structure pointer.
With
struct S {
int i;
} s;
S *sp = s;
's' has type struct-S, 'sp' is pointer-to-struct-S. To get at
the structure object you have to dereference 'sp' and then to
get at the element use the '.' operator, i.e. '(*sp).i'. That
with structure pointers you can also use the fancy '->' ope-
rator, that does two seperate things at once is irrelevant,
it's just syntactic sugar and we could live with it if it
never had been invented. So, do you call that also an "extra
level of indirection"?
And that's simply and plainly wrong. A structure (or class)
is no different from an array in this respect at all.
I have no idea how quantum computers come into this, and I don't
have one in my garden shed, already due to the non-existentence
of "my garden";-)
Claiming the same wrong thing several times unfortunately doesn't
make it true, even if you use swear words. You can a have pointer
to all kinds of objects, arrays being just one of them.
No, arrays can't be passed by by value. Structures can, but arrays
can't. If you think that's wrong please show some exapmle code of
how it's to be done.
Yes, replace it with
#include <iostream>
and it's plain, valid, legal C++.
No, it is *not* a pointer to a pointer because arrays *are not*
pointers. Pointers points to some memory address, arrays are the
collection of memory that contains their elements. It's the same
difference as between a house number and the house itself.
No, an array isn't basically a pointer. And it's exactly the same
in C and C++.
Sorry, but you're simply deeply confused. You make a wrong
assumption ("an array is a pointer") and necessarily end up
with lots on non-sense.
Again: an array is an object that contains (not points to!)
other objects. A pointer to an array points to this array
object. You don't have the same confusion about e.g. struc-
tures, where the situation is identical, so apply what you
know and understand well about structures to arrays and
you're there.
That's a statement that's true for all pointers. You can make
them point nowhere by assigning 0 to them. You can make them
even point to places where they're in principle not supposed
to point by using casts. Also in this respect pointers to
arrays are in no way different from pointers to other kinds
of objects.
If you use a pointer in an expression then the pointer alone
determines the type of what is pointed to. You'd need casts to
get around that.
An array is just one of the types of objects that C++ knows.
Again, you are confusing arrays with pointers. Stop that
and things will become simple.
By using the address of the first byte in memory where the
array starts. Not even the slightest bit of a difference to
all other kind of objects in C++.
Wrong. Apply your argument to a structure or class and you
will immediately realize that this is non-sense.
There's no difference in processing speed if you write '(*sp).x'
or 'sp->x' - the compiler will convert it into the exact same
machine instructions.
Same as everyone else, I guess.
Well, I am also rather fond of mathematics and had to study
it for a few years. And one of my experiences is that it is
always advantageous when one understands something correctly
since it helps in avoiding mistakes and getting confused fur-
ther down the way. And yes, I agree that "1+1=2" (at least in
all nunber systems except binary). The problem is that you claim
"1=0" and then draw conclusions from that which, of course,
are then as wrong as the premise you started from;-)
P
Paul
Jens Thoms Toerring said:
Applying the & operator is called pointer derivation.
When you apply the address operator to an array-type object, you are
bascially taking the address of a pointer.
An array is not a single object, its a sequence of objects.
&s.a creates a pointer, that is bascially a pointer to a pointer.
It doesn't point to 500 ints' it points to another pointer object.
No it points to a pointer object.
An array is a completely different thing than a structure.
its an array of integer objects, and a pointer to these integer objects is
of type int*
No you don't , you get an address
You cannot get any pointer that address 500 ints, its techincally
impossible.
Applying the subscript operator is identical to dereferencing.
And dereferencing a pointer type
int(*)[64] does not access any array elements whether you dereference it
with subscripts or asterix.
A pointer to an array-type object is not the same as a pointer to an array
of objects.
Its simple:
void foo(int arg1, int arg2, int arg3){
int arr[] = {arg1, arg2, arg3};
}
int arr1[3] = {1,2,3};
foo(arr1[0],arr1[1], arr1[2]);
How come it needs to be dereferenced twice to access an array of objects?
Dereference it once and you get a memory address.
int arr1[3] = {1,2,3};
int (*p)[3] = &arr1;
std::cout<< *p <<std::endl;
std::cout<<**p;
An array-type object is a pointer under the hood.
The compiler outputs a pointer compatable with the implementation, the rest
is just compiler food.
No I'm not saying "an array is a pointer".
I'm saying an array is bascially a pointer under the hood, which is
completely different.
No it's not, an array is a sequence of objects, there is no containing
object.
No you've got it all wrong.
There is no array object that contains other objects, an array object is
just a pointer with some additional typeinfo used by the compiler.
It doesn't
int* p =0;
p does not point to an integer type object.
An array is not a type of object. An array is a contiguous sequence of
objects.
There is no containing array type object
Im not confusing anything, that is how it works.
If the system has 4 byte integers then 500 integers = 2000 bytes.
You cannt have such a system that can address 2000 bytes. You can only
address individual elements of an array, it's technically impossible to
address the whole array.
What does a class have to do with it? A class is not an array.
You seem to think a class is the same as an array, this is very wrong.
I do not claim that 1=0, whatever that is supposed to mean
J
Jens Thoms Toerring
Paul said:
No, you don't because your premise that an array is a pointer
is not correct.
An array is a single object that consists of objects, the
same as a structure or a class. Have you ever asked yourself
how something can have a type (and you have agreed that there
is an array type) but not be an object? That would make it
the only beast with such a strange property in all of C++.
Not in this respect.
No, it isn't. It "opens up" the box that is an array object
and extracts the value of the indexed element. Dereferencing
only comes into it if the compiler exppamds the '[]' operator
into
arr[ i ] <-> * ( arr + i )
And I have already tried to explain as clearly as I can
what steps the compiler is going through with that:
The somewhat special relationship (but which doesn't imply
identity) of pointers and arrays is only due to the special
way arrays are handled in C++ (and C) when they appear in a
context where the compiler needs a value.
I hope you're not serious. This has nothing to do with pas-
sing arrays by value. You pass three ints to a function
and then stick them into a new array in that function. There
is abosultely no passed of an array at all here, neither by
value nor by reference.
And if you don't believe me you perhaps should consider
taking a look at one of the books by Stroustrup. E.g. in
"The C++ Programming Language (3rd edition)" he writes
in section "7.2.1 Array Arguments" (p. 147):
If an array is used as a function argument, a pointer
to it's initial element is passed. [...] That is, an
argument of type T[] will be converted to a T* when
passed as an argument. [...] In other words, arrays
differ from other types in that an array is not (and
can not be) passed by value.
And he's less sloppy here with his terminology here than in
the glossary you cited before;-)
In both cases you rely on the implicit conversion of an
array object into a pointer to its first element. If you
want to print out '*p' the compiler is looking for a value
but what it finds instead is an array object (the result
of '*p'). And that is then implicitely converted to a poin-
ter to the first element of the array object. So '*p' is
not a pointer, it is actively converted from an array ob=
ject to a pointer in this situation.
Same for the '**p' case. '*p' results is an array object,
but the compiler needs a pointer value that it can derefe-
rence. And again "the rule" kicks is, '*p' is converted
to a pointer that in turn can be dereferenced.
If you're talking of "under the hood" then this implicit
conversion of array objects to pointers is what happens
"under the hood", nothing else.
Saying the same thing again and again doesn't make it
true - an array isn't a pointer, neither directly nor
under any hoods. An array is an object. That it consists
of a collection other objects, all of the same type, is
secondary - a specific property characterizing that type
of objects. A pointer, in contrast, is an object that just
contains an address, typically that of another object.
That's immaterial. You can make a pointer point anywhere
in memory. But the hour of thruth has come when you try
to dereferencing it. For a 0 pointer you'll get a segmen-
tation fault, because the computer will try to fetch an int
value from a memory location you have no permission to access.
If it points to a more reasonable place the compiler will re-
trieve an int from that location. The type of pointer (and
nothing else) determines what kind of value the computer
will try to fetch from the location pointed to. If you in-
crement or decrement a pointer or add some integer value
the resulting address is again determined by the type of
the pointer. Same for the subtraction of two pointers.
I beg to disagree;-)
With respect to being a (composite) object that has an
address there's no difference. And that was what I was
refering out.
I do not claim that 1=0, whatever that is supposed to mean
I was alluding to your claim that an array is a pointer (which
you now somewhat retracted by qualifying it with "under the
hood", but that doesn't make too much of a difference) If you
start with that premise you can derive without any logical
flaws all kinds of further wrong statements.
Perhaps you could try to clearly describe what "under the
hood" means. It's a term you introduced without specifying
what it actually means. Since you're obviously as interested
as I am in getting at the bootom of what really is going on
when one uses arrays and what's their relationship to pointers
it would be interesting to see, for both of us, what that hood
thing is actually doing. I have explained, I think quite
detailed, how I consider things to be working (the "under the
hood" thing being nothing more than the implicit conversion of
arrays to pointers to their initial element under certain cir-
cumstances), so it would be interesting to see what's happening
"under the hood" from your point of view. Perhaps that leads us
to a point where we can apply Ocam's razor, i.e. picking the
simpler of two explanation that still explains all observable
effects.
I
Ian Collins
If an array does not have a unique type and is simply a pointer, explain
why this won't compile.
typedef char C[16];
void f( const C& ) {}
int main()
{
f( "hello" );
char* p;
f( p );
}
but
f( "hellohellohello" );
will.
P
Paul
I'm not premising that an array is a pointer, but I am acknowledging that itJens Thoms Toerring said:
it like a pointer in many ways.
An array identifier is not an object that contains elements , it's a pointer
like object that points to the array.
No I disagree with this completely. There is no containing object with an
array.
An array is a sequence of objects, the array-type object is a pointer-like
object that references the array.
An array is not a structure, its a sequence of objects of the same type.
The object type is for example with an array of chars:
char arr[64];
The object type is char. The identifier 'arr' is a pointer like object that
references an array of char objects.
If you take the address of 'arr' you are creating a pointer that points to
'arr', not to the array of chars.
char* p = ("An array of chars");
char** pp = &p;
char arr[] = ("An array of chars");
char (*parr)[18] = &arr;
parr is the same level of indirection as pp. The only difference is that
parr is a different type of pointer.
Both pointers need to be dereferenced twice to access the array of chars.
There are so many differences I don't even know where to start.
No the array object is simply converted to a pointer. The array object is
not a class like container it's a pointer-like object
You seem to be replying to yourself here.
It passes the array values to the function.
It doesn't matter how it does it, it just does do it.
You have made one good point here, that arrays differ from other types.
I wouldn't say he is sloppy at all,
Its converted to a string. The output is a string representation of a memory
address.
*p certainly does not access the array of integers, but **p does.
p is a pointer to an object that references the array, it's not a pointer to
the array of integers.
The object pointed to is an object that references the array, however you
choose to think of it. Taking the address of an array-type object creates a
pointer to the array-type object, not to the array of int objects.
An array is not a single object , its a sequence of objects. Obviously
unless it is size one.
An array is not a single addressable object comparable to a class type, it's
a sequence of objects.
For example you cannot do this:
int arr1[3];
int arr2[3];
arr1= arr2;
With an array this is not possible because you cannot access the array as a
whole. With a class type object this is perfectly doable:
struct obj_type{int x, y, z;};
obj_type a,b;
a=b;
Yes but this proves that a pointer-type does not define what it points to
So when you said:
"If you use a pointer in an expression then the pointer alone determines the
type of what is pointed to."
You were incorrect.
No a class type object is not the same as an array.
I never did say "an array is a pointer." in the context you imply.
I have said that an array is a pointer under the hood, because in many
situations that is how it works.
"under the hood" means the way a compiler treats an array as a pointer, at
slightest opportunity
P
Paul
I didn't say its simply a pointer, I said its a fancy pointer.Ian Collins said:
I
Ian Collins
Where and how is that "fancy pointer" defined?
How does a "fancy pointer" explain the above and the error messages your
compiler will give you?
J
Joshua Maurice
Sorry for replying to Paul, but I just had to for this brilliant gem.
int x;
int* y = &x;
That is taking the address of an int object, and assigning it to a
pointer object.
int* x;
int** y = &x;
That is taking the address of a pointer object, and assigning it to a /
different/ pointer object of /different/ (but related) (static) type.
Learn the difference - it could save your life!
J
Joshua Maurice
Oh wow, really? This is a new low for Paul.
Seriously Jens Thoms Toerring, I would appreciate your efforts if it
was targeted at someone genuinely willing to listen and learn, but
Paul has demonstrated over the past few months (?, a long time at
least), that he refuses to adopt the language of discourse of the
super majority. You're welcome to continue arguing with him if only
because I have no particular power nor moral justification for
stopping you, but you should be aware that this will go nowhere, and
just possibly irritate the rest of us.
Man, I really need to get a real newsreader so I can plonk people. Oh
procrastination.
I
Ian Collins
Many but not all?
How and where is this "pointer like object" specified? How does one
increment and decrement one? How does sizeof apply to one? ...
How is accessing the elements in an array with the [] operator different
form accessing the elements of a class with the . operator?
Go on, have a go.
So how can one apply sizeof to an array type?
If we change that to
struct A { int x, y, z; private: A& operator=( const A&); };
Is A no longer an addressable object? You can't assign one to another.
Explain sizeof("hello").
J
Jens Thoms Toerring
Paul said:
I have no doubt that you seem to believe that. But that doesn't
make it a fact.
There, of course, is no containing object, the array *is* the
containing object. And, again, how can be there a type without
an object that has this type? Are you avoiding the hard ques-
tions?;-)
Both are objects that contain other objects. And that's what
counts.
We've been further. You had accepted that 'arr' is of type
array-of-(some)-chars. Now it's up to you to explain why you
retract something that you already admitted to.
You always use weasel-words like "under-the-hood" or "pointer-
like" object. But programming is all about being exact. So
define your terminology or discussions are meaningless.
Of course, taking the address of 'arr' results in a value
(not a pointer yet, since that's an object) that is the
address of 'arr'. But the "not to the array of chars" bit
has me stymied. We have an array of chars, called 'arr',
when we take its address we get a pointer that points to
'arr', but then that pointer does not point to that array?
Where does it point to then, if I may ask?
No reason for the parenthesis here. And the type on the left
side object should actually be a const char pointer since you
are not allowed to change what 'p' points to afterwards.
So, you have an (immutable) array object on the right side.
And you try to assign that to a char pointer. The compiler
will notice that there's something isn't right (array object
on the left, pointer on the right), but again "the rule" ("If
I need a pointer but got an array I'm supposed to try to con-
vert the array to the first element of that array") kicks in
and safes the day.
No problem here at all, 'p' is a pointer to char, so
putting a '&' in front of it gives you a pointer-to-
pointer-to-char.
Mostly fine (modulo const-ness), 'parr' is a genuine pointer
to an object of type 'array-of-18-chars'.
But the difference in types is what this is all about.
An airplane is something completely different from a car. But
in one respect, getting you from A to B, they share something.
And there are lots of comparisons between airplanes and cars
when it comes to their advantages/disadvantages when going
from A to B, even though they are rather different things,
aren't there? So, obviously, some aspects similar can be com-
pared, putting aside all other differences that don't matter?
I just wanted to make you read what I wrote;-) If you did
you didn't show any signs that you did.
I was always completely honest with you that arrays are some-
what special. I told you about their "second-class" role in
C++ and C, I told you how they are get some special treatment
etc. So were's your point?
That's what happens after things have been handed over to
the std::cout class. Do you really want me to go also into
that as well?
Please stop throwing words around. Define what "access"
means. Otherwise I could start arguing with "safda" does
"ewori" and none of use would be wiser.
What is the difference in your language between "references"
and "pointing"? 'p' to me is a pointer to the array object
with the name 'arr'. And that's all there is about it. Now
stop hiding behind lots of undefined terms and tell me
exactly what else it is. Or are you a politician?
Sorry, what is referencing what and what's pointing to what?
This more and more sounds like a talk show were someone
doesn't want to admit something got f*cked up and uses lots
of verbiage to hide behind it.
And what made you think that this is the case?
You can't do that for exactly the same reasons you can't do
struct S {
int x;
double y;
};
int s.x = 6;
double s.y = 3.15;
Before you can set the members of a structure you need a struct
object. Before you can set the elements of an array you need an
array object.
That already has been discussed to death. Yes, arrays are
"second-class" citizens in that respect. Go back in this
thread and see that I pointed out exactly this and tried
to give an explanation why, for historical reasons, this
happened (it was just yesterday). If you want to argue about
that feel free to do so, but don't try to use things I already
explained. I hope you can do better or it's going to become
boring.
Sorry, "you were incorrect" isn't an argument, it's nothing more
than an unsubstantiated claim. I'm hope you can do alot better
than that.
Of course, a class type object is not the same as an array
(object). Where did I claim this? But they're both objects
and they both have an address (the lowest addres in memory
theu occupy).
Sorry, I'm not really impressed. Could you perhaps become a bit
more forthcoming about the "way a compiler treats an array as a
pointer, at slightest opportunity"? I've tried to explain to you
what I think the compiler is exactly doing each step along the way,
and getting back some mumblings about "what the compiler is doing",
with "slightest opportunity" thrown in, isn't very enlightening.
What is it doing under what circumstances in your POV? If we know
that we can have a meaningful discussion. I think we're quite a
bit past the hand-waving stage of an argument, so let's get down
to the nitty-gritty details.
P
Paul
What you say makes no sense re: "there is no containing the object, theJens Thoms Toerring said:
array is the containing object."
I'm avoiding nothing.
No there is no array container object. Its a pointer like object that
references the array, not a containing object.
It points to arr, not to the array of chars, that arr references.
You haven't told me anything , many of the things you say have been
completely incorrect and I have had to correct much of what you say.
I just told you what happens, its converted to a string. You are starting
to become a bit of an arse.
Yeah I was right you are becoming a total arse now.
I'm hiding behind nothing, if you don't understand a simple term like
"references" you must be a bit stupid.
If you cannot understand these simple terms then I conclude you are too
stupid to commumnicate at this level.
Beccause that is the case.
There is no comparison between a struct an an array they are two completely
different entities.
So what is this array object that contains the array elements that you speak
off?
There is no such object, there is only the array elements themselves.
Its not a claim , what you said is completely incorrect.
<quote ref="A few messages ago">
"> A structure is a differnet beast altogether because we can create a
pointer
And that's simply and plainly wrong. A structure (or class)
is no different from an array in this respect at all."
</quote>
An array is not a single object its an *drumroll* array of objects.
If you dont understand that perhaps you will understand the term it is a
contiguous sequence of objects.
There is no containing object that contains the array elements. An array is
accessed by dereferencing a pointer, oh wait you don't understand the term
accessed do you. Ok if you cannot understand. I cannot communicate with you.
I'm not particularly bothered if you are impressed or not.
I think if you cannot understand terms like "accessing an array" and
"referencing an array" then you are maybe not intelligent enough for a
conversation at this level.
P
Paul
Sorry for replying to Paul, but I just had to for this brilliant gem.
int x;
int* y = &x;
That is taking the address of an int object, and assigning it to a
pointer object.
int* x;
int** y = &x;
That is taking the address of a pointer object, and assigning it to a /
different/ pointer object of /different/ (but related) (static) type.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
And what do you think happens when you do this:
int arr[10];
int (*p)[10] = &arr;
This pointer does not point to the sequence of integer objects that is the
array.
This pointer points to an array-type identifier object, which is just a
pointer + some type info.
Dereferencing this pointer does not access the array, it gives the address
of an array.
When you derefernece a pointer to int , you access an int object.
When you derefence a pointer to a vector, you access a vector object.
When you dereference a pointer to a T, you access a T.
How is it when dereferencing the above pointer it does not access the array?
Because its not a pointer to THE array. Its a pointer to an array-type
identifier object with the name 'arr'.