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 1 of 3  [1] 2 3  Next page →

#14092 — Pointer Problem

What is the difference between the following declarations?

int *ptr[10];

    and

int (*ptr)[10];

[toc] | [next] | [standalone]

#14095

bintom <binoythomas1108@gmail.com> wrote:
> What is the difference between the following declarations?
> 
> int *ptr[10];
> 
>    and
> 
> int (*ptr)[10];

  The former is an array of 10 elements, each element being an int*.

  The latter is a pointer to a two-dimensional array (iow. a single
array which is indexed using two index values), the second dimension
of said array being 10.

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

#14099

在 2012年2月16日星期四UTC+8下午11时15分14秒，Juha Nieminen写道：
> bintom <binoythomas1108@gmail.com> wrote:
> > What is the difference between the following declarations?
> > 
> > int *ptr[10];
> > 
> >    and
> > 
> > int (*ptr)[10];
> 
>   The former is an array of 10 elements, each element being an int*.
> 

The place where  the * should be appeared is not only 
the style problem.

>   The latter is a pointer to a two-dimensional array (iow. a single
> array which is indexed using two index values), the second dimension
> of said array being 10.

int* ptr[10];
int (*ptr2)[10];

//I prefer this style. 

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

#14100

On 2/16/2012 10:17 AM, 88888 Dihedral wrote:
> 在 2012年2月16日星期四UTC+8下午11时15分14秒，Juha Nieminen写道：
>> bintom<binoythomas1108@gmail.com>  wrote:
>>> What is the difference between the following declarations?
>>>
>>> int *ptr[10];
>>>
>>>     and
>>>
>>> int (*ptr)[10];
>>
>>    The former is an array of 10 elements, each element being an int*.
>>
>
> The place where  the * should be appeared is not only
> the style problem.
>
>>    The latter is a pointer to a two-dimensional array (iow. a single
>> array which is indexed using two index values), the second dimension
>> of said array being 10.
>
> int* ptr[10];
> int (*ptr2)[10];
>
> //I prefer this style.

You do, do you?  In this declaration:

    int* a[10], b[20];

what's the type of 'b[2]'?

V
-- 
I do not respond to top-posted replies, please don't ask

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

#14101

Victor Bazarov <v.bazarov@comcast.invalid> writes:
>On 2/16/2012 10:17 AM, 88888 Dihedral wrote:
>> 在 2012年2月16日星期四UTC+8下午11时15分14秒，Juha Nieminen写道：
>>> bintom<binoythomas1108@gmail.com>  wrote:
>>>> What is the difference between the following declarations?
>>>>
>>>> int *ptr[10];
>>>>
>>>>     and
>>>>
>>>> int (*ptr)[10];
>>>
>>>    The former is an array of 10 elements, each element being an int*.
>>>
>>
>> The place where  the * should be appeared is not only
>> the style problem.
>>
>>>    The latter is a pointer to a two-dimensional array (iow. a single
>>> array which is indexed using two index values), the second dimension
>>> of said array being 10.
>>
>> int* ptr[10];
>> int (*ptr2)[10];
>>
>> //I prefer this style.
>
>You do, do you?  In this declaration:
>
>    int* a[10], b[20];
>
>what's the type of 'b[2]'?

int of course.  Yet another reason to place declarations individually.

    int *a[10];
    int *b[10];

Easier to pick out the identifier visually this way.

scott

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

#14103

On 2/16/2012 12:18 PM, Scott Lurndal wrote:
> Victor Bazarov<v.bazarov@comcast.invalid>  writes:
>> On 2/16/2012 10:17 AM, 88888 Dihedral wrote:
>>> 在 2012年2月16日星期四UTC+8下午11时15分14秒，Juha Nieminen写道：
>>>> bintom<binoythomas1108@gmail.com>   wrote:
>>>>> What is the difference between the following declarations?
>>>>>
>>>>> int *ptr[10];
>>>>>
>>>>>      and
>>>>>
>>>>> int (*ptr)[10];
>>>>
>>>>     The former is an array of 10 elements, each element being an int*.
>>>>
>>>
>>> The place where  the * should be appeared is not only
>>> the style problem.
>>>
>>>>     The latter is a pointer to a two-dimensional array (iow. a single
>>>> array which is indexed using two index values), the second dimension
>>>> of said array being 10.
>>>
>>> int* ptr[10];
>>> int (*ptr2)[10];
>>>
>>> //I prefer this style.
>>
>> You do, do you?  In this declaration:
>>
>>     int* a[10], b[20];
>>
>> what's the type of 'b[2]'?
>
> int of course.  Yet another reason to place declarations individually.
>
>      int *a[10];
>      int *b[10];
>
> Easier to pick out the identifier visually this way.

