Problem with array objects

[PaulR]

Yes, a single object of array type exists in memory.

We _cannot_ access this single object as a whole. It's as simple as
that.

So what? That's a quirk of the language.

And this is what you'd say to those who think no array object exsits
with the expression:
int* p = new int[55];

They say this is just a pointer to a sequence of integer objects, no
array object is created. This may be a valid point because according
to the C++ standard an object of array type is non modifiable and your
definition of an array object is very modifiable.

It's not a matter of seeing a difference, it's a matter of defining
the terms.
If you stipulate that when you say "array type object" you mean
exactly
the same thing as "object of array type", then I'm quite happy to
agree
that, by definition, there _is_ no difference, so I'll _see_ no
difference  =)


Yes, that's right. Being very loose with terminology, _all_ variables,
data, what-have-you, are objects. Anything to which you can write, or
from which you can read, a value, is an object. Anything that takes up
measureable memory space is an object. Objects can have subobjects.
So the array is a single object, made up of subobjects.

But we cannot access the array object as a whole, if by "access" you
mean
read the whole thing as a lump.

It just so happens that structs are assignable. But if the language
didn't
support struct assignment, would you say that structs weren't objects?

This seems a bit like a condraction.
You say that loosely spkeaing an object is a region of memory from
which you can either read or write a value.
But then you say an array object is a region of memory that you cannot
read or write to, but its the same region of memory as the integer
objects that can be read or written to.
The same object(region of memory) cannot be accessable yet also
inaccessable (accessable meaning either readable, writeable or both).

A struct is a defintion of a type, you cannot assign to a struct but
you can assign to an object of struct type.
I think this is what you mean and the term "assign to a struct".
Its like saying "assign to a class" huh this is not right, is it?

Yes, it exists. Yes it can be accessed on an element-by-element basis,
just not as one big lump.


Well, yes, they are different objects though not disjoint. The
subobjects
are fully contained within the array object.

They could be seen as the same or different depending on how you look
at it, for example:
The array is the same as the integer objects.
The array is different from a single integer object.

This is because an array can be seen as a sequence of integer objects
or as one single object that contains sub objects.

And I don't get what you're saying about
the "pluralisation". Yes, there is a single array object containing
multiple subobjects. An int has multiple bits. Does this mean that the
int is different than it's component bits? That's either trivially
true
or trivially false depending on how you interpret it, but either way
it's trivial.

As I said above the pluralisation is concerned with how you think of
an array.
Is it objects or an object. An array can be seen in both ways.

So the plural objects are accessable and the sigular object is not , isit
just a concept of all the objects grouped together as one?
Its not an object that has been declared or anything, its non modifiable,
its not accessable, a there are different opinions about whether or notit
even exists.

Some people say that there is no array object, with dynamic arrays, andthat
an array object is 'arr' in the following:
int arr[55];
This is an array type object because when you examine it with typeid its
type is int[55].
This makes sense because this object is non modifiable. Its also not
accessable, as an object in its own right, because any attempt to access it
yields a pointer to its first element.
That means that your explanation of an array being the collective for all
the elements in memory does not make sense because your explanation of an
array object would also exist with a dynamic array, would it not?

No, the "problem" with dynamic arrays is that there is no identifier
for the
array as a whole. It is anonymous. _All_ we have is a pointer to its
first
element. Since we don't have a name for it, we don't have a way of
identifying
the array-as-a-whole to find its typeid, or size, for that matter.
Again,
this is really just a quirk of the language.

What about this:

int (*p)[16] = (int (*)[16])new int[16];

cout<< sizeof(*p);
cout<< typeid(*p).name();


Does *p give us access to the array object?

Okay, good.


I'm not sure what you mean by "represents the memory". I say that the
array
object simply _is_ that chunk of memory. There may or may not be a
name
identifying that chunk of memory as a whole. There is such a name for
non-dynamic arrays, there is not for dynamics arrays. (Of course, the
name
may not be visible in all scopes, but the point is, it exists
_somewhere_
in the case of non-dynamic arrays.)

A representaton of something is similar to a vector object
representing the array in memory.
For example:
vector<int> v(16);
This creates memory for 16 int objects, and that memory is
represtented by the object 'v'. The object 'v' is not the same as the
16 integer objects that it represents.

This is *similar* to what i mean with an array object representing an
array.

This object is something that the compiler creates as a pointer to the first
element with some additional info that allows the size and typeinfo to be
carried with it.

You say that the compiler "creates [this array object] as a pointer".
I don't
agree, but leave it for a moment. [*]

No I didn't say that at all.
I described a mechanism for implementing an array object based upon a
pointer with addition type info.

I think that in memory no objects exist other than the sequence of element
objects.
However given this C++ type mechanism that allows an identifier to
represent this array as a whole, we can say that the sequence of objects is
one object as a whole.
This is the only way I can see how it works with no conflicting defintions.
The only argument I have seen against this is the "an array is not a
pointer" argument, which is nonsense because I am not saying an array is a
pointer.

[*] But you just said that the array object is "[created] as a
pointer". So it's
created as a pointer, but isn't a pointer? I agree that it isn't a
pointer, but
then what do you mean that it's created "as a pointer".

I was describing a mechanism a compiler could implement to create an
array object.

