Re: Why C has Pointers.

Discussion in 'C Programming' started by 88888 Dihedral, Dec 17, 2011.

  1. On Wednesday, December 7, 2011 8:22:56 PM UTC+8, curixinfotech wrote:
    > hi
    > my Q is on the c language tell me now why c has pointers.
    > parshant
    >
    >
    > --
    > curixinfotech
    > ------------------------------------------------------------------------
    > curixinfotech's Profile: http://forums.yourdomain.com.au/member.php?userid=134
    > View this thread: http://forums.yourdomain.com.au/showthread.php?t=3319


    OK, I'll explain how to use a pointer in C without any knowledge in the
    hardware or assembly here.
    //
    int i;
    int a[3]={ 1,2,3} ; // an array of 3 integers
    int* ptr1; // Note the star should be right after int, not initialize
    int* ptr2; // not initialized

    ptr1=a; // Read this as to make ptr1 to be an alias of a.

    for(i=0;i<3;i++) printf("The value of a[%d]=%d.\n", i, a);
    for(i=0;i<3;i++) printf("The value of ptr1[%d]=%d.\n", i, ptr1);
    //This is a shadow copy.
    ptr1[0]=6; ptr2[1]=6;
    for(i=0;i<3;i++) printf("The value of a[%d]=%d.\n", i, a);
    // a[0]=? a[1]=?

    //Deep copy is different.
    ptr2=malloc(3*sizeof(int)); // get another array from the heap
    // if (ptr2==NULL) then raise an error!!!
    memcpy(ptr2,ptr1,3*sizeof(int)); // make a deep copy
    ptr2[0]=-6; *(ptr+2)=-6;

    for(i=0;i<3;i++) printf("The value of a[%d]=%d.\n", i, a);
    for(i=0;i<3;i++) printf("The value of ptr1[%d]=%d.\n", i, ptr1);
    for(i=0;i<3;i++) printf("The value of ptr2[%d]=%d.\n", i, ptr2);
     
    88888 Dihedral, Dec 17, 2011
    #1
    1. Advertising

  2. On Sat, 17 Dec 2011 08:51:33 -0800 (PST), 88888 Dihedral
    <> wrote:

    >On Wednesday, December 7, 2011 8:22:56 PM UTC+8, curixinfotech wrote:
    >> hi
    >> my Q is on the c language tell me now why c has pointers.
    >> parshant
    >>
    >>
    >> --
    >> curixinfotech
    >> ------------------------------------------------------------------------
    >> curixinfotech's Profile: http://forums.yourdomain.com.au/member.php?userid=134
    >> View this thread: http://forums.yourdomain.com.au/showthread.php?t=3319

    >
    >OK, I'll explain how to use a pointer in C without any knowledge in the
    >hardware or assembly here.
    >//
    >int i;
    >int a[3]={ 1,2,3} ; // an array of 3 integers
    >int* ptr1; // Note the star should be right after int, not initialize
    >int* ptr2; // not initialized
    >
    >ptr1=a; // Read this as to make ptr1 to be an alias of a.


    If that were true, the sizeof(a) and sizeof(ptr1) would be equal
    which, in the general case, they are not. ptr1 is simply a pointer
    that points to the start of a. Even though they share some
    similarities in the language syntax, a pointer is a completely
    different type than an array. Calling one an alias of the other just
    breeds unnecessary confusion.

    >
    >for(i=0;i<3;i++) printf("The value of a[%d]=%d.\n", i, a);
    >for(i=0;i<3;i++) printf("The value of ptr1[%d]=%d.\n", i, ptr1);
    >//This is a shadow copy.
    >ptr1[0]=6; ptr2[1]=6;


    Since ptr2 was never initialized or assigned a value, the second
    statement invokes undefined behavior. It is probably a typo and ptr1
    was intended.

    ptr1 points to a. There is no copy. a[0] and ptr1[0] refer to the
    exact same object.

    >for(i=0;i<3;i++) printf("The value of a[%d]=%d.\n", i, a);
    >// a[0]=? a[1]=?
    >
    >//Deep copy is different.
    >ptr2=malloc(3*sizeof(int)); // get another array from the heap
    >// if (ptr2==NULL) then raise an error!!!
    >memcpy(ptr2,ptr1,3*sizeof(int)); // make a deep copy
    >ptr2[0]=-6; *(ptr+2)=-6;


    Since there is no variable ptr, this cannot compile. Was *(ptr2+2)
    intended?

    >
    >for(i=0;i<3;i++) printf("The value of a[%d]=%d.\n", i, a);
    >for(i=0;i<3;i++) printf("The value of ptr1[%d]=%d.\n", i, ptr1);
    >for(i=0;i<3;i++) printf("The value of ptr2[%d]=%d.\n", i, ptr2);


    a and ptr1 still point to the same object. ptr2 points to a
    different area of memory which at one time had a copy of a but has
    since been assigned at least one different value.

    --
    Remove del for email
     
    Barry Schwarz, Dec 17, 2011
    #2
    1. Advertising

  3. 88888 Dihedral <> writes:
    > On Wednesday, December 7, 2011 8:22:56 PM UTC+8, curixinfotech wrote:
    >> my Q is on the c language tell me now why c has pointers.
    >> parshant

    >
    > OK, I'll explain how to use a pointer in C without any knowledge in the
    > hardware or assembly here.
    > //
    > int i;
    > int a[3]={ 1,2,3} ; // an array of 3 integers
    > int* ptr1; // Note the star should be right after int, not initialize


    Why should the * be adjacent to "int"? My own preferred style (and, I
    think, that of most C programmers) is:

    int *ptr1;

    The syntax of declarations in C follows (more or less) the syntax of
    expressions; "declaration follows use". So "int *ptr;" says that *ptr
    is an int -- from which it follows that ptr is a pointer to an int,
    i.e., an int*.

    This layout follows the grammar more closely, and makes an (admittedly
    unwise) declaration like this:

    int *pointer, not_a_pointer;

    easier to understand.

    But there is a school of thought that prefers to put the * next to the
    type name. That seems to be the usual convention in C++. That's ok if
    you avoid declaring multiple variables in one declaration (which you
    should probably do anyway).

    Note that the same principle might suggest:

    int[3] arr;

    which is of course a syntax error.

    > int* ptr2; // not initialized
    >
    > ptr1=a; // Read this as to make ptr1 to be an alias of a.


    That's not necessarily a good way to think of it. Since "a" is an array
    object the expression consisting of its name decays to a pointer to its
    first element. That pointer value is then stored in ptr1. ptr1 points
    to the first element of a. To show that it's not a true alias, consider
    sizeof a vs. sizeof ptr1.

    > for(i=0;i<3;i++) printf("The value of a[%d]=%d.\n", i, a);
    > for(i=0;i<3;i++) printf("The value of ptr1[%d]=%d.\n", i, ptr1);
    > //This is a shadow copy.
    > ptr1[0]=6; ptr2[1]=6;
    > for(i=0;i<3;i++) printf("The value of a[%d]=%d.\n", i, a);
    > // a[0]=? a[1]=?
    >
    > //Deep copy is different.
    > ptr2=malloc(3*sizeof(int)); // get another array from the heap
    > // if (ptr2==NULL) then raise an error!!!
    > memcpy(ptr2,ptr1,3*sizeof(int)); // make a deep copy
    > ptr2[0]=-6; *(ptr+2)=-6;
    >
    > for(i=0;i<3;i++) printf("The value of a[%d]=%d.\n", i, a);
    > for(i=0;i<3;i++) printf("The value of ptr1[%d]=%d.\n", i, ptr1);
    > for(i=0;i<3;i++) printf("The value of ptr2[%d]=%d.\n", i, ptr2);


    Read section 6 of the comp.lang.c FAQ, <http://c-faq.com>.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Will write code for food.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Dec 17, 2011
    #3
  4. 88888 Dihedral

    ralph Guest

    On Sat, 17 Dec 2011 10:10:09 -0800, Barry Schwarz <>
    wrote:

    >On Sat, 17 Dec 2011 08:51:33 -0800 (PST), 88888 Dihedral
    ><> wrote:
    >
    >>On Wednesday, December 7, 2011 8:22:56 PM UTC+8, curixinfotech wrote:
    >>> hi
    >>> my Q is on the c language tell me now why c has pointers.
    >>> parshant
    >>>
    >>>
    >>> --
    >>> curixinfotech
    >>> ------------------------------------------------------------------------
    >>> curixinfotech's Profile: http://forums.yourdomain.com.au/member.php?userid=134
    >>> View this thread: http://forums.yourdomain.com.au/showthread.php?t=3319

    >>
    >>OK, I'll explain how to use a pointer in C without any knowledge in the
    >>hardware or assembly here.
    >>//
    >>int i;
    >>int a[3]={ 1,2,3} ; // an array of 3 integers
    >>int* ptr1; // Note the star should be right after int, not initialize
    >>int* ptr2; // not initialized
    >>
    >>ptr1=a; // Read this as to make ptr1 to be an alias of a.

    >
    >If that were true, the sizeof(a) and sizeof(ptr1) would be equal
    >which, in the general case, they are not. ptr1 is simply a pointer
    >that points to the start of a. Even though they share some
    >similarities in the language syntax, a pointer is a completely
    >different type than an array. Calling one an alias of the other just
    >breeds unnecessary confusion.
    >


    I agree.

    I have trouble understanding the constant confusion between arrays and
    pointers. Way back when (and we are talking many moons ago <g>) when I
    started out in C my mentor explained it very simply in these terms in
    the first couple of days.

    1) There is a difference between declarations and definitions.
    Remember which you are dealing with and when.
    2) A pointer is a "variable", an array is a "constant"
    3) The array name evaluates to the address of the first element in the
    array.
    4) A pointer is a variable that holds the address of another variable
    or an array.
    5) All pointers must be intialized before you use them.
    6) Since an array name is an address it can be used as a pointer that
    is initialized to point to the first element in the array.
    7) *variable means the contents of the variable.
    8) &variable means the address of the variable.
    9) The array operator evaluates to a storage map equation, eg.
    type ar := *(a + (i * sizeof(type))
    10) In all "pointer" operations you are either chewing on an address
    or the contents (value) at that address. Simple deconstrution of the
    even the most complex expression will quickly reveal which it is.

    I've since learned how to restate the above in fancier terminology,
    but those simple rules have stuck and served me well from my second
    week in C to today - thirty plus years later.

    -ralph
     
    ralph, Dec 17, 2011
    #4
  5. 88888 Dihedral

    ralph Guest

    On Sat, 17 Dec 2011 14:28:14 -0600, ralph <>
    wrote:
    I should probably amplify #1 ...

    >
    >1) There is a difference between declarations and definitions.
    >Remember which you are dealing with and when.


    1.5) C operators are overloaded to some extent and often a different
    meaning in a declaration opposed to a definition or expression. For
    example:
    *v means the contents (value) of the variable pointed to by v in an
    expression, but
    char* v means declare a pointer that holds the address of a
    variable that holds a char in a declaration.

    ....

    -ralph
     
    ralph, Dec 17, 2011
    #5
  6. ralph <> writes:
    [...]
    > I have trouble understanding the constant confusion between arrays and
    > pointers. Way back when (and we are talking many moons ago <g>) when I
    > started out in C my mentor explained it very simply in these terms in
    > the first couple of days.
    >
    > 1) There is a difference between declarations and definitions.
    > Remember which you are dealing with and when.
    > 2) A pointer is a "variable", an array is a "constant"


    That doesn't really make sense. An array variable is not a constant:

    int arr[10];
    arr[5] = 42;

    I suppose what it means is that an array name, when it appears in an
    expression (in most but not all context) decays to a pointer to the
    array's first element, and that pointer value cannot be modified. But I
    think that saying an array is a constant just reinforces the confusion
    between arrays and pointers.

    > 3) The array name evaluates to the address of the first element in the
    > array.


    This applies to any expression of array type, not just the name of a
    declared array object. But it doesn't apply in all contexts.
    Specifically, an expression of array type is converted to a pointer to
    the array object's first element *unless* it's:

    The operand of a unary "sizeof" operator (sizeof arr gives you the
    same of the array, not of a pointer);

    The operand of a unary "&" operator (&arr gives you the address of
    the array object; it's the same memory location as the address of
    its first element, but it's of a different type);

    A string literal in an initializer used to initialize an array
    object. In
    char arr[6] = "hello";
    the *value* of "hello" is copied into arr.

    > 4) A pointer is a variable that holds the address of another variable
    > or an array.


    The distinction between variables an arrays is unnecessary. Variables
    can be of any object type: integer, floating-point, struct, union,
    array, pointer. There's nothing special about arrays in that particular
    context.

    An array object is an object whose value consists of the values of its
    elements, just as a struct object is an object whose value consists of
    the values of its members.

    > 5) All pointers must be intialized before you use them.


    The same applies to any object.

    > 6) Since an array name is an address it can be used as a pointer that
    > is initialized to point to the first element in the array.


    In most contexts; see above. It would be clearer to say that an array
    name *decays to* an address (or pointer value). And I wouldn't use the
    word "initialized".

    > 7) *variable means the contents of the variable.


    No, it means the contents of the object to which "variable" points (and
    is valid only if "variable" is of pointer type).

    > 8) &variable means the address of the variable.
    > 9) The array operator evaluates to a storage map equation, eg.
    > type ar := *(a + (i * sizeof(type))


    I'm not sure what syntax you're using. What does "type" mean here? And
    C pointer arithmetic is already scaled by the size of the pointed-to
    type.

    arr is by definition equivalent to *(arr + i).

    > 10) In all "pointer" operations you are either chewing on an address
    > or the contents (value) at that address. Simple deconstrution of the
    > even the most complex expression will quickly reveal which it is.
    >
    > I've since learned how to restate the above in fancier terminology,
    > but those simple rules have stuck and served me well from my second
    > week in C to today - thirty plus years later.


    Section 6 of the comp.lang.c FAQ, <http://c-faq.com>, has an excellent
    explanation of the relationship between arrays and pointers.

    A digression: The rule that an array expression decays into a pointer to
    the array object's first element leads to an interesting little hole in
    the language. It assumes that there is an array *object* to which you
    can point. This is usually the case, but not always. For example:

    #include <stdio.h>

    struct foo {
    int arr[3];
    };

    struct foo func(void) {
    struct foo result = { { 10, 20, 30 } };
    return result;
    }

    int main(void) {
    int *ptr = func().arr;
    printf("*ptr = %d\n", *ptr);
    return 0;
    }

    func() returns a *value* of type struct foo; it doesn't refer to any
    object ("result" ceases to exist when the function returns). So we have
    an array value, a member of the struct value returned by func(), that is
    not the value of any array object.

    C201X addresses this.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Will write code for food.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Dec 17, 2011
    #6
  7. On Sunday, December 18, 2011 3:45:14 AM UTC+8, Keith Thompson wrote:
    > 88888 Dihedral <> writes:
    > > On Wednesday, December 7, 2011 8:22:56 PM UTC+8, curixinfotech wrote:
    > >> my Q is on the c language tell me now why c has pointers.
    > >> parshant

    > >
    > > OK, I'll explain how to use a pointer in C without any knowledge in the
    > > hardware or assembly here.
    > > //
    > > int i;
    > > int a[3]={ 1,2,3} ; // an array of 3 integers
    > > int* ptr1; // Note the star should be right after int, not initialize

    >
    > Why should the * be adjacent to "int"? My own preferred style (and, I
    > think, that of most C programmers) is:
    >
    > int *ptr1;
    >

    int** (*methods[ ])() ;

    How do you read this?

    int* (*methods2[ ])() ;

    int* (*methods3[ ])( int* (*functor)(), int* ) ;

    methods, methods2, and methods3 are different arrays of functors.

    It is easy to use functors to perform tricks in functional programming.
     
    88888 Dihedral, Dec 17, 2011
    #7
  8. On Sunday, December 18, 2011 4:28:14 AM UTC+8, ralph wrote:
    > On Sat, 17 Dec 2011 10:10:09 -0800, Barry Schwarz <>
    > wrote:
    >
    > >On Sat, 17 Dec 2011 08:51:33 -0800 (PST), 88888 Dihedral
    > ><> wrote:
    > >
    > >>On Wednesday, December 7, 2011 8:22:56 PM UTC+8, curixinfotech wrote:
    > >>> hi
    > >>> my Q is on the c language tell me now why c has pointers.
    > >>> parshant
    > >>>
    > >>>
    > >>> --
    > >>> curixinfotech
    > >>> ------------------------------------------------------------------------
    > >>> curixinfotech's Profile: http://forums.yourdomain.com.au/member.php?userid=134
    > >>> View this thread: http://forums.yourdomain.com.au/showthread.php?t=3319
    > >>
    > >>OK, I'll explain how to use a pointer in C without any knowledge in the
    > >>hardware or assembly here.
    > >>//
    > >>int i;
    > >>int a[3]={ 1,2,3} ; // an array of 3 integers
    > >>int* ptr1; // Note the star should be right after int, not initialize
    > >>int* ptr2; // not initialized
    > >>
    > >>ptr1=a; // Read this as to make ptr1 to be an alias of a.

    > >
    > >If that were true, the sizeof(a) and sizeof(ptr1) would be equal
    > >which, in the general case, they are not. ptr1 is simply a pointer
    > >that points to the start of a. Even though they share some
    > >similarities in the language syntax, a pointer is a completely
    > >different type than an array. Calling one an alias of the other just
    > >breeds unnecessary confusion.
    > >

    >
    > I agree.
    >
    > I have trouble understanding the constant confusion between arrays and
    > pointers. Way back when (and we are talking many moons ago <g>) when I
    > started out in C my mentor explained it very simply in these terms in
    > the first couple of days.
    >
    > 1) There is a difference between declarations and definitions.
    > Remember which you are dealing with and when.
    > 2) A pointer is a "variable", an array is a "constant"
    > 3) The array name evaluates to the address of the first element in the
    > array.
    > 4) A pointer is a variable that holds the address of another variable
    > or an array.
    > 5) All pointers must be intialized before you use them.
    > 6) Since an array name is an address it can be used as a pointer that
    > is initialized to point to the first element in the array.
    > 7) *variable means the contents of the variable.


    *variable is easy to be miss-understood

    *ptr_variable is different from ptr_variable

    *variable if used for non-pointer variables, the compiler
    will say something, thus you are right in the general sense in C,
    but not clear enough for novices
     
    88888 Dihedral, Dec 17, 2011
    #8
  9. 88888 Dihedral

    ralph Guest

    On Sat, 17 Dec 2011 13:55:44 -0800, Keith Thompson <>
    wrote:

    >ralph <> writes:
    >[...]
    >> I have trouble understanding the constant confusion between arrays and
    >> pointers. Way back when (and we are talking many moons ago <g>) when I
    >> started out in C my mentor explained it very simply in these terms in
    >> the first couple of days.
    >>
    >> 1) There is a difference between declarations and definitions.
    >> Remember which you are dealing with and when.
    >> 2) A pointer is a "variable", an array is a "constant"

    >
    >That doesn't really make sense. An array variable is not a constant:
    >
    > int arr[10];
    > arr[5] = 42;
    >
    >I suppose what it means is that an array name, when it appears in an
    >expression (in most but not all context) decays to a pointer to the
    >array's first element, and that pointer value cannot be modified. But I
    >think that saying an array is a constant just reinforces the confusion
    >between arrays and pointers.
    >


    I disagree.

    Once the beginner gets it through his head that you can never do an
    assignment to 'arr' you resolve a ton of the questions we get around
    here. That as close to the definition of a "constant" as you can get.

    -ralph


    >> 3) The array name evaluates to the address of the first element in the
    >> array.

    >
    >This applies to any expression of array type, not just the name of a
    >declared array object. But it doesn't apply in all contexts.
    >Specifically, an expression of array type is converted to a pointer to
    >the array object's first element *unless* it's:
    >
    > The operand of a unary "sizeof" operator (sizeof arr gives you the
    > same of the array, not of a pointer);
    >
    > The operand of a unary "&" operator (&arr gives you the address of
    > the array object; it's the same memory location as the address of
    > its first element, but it's of a different type);
    >
    > A string literal in an initializer used to initialize an array
    > object. In
    > char arr[6] = "hello";
    > the *value* of "hello" is copied into arr.
    >


    Yep. But what's the big deal.

    And of course I disagree that it actually matters to the beginner that
    the address is of a "different type". Semantically and syntactically
    it comes out the same. Plenty of time to get into vague language
    later.

    Actually in some implementations whether "hello" gets copied and when
    if gets copied if it does depends on context. Again, why add
    confusion?

    [You can also create snippets that demonstrate that "hello" are
    identical "constants" ...
    "hello"[3]; \\ 'l'
    arr[3]; \\ 'l'


    >> 4) A pointer is a variable that holds the address of another variable
    >> or an array.

    >
    >The distinction between variables an arrays is unnecessary. Variables
    >can be of any object type: integer, floating-point, struct, union,
    >array, pointer. There's nothing special about arrays in that particular
    >context.
    >
    >An array object is an object whose value consists of the values of its
    >elements, just as a struct object is an object whose value consists of
    >the values of its members.
    >
    >> 5) All pointers must be intialized before you use them.

    >
    >The same applies to any object.
    >
    >> 6) Since an array name is an address it can be used as a pointer that
    >> is initialized to point to the first element in the array.

    >
    >In most contexts; see above. It would be clearer to say that an array
    >name *decays to* an address (or pointer value). And I wouldn't use the
    >word "initialized".
    >


    I would. And again what does 'decay' meant to the beginner?
    In code the name "arr" is changed to, or evaluates to, the address of
    the first element.

    >> 7) *variable means the contents of the variable.

    >
    >No, it means the contents of the object to which "variable" points (and
    >is valid only if "variable" is of pointer type).
    >
    >> 8) &variable means the address of the variable.
    >> 9) The array operator evaluates to a storage map equation, eg.
    >> type ar := *(a + (i * sizeof(type))

    >
    >I'm not sure what syntax you're using. What does "type" mean here? And
    >C pointer arithmetic is already scaled by the size of the pointed-to
    >type.
    >
    >arr is by definition equivalent to *(arr + i).
    >


    Think about it.

    You say that now, but you come back later in other response to point
    out "sizes". That "already scaled" is because the compiler knows the
    type, and he knows the type because you declared it.


    >> 10) In all "pointer" operations you are either chewing on an address
    >> or the contents (value) at that address. Simple deconstrution of the
    >> even the most complex expression will quickly reveal which it is.
    >>
    >> I've since learned how to restate the above in fancier terminology,
    >> but those simple rules have stuck and served me well from my second
    >> week in C to today - thirty plus years later.

    >
    >Section 6 of the comp.lang.c FAQ, <http://c-faq.com>, has an excellent
    >explanation of the relationship between arrays and pointers.
    >
    >A digression: The rule that an array expression decays into a pointer to
    >the array object's first element leads to an interesting little hole in
    >the language. It assumes that there is an array *object* to which you
    >can point. This is usually the case, but not always. For example:
    >
    >#include <stdio.h>
    >
    >struct foo {
    > int arr[3];
    >};
    >
    >struct foo func(void) {
    > struct foo result = { { 10, 20, 30 } };
    > return result;
    >}
    >
    >int main(void) {
    > int *ptr = func().arr;
    > printf("*ptr = %d\n", *ptr);
    > return 0;
    >}
    >
    >func() returns a *value* of type struct foo; it doesn't refer to any
    >object ("result" ceases to exist when the function returns). So we have
    >an array value, a member of the struct value returned by func(), that is
    >not the value of any array object.
    >
    >C201X addresses this.
     
    ralph, Dec 18, 2011
    #9
  10. 88888 Dihedral

    ralph Guest

    On Sat, 17 Dec 2011 15:35:49 -0800 (PST), 88888 Dihedral
    <> wrote:

    >On Sunday, December 18, 2011 4:28:14 AM UTC+8, ralph wrote:
    >> On Sat, 17 Dec 2011 10:10:09 -0800, Barry Schwarz <>
    >> wrote:
    >>
    >> >On Sat, 17 Dec 2011 08:51:33 -0800 (PST), 88888 Dihedral
    >> ><> wrote:
    >> >
    >> >>On Wednesday, December 7, 2011 8:22:56 PM UTC+8, curixinfotech wrote:
    >> >>> hi
    >> >>> my Q is on the c language tell me now why c has pointers.
    >> >>> parshant
    >> >>>
    >> >>>
    >> >>> --
    >> >>> curixinfotech
    >> >>> ------------------------------------------------------------------------
    >> >>> curixinfotech's Profile: http://forums.yourdomain.com.au/member.php?userid=134
    >> >>> View this thread: http://forums.yourdomain.com.au/showthread.php?t=3319
    >> >>
    >> >>OK, I'll explain how to use a pointer in C without any knowledge in the
    >> >>hardware or assembly here.
    >> >>//
    >> >>int i;
    >> >>int a[3]={ 1,2,3} ; // an array of 3 integers
    >> >>int* ptr1; // Note the star should be right after int, not initialize
    >> >>int* ptr2; // not initialized
    >> >>
    >> >>ptr1=a; // Read this as to make ptr1 to be an alias of a.
    >> >
    >> >If that were true, the sizeof(a) and sizeof(ptr1) would be equal
    >> >which, in the general case, they are not. ptr1 is simply a pointer
    >> >that points to the start of a. Even though they share some
    >> >similarities in the language syntax, a pointer is a completely
    >> >different type than an array. Calling one an alias of the other just
    >> >breeds unnecessary confusion.
    >> >

    >>
    >> I agree.
    >>
    >> I have trouble understanding the constant confusion between arrays and
    >> pointers. Way back when (and we are talking many moons ago <g>) when I
    >> started out in C my mentor explained it very simply in these terms in
    >> the first couple of days.
    >>
    >> 1) There is a difference between declarations and definitions.
    >> Remember which you are dealing with and when.
    >> 2) A pointer is a "variable", an array is a "constant"
    >> 3) The array name evaluates to the address of the first element in the
    >> array.
    >> 4) A pointer is a variable that holds the address of another variable
    >> or an array.
    >> 5) All pointers must be intialized before you use them.
    >> 6) Since an array name is an address it can be used as a pointer that
    >> is initialized to point to the first element in the array.
    >> 7) *variable means the contents of the variable.

    >
    > *variable is easy to be miss-understood
    >
    > *ptr_variable is different from ptr_variable
    >
    > *variable if used for non-pointer variables, the compiler
    >will say something, thus you are right in the general sense in C,
    >but not clear enough for novices
    >


    I disagree. (Naturally. <g>)

    This ...
    > *ptr_variable is different from ptr_variable


    is all about context.

    You only get an error or in trouble if you use *variable on a
    NON-Address - whether constant or 'variable'.

    I firmly believe, and several years of teaching C confirms for me,
    that it is when ones starts straying from the simple that confusion is
    introduced.

    -ralph
     
    ralph, Dec 18, 2011
    #10
  11. ralph <> writes:

    > On Sat, 17 Dec 2011 13:55:44 -0800, Keith Thompson <>
    > wrote:
    >
    >>ralph <> writes:
    >>[...]
    >>> I have trouble understanding the constant confusion between arrays and
    >>> pointers. Way back when (and we are talking many moons ago <g>) when I
    >>> started out in C my mentor explained it very simply in these terms in
    >>> the first couple of days.
    >>>
    >>> 1) There is a difference between declarations and definitions.
    >>> Remember which you are dealing with and when.
    >>> 2) A pointer is a "variable", an array is a "constant"

    >>
    >>That doesn't really make sense. An array variable is not a constant:
    >>
    >> int arr[10];
    >> arr[5] = 42;
    >>
    >>I suppose what it means is that an array name, when it appears in an
    >>expression (in most but not all context) decays to a pointer to the
    >>array's first element, and that pointer value cannot be modified. But I
    >>think that saying an array is a constant just reinforces the confusion
    >>between arrays and pointers.
    >>

    >
    > I disagree.
    >
    > Once the beginner gets it through his head that you can never do an
    > assignment to 'arr' you resolve a ton of the questions we get around
    > here. That as close to the definition of a "constant" as you can get.


    I'd say that "unchanging" or "immutable" were closer definitions, and
    arrays can be changed.

    What you call a constant, I'd call a value, and I'd explain that
    array-valued expressions are (usually) converted automatically to
    pointer values.

    Most people learning programming quickly get the idea of variables and
    values. Variables can be assigned to, but values can't. This avoids
    calling arrays "constant". It's also a start towards some more
    technical matters such as why

    int x;
    x = 0;

    is ok, but

    (int)x = 0;

    is not.

    >>> 3) The array name evaluates to the address of the first element in the
    >>> array.

    >>
    >>This applies to any expression of array type, not just the name of a
    >>declared array object. But it doesn't apply in all contexts.
    >>Specifically, an expression of array type is converted to a pointer to
    >>the array object's first element *unless* it's:
    >>
    >> The operand of a unary "sizeof" operator (sizeof arr gives you the
    >> same of the array, not of a pointer);
    >>
    >> The operand of a unary "&" operator (&arr gives you the address of
    >> the array object; it's the same memory location as the address of
    >> its first element, but it's of a different type);
    >>
    >> A string literal in an initializer used to initialize an array
    >> object. In
    >> char arr[6] = "hello";
    >> the *value* of "hello" is copied into arr.
    >>

    >
    > Yep. But what's the big deal.
    >
    > And of course I disagree that it actually matters to the beginner that
    > the address is of a "different type". Semantically and syntactically
    > it comes out the same. Plenty of time to get into vague language
    > later.


    I agree about putting this off, but 'arr' and '&arr' are not the same
    semantically. If they were,

    arr + 1

    and

    &arr + 1

    would have the same value but they don't. (I'm using arr as defined
    above.)

    <snip>
    >>In most contexts; see above. It would be clearer to say that an array
    >>name *decays to* an address (or pointer value). And I wouldn't use the
    >>word "initialized".

    >
    > I would. And again what does 'decay' meant to the beginner?
    > In code the name "arr" is changed to, or evaluates to, the address of
    > the first element.


    I'd just say "converted". C has lots of automatic conversions and,
    sooner or later, these need to be explains. The array to pointer
    conversion fits into this general pattern.

    <snip>
    >>> 9) The array operator evaluates to a storage map equation, eg.
    >>> type ar := *(a + (i * sizeof(type))

    >>
    >>I'm not sure what syntax you're using. What does "type" mean here? And
    >>C pointer arithmetic is already scaled by the size of the pointed-to
    >>type.
    >>
    >>arr is by definition equivalent to *(arr + i).

    >
    > Think about it.
    >
    > You say that now, but you come back later in other response to point
    > out "sizes". That "already scaled" is because the compiler knows the
    > type, and he knows the type because you declared it.


    It's not easy to explain the lower-level arithmetic without reference to
    some particular machine. For example, on a machine with, say, byte and
    word addresses, you can't describe it as you have done. By all means,
    take a simple architecture and explain what a[0] means on one particular
    system using addresses and size calculations, but you will also have to
    explain, eventually, that arr is, by definition, *(arr + i).

    <snip>
    --
    Ben.
     
    Ben Bacarisse, Dec 18, 2011
    #11
  12. 88888 Dihedral

    ralph Guest

    On Sun, 18 Dec 2011 01:26:59 +0000, Ben Bacarisse
    <> wrote:

    >ralph <> writes:
    >
    >> On Sat, 17 Dec 2011 13:55:44 -0800, Keith Thompson <>
    >> wrote:
    >>
    >>>ralph <> writes:
    >>>[...]
    >>>> I have trouble understanding the constant confusion between arrays and
    >>>> pointers. Way back when (and we are talking many moons ago <g>) when I
    >>>> started out in C my mentor explained it very simply in these terms in
    >>>> the first couple of days.
    >>>>
    >>>> 1) There is a difference between declarations and definitions.
    >>>> Remember which you are dealing with and when.
    >>>> 2) A pointer is a "variable", an array is a "constant"
    >>>
    >>>That doesn't really make sense. An array variable is not a constant:
    >>>
    >>> int arr[10];
    >>> arr[5] = 42;
    >>>
    >>>I suppose what it means is that an array name, when it appears in an
    >>>expression (in most but not all context) decays to a pointer to the
    >>>array's first element, and that pointer value cannot be modified. But I
    >>>think that saying an array is a constant just reinforces the confusion
    >>>between arrays and pointers.
    >>>

    >>
    >> I disagree.
    >>
    >> Once the beginner gets it through his head that you can never do an
    >> assignment to 'arr' you resolve a ton of the questions we get around
    >> here. That as close to the definition of a "constant" as you can get.

    >
    >I'd say that "unchanging" or "immutable" were closer definitions, and
    >arrays can be changed.
    >
    >What you call a constant, I'd call a value, and I'd explain that
    >array-valued expressions are (usually) converted automatically to
    >pointer values.
    >
    >Most people learning programming quickly get the idea of variables and
    >values. Variables can be assigned to, but values can't. This avoids
    >calling arrays "constant". It's also a start towards some more
    >technical matters such as why
    >
    > int x;
    > x = 0;
    >
    >is ok, but
    >
    > (int)x = 0;
    >
    >is not.
    >
    >>>> 3) The array name evaluates to the address of the first element in the
    >>>> array.
    >>>
    >>>This applies to any expression of array type, not just the name of a
    >>>declared array object. But it doesn't apply in all contexts.
    >>>Specifically, an expression of array type is converted to a pointer to
    >>>the array object's first element *unless* it's:
    >>>
    >>> The operand of a unary "sizeof" operator (sizeof arr gives you the
    >>> same of the array, not of a pointer);
    >>>
    >>> The operand of a unary "&" operator (&arr gives you the address of
    >>> the array object; it's the same memory location as the address of
    >>> its first element, but it's of a different type);
    >>>
    >>> A string literal in an initializer used to initialize an array
    >>> object. In
    >>> char arr[6] = "hello";
    >>> the *value* of "hello" is copied into arr.
    >>>

    >>
    >> Yep. But what's the big deal.
    >>
    >> And of course I disagree that it actually matters to the beginner that
    >> the address is of a "different type". Semantically and syntactically
    >> it comes out the same. Plenty of time to get into vague language
    >> later.

    >
    >I agree about putting this off, but 'arr' and '&arr' are not the same
    >semantically. If they were,
    >
    > arr + 1
    >
    >and
    >
    > &arr + 1
    >
    >would have the same value but they don't. (I'm using arr as defined
    >above.)
    >
    ><snip>
    >>>In most contexts; see above. It would be clearer to say that an array
    >>>name *decays to* an address (or pointer value). And I wouldn't use the
    >>>word "initialized".

    >>
    >> I would. And again what does 'decay' meant to the beginner?
    >> In code the name "arr" is changed to, or evaluates to, the address of
    >> the first element.

    >
    >I'd just say "converted". C has lots of automatic conversions and,
    >sooner or later, these need to be explains. The array to pointer
    >conversion fits into this general pattern.
    >
    ><snip>
    >>>> 9) The array operator evaluates to a storage map equation, eg.
    >>>> type ar := *(a + (i * sizeof(type))
    >>>
    >>>I'm not sure what syntax you're using. What does "type" mean here? And
    >>>C pointer arithmetic is already scaled by the size of the pointed-to
    >>>type.
    >>>
    >>>arr is by definition equivalent to *(arr + i).

    >>
    >> Think about it.
    >>
    >> You say that now, but you come back later in other response to point
    >> out "sizes". That "already scaled" is because the compiler knows the
    >> type, and he knows the type because you declared it.

    >
    >It's not easy to explain the lower-level arithmetic without reference to
    >some particular machine. For example, on a machine with, say, byte and
    >word addresses, you can't describe it as you have done. By all means,
    >take a simple architecture and explain what a[0] means on one particular
    >system using addresses and size calculations, but you will also have to
    >explain, eventually, that arr is, by definition, *(arr + i).
    >


    Sure it is because it ain't *(arr + i). It is ...

    *(arr + ( i * sizeof(datatype)))

    So for int arr[10];
    arr[5] is *(arr + (5 * sizeof(int)))
    byte arr[10];
    arr[5] is *(arr + (5 * sizeof(byte)))

    You don't care what platform you are using because the sizeof takes
    care of it. sizeof and size of datatypes are defined for each compiler
    (which is platform specific by default). That's how pointer arithmetic
    works. That's how the C language achieves platform independence and
    compilers can be implemented for any specific architecture.
     
    ralph, Dec 18, 2011
    #12
  13. On Sunday, December 18, 2011 9:26:59 AM UTC+8, Ben Bacarisse wrote:
    > ralph <> writes:
    >
    > > On Sat, 17 Dec 2011 13:55:44 -0800, Keith Thompson <>
    > > wrote:
    > >
    > >>ralph <> writes:
    > >>[...]
    > >>> I have trouble understanding the constant confusion between arrays and
    > >>> pointers. Way back when (and we are talking many moons ago <g>) when I
    > >>> started out in C my mentor explained it very simply in these terms in
    > >>> the first couple of days.
    > >>>
    > >>> 1) There is a difference between declarations and definitions.
    > >>> Remember which you are dealing with and when.
    > >>> 2) A pointer is a "variable", an array is a "constant"
    > >>
    > >>That doesn't really make sense. An array variable is not a constant:
    > >>
    > >> int arr[10];
    > >> arr[5] = 42;
    > >>
    > >>I suppose what it means is that an array name, when it appears in an
    > >>expression (in most but not all context) decays to a pointer to the
    > >>array's first element, and that pointer value cannot be modified. But I
    > >>think that saying an array is a constant just reinforces the confusion
    > >>between arrays and pointers.
    > >>

    > >
    > > I disagree.
    > >
    > > Once the beginner gets it through his head that you can never do an
    > > assignment to 'arr' you resolve a ton of the questions we get around
    > > here. That as close to the definition of a "constant" as you can get.

    >
    > I'd say that "unchanging" or "immutable" were closer definitions, and
    > arrays can be changed.
    >
    > What you call a constant, I'd call a value, and I'd explain that
    > array-valued expressions are (usually) converted automatically to
    > pointer values.
    >
    > Most people learning programming quickly get the idea of variables and
    > values. Variables can be assigned to, but values can't. This avoids
    > calling arrays "constant". It's also a start towards some more
    > technical matters such as why
    >
    > int x;
    > x = 0;
    >
    > is ok, but
    >
    > (int)x = 0;
    >
    > is not.
    >
    > >>> 3) The array name evaluates to the address of the first element in the
    > >>> array.
    > >>
    > >>This applies to any expression of array type, not just the name of a
    > >>declared array object. But it doesn't apply in all contexts.
    > >>Specifically, an expression of array type is converted to a pointer to
    > >>the array object's first element *unless* it's:
    > >>
    > >> The operand of a unary "sizeof" operator (sizeof arr gives you the
    > >> same of the array, not of a pointer);
    > >>
    > >> The operand of a unary "&" operator (&arr gives you the address of
    > >> the array object; it's the same memory location as the address of
    > >> its first element, but it's of a different type);
    > >>
    > >> A string literal in an initializer used to initialize an array
    > >> object. In
    > >> char arr[6] = "hello";
    > >> the *value* of "hello" is copied into arr.
    > >>

    > >
    > > Yep. But what's the big deal.
    > >
    > > And of course I disagree that it actually matters to the beginner that
    > > the address is of a "different type". Semantically and syntactically
    > > it comes out the same. Plenty of time to get into vague language
    > > later.

    >
    > I agree about putting this off, but 'arr' and '&arr' are not the same
    > semantically. If they were,
    >
    > arr + 1
    >
    > and
    >
    > &arr + 1
    >
    > would have the same value but they don't. (I'm using arr as defined
    > above.)
    >
    > <snip>
    > >>In most contexts; see above. It would be clearer to say that an array
    > >>name *decays to* an address (or pointer value). And I wouldn't use the
    > >>word "initialized".

    > >
    > > I would. And again what does 'decay' meant to the beginner?
    > > In code the name "arr" is changed to, or evaluates to, the address of
    > > the first element.

    >
    > I'd just say "converted". C has lots of automatic conversions and,
    > sooner or later, these need to be explains. The array to pointer
    > conversion fits into this general pattern.
    >
    > <snip>
    > >>> 9) The array operator evaluates to a storage map equation, eg.
    > >>> type ar := *(a + (i * sizeof(type))
    > >>
    > >>I'm not sure what syntax you're using. What does "type" mean here? And
    > >>C pointer arithmetic is already scaled by the size of the pointed-to
    > >>type.
    > >>
    > >>arr is by definition equivalent to *(arr + i).

    > >
    > > Think about it.
    > >
    > > You say that now, but you come back later in other response to point
    > > out "sizes". That "already scaled" is because the compiler knows the
    > > type, and he knows the type because you declared it.

    >
    > It's not easy to explain the lower-level arithmetic without reference to
    > some particular machine. For example, on a machine with, say, byte and
    > word addresses, you can't describe it as you have done. By all means,
    > take a simple architecture and explain what a[0] means on one particular
    > system using addresses and size calculations, but you will also have to
    > explain, eventually, that arr is, by definition, *(arr + i).
    >
    > <snip>
    > --
    > Ben.



    In C there is no boundary checking in the index of an array in a read
    or write operation to the array.
     
    88888 Dihedral, Dec 18, 2011
    #13
  14. 88888 Dihedral

    Seebs Guest

    On 2011-12-18, 88888 Dihedral <> wrote:
    > In C there is no boundary checking in the index of an array in a read
    > or write operation to the array.


    This is a vast oversimplification. It's undefined behavior to access
    outside the object. Whether or not there is bounds checking is up to the
    implementation; some real implementations have done it.

    -s
    --
    Copyright 2011, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    I am not speaking for my employer, although they do rent some of my opinions.
     
    Seebs, Dec 18, 2011
    #14
  15. On Sunday, December 18, 2011 12:56:07 PM UTC+8, Seebs wrote:
    > On 2011-12-18, 88888 Dihedral <> wrote:
    > > In C there is no boundary checking in the index of an array in a read
    > > or write operation to the array.

    >
    > This is a vast oversimplification. It's undefined behavior to access
    > outside the object. Whether or not there is bounds checking is up to the
    > implementation; some real implementations have done it.
    >
    > -s
    > --

    In the language design C is easy to be mixed with assembly.

    If one needs boundary checking of an array, other higher level programming
    languages are better options.
     
    88888 Dihedral, Dec 18, 2011
    #15
  16. 88888 Dihedral

    Seebs Guest

    On 2011-12-18, 88888 Dihedral <> wrote:
    > In the language design C is easy to be mixed with assembly.


    That, too, is an oversimplification.

    > If one needs boundary checking of an array, other higher level programming
    > languages are better options.


    Could be, but the fact is, there are bounds-checking implementations. The
    claim that there's no bounds-checking in C is not really generally true.

    -s
    --
    Copyright 2011, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    I am not speaking for my employer, although they do rent some of my opinions.
     
    Seebs, Dec 18, 2011
    #16
  17. 88888 Dihedral

    Philip Lantz Guest

    On Sat, 17 Dec 2011, ralph wrote:
    > On Sun, 18 Dec 2011, Ben Bacarisse wrote:
    >> ... arr is, by definition, *(arr + i).
    >>

    >
    > ... it ain't *(arr + i). It is ...
    >
    > *(arr + ( i * sizeof(datatype)))
    >
    > So for int arr[10];
    > arr[5] is *(arr + (5 * sizeof(int)))
    > byte arr[10];
    > arr[5] is *(arr + (5 * sizeof(byte)))
    >
    > You don't care what platform you are using because the sizeof takes
    > care of it. sizeof and size of datatypes are defined for each compiler
    > (which is platform specific by default). That's how pointer arithmetic
    > works. That's how the C language achieves platform independence and
    > compilers can be implemented for any specific architecture.



    Ralph, could you do me a favor, please, and run the following program,
    and let us know what its output is for you?


    #include <stdio.h>

    int main(void)
    {
    int arr[20] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
    11,12,13,14,15,16,17,18,19,20 };

    printf("%d\n", arr[2]);
    printf("%d\n", *(arr + (2 * sizeof(int))));
    printf("%d\n", *(arr + 2));

    return 0;
    }


    Thanks.

    Philip

    P.S. I get:
    3
    17
    3
     
    Philip Lantz, Dec 18, 2011
    #17
  18. ralph <> writes:

    > On Sun, 18 Dec 2011 01:26:59 +0000, Ben Bacarisse
    > <> wrote:
    >
    >>ralph <> writes:
    >>
    >>> On Sat, 17 Dec 2011 13:55:44 -0800, Keith Thompson <>

    <snip>
    >>>>arr is by definition equivalent to *(arr + i).
    >>>
    >>> Think about it.
    >>>
    >>> You say that now, but you come back later in other response to point
    >>> out "sizes". That "already scaled" is because the compiler knows the
    >>> type, and he knows the type because you declared it.

    >>
    >>It's not easy to explain the lower-level arithmetic without reference to
    >>some particular machine. For example, on a machine with, say, byte and
    >>word addresses, you can't describe it as you have done. By all means,
    >>take a simple architecture and explain what a[0] means on one particular
    >>system using addresses and size calculations, but you will also have to
    >>explain, eventually, that arr is, by definition, *(arr + i).
    >>

    >
    > Sure it is because it ain't *(arr + i). It is ...
    >
    > *(arr + ( i * sizeof(datatype)))
    >
    > So for int arr[10];
    > arr[5] is *(arr + (5 * sizeof(int)))
    > byte arr[10];
    > arr[5] is *(arr + (5 * sizeof(byte)))


    That's wrong, if what you are writing there are C expressions. arr[5]
    is defined to be the same as *(arr + 5). Can you clear this up? Do you
    agree that

    arr[5] == *(arr + 5)

    and

    &arr[5] == arr + 5

    are C expressions that always evaluate to 1? (Let's assume arr[5] has
    been assigned some non-trap representation!)

    You may be trying to explain arr[5] using a confusingly C-like
    notation. If so, that's a very confusing thing to do. If I wanted to
    explain what a compiler has to do, I'd use some entirely un-C-like
    notation to avoid any possible misunderstanding.

    > You don't care what platform you are using because the sizeof takes
    > care of it. sizeof and size of datatypes are defined for each compiler
    > (which is platform specific by default). That's how pointer arithmetic
    > works.


    Not always. It's not sizeof that takes care of it, it's the compiler.
    A C compiler must ensure that arr and *(arr + i) have the same
    meaning. To do that, it must do something with machine addresses that
    involves the size of the array elements, but it's not always as simple
    as you suggest. For example, I've used a machine where sizeof(int) is 2
    but arr[5] (where arr is your int array from above) is implemented by
    adding 5 (yes, 5, not 2*5) to the address of the array's first element.

    > That's how the C language achieves platform independence and
    > compilers can be implemented for any specific architecture.


    It's more subtle than that. The address arithmetic is related to the
    size but it need not be exactly as you describe.

    --
    Ben.
     
    Ben Bacarisse, Dec 18, 2011
    #18
  19. On Sunday, December 18, 2011 1:42:59 PM UTC+8, Seebs wrote:
    > On 2011-12-18, 88888 Dihedral <> wrote:
    > > In the language design C is easy to be mixed with assembly.

    >
    > That, too, is an oversimplification.
    >
    > > If one needs boundary checking of an array, other higher level programming
    > > languages are better options.

    >
    > Could be, but the fact is, there are bounds-checking implementations. The
    > claim that there's no bounds-checking in C is not really generally true.
    >
    > -s


    If there is any boundary checking on a machine,
    what does that mean in the execution speed?

    Happy programming?
     
    88888 Dihedral, Dec 18, 2011
    #19
  20. 88888 Dihedral

    James Kuyper Guest

    On 12/17/2011 11:34 PM, ralph wrote:
    ....
    > So for int arr[10];
    > arr[5] is *(arr + (5 * sizeof(int)))


    Other people have told you that this is wrong, and have cited the
    relevant parts of the standard to prove it. If your compiler implements
    a as meaning anything other than *(a+i), it's not a conforming
    implementation of C (or C++, or any of several other C-like languages).

    However, a couple of casts would make it correct:

    arr[5] == *(int*)((char*)arr + (5 * sizeof(int)));

    When you understand precisely why the casts make a difference, you'll
    have a much better understanding of C arrays and pointers than you
    currently appear to have.

    > byte arr[10];
    > arr[5] is *(arr + (5 * sizeof(byte)))


    You haven't provided a typedef for 'byte', but is seems likely, given
    the name, that sizeof(byte) == 1. If that's true, than so is your
    statement above. Otherwise, it's false.
    --
    James Kuyper
     
    James Kuyper, Dec 18, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    935
    Mark Rae
    Dec 21, 2006
  2. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,129
    Smokey Grindel
    Dec 2, 2006
  3. cerr

    pointers, pointers, pointers...

    cerr, Apr 7, 2011, in forum: C Programming
    Replies:
    12
    Views:
    714
  4. Keith Thompson

    Re: Why C has Pointers.

    Keith Thompson, Dec 7, 2011, in forum: C Programming
    Replies:
    5
    Views:
    273
    James Kuyper
    Dec 8, 2011
  5. ArifulHossain tuhin

    Why pointers to pointers used

    ArifulHossain tuhin, Feb 28, 2012, in forum: C Programming
    Replies:
    16
    Views:
    493
    Stephen Sprunk
    Mar 1, 2012
Loading...

Share This Page