strings Vs. Char pointers

Hello,
I wanna illustrate the difference between a char array (a string that is) and a pointer to char using a simple function which say capitalizes all the letters of a given string.

To that affect I have written a simple code which (hopefully) should be doing just that. I have a function which does the checkin g and the capitalizing part. The function accepts a char pointer as an argument so I pass it a char pointer once and a char array the other time.

So I hope that the former one should give me a seg fault as i am trying to access and write back to a memory element which does not belong to the function (is it a scope issue or what??...im bedazled as of now). And yeah it does flag a seg fault for the former case.

However when I pass the array (using the name of the array which is also a char pointer) it still flags the seg fault error!!!..why is that..

heres the code:

Code:

---

#include <stdio.h>
#include <ctype.h>

void set2caps(char *);//func prototype for capitalizing letters of string

int main()

{
    char *str = "string for pointer";
 //  char str1[] = "string for array";

    set2caps(str);
    set2caps(str1);

    puts("strings displayed in caps\n");

  //  printf("str in caps is &#37;s\n",str);
    printf("str1 in caps is %s\n",str);

    return 0;
}

void set2caps(char *str_hld)

{
    unsigned int chr_cnt = 0;
    char temp;

    while(str_hld[chr_cnt]) {
        if (!isupper(str_hld[chr_cnt]))
            temp = toupper(str_hld[chr_cnt]);
        str_hld[chr_cnt] = temp;
        chr_cnt++;
    }
}

---

Code:

---

char *str = "string for pointer";

---

...is actually:

Code:

---

const char *str = "string for pointer";

---

Because the memory in which the string is stored is read-only.

I also don't think you should try to prove that char* is not an array and char[] is, because technically, they are almost the same. I see both are strings. I see arrays as pointers due to their underlying nature.

Code:

---

set2caps(str1);

---

Works just fine.

Now, if you do like this:

Code:

---

const char str2[] = "string for pointer";
char* str = malloc( sizeof(str2) );
strcpy(str, str2);
set2caps(str);

---

It will work fine, you'll see.

Both strings are pointing to literal string constants. Modifying them will yield unexpected results. At best it will blow up; at worst it will appear to do what you wanted.

well....
they are not the same if you care about the specifics.

A char pointer is a variable. It can be the lvalue of an expression while the name of an array is a constant. So it cannot be the lvalue of an expression as it is a constant pointer.

I actually asked a wrong question as the program does work fine for the str1 character string..which I would change in the question now...

However my main question is about the scope...what about the scope...

Quote:

---

Originally Posted by aijazbaig1

well....
they are not the same if you care about the specifics.

A char pointer is a variable. It can be the lvalue of an expression while the name of an array is a constant. So it cannot be the lvalue of an expression as it is a constant pointer.

---

Well, see, that's because the array is a special syntax for pointers. You must specify the size to allocate, so therefore you use a special syntax. The compiler knows that it's more than one elements and thus won't allow you to assign something to it if it isn't the same size.
That's how I see it. There was a discussion about how arrays are pointers just a while ago.

Quote:

---

However my main question is about the scope...what about the scope...

---

The scope has nothing to do with it. Str can be modified if you malloc the memory and copy the string inside. The reason it didn't work was due to the read-only memory.
So long as the original buffer doesn't go out of scope (which can never happen in a synchronous call), the buffer will remain valid and can be changed and manipulated however much you want within the function, and any other functions that has a pointer to it.

Quote:

---

I wanna illustrate the difference between a char array (a string that is) and a pointer to char

---

Perhaps this might help (the code is C99, the concept is the same in C89):

Code:

---

#include <stdio.h>

static void print_object(const void *p, size_t s)
{
  printf("Object %p:\n", p);
  for(size_t i = 0; i < s; i++) printf("%hhu\n", ((unsigned char*)p)[i]);
}

int main(void)
{
  char string1[] = "this is a string";
  const char *string2 = "this is a string";

  print_object(&string1, sizeof string1);
  print_object(&string2, sizeof string2);

  return 0;
}