Going back to a vector object. It will have some allocator that
references the memory location where its elements are stored but this
allocater will eventuall boil down to a pointer somewhere along the
lines. I'm not saying that a vector is a pointer , I am explaining how
it may be implemented.

 

[Paul]

On 2011-06-02 09:23:12 -1000, Paul said:


I am simply trying to get to the bottom of why you think a pointer of
type int* cannot point to an array of integer objects.

The reason is simple: a pointer of type int* points to an int. That's
what int* means. An int is not an array of integer objects.

int arr1[1];
This is an int(singular)
int arr2[16];
These are ints(plural)
A pointer to all these ints can be, and usually is, of type int*.

A pointer to any of these ints is of type int*. There is no single
pointer to all of these ints.

A pointer references a memory location and when its dereferenced we get
the value from that location.
You cannot reference a whole array unless you have an array of pointers.
You can only represent a pointer to the whole array using the C++ type
system.

I can appreciate both pointer types as pointing to an array of objects,
in different ways. I do not think that an int* cannot point to an array
of int objects.

Which is what I said above: an int* points to an int. It does not point
to an array of int objects, because an array of int objects is not an
int.

Whoops, misread the double negative. I said the opposite, and merely
re-asserting your claim that you disagree doesn't contribute to the
discussion. The C++ language definition tells you what the type of a
pointer is in C++; if you think it should mean something else then you
belong in a different newsgroup.

--

Simply stating that this is NOT correct or that is NOT correct doesn't do
alot for the discussion either. But I have another discussion going on, that
you were previously involved in but have now shifted over to this one, where
the guy is say that an array object is the same thing as an array of
integers.
So is an object of type int array the same memory region that is a sequence
of integer objects? If it is then :
[int][int][int][int]
The above is four integer objects or a single array object.

[int]
The above is a single integer object or an array of size one.

In the latter example , the array object is the same thing as its element
object. You are saying this is not an int, please can you clarify how this
region of memory can possibly be conveived as NOT being an int.

You have not clarified what exactly is your idea of an array object, because
you started to dsiscuss it but you seem to have dropped out of the
discussion when I asked whether an array object exists with:

int* p = new int[55];
People seem to have different opinions about whether or not an array object
exists here. Or to make it in linewith the current discussion consider this:

int p2 = new int[1];
What exaclty is the object created by this expression?

I have said that I think it can be considered as either
a) an array of size one
b) Just one integer object.

Just as the 55 elements p points to above can be considered:
a) an arrayt of size 55
b) int objects, in sequence


There is no right or wrong way to view an array , it can bew seen both ways.

 

[Paul]

* Pete Becker, on 03.06.2011 04:06:

It's just a question of terminology, common sense & effective
communication.

If you want I can cite you umpteen examples from the standard that employ
far worse terminological shortcuts.

Intelligent folks don't write to you requiring that you do editorial fixes
of those places, because to anyone with half a mind it's obvious what's
meant.

This is nonsense, a document that's presented as an ISO standard is in place
to define the language.
Its meaning should not be decided by the interpretation of the reader.
If there are techincal innacuraicies in a techincal standard they must be
corrected or the document doesn't define the language correctly.


Also when we say a pointer type int* can point to an int, an array of
integers or nothing. It obvious what is meant to intelligent folks.

 

[Paul]

[snip]

I am simply trying to get to the bottom of why you think a pointer of
type
int* cannot point to an array of integer objects.

A pointer of type int* cannot point to an array of int because
converting a pointer to array of T to a pointer to T is not one of
the standard conversions enumerated in section 4 (Standard
conversions) of the C++ standard.

A pointer of type int* can point to an element in an array of int.
Pointing to an array is not the same as pointing to an element in
the array; an array and an element in it do not have the same type.

Yes pointing to an object of array type , is not the same as pointing to an
array of objects of integer type.

You are defining the term "pointing to an array" to mean poiting to an
object of array type only. It is quite acceptable to conceive an array as a
sequence of integer objects rather than one single array type object.
This is why the types are different.
It's simply terminology, you see at as one single object, whereas I can see
it as a single object but also as a sequence of objects.

With the following code..
int arr[7];
int* p1 = arr;
int (*p2)[7] = &arr;

Both the pointers point-to the first element in the array, and both pointers
also point-to the array of integer objects. They are just different types of
pointers.
They both point to exactly the same location.

A example of both pointers accessing...;
a) A single object:
*p1;
**p2;
b) An array of obects:
*p2;
for(int i=0; i<7 ; ++i){ p1;}

Note that in (b) p1 does not access the integer objects it just accesses the
array type object. p2 does access the array of integer objects but it does
not access the array type object.
They only differ, because of their pointer types, in the way they access the
array. They both point to exactly the same array but in this different way.


Consider a stack frame pointer, pointing to the stack. It doesn't actually
point the whole stack at the same time but nonetheless its still considered
to be pointing to the stack.

 

[hanukas]

So is an object of type int array the same memory region that is a sequence

of integer objects? If it is then :
[int][int][int][int]
The above is four integer objects or a single array object.

[int]
The above is a single integer object or an array of size one.

In the latter example , the array object is the same thing as its element
object. You are saying this is not an int, please can you clarify how this
region of memory can  possibly be conveived as NOT being an int.

