Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #14092 > unrolled thread

Pointer Problem

Back to article view | Back to comp.lang.c++

Contents

  Pointer Problem bintom <binoythomas1108@gmail.com> - 2012-02-16 06:51 -0800
    Re: Pointer Problem Juha Nieminen <nospam@thanks.invalid> - 2012-02-16 15:15 +0000
      Re: Pointer Problem 88888 Dihedral <dihedral88888@googlemail.com> - 2012-02-16 07:17 -0800
        Re: Pointer Problem Victor Bazarov <v.bazarov@comcast.invalid> - 2012-02-16 11:15 -0500
          Re: Pointer Problem scott@slp53.sl.home (Scott Lurndal) - 2012-02-16 17:18 +0000
            Re: Pointer Problem Victor Bazarov <v.bazarov@comcast.invalid> - 2012-02-16 13:46 -0500
              Re: Pointer Problem Mike McCarty <mcmccarty@gmail.com> - 2012-02-16 12:41 -0800
              Re: Pointer Problem scott@slp53.sl.home (Scott Lurndal) - 2012-02-16 20:45 +0000
              Re: Pointer Problem Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-17 01:44 -0800
      Re: Pointer Problem jt@toerring.de (Jens Thoms Toerring) - 2012-02-17 03:14 +0000
        Re: Pointer Problem Juha Nieminen <nospam@thanks.invalid> - 2012-02-17 07:23 +0000
          Re: Pointer Problem jt@toerring.de (Jens Thoms Toerring) - 2012-02-18 22:39 +0000
            Re: Pointer Problem Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2012-02-20 21:07 +0100
              Re: Pointer Problem Paul <pchristor@yahoo.co.uk> - 2012-02-21 18:49 -0800
            Re: Pointer Problem Paul <pchristor@yahoo.co.uk> - 2012-02-21 18:49 -0800
              Re: Pointer Problem Juha Nieminen <nospam@thanks.invalid> - 2012-02-22 10:15 +0000
                Re: Pointer Problem Paul <pchristor@yahoo.co.uk> - 2012-02-22 07:49 -0800
                  Re: Pointer Problem Leigh Johnston <leigh@i42.co.uk> - 2012-02-22 20:24 +0000
                  Re: Pointer Problem Juha Nieminen <nospam@thanks.invalid> - 2012-02-23 10:36 +0000
                    Re: Pointer Problem "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-02-23 18:59 +0000
                      Re: Pointer Problem Leigh Johnston <leigh@i42.co.uk> - 2012-02-23 19:15 +0000
                        Re: Pointer Problem "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-02-23 21:08 +0000
                          Re: Pointer Problem Leigh Johnston <leigh@i42.co.uk> - 2012-02-23 21:17 +0000
                            Re: Pointer Problem Leigh Johnston <leigh@i42.co.uk> - 2012-02-23 21:29 +0000
                              Re: Pointer Problem Joshua Maurice <joshuamaurice@gmail.com> - 2012-02-23 17:06 -0800
                              Re: Pointer Problem Paul <pchristor@yahoo.co.uk> - 2012-02-24 03:42 -0800
                                Re: Pointer Problem Leigh Johnston <leigh@i42.co.uk> - 2012-02-24 12:33 +0000
                                  Re: Pointer Problem "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-02-24 15:09 +0000
                  Re: Pointer Problem Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-23 20:53 +0000
                    Re: Pointer Problem Paul <pchristor@yahoo.co.uk> - 2012-02-24 04:11 -0800
                      Re: Pointer Problem Leigh Johnston <leigh@i42.co.uk> - 2012-02-24 12:36 +0000
                        Re: Pointer Problem Paul <pchristor@yahoo.co.uk> - 2012-02-24 06:07 -0800
                          Re: Pointer Problem Leigh Johnston <leigh@i42.co.uk> - 2012-02-24 14:11 +0000
                            Re: Pointer Problem "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-02-24 15:49 +0000
                              Re: Pointer Problem Mike McCarty <mcmccarty@gmail.com> - 2012-02-24 08:50 -0800
                                Re: Pointer Problem "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-02-24 18:47 +0000
                                  Re: Pointer Problem Paul <pchristor@yahoo.co.uk> - 2012-02-24 13:44 -0800
                                Re: Pointer Problem Paul <pchristor@yahoo.co.uk> - 2012-02-26 12:41 -0800
                                  Re: Pointer Problem Mike McCarty <mcmccarty@gmail.com> - 2012-02-26 21:30 -0800
                                    Re: Pointer Problem Paul <pchristor@yahoo.co.uk> - 2012-02-27 06:07 -0800
                                      Re: Pointer Problem Mike McCarty <mcmccarty@gmail.com> - 2012-02-27 07:25 -0800
                                        Re: Pointer Problem Paul <pchristor@yahoo.co.uk> - 2012-02-27 08:17 -0800
                                          Re: Pointer Problem Mike McCarty <mcmccarty@gmail.com> - 2012-02-27 08:51 -0800
                                            Re: Pointer Problem Ian Collins <ian-news@hotmail.com> - 2012-02-28 07:18 +1300
                                              Re: Pointer Problem Paul <pchristor@yahoo.co.uk> - 2012-02-27 11:32 -0800
                                            Re: Pointer Problem Paul <pchristor@yahoo.co.uk> - 2012-02-27 11:32 -0800
                                          Re: Pointer Problem Leigh Johnston <leigh@i42.co.uk> - 2012-02-27 19:17 +0000
                                            Re: Pointer Problem Paul <pchristor@yahoo.co.uk> - 2012-02-27 11:49 -0800
                                              Re: Pointer Problem Leigh Johnston <leigh@i42.co.uk> - 2012-02-27 20:04 +0000
                                                Re: Pointer Problem Paul <pchristor@yahoo.co.uk> - 2012-02-27 12:55 -0800
                                                  Re: Pointer Problem Leigh Johnston <leigh@i42.co.uk> - 2012-02-27 21:15 +0000
                                                    Re: Pointer Problem Paul <pchristor@yahoo.co.uk> - 2012-02-27 14:26 -0800
                                        Re: Pointer Problem Paul <pchristor@yahoo.co.uk> - 2012-02-27 11:21 -0800
    Re: Pointer Problem SG <s.gesemann@gmail.com> - 2012-02-16 07:00 -0800
    Re: Pointer Problem LR <lruss@superlink.net> - 2012-02-16 16:49 -0500
      Re: Pointer Problem Juha Nieminen <nospam@thanks.invalid> - 2012-02-16 22:18 +0000
        Re: Pointer Problem LR <lruss@superlink.net> - 2012-02-16 23:40 -0500
          Re: Pointer Problem Juha Nieminen <nospam@thanks.invalid> - 2012-02-17 07:24 +0000
            Re: Pointer Problem LR <lruss@superlink.net> - 2012-02-17 09:48 -0500
              Re: Pointer Problem Juha Nieminen <nospam@thanks.invalid> - 2012-02-17 15:13 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#14459