---

Maybe just printing out the result of sizeof on each object is enough to show the difference, too. I guess it depends on how convincing you're trying to be.

I don't understand what you're trying to accomplish through this whole arrays are different that pointers?
Many treat arrays as pointers and rightly so, as they basically the same thing.

Quote:

---

The scope has nothing to do with it. Str can be modified if you malloc the memory and copy the string inside. The reason it didn't work was due to the read-only memory.
So long as the original buffer doesn't go out of scope (which can never happen in a synchronous call), the buffer will remain valid and can be changed and manipulated however much you want within the function, and any other functions that has a pointer to it.

---

By mallocing the memory and then copying the string do you mean I should first allocate space for the string and the pass the memory head as a pointer to the function right?

What exactly do you mean by the buffer not going out of the scope of the function?...like when I pass str1 to this function I do not get a seg fault. However it looks like the contents of the memory have remained unchanged as the string is exactly like before without any capitalization.

And when I try to pass str to the function I get a seg fault right away...

Whew ..this can get a bit confusing some times...:|

Well... Arrays are different than pointers, and the difference can come into play. As my example alluded to, applying & to a pointer to char yields something different than when it's applied to an array of char. A more common--from what I've seen--misconception is that an array of array (i.e. a 2d array) is the same thing as a pointer to pointer. I imagine there have been posts here where a person is confused as to why:

Code:

---

int f(int **a);
int a[5][5];
f(a);

---

doesn't work, for example.

There's no question that pointers and arrays are intimately connected, and that for the most part an array can be treated as a pointer to its first element. However, there is a difference, and it behooves a programmer to know what the difference is so it won't bite him.

OK, so let me demonstrate:

Code:

---

int main()
{
        char* mystr = "My string";
        foo(mystr); /* Will segfault because mystr is read-only */
        char* mystr2 = malloc(sizeof("My string") + 1);
        strcpy(mystr2, "My string");
        foo(mystr2); /* Will work because you allocated memory you can read/write to */
        char mystr3[] = "My string";
        foo(mystr3); /* Works because it's read/write memory allocated on the stack */
        return 0;
}

void foo(char* pStr)
{
        pStr[0] = toupper(pStr[0]);
}

---

This shows the difference between all 3 methods.
Scope demonstration:

Code:

---

int main()
{
        char* pStr = foo(); /* Doesn't work! */
        char mystr[] = "my string";
        foo2(mystr); /* foo2 can do whatever it wants to mystr because it will go out of scope once main ends */
}

char* foo()
{
        char mystr[] = "my string";
        mystr[0] = toupper(mystr[0]); /* Works because mystr exists in this function */
        return mystr; /* Won't work because mystr will go out of scope */
}

void foo2(char* pStr)
{
        pStr[0] = toupper(pStr[0]);
}

---

Quote:

---

Originally Posted by cas

Well... Arrays are different than pointers, and the difference can come into play. As my example alluded to, applying & to a pointer to char yields something different than when it's applied to an array of char. A more common--from what I've seen--misconception is that an array of array (i.e. a 2d array) is the same thing as a pointer to pointer. I imagine there have been posts here where a person is confused as to why:

Code:

---

int f(int **a);
int a[5][5];
f(a);

---

doesn't work, for example.

There's no question that pointers and arrays are intimately connected, and that for the most part an array can be treated as a pointer to its first element. However, there is a difference, and it behooves a programmer to know what the difference is so it won't bite him.

---

I'm assuming that the standard wants the compiler to have some kind of knowledge about what type is passed. But it doesn't really matter because even if you use such syntax, it's still used as a pointer, hence it is a pointer and not an array. You can't get the size of the array, you can't see the contents of the array because it's a pointer.

Quote:

---

Originally Posted by Elysia

I'm assuming that the standard wants the compiler to have some kind of knowledge about what type is passed. But it doesn't really matter because even if you use such syntax, it's still used as a pointer, hence it is a pointer and not an array. You can't get the size of the array, you can't see the contents of the array because it's a pointer.

---