It is just memory, the type system in C/C++ is abstraction. The key
concept relevant to your suggestion above is that object of type int
is stored in that memory location. References and pointers are
abstraction of concept of "address" in memory.

The first example of yours is that sizeof(int)*4 chars worth of memory
is allocated, typically aligned to sizeof(int). The type of objects
for that region of storage (read: memory) is int. You are supposed to
read and write int objects to memory which can be pointed at with
pointer-to-int (int*).

The second example of yours doesn't stipulate how the storage (read:
memory) is allocated. That is critical piece of information as it will
determine the type. There are four ways that spring to mind at this
sitting:

1. int* p = new int; // single int object in heap
2. int* p = new int[1]; // array of 1 int in heap
3. int value; // in stack or global scope
4. static int value; // definitely not in stack

But that is irrelevant for the point at hand: if you have a pointer to
that integer, that's all you going to need to access it. Beyond that,
you need to know if the int is in sequence of integers and the range.
That is something the C++ does not do for you, this is important to
realize. You're on your own when you do pointer arithmetic to access
adjacent int objects, if any.

You have a knack for making the obvious obfuscated;
congratulations! ;----o

 

[Paul]

[snip]

I am simply trying to get to the bottom of why you think a pointer of
type
int* cannot point to an array of integer objects.

A pointer of type int* cannot point to an array of int because
converting a pointer to array of T to a pointer to T is not one of
the standard conversions enumerated in section 4 (Standard
conversions) of the C++ standard.

A pointer of type int* can point to an element in an array of int.
Pointing to an array is not the same as pointing to an element in
the array; an array and an element in it do not have the same type.

Yes pointing to an object of array type , is not the same as pointing to
an
array of objects of integer type.

No, pointing to an array of objects of integer type, that is,
pointing to a C++ array of int, is pointing to an object of array
type. An array of int is an array. An object of type array of int
is an object of array type.

Pointing to an array type is not the same as pointing to an element
type of the array.

You are defining the term "pointing to an array" to mean poiting to an
object of array type only. It is quite acceptable to conceive an array as
a
sequence of integer objects rather than one single array type object.
This is why the types are different.
It's simply terminology, you see at as one single object, whereas I can
see
it as a single object but also as a sequence of objects.

The C++ sees it as: "An object of array type contains a
contiguously allocated nonempty set of N sub-objects of type T."
Pointing to an array is pointing to an object of array type.
Pointing to a sub-object in an array is pointing to something other
than an object of the array type of the array that the sub-object is
in.

You have quoted some text from that seems to describe an object of array
type.
As I said , and you have proved me correct, you can only see an array as "a
single array type object". You cannot see it at as array of integer
objects( or whatever type it is).

With the following code..
int arr[7];
int* p1 = arr;
int (*p2)[7] = &arr;

Both the pointers point-to the first element in the array, and both
pointers
also point-to the array of integer objects. They are just different types
of
pointers.
They both point to exactly the same location.

Both pointers do not point to the first element of the array. p1
points to the first element of the array; p2 points to the array.
An array is not the same as its first element.

The address of an array is the same as the address of the first element, and
a pointer is this address.

They both point to exactly the same place and they both point to exactly the
same array. Whether you view it as pointing to an array of pointing to the
first element is just a POV.

A example of both pointers accessing...;
a) A single object:
*p1;
**p2;
b) An array of obects:
*p2;
for(int i=0; i<7 ; ++i){ p1;}

Note that in (b) p1 does not access the integer objects it just accesses
the
array type object. p2 does access the array of integer objects but it
does
not access the array type object.
They only differ, because of their pointer types, in the way they access
the
array. They both point to exactly the same array but in this different
way.

p1 in (b) does not access an array type object. p1 is a pointer to
int. The expression p1 is equivalent to *(p1+i). According to
the C++ standard (start of paragraph 5 of 5.7 (Additive operators)):

No p1 is not a pointer to integer(singular) , it is a pointer to
integers(plural).
Correct p1 doesn't access the array-type object , but it accesses the array
of integer objects.

When an expression that has integral type is added to or subtracted
from a pointer, the result has the type of the pointer operand. If
the pointer operand points to an element of an array object, and
the array is large enough, the result points to an element offset
from the original element such that the difference of the
subscripts of the resulting and original array elements equals the
integral expression.

The result of (p1+i) is a pointer to int that points to the i-th
element from the array element that p1 points to. p1 points to an
array element; it does not point to the array that the element is in.

Look at the expression :
p1 + i;

It's a pointer plus offset(or index).
p1 is pointer to the beginning of the array
i is an offest that indexes the array.

It cannot be any clearer that p1 points to the array.

Unlike p1, p2 is a pointer to an array type object. p2 points to an
array. p1 does not point to an array; it points to the first
element of the array that p2 points to.

p1 and p2 point to exactly the same place, and the same array.

There is a significant difference between a stack frame pointer and a
C++ pointer: a C++ pointer is typed. In C++, the result of
dereferencing a pointer to T, where T is a type, is a T.

No, dereferencing a pointer of type pointer-to-T, will result in a T if it
points to a valid T object.
The pointer type declares a pointer object that can address an object of the
decalred type , for example:
int *p = 0;
p = &ix; /*assume x is valid int*/
p = new int[64];