On 23/02/2012 18:59, Paul <pchrist wrote:
> "Juha Nieminen"<nospam@thanks.invalid>  wrote in message
> news:4f46169d$0$4388$7b1e8fa0@news.nbl.fi...
>> Paul<pchristor@yahoo.co.uk>  wrote:
>>>> (Let your ranting begin.)
>>> Ranting?
>>
>>   Yes. Exactly like this:
>>
>>> What you're saying is like saying int* and int** point to different
>>> types. Sure if you assert them at different levels of indirection they
>>> will appear different but regarding types, ultimately they both point
>>> to an int type object.
>>>
>>> If your argument would be to suggest that they point to different
>>> types because int** points to an int* type and int* points to an int
>>> type. I'd suggest that you are confusing the term "level of
>>> indirection" with "type".
>>
>>   You do understand that "int" and "int*" are different types, do you?
>> They may even have difference sizes (eg. in most 64-bit systems they do).
>>
>>   Likewise "int" and "int[10]" are different types. The former is an
>> integral while the latter is an array of 10 integrals. (Again, they have
>> different sizes: The former is sizeof(int) bytes big, while the latter
>> is 10*sizeof(int) bytes big.)
>>
>>   "int*" points to an "int", and "int(*)[10]" points to an array of 10
>> ints.
>> The difference becomes clear eg. when you increment those pointers (the
>> former will change by the size of one int, while the latter will change
>> by the the size of 10 ints), or take the size of what they are pointing
>> at.
>>
>>   There's no way of interpreting this that would allow you to say that
>> "int*" and "int(*)[10]" are of the same type.
>
> Its not about "types" its about level of indirection, you can only obtain
> another pointer if you dereference an int(*)[10].

It is all about types silly.

> For example:
>
> int anarray[10] ={1,2,3,4};
> int(*ptr1)[10] =&anarray;
> int* ptr2 = *ptr1; /* When dereferneced another pointer is obtained, not an
> array type object. */

Not true; when dereferenced a reference to an array is returned as the 
following code illustrates:

int main()
{
	int anarray[10] ={1,2,3,4};
	int(*ptr1)[10] = &anarray;
	std::cout << (typeid(*ptr1) == typeid(int*) ? "is a pointer\n" : "is 
not a pointer\n");
	std::cout << (typeid(*ptr1) == typeid(int(&)[10]) ? "is a reference\n" 
: "is not a reference\n");
}

outputs:
is not a pointer
is a reference

or:

struct other_type;

int main()
{
	int anarray[10] ={1,2,3,4};
	int(*ptr1)[10] = &anarray;
	other_type* ptr2 = *ptr1;
}

1>c:\projects\foo\tu1.cpp(13) : error C2440: 'initializing' : cannot 
convert from 'int [10]' to 'other_type *'

ergo 'ptr1' is a pointer to an array of 10 int and '*ptr1' is a 
reference to an array of 10 int.

/Leigh

[toc] | [prev] | [next] | [standalone]

#14462

"Leigh Johnston" <leigh@i42.co.uk> wrote in message 
news:WN2dnaiGtOXUDdvSnZ2dnUVZ8tidnZ2d@giganews.com...
> On 23/02/2012 18:59, Paul <pchrist wrote:
>> "Juha Nieminen"<nospam@thanks.invalid>  wrote in message
>> news:4f46169d$0$4388$7b1e8fa0@news.nbl.fi...
>>> Paul<pchristor@yahoo.co.uk>  wrote:
>>>>> (Let your ranting begin.)
>>>> Ranting?
>>>
>>>   Yes. Exactly like this:
>>>
>>>> What you're saying is like saying int* and int** point to different
>>>> types. Sure if you assert them at different levels of indirection they
>>>> will appear different but regarding types, ultimately they both point
>>>> to an int type object.
>>>>
>>>> If your argument would be to suggest that they point to different
>>>> types because int** points to an int* type and int* points to an int
>>>> type. I'd suggest that you are confusing the term "level of
>>>> indirection" with "type".
>>>
>>>   You do understand that "int" and "int*" are different types, do you?
>>> They may even have difference sizes (eg. in most 64-bit systems they 
>>> do).
>>>
>>>   Likewise "int" and "int[10]" are different types. The former is an
>>> integral while the latter is an array of 10 integrals. (Again, they have
>>> different sizes: The former is sizeof(int) bytes big, while the latter
>>> is 10*sizeof(int) bytes big.)
>>>
>>>   "int*" points to an "int", and "int(*)[10]" points to an array of 10
>>> ints.
>>> The difference becomes clear eg. when you increment those pointers (the
>>> former will change by the size of one int, while the latter will change
>>> by the the size of 10 ints), or take the size of what they are pointing
>>> at.
>>>
>>>   There's no way of interpreting this that would allow you to say that
>>> "int*" and "int(*)[10]" are of the same type.
>>
>> Its not about "types" its about level of indirection, you can only obtain
>> another pointer if you dereference an int(*)[10].
>
> It is all about types silly.
>
>> For example:
>>
>> int anarray[10] ={1,2,3,4};
>> int(*ptr1)[10] =&anarray;
>> int* ptr2 = *ptr1; /* When dereferneced another pointer is obtained, not 
>> an
>> array type object. */
>
> Not true; when dereferenced a reference to an array is returned as the 
> following code illustrates:
>
> int main()
> {
> int anarray[10] ={1,2,3,4};
> int(*ptr1)[10] = &anarray;
> std::cout << (typeid(*ptr1) == typeid(int*) ? "is a pointer\n" : "is not a 
> pointer\n");
> std::cout << (typeid(*ptr1) == typeid(int(&)[10]) ? "is a reference\n" : 
> "is not a reference\n");
> }
>
> outputs:
> is not a pointer
> is a reference
>
A reference isn't a type either.


> or:
>
> struct other_type;
>
> int main()
> {
> int anarray[10] ={1,2,3,4};
> int(*ptr1)[10] = &anarray;
> other_type* ptr2 = *ptr1;
> }
>
> 1>c:\projects\foo\tu1.cpp(13) : error C2440: 'initializing' : cannot 
> convert from 'int [10]' to 'other_type *'

^_^ And the above is supposed to prove what exactly?

>
> ergo 'ptr1' is a pointer to an array of 10 int and '*ptr1' is a reference 
> to an array of 10 int.
>
The type/s pointed to is int, the pointer type reflects the level of 
indirection and not the type. You cannot say this pointer will always point 
to 10 ints.

int anotherarray[10][10] = {0};
ptr1  = anotherarray;
Now this pointer points to an array of 100 ints, not 10.

*ptr1 may indeed return a reference but this implicitly decays into a 
pointer



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#14463

On 23/02/2012 21:08, Paul <pchrist wrote:
> "Leigh Johnston"<leigh@i42.co.uk>  wrote in message
> news:WN2dnaiGtOXUDdvSnZ2dnUVZ8tidnZ2d@giganews.com...
>> On 23/02/2012 18:59, Paul<pchrist wrote:
>>> "Juha Nieminen"<nospam@thanks.invalid>   wrote in message
>>> news:4f46169d$0$4388$7b1e8fa0@news.nbl.fi...
>>>> Paul<pchristor@yahoo.co.uk>   wrote:
>>>>>> (Let your ranting begin.)
>>>>> Ranting?
>>>>
>>>>    Yes. Exactly like this:
>>>>
>>>>> What you're saying is like saying int* and int** point to different
>>>>> types. Sure if you assert them at different levels of indirection they
>>>>> will appear different but regarding types, ultimately they both point
>>>>> to an int type object.
>>>>>
>>>>> If your argument would be to suggest that they point to different
>>>>> types because int** points to an int* type and int* points to an int
>>>>> type. I'd suggest that you are confusing the term "level of
>>>>> indirection" with "type".
>>>>
>>>>    You do understand that "int" and "int*" are different types, do you?
>>>> They may even have difference sizes (eg. in most 64-bit systems they
>>>> do).
>>>>
>>>>    Likewise "int" and "int[10]" are different types. The former is an
>>>> integral while the latter is an array of 10 integrals. (Again, they have
>>>> different sizes: The former is sizeof(int) bytes big, while the latter
>>>> is 10*sizeof(int) bytes big.)
>>>>
>>>>    "int*" points to an "int", and "int(*)[10]" points to an array of 10
>>>> ints.
>>>> The difference becomes clear eg. when you increment those pointers (the
>>>> former will change by the size of one int, while the latter will change
>>>> by the the size of 10 ints), or take the size of what they are pointing
>>>> at.
>>>>
>>>>    There's no way of interpreting this that would allow you to say that
>>>> "int*" and "int(*)[10]" are of the same type.
>>>
>>> Its not about "types" its about level of indirection, you can only obtain
>>> another pointer if you dereference an int(*)[10].
>>
>> It is all about types silly.
>>
>>> For example:
>>>
>>> int anarray[10] ={1,2,3,4};
>>> int(*ptr1)[10] =&anarray;
>>> int* ptr2 = *ptr1; /* When dereferneced another pointer is obtained, not
>>> an
>>> array type object. */
>>
>> Not true; when dereferenced a reference to an array is returned as the
>> following code illustrates:
>>
>> int main()
>> {
>> int anarray[10] ={1,2,3,4};
>> int(*ptr1)[10] =&anarray;
>> std::cout<<  (typeid(*ptr1) == typeid(int*) ? "is a pointer\n" : "is not a
>> pointer\n");
>> std::cout<<  (typeid(*ptr1) == typeid(int(&)[10]) ? "is a reference\n" :
>> "is not a reference\n");
>> }
>>
>> outputs:
>> is not a pointer
>> is a reference
>>
> A reference isn't a type either.

'int(&)[10]' is a type.

>
>
>> or:
>>
>> struct other_type;
>>
>> int main()
>> {
>> int anarray[10] ={1,2,3,4};
>> int(*ptr1)[10] =&anarray;
>> other_type* ptr2 = *ptr1;
>> }
>>
>> 1>c:\projects\foo\tu1.cpp(13) : error C2440: 'initializing' : cannot
>> convert from 'int [10]' to 'other_type *'
>
> ^_^ And the above is supposed to prove what exactly?

That you are wrong.

>
>>
>> ergo 'ptr1' is a pointer to an array of 10 int and '*ptr1' is a reference
>> to an array of 10 int.
>>
> The type/s pointed to is int, the pointer type reflects the level of
> indirection and not the type. You cannot say this pointer will always point
> to 10 ints.
>
> int anotherarray[10][10] = {0};
> ptr1  = anotherarray;
> Now this pointer points to an array of 100 ints, not 10.
>
> *ptr1 may indeed return a reference but this implicitly decays into a
> pointer

Wrong.

http://www.youtube.com/watch?feature=player_embedded&v=EdooYar_A6g

/Leigh

[toc] | [prev] | [next] | [standalone]

#14465

On 23/02/2012 21:17, Leigh Johnston wrote:
> On 23/02/2012 21:08, Paul <pchrist wrote:
>>
>> *ptr1 may indeed return a reference but this implicitly decays into a
>> pointer
>
> Wrong.

By that I mean array to pointer conversion *can* happen not that array 
to pointer conversion *will* happen:

int a[10];
int (*p)[10] = &a;
int (&r)[10] = *p; // no array to pointer conversion

http://www.youtube.com/watch?feature=player_embedded&v=EdooYar_A6g

/Leigh

[toc] | [prev] | [next] | [standalone]

#14467

Deja vu.
Déjà vu.
http://en.wikipedia.org/wiki/D%C3%A9j%C3%A0_vu

[toc] | [prev] | [next] | [standalone]

#14476

On Feb 23, 9:29 pm, Leigh Johnston <le...@i42.co.uk> wrote:
> On 23/02/2012 21:17, Leigh Johnston wrote:
>
> > On 23/02/2012 21:08, Paul <pchrist wrote:
>
> >> *ptr1 may indeed return a reference but this implicitly decays into a
> >> pointer
>
> > Wrong.
>
> By that I mean array to pointer conversion *can* happen not that array
> to pointer conversion *will* happen:
>
> int a[10];
> int (*p)[10] = &a;
> int (&r)[10] = *p; // no array to pointer conversion
>
Of course there is no array to pointer conversion because the
expression does not contain an array.
I think perhaps you are mistaking the pointer or reference types { T(*)
[S] and T(&)[S] respectively }, to be arrays. These are not arrays
they're pointers and references.

A pointer to an array stores only one address, usually to the first
element unless pointer arithmetic has been carried out. The difference
between pointer types does not change the type of array pointed-to,
the difference is in the level of indirection of the pointer.

[toc] | [prev] | [next] | [standalone]

#14478

On 24/02/2012 11:42, Paul wrote:
> On Feb 23, 9:29 pm, Leigh Johnston<le...@i42.co.uk>  wrote:
>> On 23/02/2012 21:17, Leigh Johnston wrote:
>>
>>> On 23/02/2012 21:08, Paul<pchrist wrote:
>>
>>>> *ptr1 may indeed return a reference but this implicitly decays into a
>>>> pointer
>>
>>> Wrong.
>>
>> By that I mean array to pointer conversion *can* happen not that array
>> to pointer conversion *will* happen:
>>
>> int a[10];
>> int (*p)[10] =&a;
>> int (&r)[10] = *p; // no array to pointer conversion
>>
> Of course there is no array to pointer conversion because the
> expression does not contain an array.
> I think perhaps you are mistaking the pointer or reference types { T(*)
> [S] and T(&)[S] respectively }, to be arrays. These are not arrays
> they're pointers and references.

They are pointers and references to arrays.  You claimed that (*p) 
results in array to pointer conversion but I have shown that this not 
always the case.

>
> A pointer to an array stores only one address, usually to the first
> element unless pointer arithmetic has been carried out. The difference
> between pointer types does not change the type of array pointed-to,
> the difference is in the level of indirection of the pointer.

That was just noise.

/Leigh

[toc] | [prev] | [next] | [standalone]

#14484

"Leigh Johnston" <leigh@i42.co.uk> wrote in message 
news:SbednbPbF-8_HtrSnZ2dnUVZ8kCdnZ2d@giganews.com...
> On 24/02/2012 11:42, Paul wrote:
>> On Feb 23, 9:29 pm, Leigh Johnston<le...@i42.co.uk>  wrote:
>>> On 23/02/2012 21:17, Leigh Johnston wrote:
>>>
>>>> On 23/02/2012 21:08, Paul<pchrist wrote:
>>>
>>>>> *ptr1 may indeed return a reference but this implicitly decays into a
>>>>> pointer
>>>
>>>> Wrong.
>>>
>>> By that I mean array to pointer conversion *can* happen not that array
>>> to pointer conversion *will* happen:
>>>
>>> int a[10];
>>> int (*p)[10] =&a;
>>> int (&r)[10] = *p; // no array to pointer conversion
>>>
>> Of course there is no array to pointer conversion because the
>> expression does not contain an array.
>> I think perhaps you are mistaking the pointer or reference types { T(*)
>> [S] and T(&)[S] respectively }, to be arrays. These are not arrays
>> they're pointers and references.
>
> They are pointers and references to arrays.  You claimed that (*p) results 
> in array to pointer conversion but I have shown that this not always the 
> case.
>
But I didn't say that it was *always* the case. So are you trying to prove 
that the pointer type T(*)[S] is not a 2nd level indirect pointer?
You seem to be suggesting that it can be directly dereferenced to access the 
array. Which is not the case.

>>
>> A pointer to an array stores only one address, usually to the first
>> element unless pointer arithmetic has been carried out. The difference
>> between pointer types does not change the type of array pointed-to,
>> the difference is in the level of indirection of the pointer.
>
> That was just noise.
>
I honestly don't understand what you are trying to say because you don't 
make much sense.All I can work out is that you have said that a pointer of 
type T(*)[S] is a pointer to an array of S x T's, and that it cannot point 
to anything else such as a 2d array because you don't seem to acknowledge 
the difference in levels of indirection with different dimensional arrays. 



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#14461

On Wed, 2012-02-22, Paul wrote:
...
> What you're saying is like saying int* and int** point to different
> types. Sure if you assert them at different levels of indirection they
> will appear different but regarding types, ultimately they both point
> to an int type object.
>
> If your argument would be to suggest that they point to different
> types because int** points to an int* type and int* points to an int
> type. I'd suggest that you are confusing the term "level of
> indirection" with "type".

You may not like it, but that's the accepted terminology in C++.

You have some kind of point of course: the only reason to mess around
with int*, int** or int***** is to eventually do something to a bunch
of ints. But the language doesn't know, or care.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#14477

On Feb 23, 8:53 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
> On Wed, 2012-02-22, Paul wrote:
>
> ...
>
> > What you're saying is like saying int* and int** point to different
> > types. Sure if you assert them at different levels of indirection they
> > will appear different but regarding types, ultimately they both point
> > to an int type object.
>
> > If your argument would be to suggest that they point to different
> > types because int** points to an int* type and int* points to an int
> > type. I'd suggest that you are confusing the term "level of
> > indirection" with "type".
>
> You may not like it, but that's the accepted terminology in C++.

AFAICT the accepted terminology in C++ is that a pointer of type T*
can point to a T or an array of T's.

>
> You have some kind of point of course: the only reason to mess around
> with int*, int** or int***** is to eventually do something to a bunch
> of ints. But the language doesn't know, or care.
>
I was merely trying to demonstrate that different levels of
indirection do not change the object type. The object pointed to is an
int type, whether you create a pointer to it with one level of
indirection or five i.e: int*****.
The same applies to an array, the arrays' type does not change because
of the pointer type used to address it. An array of chars, for
example, is addressed using a char* because you cannot address  n x
chars, you can address only one char. If you create a pointer with two
or three levels of indirection to this array of chars it doesn't
change the type of the pointed-to object.

And this is exactly what a pointer of type char(*ptr)[S] is, a pointer
to chars with two levels of indirection. The level of indirection
doesn't affect the type of the addressed object.


Yeah sure you can be really pedantic and argue that between each level
of indirection the pointer type changes from eg: char*** to char** to
char*. But at the end of the day each of these pointers is just
another pointer variable that stores a memory address and its doesn't
really change the type of the pointed-to object. Its just changing in
levels of indirection. For example: a char**** is a pointer to a char
just the same as a char** is a pointer to a char, is it not?.

[toc] | [prev] | [next] | [standalone]

#14479

On 24/02/2012 12:11, Paul wrote:
> On Feb 23, 8:53 pm, Jorgen Grahn<grahn+n...@snipabacken.se>  wrote:
>> On Wed, 2012-02-22, Paul wrote:
>>
>> ...
>>
>>> What you're saying is like saying int* and int** point to different
>>> types. Sure if you assert them at different levels of indirection they
>>> will appear different but regarding types, ultimately they both point
>>> to an int type object.
>>
>>> If your argument would be to suggest that they point to different
>>> types because int** points to an int* type and int* points to an int
>>> type. I'd suggest that you are confusing the term "level of
>>> indirection" with "type".
>>
>> You may not like it, but that's the accepted terminology in C++.
>
> AFAICT the accepted terminology in C++ is that a pointer of type T*
> can point to a T or an array of T's.
>
>>
>> You have some kind of point of course: the only reason to mess around
>> with int*, int** or int***** is to eventually do something to a bunch
>> of ints. But the language doesn't know, or care.
>>
> I was merely trying to demonstrate that different levels of
> indirection do not change the object type. The object pointed to is an
> int type, whether you create a pointer to it with one level of
> indirection or five i.e: int*****.
> The same applies to an array, the arrays' type does not change because
> of the pointer type used to address it. An array of chars, for
> example, is addressed using a char* because you cannot address  n x
> chars, you can address only one char. If you create a pointer with two
> or three levels of indirection to this array of chars it doesn't
> change the type of the pointed-to object.
>
> And this is exactly what a pointer of type char(*ptr)[S] is, a pointer
> to chars with two levels of indirection. The level of indirection
> doesn't affect the type of the addressed object.
>
>
> Yeah sure you can be really pedantic and argue that between each level
> of indirection the pointer type changes from eg: char*** to char** to
> char*. But at the end of the day each of these pointers is just
> another pointer variable that stores a memory address and its doesn't
> really change the type of the pointed-to object. Its just changing in
> levels of indirection. For example: a char**** is a pointer to a char
> just the same as a char** is a pointer to a char, is it not?.

No; char**** is a pointer to a char***.

/Leigh

[toc] | [prev] | [next] | [standalone]

#14482

On Feb 24, 12:36 pm, Leigh Johnston <le...@i42.co.uk> wrote:
> On 24/02/2012 12:11, Paul wrote:
>
>
>
>
>
>
>
>
>
> > On Feb 23, 8:53 pm, Jorgen Grahn<grahn+n...@snipabacken.se>  wrote:
> >> On Wed, 2012-02-22, Paul wrote:
>
> >> ...
>
> >>> What you're saying is like saying int* and int** point to different
> >>> types. Sure if you assert them at different levels of indirection they
> >>> will appear different but regarding types, ultimately they both point
> >>> to an int type object.
>
> >>> If your argument would be to suggest that they point to different
> >>> types because int** points to an int* type and int* points to an int
> >>> type. I'd suggest that you are confusing the term "level of
> >>> indirection" with "type".
>
> >> You may not like it, but that's the accepted terminology in C++.
>
> > AFAICT the accepted terminology in C++ is that a pointer of type T*
> > can point to a T or an array of T's.
>
> >> You have some kind of point of course: the only reason to mess around
> >> with int*, int** or int***** is to eventually do something to a bunch
> >> of ints. But the language doesn't know, or care.
>
> > I was merely trying to demonstrate that different levels of
> > indirection do not change the object type. The object pointed to is an
> > int type, whether you create a pointer to it with one level of
> > indirection or five i.e: int*****.
> > The same applies to an array, the arrays' type does not change because
> > of the pointer type used to address it. An array of chars, for
> > example, is addressed using a char* because you cannot address  n x
> > chars, you can address only one char. If you create a pointer with two
> > or three levels of indirection to this array of chars it doesn't
> > change the type of the pointed-to object.
>
> > And this is exactly what a pointer of type char(*ptr)[S] is, a pointer
> > to chars with two levels of indirection. The level of indirection
> > doesn't affect the type of the addressed object.
>
> > Yeah sure you can be really pedantic and argue that between each level
> > of indirection the pointer type changes from eg: char*** to char** to
> > char*. But at the end of the day each of these pointers is just
> > another pointer variable that stores a memory address and its doesn't
> > really change the type of the pointed-to object. Its just changing in
> > levels of indirection. For example: a char**** is a pointer to a char
> > just the same as a char** is a pointer to a char, is it not?.
>
> No; char**** is a pointer to a char***.
>
You're reply is incorrect on two points:
a) The pointer may point to a char indirectly.
b) The pointer may be null and point to nothing.

The scenario , that you agree with, where char**** is a pointer to a
char*** you are considering only one level of indirection:
char**** ---- dereferneces to ---> char***.

Now considering a less simpleton mind:
char**** ---> char*** ---> char** ---> char* ---> char.


It may point to a char(indirectly) *and* a char***. You'd be incorrect
to say this is incorrect.





Just as with the pointer type int(*)[S]. You say that this is a
pointer to an array of S, and only to an array of S, all other
contexts are deemed as incorrect. But this is nonsense because:

int array1[8][10] = {0};
int array2[9][10] ={0};
int array3[10]={0};
int (*ptr1)[10];
ptr1 = array1;
ptr1 = array2;
ptr1 = &array3;


It is correct to say that ptr1 points to 3 different sized arrays and
incorrect to say that ptr1 is only a pointer to an array of 10 ints.
The pointer type can point to arrays of different sizes and not only
to an array of 10 ints. The difference between this pointer type and
an int* type is obviously in it's level of indirection. The int type
never changes from each level of indirection, only the pointer-type to
reflect that different level of indirection, as in the case with
char***, char**, char*.

[toc] | [prev] | [next] | [standalone]

#14483

On 24/02/2012 14:07, Paul wrote:
> On Feb 24, 12:36 pm, Leigh Johnston<le...@i42.co.uk>  wrote:
>> On 24/02/2012 12:11, Paul wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> On Feb 23, 8:53 pm, Jorgen Grahn<grahn+n...@snipabacken.se>    wrote:
>>>> On Wed, 2012-02-22, Paul wrote:
>>
>>>> ...
>>
>>>>> What you're saying is like saying int* and int** point to different
>>>>> types. Sure if you assert them at different levels of indirection they
>>>>> will appear different but regarding types, ultimately they both point
>>>>> to an int type object.
>>
>>>>> If your argument would be to suggest that they point to different
>>>>> types because int** points to an int* type and int* points to an int
>>>>> type. I'd suggest that you are confusing the term "level of
>>>>> indirection" with "type".
>>
>>>> You may not like it, but that's the accepted terminology in C++.
>>
>>> AFAICT the accepted terminology in C++ is that a pointer of type T*
>>> can point to a T or an array of T's.
>>
>>>> You have some kind of point of course: the only reason to mess around
>>>> with int*, int** or int***** is to eventually do something to a bunch
>>>> of ints. But the language doesn't know, or care.
>>
>>> I was merely trying to demonstrate that different levels of
>>> indirection do not change the object type. The object pointed to is an
>>> int type, whether you create a pointer to it with one level of
>>> indirection or five i.e: int*****.
>>> The same applies to an array, the arrays' type does not change because
>>> of the pointer type used to address it. An array of chars, for
>>> example, is addressed using a char* because you cannot address  n x
>>> chars, you can address only one char. If you create a pointer with two
>>> or three levels of indirection to this array of chars it doesn't
>>> change the type of the pointed-to object.
>>
>>> And this is exactly what a pointer of type char(*ptr)[S] is, a pointer
>>> to chars with two levels of indirection. The level of indirection
>>> doesn't affect the type of the addressed object.
>>
>>> Yeah sure you can be really pedantic and argue that between each level
>>> of indirection the pointer type changes from eg: char*** to char** to
>>> char*. But at the end of the day each of these pointers is just
>>> another pointer variable that stores a memory address and its doesn't
>>> really change the type of the pointed-to object. Its just changing in
>>> levels of indirection. For example: a char**** is a pointer to a char
>>> just the same as a char** is a pointer to a char, is it not?.
>>
>> No; char**** is a pointer to a char***.
>>
> You're reply is incorrect on two points:
> a) The pointer may point to a char indirectly.
> b) The pointer may be null and point to nothing.
>
> The scenario , that you agree with, where char**** is a pointer to a
> char*** you are considering only one level of indirection:
> char**** ---- dereferneces to --->  char***.
>
> Now considering a less simpleton mind:
> char**** --->  char*** --->  char** --->  char* --->  char.
>
>
> It may point to a char(indirectly) *and* a char***. You'd be incorrect
> to say this is incorrect.
>
>
>
>
>
> Just as with the pointer type int(*)[S]. You say that this is a
> pointer to an array of S, and only to an array of S, all other
> contexts are deemed as incorrect. But this is nonsense because:
>
> int array1[8][10] = {0};
> int array2[9][10] ={0};
> int array3[10]={0};
> int (*ptr1)[10];
> ptr1 = array1;
> ptr1 = array2;
> ptr1 =&array3;
>
>
> It is correct to say that ptr1 points to 3 different sized arrays and
> incorrect to say that ptr1 is only a pointer to an array of 10 ints.
> The pointer type can point to arrays of different sizes and not only
> to an array of 10 ints. The difference between this pointer type and
> an int* type is obviously in it's level of indirection. The int type
> never changes from each level of indirection, only the pointer-type to
> reflect that different level of indirection, as in the case with
> char***, char**, char*.