I'm sorry, but I'm not sure what you're saying.

The snippet I posted is not valid C: it requires a diagnostic. It also, I believe, illustrates that pointers and arrays are not the same thing and that the difference is not just some abstract concept. Trying to pass a 2d array to a function that expects a pointer to pointer is indeed something that newbies try.

While it is important to know how arrays and pointers are similar, I feel that knowing the difference is just as important.

OK, so we know you can't just pass a 2D array as array**. That won't work.
However, even so, you are accessing the array just like a 2D-pointer. That, in my book, makes it an array.
I don't know why the standard requires you to specify the inner/outmost dimension, whichever it is, when passing 2D-arrays. I just don't. But it doesn't change the fact that after the function that takes the arguments acquires that variable, it's just like a pointer. Again.

So, arrays are just pointers with special syntax. Makes sense if you think about it.
I don't think you should teach arrays and pointers as different things. I believe in that teaching that arrays are pointers with special syntax. Because if you know how to use pointers, then you also know how arrays works.

Quote:

---

Originally Posted by Elysia

However, even so, you are accessing the array just like a 2D-pointer.

---

That's not really true: If a is defined as int a[10][10], a does not get passed into a function as a pointer to pointer, but a pointer to an array. (Array decay does not happen recursively, in other words.)

Quote:

---

Originally Posted by Elysia

I don't know why the standard requires you to specify the inner/outmost dimension, whichever it is, when passing 2D-arrays.

---

I believe you, as breathtaking an admission as that is. Think for a minute: If you had a[10][10], so you needed to store 100 integers in memory somewhere, how would you arrange it so you could find a[0][1] and a[1][0] easily?

Right: you'd store things in rows, so that all the a[0][m]'s appear first, then all the a[1][m]'s next, and so on. In fact, you would know that the offset for a[x][y] would be 10*x+y (times the size of an int, of course). Now, if all you had was a bare pointer to the first element, how would you find a[1][0]?

Makes sense. I haven't used many 2D arrays. Believe it or not. The only times I have, it's been local. Thanks to CString and std::vector for that! :D
But it doesn't change that the array is basically a pointer. The compiler just needs to know how to calculate the offset. You could see an array as a tool for helping a programmer use a contiguous memory block with pointers.
It will still just use a pointer and calculate the offset.

Quote:

---

Originally Posted by tabstop

Now, if all you had was a bare pointer to the first element, how would you find a[1][0]?

---

The same way that you would know how to find a[5] in a 1D array. You'd need to pass the size of the array to the function as well as the array. So if you pass a 2D array, I'm not sure why a pointer-to-pointer doesn't work since you could just pass 2 sizes along with the pointer?

Quote:

---

But it doesn't really matter because even if you use such syntax, it's still used as a pointer, hence it is a pointer and not an array. You can't get the size of the array, you can't see the contents of the array because it's a pointer.

---

That's a fallacy: in such a (corrected) function, one has a pointer to the first array in an array of arrays.

If we use sizeof as the determinant, then within the caller, we have an array of arrays, not a pointer to the first array of an array of arrays.

Quote:

---

But it doesn't change that the array is basically a pointer. The compiler just needs to know how to calculate the offset. You could see an array as a tool for helping a programmer use a contiguous memory block with pointers.
It will still just use a pointer and calculate the offset.

---

I would sum that up as: an array is basically a pointer, but an array is not a pointer.

For the purposes of understanding how it all actually works, we can say that an array is basically a pointer. When it comes to interpreting the syntax with respect to the language, an array is not a pointer.

Quote:

---

Originally Posted by cpjust

The same way that you would know how to find a[5] in a 1D array. You'd need to pass the size of the array to the function as well as the array. So if you pass a 2D array, I'm not sure why a pointer-to-pointer doesn't work since you could just pass 2 sizes along with the pointer?

---

Which is why you need to pass a 2-D array as a[][10], just so that you can pass the size along with the pointer. If all you have is a pointer (which is all you get with int **), you don't have the size of the array there.