Here the pointer p is declared to be a pointer of type ptr-to-int, it means
this pointer must be capable of pointing to a valid int object., It has
nothing to do with what it points to.
The above the pointer is shown pointing to nothing, an integer and an array
of integers.

Now consider the following code:
int *p;
What does this point to? Uninitialised memory that could contain anything.
The pointer type only tells us that the declared pointer object is capable
of pointing to an integer, it does not define what is pointed to, as you
have tried to imply.

The result of using a stack frame pointer as an address operand
depends on what the operator does. Different operators move 1, 2, 4,
8, or some other number of bytes to or from storage starting at the
address given by the address operand.

What you seem to be talking about here is what I know as the PTR keyword in
assembly, it may change in different assemblers.
I don't really see what this has to do with the fundamental concept that a
SFP "points to" a stack frame.

 

[hanukas]

int* p = new int[55];

People seem to have different opinions about whether or not an array object
exists here. Or to make it in linewith the current discussion consider this:

Memory is allocated and returned; you get a pointer to the first
element. The type is "int*"

int p2 = new int[1];
What exaclty is the object created by this expression?

That's a syntax error, but I assume you meant "int *p2 = new int[1];",
in which case memory is allocated and returned; you get a pointer to
the first (and in this case only) element. The type is "int*"

I have said that I think it can be considered as either
a) an array of size one
b) Just one integer object.

Array of size one has only one object, just like array of size two has
two objects and so on - amazing, yes. But operator new [] does not
create array, it does dynamic memory allocation. The allocated memory
is returned to you as pointer to the first element.

Just as the 55 elements p points to above can be considered:
a) an arrayt of size 55

No, you cannot consider it as an array of size 55, as it is not an
array.

b) int objects, in sequence

Better.

There is no right or wrong way to view an array , it can bew seen both ways.

When you view an array, yes, but your examples are dynamic memory
allocation.

 

[hanukas]

message










This is nonsense, a document that's presented as an ISO standard is in place
to define the language.
Its meaning should not be decided by the interpretation of the reader.
If there are techincal innacuraicies in a techincal standard they must be
corrected or the document doesn't define the language correctly.

Also when we say a pointer type int* can point to an int, an array of
integers or nothing. It obvious what is meant to intelligent folks.

class paul
{
public:
int value;
int data[10];
std::string message;
};

paul paulArray[10];
int* p = &paulArray[0].value;

So now p points to array of paul, huh? How about adding that into the C
++ standard, too? NO! The p points to int. End of story.

 

[Paul]

int* p = new int[55];
People seem to have different opinions about whether or not an array
object
exists here. Or to make it in linewith the current discussion consider
this:

Memory is allocated and returned; you get a pointer to the first
element. The type is "int*"

int p2 = new int[1];
What exaclty is the object created by this expression?

That's a syntax error, but I assume you meant "int *p2 = new int[1];",
in which case memory is allocated and returned; you get a pointer to
the first (and in this case only) element. The type is "int*"

I have said that I think it can be considered as either
a) an array of size one
b) Just one integer object.

Array of size one has only one object, just like array of size two has
two objects and so on - amazing, yes. But operator new [] does not
create array, it does dynamic memory allocation. The allocated memory
is returned to you as pointer to the first element.

Just as the 55 elements p points to above can be considered:
a) an arrayt of size 55

No, you cannot consider it as an array of size 55, as it is not an
array.

I disagree , an array of integer objects are created in memory.

Better.



When you view an array, yes, but your examples are dynamic memory
allocation.

So obviously you are of the opinion that an array type object doesn't exist
in the example of a "dynamic array".

Other people here , who seem just as confident as you in their correctness,
think that an array object exists. So is it a case of one view is wrong and
the other is right? Or is it a case, as I have said, that both views are
correct?

 

[hanukas]

int* p = new int[55];
People seem to have different opinions about whether or not an array
object
exists here. Or to make it in linewith the current discussion consider
this:

Memory is allocated and returned; you get a pointer to the first
element. The type is "int*"

int p2 = new int[1];
What exaclty is the object created by this expression?

That's a syntax error, but I assume you meant "int *p2 = new int[1];",
in which case memory is allocated and returned; you get a pointer to
the first (and in this case only) element. The type is "int*"

I have said that I think it can be considered as either
a) an array of size one
b) Just one integer object.

Array of size one has only one object, just like array of size two has
two objects and so on - amazing, yes. But operator new [] does not
create array, it does dynamic memory allocation. The allocated memory
is returned to you as pointer to the first element.

Just as the 55 elements p points to above can be considered:
a) an arrayt of size 55

No, you cannot consider it as an array of size 55, as it is not an
array.

I disagree , an array of integer objects are created in memory.

Better.

When you view an array, yes, but your examples are dynamic memory
allocation.

So obviously you are of the opinion that an array type object doesn't exist
in the example of a "dynamic array".

There is no example of "dynamic array", it's dynamic memory
allocation.

Other people here , who seem just as confident as you in their correctness,
think that an array object exists. So is it a case of one view is wrong and
the other is right? Or is it a case, as I have said, that both views are
correct?

I can't nor won't speak for other people here, anything else?

 

[Paul]