Identifiers should have a meaningful number of characters for easy 
picking out, IMNSHO.  'a' or 'b' aren't very good no matter whether you 
declare them each on a separate line, or together.

Besides that, why waste a line of code in the following idiom:

     sometype obj, *ptr = &obj;

?

V
-- 
I do not respond to top-posted replies, please don't ask

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

#14109

On Thursday, February 16, 2012 12:46:32 PM UTC-6, Victor Bazarov wrote:
> ...
> Besides that, why waste a line of code in the following idiom:
> 
>      sometype obj, *ptr = &obj;
> 
> ?


Uh, why not?  

Do you also prefer this:

    Foo f; Bar *b=&f;

?

If not, why not?  Semantically, it's exactly the same thing.

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

#14111

Victor Bazarov <v.bazarov@comcast.invalid> writes:
>On 2/16/2012 12:18 PM, Scott Lurndal wrote:
>> Victor Bazarov<v.bazarov@comcast.invalid>  writes:
>>> On 2/16/2012 10:17 AM, 88888 Dihedral wrote:
>>>> 在 2012年2月16日星期四UTC+8下午11时15分14秒，Juha Nieminen写道：
>>>>> bintom<binoythomas1108@gmail.com>   wrote:
>>>>>> What is the difference between the following declarations?
>>>>>>
>>>>>> int *ptr[10];
>>>>>>
>>>>>>      and
>>>>>>
>>>>>> int (*ptr)[10];
>>>>>
>>>>>     The former is an array of 10 elements, each element being an int*.
>>>>>
>>>>
>>>> The place where  the * should be appeared is not only
>>>> the style problem.
>>>>
>>>>>     The latter is a pointer to a two-dimensional array (iow. a single
>>>>> array which is indexed using two index values), the second dimension
>>>>> of said array being 10.
>>>>
>>>> int* ptr[10];
>>>> int (*ptr2)[10];
>>>>
>>>> //I prefer this style.
>>>
>>> You do, do you?  In this declaration:
>>>
>>>     int* a[10], b[20];
>>>
>>> what's the type of 'b[2]'?
>>
>> int of course.  Yet another reason to place declarations individually.
>>
>>      int *a[10];
>>      int *b[10];
>>
>> Easier to pick out the identifier visually this way.
>
>Identifiers should have a meaningful number of characters for easy 
>picking out, IMNSHO.  'a' or 'b' aren't very good no matter whether you 
>declare them each on a separate line, or together.
>
>Besides that, why waste a line of code in the following idiom:
>
>     sometype obj, *ptr = &obj;

Makes diffs prettier when one of the decl's needs to change?

Takes two punched cards instead of one?  (which does make patching
simpler :-)

      sometype   obj;
      sometype  *ptr = &obj;

makes it easier to pick out ptr visually when maintaining unfamiliar
code.

YMMV

scott

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

#14148

On Feb 16, 6:46 pm, Victor Bazarov <v.baza...@comcast.invalid> wrote:
> On 2/16/2012 12:18 PM, Scott Lurndal wrote:

<snip>

> > [...] Yet another reason to place declarations individually.
>
> >      int *a[10];
> >      int *b[10];
>
> > Easier to pick out the identifier visually this way.
>
> Identifiers should have a meaningful number of characters for easy
> picking out, IMNSHO.  'a' or 'b' aren't very good no matter whether you
> declare them each on a separate line, or together.

depends. If you're solving quadratic equations than 'a' and 'b' may be
quite sensible identifiers.

On behalf of the Campaign Against Unnecessarily Long Variable Names

<snip>

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

#14125

Juha Nieminen <nospam@thanks.invalid> wrote:
> bintom <binoythomas1108@gmail.com> wrote:
> > What is the difference between the following declarations?
> > 
> > int *ptr[10];
> > 
> >    and
> > 
> > int (*ptr)[10];