The point I'm (failing to) make here is that int ** and int[][10] are not the same type at all, since the first is "just a" pointer, while the second is a pointer plus enough information to make actually using the thing work.

Hmm, I've never thought of this stuff the way you guys(cas especially) are putting it.

So, if I'm getting this right:

If you take the address of a char * variable initialized as a string literal, you'd get the address of the pointer variable, but if you'd take the address of an array, you'd just get the address of the first element, which in fact means that there is no real variable 'storing' the address, so to speak?

And if my thoughts are on the right track, does someone care to explain how the sizeof macro works on arrays, when it doesn't on pointers?

I do understand the difference between the two more thoroughly now, but I still can't think of a way how the macro can work?

Quote:

---

Originally Posted by IceDane

Hmm, I've never thought of this stuff the way you guys(cas especially) are putting it.

So, if I'm getting this right:

If you take the address of a char * variable initialized as a string literal, you'd get the address of the pointer variable, but if you'd take the address of an array, you'd just get the address of the first element, which in fact means that there is no real variable 'storing' the address, so to speak?

And if my thoughts are on the right track, does someone care to explain how the sizeof macro works on arrays, when it doesn't on pointers?

I do understand the difference between the two more thoroughly now, but I still can't think of a way how the macro can work?

---

The first paragraph is basically right. If I declare int a[10][10], a (by itself) will generally decay to a pointer to first element, and &a must mean the address of (the start of) the array, so they'll give you the same value. I usually think of the variable a as storing the address and a[m][n] the actual data.

Sizeof is an operator that works on types; if you give it an expression, it is converted to its type first. So sizeof(int *) gives you the size of a pointer, sizeof(int[10]) gives you the size of a 10-element array of integers. Edit to add: And here's where the difference between a and &a comes in: with the declaration above, sizeof(a)==400 and sizeof(&a)==4 (at least on my machine, et cetera).

Quote:

---

If you take the address of a char * variable initialized as a string literal, you'd get the address of the pointer variable, but if you'd take the address of an array, you'd just get the address of the first element, which in fact means that there is no real variable 'storing' the address, so to speak?

---

Yes, that is correct. I suppose to be really correct you get the address of the array itself, which happens to be the address of the first element, too: they just have different types. But your thinking is right on. With an array, there is not a variable that holds an address. You can think of it like this:

Code:

---

char c = 's'; /* c holds the value 's' */
char a[] = "string"; /* a holds the values 's', 't', 'r', 'i', 'n', 'g', and 0 */
char *p = "string"; /* p holds an address */

---

The variable a is not unlike the variable c: it contains the data you're interested in. Variable p is different: it contains an address that tells you where to find the data you're interested in (assuming you're interested in the string!)

The confusion comes along when you actually try to use the variable a. In almost every case it is converted into a pointer to its first element (this is often referred to as decaying to a pointer). The array itself is really an array, but when you try to use it, C sneaks behind your back and gives you a pointer instead.

Quote:

---

And if my thoughts are on the right track, does someone care to explain how the sizeof macro works on arrays, when it doesn't on pointers?

---

Well, sizeof is an operator, it's not a macro. And it does "work" on both pointers and arrays. What sizeof does is tell you the size of the object (expression, actually, but that's not especially important here). So if you have an array of 10 char, that array is clearly 10 bytes long (a char being a byte). Your compiler can see your declaration so it can see just how big a particular array is. Thus when sizeof is applied to it, your compiler can easily yield the correct size, just like you can if you look at the declaration.

When it comes to pointers, sizeof can't tell you how large the memory area the pointer points to is. For one, the pointer might not be pointing anywhere: what should sizeof yield? Or it might point to 100 bytes, but only the first 5 contain a string. Should it yield 5 or 100? And so on. (Not to mention the fact that sizeof is evaluated at compile time, not runtime {except for C99's VLAs}).

But of course there is a perfectly reasonable value that sizeof can yield and that is the size of the pointer itself. C doesn't have a clue of how you're using a pointer; it's up to you to know what it points to, not the compiler. So sizeof works with pointers like it does any other type: the size of the object itself is given.