You are so wrong that you could say that you are not *even* wrong.

HTH.

/Leigh

[toc] | [prev] | [next] | [standalone]

#14485

"Leigh Johnston" <leigh@i42.co.uk> wrote in message 
news:upidnQHsXYY4B9rSnZ2dnUVZ8qOdnZ2d@giganews.com...
> On 24/02/2012 14:07, Paul wrote:
>> On Feb 24, 12:36 pm, Leigh Johnston<le...@i42.co.uk>  wrote:
>>> On 24/02/2012 12:11, Paul wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> On Feb 23, 8:53 pm, Jorgen Grahn<grahn+n...@snipabacken.se>    wrote:
>>>>> On Wed, 2012-02-22, Paul wrote:
>>>
>>>>> ...
>>>
>>>>>> What you're saying is like saying int* and int** point to different
>>>>>> types. Sure if you assert them at different levels of indirection 
>>>>>> they
>>>>>> will appear different but regarding types, ultimately they both point
>>>>>> to an int type object.
>>>
>>>>>> If your argument would be to suggest that they point to different
>>>>>> types because int** points to an int* type and int* points to an int
>>>>>> type. I'd suggest that you are confusing the term "level of
>>>>>> indirection" with "type".
>>>
>>>>> You may not like it, but that's the accepted terminology in C++.
>>>
>>>> AFAICT the accepted terminology in C++ is that a pointer of type T*
>>>> can point to a T or an array of T's.
>>>
>>>>> You have some kind of point of course: the only reason to mess around
>>>>> with int*, int** or int***** is to eventually do something to a bunch
>>>>> of ints. But the language doesn't know, or care.
>>>
>>>> I was merely trying to demonstrate that different levels of
>>>> indirection do not change the object type. The object pointed to is an
>>>> int type, whether you create a pointer to it with one level of
>>>> indirection or five i.e: int*****.
>>>> The same applies to an array, the arrays' type does not change because
>>>> of the pointer type used to address it. An array of chars, for
>>>> example, is addressed using a char* because you cannot address  n x
>>>> chars, you can address only one char. If you create a pointer with two
>>>> or three levels of indirection to this array of chars it doesn't
>>>> change the type of the pointed-to object.
>>>
>>>> And this is exactly what a pointer of type char(*ptr)[S] is, a pointer
>>>> to chars with two levels of indirection. The level of indirection
>>>> doesn't affect the type of the addressed object.
>>>
>>>> Yeah sure you can be really pedantic and argue that between each level
>>>> of indirection the pointer type changes from eg: char*** to char** to
>>>> char*. But at the end of the day each of these pointers is just
>>>> another pointer variable that stores a memory address and its doesn't
>>>> really change the type of the pointed-to object. Its just changing in
>>>> levels of indirection. For example: a char**** is a pointer to a char
>>>> just the same as a char** is a pointer to a char, is it not?.
>>>
>>> No; char**** is a pointer to a char***.
>>>
>> You're reply is incorrect on two points:
>> a) The pointer may point to a char indirectly.
>> b) The pointer may be null and point to nothing.
>>
>> The scenario , that you agree with, where char**** is a pointer to a
>> char*** you are considering only one level of indirection:
>> char**** ---- dereferneces to --->  char***.
>>
>> Now considering a less simpleton mind:
>> char**** --->  char*** --->  char** --->  char* --->  char.
>>
>>
>> It may point to a char(indirectly) *and* a char***. You'd be incorrect
>> to say this is incorrect.
>>
>>
>>
>>
>>
>> Just as with the pointer type int(*)[S]. You say that this is a
>> pointer to an array of S, and only to an array of S, all other
>> contexts are deemed as incorrect. But this is nonsense because:
>>
>> int array1[8][10] = {0};
>> int array2[9][10] ={0};
>> int array3[10]={0};
>> int (*ptr1)[10];
>> ptr1 = array1;
>> ptr1 = array2;
>> ptr1 =&array3;
>>
>>
>> It is correct to say that ptr1 points to 3 different sized arrays and
>> incorrect to say that ptr1 is only a pointer to an array of 10 ints.
>> The pointer type can point to arrays of different sizes and not only
>> to an array of 10 ints. The difference between this pointer type and
>> an int* type is obviously in it's level of indirection. The int type
>> never changes from each level of indirection, only the pointer-type to
>> reflect that different level of indirection, as in the case with
>> char***, char**, char*.
>
> You are so wrong that you could say that you are not *even* wrong.
>