>   The former is an array of 10 elements, each element being an int*.

>   The latter is a pointer to a two-dimensional array (iow. a single
> array which is indexed using two index values), the second dimension
> of said array being 10.

Sorry for chiming in, but the second is just a pointer to
an array of 10 ints, nothing two-dimensional involved at
this stage (see e.g. http://www.torek.net/torek/c/pa.html
even though it's abot C, but there's no difference to C++).

                          Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

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

#14136

Jens Thoms Toerring <jt@toerring.de> wrote:
> Juha Nieminen <nospam@thanks.invalid> wrote:
>> bintom <binoythomas1108@gmail.com> wrote:
>> > What is the difference between the following declarations?
>> > 
>> > int *ptr[10];
>> > 
>> >    and
>> > 
>> > int (*ptr)[10];
> 
>>   The former is an array of 10 elements, each element being an int*.
> 
>>   The latter is a pointer to a two-dimensional array (iow. a single
>> array which is indexed using two index values), the second dimension
>> of said array being 10.
> 
> Sorry for chiming in, but the second is just a pointer to
> an array of 10 ints, nothing two-dimensional involved at
> this stage

  If you want to be really pedantic, that might be so. It's the same as
with an "int*" which doubles as a pointer to a single int and a pointer
to an array of ints.

  In practice "int*" is basically always a pointer to an array of ints
because it has intrinsic support for it being an array (ie. you can
index the potential array behind it). If it's pointing to a single int
you can think of it as pointing to an array of size 1.

  Likewise "int (*ptr)[10]" is always a pointer to a two-dimensional array
where the second dimension is 10, even if it's pointing to just an array
of 10 elements (in which case you can think of it as the first dimension
being 1).

  It's useful to know that because it allows you to create pointers to
multi-dimensional arrays, something that's a lesser-known feature of C/C++.
For example, you can have something along the lines of:

    int array1[20][10] = { ... };
    int array2[20][10] = { ... };

    int (*currentArray)[10];
    if(something) currentArray = array1;
    else currentArray = array2;

    currentArray[3][7] = 5;
    ...

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

#14246

Juha Nieminen <nospam@thanks.invalid> wrote:
> Jens Thoms Toerring <jt@toerring.de> wrote:
> > Juha Nieminen <nospam@thanks.invalid> wrote:
> >> bintom <binoythomas1108@gmail.com> wrote:
> >> > What is the difference between the following declarations?
> >> > 
> >> > int *ptr[10];
> >> > 
> >> >    and
> >> > 
> >> > int (*ptr)[10];
> > 
> >>   The former is an array of 10 elements, each element being an int*.
> > 
> >>   The latter is a pointer to a two-dimensional array (iow. a single
> >> array which is indexed using two index values), the second dimension
> >> of said array being 10.
> > 
> > Sorry for chiming in, but the second is just a pointer to
> > an array of 10 ints, nothing two-dimensional involved at
> > this stage

>   If you want to be really pedantic, that might be so. It's the same as
> with an "int*" which doubles as a pointer to a single int and a pointer
> to an array of ints.

Ok, let me really pedantic;-) An "int*" doesnt double as a pointer
to an array (of ints), it just can point to an element of an array
(just as it can point to a "lonely" int).

> In practice "int*" is basically always a pointer to an array of ints

There are a lot of cases where there are pointers to single ints,
e.g. when passing them to a function (admitedly, more often in C
were ypu don't have references and pointers are the only way to
pass something to a function that can be modified from within
the function).

> because it has intrinsic support for it being an array (ie. you can
> index the potential array behind it). If it's pointing to a single int
> you can think of it as pointing to an array of size 1.

I understand what you mean, but this is saddling the horse from
the back. An "int*" never points to more than a single int. Due
to the shortcoming of C (and thus C++) that arrays aren't "first
class" objects (i.e. they can't be passed to functions by value
since an array isn't a "value", contrary to e.g. structures) a
special case was introduced: when an array appears in a place
were a value is required then the array gets converted to a
pointer to the first element of that array. And this has
resulted in many people (even experienced C and C++ program-
mers) getting confused about the distinction between arrays
and pointers. But that doesn't make a pointer anything "array-
like" - it's just that in certain situations when an array is
found it is converted silently to a pointer to that array's
first element. That's all there's about "intrinsic support".