And if you think about it, this is useful: you know you need to know the size of an int if you want to create a dynamic "array" of ints with malloc(). The same goes for pointers (assume malloc() can't fail):

Code:

---

char **a;
a = malloc(10 * sizeof *a);
a[0] = "string 1";
a[1] = "string 2";
/* etc */

---

If you're interested in the size of an object pointed to, it's up to you to figure out what that means. Maybe use strlen(), if you're interested in a string length. Or if you're passing an array to a function, pass along the size, too (which you can calculate with sizeof, to bring this all back around again).

This is one of the more difficult parts of C to wrap one's head around and I'm afraid I'm just not too good at explaining it. But I hope I've at least not confused you more, if I haven't helped.

cas, is your example intended to be correct? Const-correctness aside, it seems to me that sizeof *a is not correct since at that point a does not point to anything (or points to garbage, if you prefer).

sizeof does not evaluate its argument. *a is a char *, and that's all that matters.

Quote:

---

sizeof does not evaluate its argument. *a is a char *, and that's all that matters.

---

Yeah, C99 confirms that, though with the caveat that the operand is evaluated if it is a variable length array type.

Here you go, undeniable proof that an array is just a pointer: :)

Code:

---

        char myarray[20] = { 'a', 'b', 'c' };
        printf("%c", *myarray);
        char myarray2[10][10] = { { 'a', 'b', 'c' } };
        printf("%c", **myarray2);

---

Believe it or not, it works. That just proves my theory that an array is just holding the address. Because the [] operator dereferences the pointer and adds an offset depending on what element you try to access.
Of course, a pointer to pointer ** can't be the same as a 2D-array simply because the compiler cannot know the offset to add to the pointer when dereferencing it. Thus it catches your simple little mistake trying to pass the array as a pointer to pointer **.

Quote:

---

Originally Posted by Elysia

Here you go, undeniable proof that an array is just a pointer: :)

Code:

---

        char myarray[20] = { 'a', 'b', 'c' };
        printf("%c", *myarray);
        char myarray2[10][10] = { { 'a', 'b', 'c' } };
        printf("%c", **myarray2);

---

Believe it or not, it works. That just proves my theory that an array is just holding the address. Because the [] operator dereferences the pointer and adds an offset depending on what element you try to access.
Of course, a pointer to pointer ** can't be the same as a 2D-array simply because the compiler cannot know the offset to add to the pointer when dereferencing it. Thus it catches your simple little mistake trying to pass the array as a pointer to pointer **.

---

Thanks for your answer above.

From reading the various answers, it seems to me that the reason why one can not pass a 2d-array as a ** is rather because it's not invalid as such, but merely to prevent coding mistakes. Like someone pointed out, if you'd pass the size along with it, it shouldn't be a problem as such.

But aye, your example shows that a 2D-array is indeed just a pointer that stores the address of the first 'unit' on the lowest level, but on a syntactical level, arrays and pointers to pointers are not the same. I believe this is what Laserlight was saying?

Actually with 2D arrays, they aren't the same as pointer-to-pointers.
Try this:

Code:

---

#include <stdio.h>

int f1( int a[3][3] )
{
        return a[1][1];
}

int f2( int* a[3] )
{
        return a[1][1];
}

int f3( int** a )
{
        return a[1][1];
}

int main()
{
        int a[3][3] = { {1,2,3}, {4,5,6}, {7,8,9} };

        printf( "a = %d", f1( a ) );
        printf( "a = %d", f2( (int**)a ) );        /* Boom! */
        printf( "a = %d", f3( (int**)a ) );        /* Boom! */

        return 0;
}

---

I think it's blowing up because when f2() & f3() try to dereference a they assume that the value stored in a[1] is a pointer, so they dereference the value of a[1] which isn't a valid address.

Problem with f2 is that it's an array of 3 pointers. You wanted a pointer to an array with 3 elements, right?
That would be int (*a)[3] or similar, wouldn't it?
And the problem with f3 is that the compiler has no knowing of how large each column is, so it can't calculate correct offset. Which is why we must use a special syntax with 2d-arrays in the first place.