You don't make alot of sense.



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#14487

I'm not sure but I think Leigh is trying to say that your notion of "indirect" is irrelevant:

typedef <something> P;
typedef P*    PP;
typedef PP*   PPP;
typedef PPP*  PPPP;
typedef PPPP* PPPPP;

PPPPP x = ppppp();

In the end, _x_ is a pointer to something of type PPPP.  As far as _x_ is concerned, it really does not matter what PPPP is.  If you try to evaluate _*x_, that's a different matter but then you're really no longer talking about _x_ at that point because _*x_ evaluates to a different (tho related) type.

As for your point, well... I'm not really sure what your point is but I'm beginning to think that the two of you are in violent agreement, you just don't realize it.

[toc] | [prev] | [next] | [standalone]

#14488

>>"Mike McCarty" <mcmccarty@gmail.com> wrote in message 
>>news:30064152.294.1330102204173.JavaMail.geo-discussion-forums@vbpw16...
>>I'm not sure but I think Leigh is trying to say that your notion of 
>>"indirect" is irrelevant:

>>typedef <something> P;

Is "something a new C++ keyword"? Wtf is that shit supposed to mean?
Please don't speak to me until you've grown a brain tyvm :)


plonk.



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#14490

On Feb 24, 6:47 pm, "Paul" <pchrist<nospam>o...@yahoo.co.uk> wrote:
> >>"Mike McCarty" <mcmcca...@gmail.com> wrote in message
> >>news:30064152.294.1330102204173.JavaMail.geo-discussion-forums@vbpw16...
> >>I'm not sure but I think Leigh is trying to say that your notion of
> >>"indirect" is irrelevant:
> >>typedef <something> P;
>
> Is "something a new C++ keyword"? Wtf is that shit supposed to mean?
> Please don't speak to me until you've grown a brain tyvm :)
>
> plonk.
>
> --- Posted via news://freenews.netfront.net/ - Complaints to n...@netfront.net ---