> Likewise "int (*ptr)[10]" is always a pointer to a two-dimensional array

Sorry, but no. Like an "int*" only points to a single int, a "int
(*ptr)[10]" points to just a single array of 10 ints. But because,
when incremented, it points to the next following array of 10
ints it can be used to iterate over the sub-arrays of a two-
dimensional array when that is an array of arrays of 10 ints.

I can just recommend reading what Chris Torek writes about all
this (even though it doesn't mention C++, but it's exactly the
same in C++) - it's the most lucid explanation I've ever found.

                           Best regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

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

#14334

Am 18.02.2012 23:39, schrieb Jens Thoms Toerring:

> Ok, let me really pedantic;-) An "int*" doesnt double as a pointer
> to an array (of ints), it just can point to an element of an array
> (just as it can point to a "lonely" int).

I think I have a deja vu :)



Peter

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

#14396

On Feb 20, 8:07 pm, Peter Remmers
<p.remm...@expires-2011-04-30.arcornews.de> wrote:
> Am 18.02.2012 23:39, schrieb Jens Thoms Toerring:
>
> > Ok, let me really pedantic;-) An "int*" doesnt double as a pointer
> > to an array (of ints), it just can point to an element of an array
> > (just as it can point to a "lonely" int).
>
> I think I have a deja vu :)
>
> Peter

oh yes.

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

#14395

On Feb 18, 10:39 pm, j...@toerring.de (Jens Thoms Toerring) wrote:
> Juha Nieminen <nos...@thanks.invalid> wrote:
> > Jens Thoms Toerring <j...@toerring.de> wrote:
> > > Juha Nieminen <nos...@thanks.invalid> wrote:
> > >> bintom <binoythomas1...@gmail.com> wrote:
> > >> > What is the difference between the following declarations?
>
> > >> > int *ptr[10];
>
> > >> >    and
>
> > >> > int (*ptr)[10];
>
> > >>   The former is an array of 10 elements, each element being an int*.
>
> > >>   The latter is a pointer to a two-dimensional array (iow. a single
> > >> array which is indexed using two index values), the second dimension
> > >> of said array being 10.
>
> > > Sorry for chiming in, but the second is just a pointer to
> > > an array of 10 ints, nothing two-dimensional involved at
> > > this stage
> >   If you want to be really pedantic, that might be so. It's the same as
> > with an "int*" which doubles as a pointer to a single int and a pointer
> > to an array of ints.
>
> Ok, let me really pedantic;-) An "int*" doesnt double as a pointer
> to an array (of ints), it just can point to an element of an array
> (just as it can point to a "lonely" int).
>
> > In practice "int*" is basically always a pointer to an array of ints
>
> There are a lot of cases where there are pointers to single ints,
> e.g. when passing them to a function (admitedly, more often in C
> were ypu don't have references and pointers are the only way to
> pass something to a function that can be modified from within
> the function).

The pointer can point to a single integer or an array of integers, it
is dependant on the context.
>
> > because it has intrinsic support for it being an array (ie. you can
> > index the potential array behind it). If it's pointing to a single int
> > you can think of it as pointing to an array of size 1.
>
> I understand what you mean, but this is saddling the horse from
> the back. An "int*" never points to more than a single int.

What you say is technically incorrect because an int* can point to one
past the last element of an array of integers thus it may not point to
any single integer.
If such a pointer doesn't point to any single integer yet still points
to an array of integers , what does this pointer point to?

> Due
> to the shortcoming of C (and thus C++) that arrays aren't "first
> class" objects (i.e. they can't be passed to functions by value
> since an array isn't a "value", contrary to e.g. structures) a
> special case was introduced: when an array appears in a place
> were a value is required then the array gets converted to a
> pointer to the first element of that array. And this has
> resulted in many people (even experienced C and C++ program-
> mers) getting confused about the distinction between arrays
> and pointers. But that doesn't make a pointer anything "array-
> like" - it's just that in certain situations when an array is
> found it is converted silently to a pointer to that array's
> first element. That's all there's about "intrinsic support".
>
> > Likewise "int (*ptr)[10]" is always a pointer to a two-dimensional array
>
> Sorry, but no. Like an "int*" only points to a single int,
This is not correct see above.