Quote:

---

Originally Posted by cpjust

I think it's blowing up because when f2() & f3() try to dereference a they assume that the value stored in a[1] is a pointer...

---

But it is! I just proved that with my little sample.
The compiler just doesn't know the correct offset.

Quote:

---

I just proved that with my little sample.

---

What about sizeof?

Code:

---

int ** a;
sizeof(*a)

int a[3][3];
sizeof(*a);

---

Do you think they are the same as well?

Quote:

---

Originally Posted by vart

What about sizeof?

Code:

---

int ** a;
sizeof(*a)

int a[3][3];
sizeof(*a);

---

Do you think they are the same as well?

---

That won't even compile.

--
Mats

Quote:

---

That won't even compile.

---

I tested with:

Code:

---

#include <iostream>

int main()
{
        int ** a;
        std::cout << sizeof(*a) << std::endl;

        int b[3][3];
        std::cout << sizeof(*b) << std::endl;
}

---

It compiles as expected. If you mean to say that vart's code snippet is not compilable, then that is obvious.

An array is not a pointer. The reason arrays appear to be pointers is that in most expressions, C will convert an array into a pointer to its first element. This is apparently where the confusion comes in, and that's not surprising.

Now, if you want to make a statement along the lines of "Ignoring a couple of corner cases, an array is a pointer," then you at least have a leg to stand on; if a C program can't tell the difference (and it can, of course, but let's pretend that the & and sizeof operators don't exist and that arrays of arrays don't exist), then there'd be no real reason to draw a distinction.

And, generally speaking, you can get away with thinking that an array is a pointer; avoiding & and sizeof with arrays and avoiding multidimensional arrays is not a hard thing to do, I suppose, and in that case, as far as you care, arrays are pointers.

Perhaps I've missed a corner case or two, but that's OK: I'm not trying to convince anybody that arrays should be treated as pointers, merely explaining why or how they can. I think C programmers should know the difference, but if you can get away with thinking they're the same, well, who am I to stop you?

sizeof of a pointer will always return 4 on x86, and 8 on x64-64 I believe.
Point is, an array is a pointer, but an array requires special syntax to define how many elements you are allocating. And it's even trickier with 2D-arrays since the compiler must know the number of columns in the dimension or it can't calculate a proper offset. In the end, it's all a pointer and an offset. The compiler just needs a little help when you define a 2D-array since it couldn't calculate the proper offset otherwise.

The only exception to arrays not being a pointer is that you can do sizeof the array and it will return the array size, but only in the local function where it's defined. Because in that function, the compiler can clearly see that it defined as a pointer to storage of n elements. But when passing the array or pointer to a function, that information is now lost to the compiler.

Quote:

---

Point is, an array is a pointer, but an array requires special syntax to define how many elements you are allocating.

---

To put things in a Standard perspective with C99:

Quote:

---

Originally Posted by ISO/IEC 9899:1999 Section 6.2.5

Any number of derived types can be constructed from the object, function, and incomplete types, as follows:

• An array type describes a contiguously allocated nonempty set of objects with a particular member object type, called the element type. Array types are characterized by their element type and by the number of elements in the array. An array type is said to be derived from its element type, and if its element type is T, the array type is sometimes called "array of T". The construction of an array type from an element type is called "array type derivation".
• ...
• A pointer type may be derived from a function type, an object type, or an incomplete type, called the referenced type. A pointer type describes an object whose value provides a reference to an entity of the referenced type. A pointer type derived from the referenced type T is sometimes called "pointer to T". The construction of a pointer type from a referenced type is called "pointer type derivation".

These methods of constructing derived types can be applied recursively.

Arithmetic types and pointer types are collectively called scalar types. Array and structure types are collectively called aggregate types.

---

Quote:

---

Originally Posted by ISO/IEC 9899:1999 Section 6.3.2.1