Hey man sorry for being a bit snappy at you. The comment about
indirection being irrelevant annoyed me a bit, on top of Leighs
constant bickering.

[toc] | [prev] | [next] | [standalone]

#14517

On Feb 24, 4:50 pm, Mike McCarty <mcmcca...@gmail.com> wrote:
> I'm not sure but I think Leigh is trying to say that your notion of "indirect" is irrelevant:
>
> typedef <something> P;
> typedef P*    PP;
> typedef PP*   PPP;
> typedef PPP*  PPPP;
> typedef PPPP* PPPPP;
>
> PPPPP x = ppppp();
>
> In the end, _x_ is a pointer to something of type PPPP.  As far as _x_ is concerned, it really does not matter what PPPP is.  If you try to evaluate _*x_, that's a different matter but then you're really no longer talking about _x_ at that point because _*x_ evaluates to a different (tho related) type.
>
> As for your point, well... I'm not really sure what your point is but I'm beginning to think that the two of you are in violent agreement, you just don't realize it.

The point is that Leigh and one or two others are saying that an int(*)
[S] is a pointer to a 1-dimensional array, and not to a 2-dim array.
Of course they are correct to say that its a pointer to a 1-dim array
in the context of the pointers' type but they are saying this is also
true in the context of what is pointed to.
It is not always correct in the context of what is pointed to , and
this is why I originally objected to Juha's post where he wrote "int*
points to an int, and int(*)[10] points to an array of 10 ints.".