> a "int
> (*ptr)[10]" points to just a single array of 10 ints. But because,
> when incremented, it points to the next following array of 10
> ints it can be used to iterate over the sub-arrays of a two-
> dimensional array when that is an array of arrays of 10 ints.
>
The pointer type int(*)[S]  will point to the same thing as an int*
that stores the same address.

In C++ the array works in such a way that it defaults to a pointer, or
an address , and you don't need to take the address of an array in the
same way you'd normally take the address of an object. The language is
structured in such a way that the index operator [] automatically
dereferences a pointer to an array. For example:

int anarray[5] = {0};
int* ptr = anarray;

There is no need to take the address of an array , it automatically is
converted to a pointer.



An array can be thought of in two ways:
a) one complete object with its own type
b) a sequence of objects
The argument you put forward is based on a) where the pointer-type T*
is a pointer to an object of type T, where T is an array object type.
But as you said arrays aren't first class objects and cannot be
accessed by value. So we cannot have a pointer that, when
dereferenced, returns an array.

I think the way most people see it is that an array is a sequence of
elements of type T, so it makes sense that the pointer that points to
them is of type T*. The fancy pointer types like T(*)[S] are of the
same type but have another level of indirection to allow for multiple
indexing .. anarray[i1][i2].

HTH
Paul.

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

#14408

Paul <pchristor@yahoo.co.uk> wrote:
> I think the way most people see it is that an array is a sequence of
> elements of type T, so it makes sense that the pointer that points to
> them is of type T*. The fancy pointer types like T(*)[S] are of the
> same type but have another level of indirection to allow for multiple
> indexing .. anarray[i1][i2].

  T* and T(*)[S] are not of the same type, which becomes clear if you,
for example, look at the size of their derefenced types. In other words,
if you have a "T *p1" and a "T (*p2)[123]" then sizeof(*p1) is not the
same as sizeof(*p2). That's because p2 points to an array of
123 elements of type T while p1 points to one value of type T.

  (Let your ranting begin.)

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

#14424

On Feb 22, 10:15 am, Juha Nieminen <nos...@thanks.invalid> wrote:
> Paul <pchris...@yahoo.co.uk> wrote:
> > I think the way most people see it is that an array is a sequence of
> > elements of type T, so it makes sense that the pointer that points to
> > them is of type T*. The fancy pointer types like T(*)[S] are of the
> > same type but have another level of indirection to allow for multiple
> > indexing .. anarray[i1][i2].
>
>   T* and T(*)[S] are not of the same type, which becomes clear if you,
> for example, look at the size of their derefenced types. In other words,
> if you have a "T *p1" and a "T (*p2)[123]" then sizeof(*p1) is not the
> same as sizeof(*p2). That's because p2 points to an array of
> 123 elements of type T while p1 points to one value of type T.
>
>   (Let your ranting begin.)
Ranting?


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

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

#14432

On 22/02/2012 15:49, Paul wrote:
> On Feb 22, 10:15 am, Juha Nieminen<nos...@thanks.invalid>  wrote:
>> Paul<pchris...@yahoo.co.uk>  wrote:
>>> I think the way most people see it is that an array is a sequence of
>>> elements of type T, so it makes sense that the pointer that points to
>>> them is of type T*. The fancy pointer types like T(*)[S] are of the
>>> same type but have another level of indirection to allow for multiple
>>> indexing .. anarray[i1][i2].
>>
>>    T* and T(*)[S] are not of the same type, which becomes clear if you,
>> for example, look at the size of their derefenced types. In other words,
>> if you have a "T *p1" and a "T (*p2)[123]" then sizeof(*p1) is not the
>> same as sizeof(*p2). That's because p2 points to an array of
>> 123 elements of type T while p1 points to one value of type T.
>>
>>    (Let your ranting begin.)
> Ranting?
>
>
> 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".

Not this tedious argument again.

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

/Leigh

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

#14449

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.

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

#14458

"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].
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. */
This pointer points-to a memory location and not to a type.


Each n-dimensional pointer-to-array increases in levels of indirection, The 
underlying pointed-to type doesn't change just as it doesn't with int*, 
int**, int*** etc.



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

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web