Except when it is the operand of the sizeof operator or the unary & operator, or is a string literal used to initialize an array, an expression that has type "array of type" is converted to an expression with type "pointer to type" that points to the initial element of the array object and is not an lvalue.

---

Quote:

---

Originally Posted by Elysia

sizeof of a pointer will always return 4 on x86, and 8 on x64-64 I believe.
Point is, an array is a pointer, but an array requires special syntax to define how many elements you are allocating. And it's even trickier with 2D-arrays since the compiler must know the number of columns in the dimension or it can't calculate a proper offset. In the end, it's all a pointer and an offset. The compiler just needs a little help when you define a 2D-array since it couldn't calculate the proper offset otherwise.

The only exception to arrays not being a pointer is that you can do sizeof the array and it will return the array size, but only in the local function where it's defined. Because in that function, the compiler can clearly see that it defined as a pointer to storage of n elements. But when passing the array or pointer to a function, that information is now lost to the compiler.

---

Regarding 2D arrays, I don't think you can claim that it's equivalent to type** because then you would have an array of pointers and then the memory wouldn't be contiguous like a type[][] would be. A type[][] would basically boil down to a &type[0][0] and you'd have to access it as a type*.
So accessing a int array[3][3] as a pointer would be something like: int val = (array + (3*x) + y);

Then perhaps you have a good explanation of why **array works? As expected, it gets the first value in the array. So if it isn't an array of pointers, then what is it?

Quote:

---

Then perhaps you have a good explanation of why **array works?

---

Array to pointer conversion.

Quote:

---

Originally Posted by Elysia

Then perhaps you have a good explanation of why **array works? As expected, it gets the first value in the array. So if it isn't an array of pointers, then what is it?

---

Pass your array to a function that takes a type** and then see what happens when you de-reference it.

Indeed, it outputs "a":

Code:

---

void foo(char** p)
{
        cout << **p;
}

void Help()
{
        char myarray2[10][10] = { { 'a', 'b', 'c' } };
        foo((char**)myarray2);
}

---

Quote:

---

Originally Posted by Elysia

Indeed, it outputs "a":

Code:

---

void foo(char** p)
{
        cout << **p;
}

void Help()
{
        char myarray2[10][10] = { { 'a', 'b', 'c' } };
        foo((char**)myarray2);
}

---

---

And does

Code:

---

void foo(char** p)
{
        cout << p[1][0];
}

void Help()
{
        char myarray2[10][10] = { { 'a', 'b', 'c' }, {'b', 'c', 'd'} };
        foo((char**)myarray2);
}

---

print "b"? So I think we can safely say that **array doesn't work. Passing in a ** passes a pointer to a pointer; passing in a [][10] passes a pointer to an array. In the first case, when the compiler sees p[1] it advances by the size of what p points to, namely a char * (4 bytes); in the second case, when the compiler sees p[1] it advances by the size of what p points to, namely a char[10] (10 bytes).

Quote:

---

So I think we can safely say that **array doesn't work.

---

That would not be accurate: **array works since when we are dealing with the first of firsts, we can afford to pretend that a scalar type is an aggregate type (and vice versa) even without having additional (otherwise necessary) information.

Quote:

---

Originally Posted by laserlight

That would not be accurate: **array works since when we are dealing with the first of firsts, we can afford to pretend that a scalar type is an aggregate type (and vice versa) even without having additional (otherwise necessary) information.

---

Right, but only when we are dealing with the first of firsts (or, to be fair, the [0][anything] element).

Quote:

---

Originally Posted by tabstop

Right, but only when we are dealing with the first of firsts (or, to be fair, the [0][anything] element).

---

I'm thinking there seems to be some problems with it. The function didn't work as expected at all.
It might just be that a 2D array is just a regular pointer. I'm going to have to investigate about this. I'm thinking that since the standard specifies that an array is not a pointer, compiler makers did not have to worry about this.

Quote:

---

Originally Posted by Elysia

I'm thinking there seems to be some problems with it. The function didn't work as expected at all.
It might just be that a 2D array is just a regular pointer. I'm going to have to investigate about this. I'm thinking that since the standard specifies that an array is not a pointer, compiler makers did not have to worry about this.