With an array of ints the pointer type norammly used to point to them
is an int*, a pointer of type int(*)[S] can also be used to point to
them but this would have an added level of indirection.

Lets describe a pointer as a variable that stores the address of an
object and thus is a variable that is used to indirectly access some
pointed-to object. So it seems like common sense that the pointed-to
object is the object which is returned(or accessed) when the pointer
is dereferenced and as with the following:

int x; /*an object.*/
int* p = &x; /*a pointer-to object x, of type int*. */
int** pp = &p; /*a pointer to p, of type int**, which also points to x
indirectly. */

The above shows pointers that differ in levels of indirection so lets
consider what Leighs argument might be regarding the last line where I
commented that pp points to x indirectly. Leigh might say that it does
not point to x and it only points to an p because this is the basis of
his argument i.e: That the pointers' type defines what is pointed to,
and it cannot point-to anything else. I could understand this argument
because when you dereference the pointer pp you access the pointer p
thus it could be said that pp only points to p, and not to x, if we
disregard the context of pointing to an object indirectly.
If the context of pointing to an object indirectly is not disregarded
Leighs argument doesn't add up at all , as we will see later.

Moving on to pointers to arrays lets consider the following:
int arr[10];
int* p = arr;
int (*pa)[10] = &arr;


In the context of what is pointed to , and not the pointers type, pa
cannot be said to directly point to the array because when we
dereference pa we do not access the array. the pointer pa needs to be
dereferenced twice to access the array so it can only be said that it
points-to the array indirectly. On the other hand p , when
dereferenced, accesses the array. Obviously, to me , they can both
point to the array but in a slightly different context because they
have different levels of indirection.
This argument , from Leighs side, is strongly based on confusing
people between the pointers' type with what is pointed-to, or in some
cases the type of the pointed-to object. But when we get down to the
nitty gritty a pointers' type does not define what is pointed-to ,
just look at a void* for evidence of this.