int* p = new int[55];
People seem to have different opinions about whether or not an array
object
exists here. Or to make it in linewith the current discussion consider
this:

Memory is allocated and returned; you get a pointer to the first
element. The type is "int*"

int p2 = new int[1];
What exaclty is the object created by this expression?

That's a syntax error, but I assume you meant "int *p2 = new int[1];",
in which case memory is allocated and returned; you get a pointer to
the first (and in this case only) element. The type is "int*"

I have said that I think it can be considered as either
a) an array of size one
b) Just one integer object.

Array of size one has only one object, just like array of size two has
two objects and so on - amazing, yes. But operator new [] does not
create array, it does dynamic memory allocation. The allocated memory
is returned to you as pointer to the first element.

Just as the 55 elements p points to above can be considered:
a) an arrayt of size 55

No, you cannot consider it as an array of size 55, as it is not an
array.

I disagree , an array of integer objects are created in memory.

Better.

When you view an array, yes, but your examples are dynamic memory
allocation.

So obviously you are of the opinion that an array type object doesn't
exist
in the example of a "dynamic array".

--There is no example of "dynamic array", it's dynamic memory
--allocation.

So what exactly is a "dynamic array", in your terms?

Other people here , who seem just as confident as you in their
correctness,
think that an array object exists. So is it a case of one view is wrong
and
the other is right? Or is it a case, as I have said, that both views are
correct?

--I can't nor won't speak for other people here, anything else?

No you do not speak for other people, you can read their posts if you like
and perhaps you would understand that their views differ from yours.
Nothing else required nope.

 

[hanukas]

int* p = new int[55];
People seem to have different opinions about whether or not an array
object
exists here. Or to make it in linewith the current discussion consider
this:
Memory is allocated and returned; you get a pointer to the first
element. The type is "int*"
int p2 = new int[1];
What exaclty is the object created by this expression?
That's a syntax error, but I assume you meant "int *p2 = new int[1];",
in which case memory is allocated and returned; you get a pointer to
the first (and in this case only) element. The type is "int*"
I have said that I think it can be considered as either
a) an array of size one
b) Just one integer object.
Array of size one has only one object, just like array of size two has
two objects and so on - amazing, yes. But operator new [] does not
create array, it does dynamic memory allocation. The allocated memory
is returned to you as pointer to the first element.
Just as the 55 elements p points to above can be considered:
a) an arrayt of size 55
No, you cannot consider it as an array of size 55, as it is not an
array.

I disagree , an array of integer objects are created in memory.

So obviously you are of the opinion that an array type object doesn't
exist
in the example of a "dynamic array".

--There is no example of "dynamic array", it's dynamic memory
--allocation.

So what exactly is a "dynamic array", in your terms?

Other people here , who seem just as confident as you in their
correctness,
think that an array object exists. So is it a case of one view is wrong
and
the other is right? Or is it a case, as I have said, that both views are
correct?

--I can't nor won't speak for other people here, anything else?

No you do not speak for other people, you can read their posts if you like
and perhaps you would understand that their views differ from yours.
Nothing else required nope.

Haystack. Needle. 400+ posts, yeah, right.

 

[Joshua Maurice]

* Pete Becker, on 03.06.2011 04:06:




It's just a question of terminology, common sense & effective communication.

If you want I can cite you umpteen examples from the standard that employfar
worse terminological shortcuts.

Intelligent folks don't write to you requiring that you do editorial fixes of
those places, because to anyone with half a mind it's obvious what's meant.

   ---

So, why not leave Paul's favorite TROLLING question alone? It was quiet for a
while here. Then Ian Collins and you started responding to Paul again. Argh.

Please keep in mind: many of us have much invested in using particular software
such as Thunderbird, and can't easily switch to newsreaders with general scoring.

Cheers, & exasperated,

Heh. I'm basically done with Paul, short of a one liner reply if he
makes a new thread on this subject (or exactly where member functions
"live"). As I've said, my recent posting has been because I finally
saw what he's arguing, and that gave me a little hope.

I'm personally a little annoyed that the other people arguing against
him are almost arguing non-sequiturs, and not arguing what really
matters, despite my explanations thereof. You need to convince Paul
that the object of array type is the same thing as the array object is
the same thing as the array type object, and the elements of the array
are sub-objects of the array object and are contained within the
memory of the array object. You also need to convince Paul that a
reasonable person will interpret "X is a pointer to int" as a claim
about the static type of X, not as a claim about the runtime value of
X. And everyone needs to drop this annoying argument that "int* x;"
cannot point to an array and can only point at int objects (contrast
"is a pointer to int") - that's simply not how most people use the
terminology. Ex:
class A {};
class B : public A {};
B b;
A* a = &b;
Most people would not bat an eye at saying "a points at b", even
though by this absurd pedantic argument in this thread against Paul,
one would conclude that "a does not point at b; a only points at the
sub-object of type A contained in b".

 

[Paul]

* Pete Becker, on 03.06.2011 04:06:




It's just a question of terminology, common sense & effective
communication.

If you want I can cite you umpteen examples from the standard that employ
far
worse terminological shortcuts.

Intelligent folks don't write to you requiring that you do editorial fixes
of
those places, because to anyone with half a mind it's obvious what's
meant.

---