---

Well just think about how you would implement a real char** instead of a char[][].
You'd do something like this:

Code:

---

char** pStrArray = malloc( 3 * sizeof( char* ) );
for ( int i = 0; i < 3; ++i )
{
    pStrArray[i] = malloc( 3 * sizeof( char ) );
}

---

So the memory layout of that is going to look a lot different than char strArray[3][3];

Indeed, a 2D array is not type**. Actually, it's still just type*.
The following works:

Code:

---

void foo(char* p)
{
        cout << *p;
        cout << *(p + 1);
        cout << *(p + 2);

        cout << *(p + 3);
        cout << *(p + 4);
        cout << *(p + 5);
}

void Help()
{
        char myarray2[][3] = { { 'a', 'b', 'c' }, { 'd', 'e', 'f' } };
        foo((char*)myarray2);
}

---

It shows that they are just, indeed, pointers. It just allocated a contiguous memory space and assigned the pointer to the array.
While using a pointer like this, we can't use array-like syntax, naturally, because it doesn't know the size of the dimensions.

Quote:

---

Indeed, a 2D array is not type**. Actually, it's still just type*.

---

A 2D array is a 2D array, but being an array it can be converted into a pointer to its first element, which is itself an array.

EDIT:
On second thought, it did not make sense: a char* was not a pointer to an array of chars, but a pointer to a char. Then I realised that you were posting C++ code in the C programming forum, and yet used a C-style cast. Your code actually uses a reinterpret_cast, hence you mistook a char[][3] for a char*.

Quote:

---

Originally Posted by aijazbaig1

Hello,
heres the code:

Code:

---

...
void set2caps(char *str_hld)

{
    unsigned int chr_cnt = 0;
    char temp;

    while(str_hld[chr_cnt]) {
        if (!isupper(str_hld[chr_cnt]))
            temp = toupper(str_hld[chr_cnt]);
        str_hld[chr_cnt] = temp;
        chr_cnt++;
    }
}

---

---

Actually, there's a bug in this function. It should be changed as follows:

Code:

---

void set2caps(char *str_hld)
{
    unsigned int chr_cnt = 0;
    char temp;

    while(str_hld[chr_cnt])
    {
        if (!isupper(str_hld[chr_cnt]))
        {
            temp = toupper(str_hld[chr_cnt]);
            str_hld[chr_cnt] = temp;
        }
        chr_cnt++;
    }
}

---

Otherwise, all letters that were previously capitalized are either ignored (temp is not initialized) or set to the previous uncapitalized letter.

Quote:

---

Originally Posted by laserlight

On second thought, it did not make sense: a char* was not a pointer to an array of chars, but a pointer to a char. Then I realised that you were posting C++ code in the C programming forum, and yet used a C-style cast. Your code actually uses a reinterpret_cast, hence you mistook a char[][3] for a char*.

---

I can't be bothered with C++ casts. IMHO, they're too long to type.

Quote:

---

IMHO, they're too long to type.

---

That's the point - make them easier to spot, and discourage their use. Anyway, I was just saying what the cast actually would be in C++, we cannot use it here anyway since this is C.

Quote:

---

Originally Posted by Elysia

I can't be bothered with C++ casts. IMHO, they're too long to type.

---

I ONLY use C++ casts (in C++ at least).
C++ casts allow the compiler to tell you if you're doing something wrong (like removing const when all you wanted to do is cast the type).
They also allow you to easily search & find any casts in your code, so you can remove them later if you change your code to make them unnecessary. Try searching for a C cast -- not quite as easy, especially if different coding styles are used.
They make the intent of your cast obvious to everyone that reads it because each C++ cast does only one job. With C casts, people don't know if you actually intended to remove const or if it's a bug...

I feel confident in C-style casts and I don't do a lot of mistakes in removing things such as "const."
But either way, if a bug is due to a cast, I fix it pretty quickly, so C-style works for me. Not that it's good practice...