I am arguing that both p and pa can be said to point to the array, and
in their own contexts both are correct because an array can be seen in
two ways: as a single object or as a sequence of objects. The argument
I am opposing is that an int* cannot point to an array of ints and can
only point to one single int. I am arguing against this because it
breaks in so many ways the most obvious being that.. the pointer type
does not define the pointed-to object as I think I have explained
above.
This seems to be the argument against me: that int* points to a single
int because its type is pointer to int, int(*)[10] is a pointer to an
array of 10 ints because its pointer type is pointer to int[10] etc
etc. As I have said this argument breaks down in many ways and thus I
object to them saying it's incorrect that an int* points to an array.

Additionally Bjarne Stroustrup says in one of his books that a char*
can point to a single char or an array of chars. I think Bjarne knows
what he is talking about when it comes to C++ and I would take much
consideration before disputing what he says. Even if their(Leigh and
others who agree with him) point was eventually proven to be correct
in standardesque and legal terms , which it will never be, most of us
know that its common knowledge and acceptable terminology that an int*
can point to an array of ints.

Again I apologise for being cheeky and a bit snappy in my previous
reply but these tedious argument can get me a bit wound up at times.
HTH
Paul.

[toc] | [prev] | [next] | [standalone]

#14530

On Sunday, February 26, 2012 2:41:07 PM UTC-6, Paul wrote:
> The argument
> I am opposing is that an int* cannot point to an array of ints and can
> only point to one single int. I am arguing against this because it
> breaks in so many ways the most obvious being that.. the pointer type
> does not define the pointed-to object as I think I have explained
> above.

In fact, I think that's exactly the point they're trying to make:  The conversion from 'int[10]' to 'int*' implies loss of information.  The lost information can only be resurrected via _convention_ (e.g. begin/end range pointers, etc.), not thru the type system itself.

An example:

int a[10];
int (&b)[9] = a[1];

The C++ language dictates that this is illegal syntax, despite the fact that simple analysis shows that it is perfectly reasonable and logically correct.  This is the sort of 'context' you've been referring to but this 'context' is exactly what the language does not support.  

FWIW, you can always force context upon the language, see http://codepad.org/pyZzy6Ae.  Not that I recommend it...


> This seems to be the argument against me: that int* points to a single
> int because its type is pointer to int, int(*)[10] is a pointer to an
> array of 10 ints because its pointer type is pointer to int[10] etc
> etc. As I have said this argument breaks down in many ways and thus I
> object to them saying it's incorrect that an int* points to an array.

Given only 

int* iptr = something();

all you can say definitely is that iptr either points to an object (e.g. iptr=&arr[15]) or it does not (iptr=NULL).  Everything else can only be deduced from additional external information that the int* type itself does not provide.  

If I've still managed to miss the point, you're going to have to forgive me.


Mike

[toc] | [prev] | [next] | [standalone]

#14542

On Feb 27, 5:30 am, Mike McCarty <mcmcca...@gmail.com> wrote:
> On Sunday, February 26, 2012 2:41:07 PM UTC-6, Paul wrote:
> > The argument
> > I am opposing is that an int* cannot point to an array of ints and can
> > only point to one single int. I am arguing against this because it
> > breaks in so many ways the most obvious being that.. the pointer type
> > does not define the pointed-to object as I think I have explained
> > above.
>
> In fact, I think that's exactly the point they're trying to make:  The conversion from 'int[10]' to 'int*' implies loss of information.  The lost information can only be resurrected via _convention_ (e.g. begin/end range pointers, etc.), not thru the type system itself.
>
The two pointers you compared are different levels of indirection,
It's different pointer types look:
int* pointer to a 1-dim array.
int(*)[S]
int(*)[S1]S2]
int(*)[S1][S2][S3] pointer to a 4-dim array


These pointers are pointers to arrays of different dimensions.
The numbers that accompany the pointers are simply a multiplier for
the index, used by the compiler when the pointer is dereferenced, it
doesn't affect the type of the pointed-to object.
A 1-dim array doesn't need a multiplier. A 2-dim array doesn't need
two multipliers it only needs one. This is not "loss of information"
as you have put it, the information is not there because it's not
required.


> An example:
>

> An example:
>
> int a[10];
> int (&b)[9] = a[1];
>
> The C++ language dictates that this is illegal syntax, despite the fact that simple analysis shows that it is perfectly reasonable and logically correct.  This is the sort of 'context' you've been referring to but this 'context' is exactly what the language does not support.

No I never brought references into the discussion.,
>
> FWIW, you can always force context upon the language, seehttp://codepad.org/pyZzy6Ae.  Not that I recommend it...
>
> > This seems to be the argument against me: that int* points to a single
> > int because its type is pointer to int, int(*)[10] is a pointer to an
> > array of 10 ints because its pointer type is pointer to int[10] etc
> > etc. As I have said this argument breaks down in many ways and thus I
> > object to them saying it's incorrect that an int* points to an array.
>
> Given only
>
> int* iptr = something();

I wish you wouldn't use this default object construction syntax(or
function syntax) when assigning to pointers, because more often than
not this will not return an objects' address. An objects' address is
assigned to a pointer, not an object.
>
> all you can say definitely is that iptr either points to an object (e.g. iptr=&arr[15]) or it does not (iptr=NULL).  Everything else can only be deduced from additional external information that the int* type itself does not provide.

A pointer doesn't only point to an object or null because it can also
point to objects(plural).

>
> If I've still managed to miss the point, you're going to have to forgive me.
>

If you agree with Leighs argument , and disagree with Bjarne S, then I
think you have missed the point :)
I'm sorry if I can't present my argument well enough to make you
understand

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c++

csiph-web