So, why not leave Paul's favorite TROLLING question alone? It was quiet
for a
while here. Then Ian Collins and you started responding to Paul again.
Argh.

Please keep in mind: many of us have much invested in using particular
software
such as Thunderbird, and can't easily switch to newsreaders with general
scoring.

Cheers, & exasperated,

--Heh. I'm basically done with Paul, short of a one liner reply if he
--makes a new thread on this subject (or exactly where member functions
--"live"). As I've said, my recent posting has been because I finally
--saw what he's arguing, and that gave me a little hope.

--I'm personally a little annoyed that the other people arguing against
--him are almost arguing non-sequiturs, and not arguing what really
--matters, despite my explanations thereof. You need to convince Paul
--that the object of array type is the same thing as the array object is
--the same thing as the array type object, and the elements of the array
--are sub-objects of the array object and are contained within the
--memory of the array object. You also need to convince Paul that a
--reasonable person will interpret "X is a pointer to int" as a claim
--about the static type of X, not as a claim about the runtime value of
--X.

Using the term "a pointer to X" to refer to the type of the pointer is loose
use of english language and is shorthand for saying "is a pointer of type
ptr-to-X".
The term "is a pointer to" is more commonly used as an indiciation of what
is pointed to , not the type of the pointer.



-- And everyone needs to drop this annoying argument that "int* x;"
--cannot point to an array and can only point at int objects (contrast
--"is a pointer to int") - that's simply not how most people use the
--terminology. Ex:
-- class A {};
-- class B : public A {};
-- B b;
-- A* a = &b;
--Most people would not bat an eye at saying "a points at b", even
--though by this absurd pedantic argument in this thread against Paul,
--one would conclude that "a does not point at b; a only points at the
--sub-object of type A contained in b".

Well you are beginning to see sense.
But the old polymorphic argument will not convince the die hards, I've
already tried that one

When we access an array the pointer expression can be shown as:
*(p + i);
In this expression.. 'p' is a pointer to the beginning of the array and 'i'
is an offset that indexes the individual elements.

 

[Paul]

The difference here is that 'a' can point to a 'b' (as you have shown)

Applying your argument to this would be equivalent to saying that because a
is of type A* it can point to ONLY one single A object and nothing more.

but if the type of 'a' was 'int*' and the type of 'b' was 'int[42]' then
'a' can not point to 'b':

But the type of 'a' is not int*, and the tpye of 'b' is not int[42].

 

[Thomas J. Gritzan]

Am 05.06.2011 14:48, schrieb Leigh Johnston:

Heh. I'm basically done with Paul, short of a one liner reply if he
makes a new thread on this subject (or exactly where member functions
"live"). As I've said, my recent posting has been because I finally
saw what he's arguing, and that gave me a little hope.

I'm personally a little annoyed that the other people arguing against
him are almost arguing non-sequiturs, and not arguing what really
matters, despite my explanations thereof. You need to convince Paul
that the object of array type is the same thing as the array object is
the same thing as the array type object, and the elements of the array
are sub-objects of the array object and are contained within the
memory of the array object. You also need to convince Paul that a
reasonable person will interpret "X is a pointer to int" as a claim
about the static type of X, not as a claim about the runtime value of
X. And everyone needs to drop this annoying argument that "int* x;"
cannot point to an array and can only point at int objects (contrast
"is a pointer to int") - that's simply not how most people use the
terminology. Ex:
class A {};
class B : public A {};
B b;
A* a =&b;
Most people would not bat an eye at saying "a points at b", even
though by this absurd pedantic argument in this thread against Paul,
one would conclude that "a does not point at b; a only points at the
sub-object of type A contained in b".

The difference here is that 'a' can point to a 'b' (as you have shown)
but if the type of 'a' was 'int*' and the type of 'b' was 'int[42]' then
'a' can not point to 'b':

int b[42];
int* a = &b; // will not compile

More important is that an A* can point to a B, but it cannot point to an
array of B without problems:

B b_arr[100];
A* a = b_arr;

a points to a *single* B object (the first of the array), but it does
not point to an array of Bs.

 

[Paul]

Am 05.06.2011 14:48, schrieb Leigh Johnston:

Heh. I'm basically done with Paul, short of a one liner reply if he
makes a new thread on this subject (or exactly where member functions
"live"). As I've said, my recent posting has been because I finally
saw what he's arguing, and that gave me a little hope.

I'm personally a little annoyed that the other people arguing against
him are almost arguing non-sequiturs, and not arguing what really
matters, despite my explanations thereof. You need to convince Paul
that the object of array type is the same thing as the array object is
the same thing as the array type object, and the elements of the array
are sub-objects of the array object and are contained within the
memory of the array object. You also need to convince Paul that a
reasonable person will interpret "X is a pointer to int" as a claim
about the static type of X, not as a claim about the runtime value of
X. And everyone needs to drop this annoying argument that "int* x;"
cannot point to an array and can only point at int objects (contrast
"is a pointer to int") - that's simply not how most people use the
terminology. Ex:
class A {};
class B : public A {};
B b;
A* a =&b;
Most people would not bat an eye at saying "a points at b", even
though by this absurd pedantic argument in this thread against Paul,
one would conclude that "a does not point at b; a only points at the
sub-object of type A contained in b".

The difference here is that 'a' can point to a 'b' (as you have shown)
but if the type of 'a' was 'int*' and the type of 'b' was 'int[42]' then
'a' can not point to 'b':

int b[42];
int* a = &b; // will not compile

More important is that an A* can point to a B, but it cannot point to an
array of B without problems:

B b_arr[100];
A* a = b_arr;

a points to a *single* B object (the first of the array), but it does not
point to an array of Bs.

A *single* object, is not also (the first of an array), as you put it.
An array is a sequence of objects, it cannot also be a single object except
for silly cases where it's size one.

If your intention is to use this pointer as a pointer to a single element
you'd be better using the syntax:
A* a = &b_arr[n];

The expression :
A* a = b_arr;
Could be interpreted as an array being assigned to a pointer of incompatable
type. If you want to use the pointer as a pointer to the array then use the
correct type :
B* b = b_arr;

 

[Joshua Maurice]

He's a troll. Don't feet the troll.

 

[Joshua Maurice]

He's a troll. Don't feet the troll.

Don't feed* the troll.

 

[Paul]

On 2011-06-03, Paul <[email protected]> wrote:

[snip]

The C++ sees it as: "An object of array type contains a
contiguously allocated nonempty set of N sub-objects of type T."
Pointing to an array is pointing to an object of array type.
Pointing to a sub-object in an array is pointing to something other
than an object of the array type of the array that the sub-object is
in.

You have quoted some text from that seems to describe an object of array
type.
As I said , and you have proved me correct, you can only see an array as
"a
single array type object". You cannot see it at as array of integer
objects( or whatever type it is).

I have quoted the C++ standard. Seeing it as the C++ standard does
is the proper way to see it when discussing C++, such as in the
comp.lang.c++ newsgroup. Seeing it another way is seeing it in a
way different from the C++ standard.

This is not a definition of the term "array", this piece of text you have
quoted is not the C++ std's way of saying an array is definitely not an
sequence of objects, this is saying and array TYPE object is ....and it
doesn't mean this is the only possible way to consider an array.

With the following code..
int arr[7];
int* p1 = arr;
int (*p2)[7] = &arr;

Both the pointers point-to the first element in the array, and both
pointers
also point-to the array of integer objects. They are just different
types
of
pointers.
They both point to exactly the same location.

Both pointers do not point to the first element of the array. p1
points to the first element of the array; p2 points to the array.
An array is not the same as its first element.

The address of an array is the same as the address of the first element,
and
a pointer is this address.

The first element of an array is at the same memory location as the
array. The value of a C++ pointer is not only a memory location; it
is a typed memory location.

Rubbish the value of a pointer object does not contain any typeinfo. Its a
simple integer value that represents the address of the pointed to object.

Ignoring their types, the p1 and p2 have
the same value; however because p1 and p2 have different types, they
do not point to the same entity. p1 points to the first element of
the array, not to the array; p2 points to the array.

They point to exactly the same location.
The type of a pointer does not define what is pointed to.

They both point to exactly the same place and they both point to exactly
the
same array. Whether you view it as pointing to an array of pointing to
the
first element is just a POV.

They do not both point to exactly the same array. One points to an
array; the other may point to an element of that array. The point of
view of the C++ standard is that a

int (*)[]

points to an array of int while a

int *

points to an int, the int it points to may be an element in an array
of int.

This is completely made up. Where does the standard define that a pointer
type defines what is pointed to?
In fact where does the C++ standard define the term "points to"? It doesn't.

A example of both pointers accessing...;
a) A single object:
*p1;
**p2;
b) An array of obects:
*p2;
for(int i=0; i<7 ; ++i){ p1;}

Note that in (b) p1 does not access the integer objects it just
accesses
the
array type object. p2 does access the array of integer objects but it
does
not access the array type object.
They only differ, because of their pointer types, in the way they
access
the
array. They both point to exactly the same array but in this different
way.

p1 in (b) does not access an array type object. p1 is a pointer to
int. The expression p1 is equivalent to *(p1+i). According to
the C++ standard (start of paragraph 5 of 5.7 (Additive operators)):

No p1 is not a pointer to integer(singular) , it is a pointer to
integers(plural).
Correct p1 doesn't access the array-type object , but it accesses the
array
of integer objects.

The declarations were

int arr[7];
int* p1 = arr;
int (*p2)[7] = &arr;

p1 is a pointer to an integer.

No its a pointer to 7 integers.

What C++ has available as a pointer to
multiple integers is a pointer to an array of integers, such as p2.
p1 is a pointer to an integer, accessing what p1 points to access
that integer.

Accessing what p2 points to also accesses the same integer.
They are just different types of pointer but they both point to exactly the
same thing.

Look at the expression :
p1 + i;

It's a pointer plus offset(or index).
p1 is pointer to the beginning of the array
i is an offest that indexes the array.

It cannot be any clearer that p1 points to the array.

An element in an array has a different type than the array the
element is in. The type of p1 is int*. When p1 points to an element
of an array of int, it is pointing to an an int, not to an array.
The type of a pointer to an array of int is of the form int(*)[].
The C++ standard is clear about this in the following example from
8.1 (Types).

int // int i
int * // int *pi
int *[3] // int *p[3]
int (*)[3] // int (*p3i)[3]
int *() // int *f()
int (*)(double) // int (*pf)(double)

name respectively the types "int," "pointer to int," "array of 3
pointers to int," "pointer to array of 3 int," "function of (no
parameters) returning pointer to int," and "pointer to a function
of (double) returning int.

That is the TYPE of pointer, nobody is disputing the pointer TYPE. But a
pointer TYPE does not define what is pointed to by that pointer.

A pointers' type simply tells us that that pointer is capable of addressing
objects of the given type.
For example:
char* cp;
This pointer is capable of addressing char objects, it doesn't point to a
char object.

The distinction between a pointer to an array and a pointer to an
element of that array is important for multidimensional arrays as
arrays of arrays in C++. The declaration

int x[3][5];

declares an array of 3 array of 5 int. The expression x[j] is
equivalent to *(*(x+i)+j). When that expression is evaluated

This is not what the Std says. The standard says that each subsctipt will be
calucalated individually.
i has a multiplier of 5xsizeof(int), j has the multiplier of 1xsizeof(int).

- x is an array of 3 array of 5 int
- array-to-pointer conversion results in a pointer to the first array
of 5 int in x
- adding i results in a pointer to the i-th array of 5 int in x
- dereferencing that results in the i-th array of 5 int in x
- array-to-pointer conversion results in a pointer to the first int in
the i-th array of 5 int in x
- adding j results in a pointer to the j-th int in the i-th array of
5 int in x
- dereferencing that result in the j-th int in the i-th array of 5 int
in x

Multidimensional arrays in C++ depend on the distinction between a
pointer to an array and a pointer to an element of that array. Not
understanding this distinction may lead to confusion.


p1 and p2 have different types. p1 points to an int, not to an
array. p2 points to an array of 7 int.

They have different types, but they both point to the same location.

Consider a stack frame pointer, pointing to the stack. It doesn't
actually
point the whole stack at the same time but nonetheless its still
considered
to be pointing to the stack.

There is a significant difference between a stack frame pointer and a
C++ pointer: a C++ pointer is typed. In C++, the result of
dereferencing a pointer to T, where T is a type, is a T.

No, dereferencing a pointer of type pointer-to-T, will result in a T if
it
points to a valid T object.
The pointer type declares a pointer object that can address an object of
the
decalred type , for example:
int *p = 0;
p = &ix; /*assume x is valid int*/
p = new int[64];

What I have written is about what a C++ compiler does, along the
lines of what the C++ standard does in the folliwng sentence about
the unary * operator: "If the type of the expression is pointer to T,
the type of the result is T." These post are long enough without
adding possible undefined behaviors when the program runs due to the
value of a pointer to a non-polymorphic type.

This is explaining just what I said, if the type of the pointer is T then
derefernecing it addresses a T.
Assuming it points to a valid T type object.
This is not defining what p points to. p points to a location and whatever
is stored there is what is pointed to.

Here the pointer p is declared to be a pointer of type ptr-to-int, it
means
this pointer must be capable of pointing to a valid int object., It has
nothing to do with what it points to.
The above the pointer is shown pointing to nothing, an integer and an
array
of integers.

What is shown is p having the null pointer value, pointing to an
integer, and pointing to the first integer in an array of integers
(the result of the expression (new int[64]) is a pointer to int,
not a pointer to array of int).

No what is returned from the new expression is a pointer to the first
element *of an array* of integers.
When the pointer is used as a pointer to the array like so:
p[3];
The expression is evaluated as:
*(p+ 3xsizeof(int))
Where p is a pointer to the beginning of the array , and the offset to the
individual element is added.

This pointer is used as a pointer to the array, not to only just one
element. And it can be used as a pointer to the array because it points to
an array.

Yes its TYPE is int*, but this does not mean it can only point to one single
integer. Its type does not define what it points to.

It is undefined what p points to. I have used shorter phrases, such
as "is a T", rather than a longer ones, such as "is of type T". You
are misreading "is a T" as "is an object of type T that exists when
the program runs".

Well you have said that, becuase it is of type int*, it can only point to an
int.
Now you are saying it is undefined what it points to.
I repeat..the pointer type does not define what is pointed to.


You are shortening the term a "pointer type ptr-to-T" to mean the same as a
"pointer to T". But the two terms do not mean the same thing.
One term is specifically describing the pointer type. The other is referring
to whatever is at the location pointed to.

In that case, you don't really see the difference between a value
with the correct number of bits to be used as an address in assembler
and a C++ pointer. C++ pointers are typed.

The term "pointer" is not redefined because C++ pointers are typed.

A pointer is defined in the C standard and C++ inherits this defintion. A
pointer of type char* can point to a single char, and array of chars or
nothing at all. This is the view of the C standard and also Bjarne
Stroustrup in one of his C++ books.

With an array like so:
[int][int][int][int][int][int][int][int]
If a pointer 'p' points to the beinning of this array then the expression:
p+1;
points to the second element.
p+2;
points to the third element, and so on.

The pointer 'p' points to an array of integers, not only one single integer.
The TYPE of 'p' can only be int*, because if it were of type int (*)[8] then
p+2 would point away past the array.

The pointer 'p' is used as a pointer to an array of integers, it could not
be used as a pointer to an array if it only pointed to one single object.
It is a different concept from pointing to one single array type object.