array[0] != array + 0 ???

I have this line:

PHP Code:

---

printf("c[bk]: %c \t c+bk: %c\n",camadas_dados[bk],camadas_dados+bk); 


---

But when it prints out, i receive this:


http://xs125.xs.to/xs125/08141/lol647.jpg


Why are they different? How can i make them equal?

Thanks!

The subscript operator dereferences the address

Quote:

---

camadas_dados[bk]

---

is equivalent to

Code:

---

*( camadas_dados + bk )

---

array[0] is the first element of the array. array + 0 is a pointer to the first element of the array. Clearly, a value and a pointer to that value are fundamentally different.

Thanks! ;)

That is,
camadas_dados[bk]
Should actually be
&camadas_dados[bk]

Quote:

---

That is,
camadas_dados[bk]
Should actually be
&camadas_dados[bk]

---

I think it depends on what Milhas actually wants to do, e.g., from the example I would say that camadas_dados + bk should be *(camadas_dados + bk) as in Prelude's example.

Also, why use &camadas_dados[bk] instead of camadas_dados + bk? It seems to me that if bk is equal to the number of elements of the array, camadas_dados + bk would result in a one past the end pointer, but &camadas_dados[bk] would take the address of a non-existent object.

Quote:

---

Originally Posted by laserlight

Also, why use &camadas_dados[bk] instead of camadas_dados + bk? It seems to me that if bk is equal to the number of elements of the array, camadas_dados + bk would result in a one past the end pointer, but &camadas_dados[bk] would take the address of a non-existent object.

---

Whilst technically there may be a subtle difference, if we are talking char arrays (or any other plain old data/C types), rather than some C++ type where [] is overloaded with a function, &camadas_dados[bk] and camadas_dados + bk would generate exactly the same code [and both produce the address of the element immediately after the array memory provided if bk == number of array elements. The only difference is style.

--
Mats

Oops, yes, you're right in that it wasn't supposed to take the address.
The correct statement would be that
camadas_dados + bk
Is the same as
&camadas_dados[bk]

And
camadas_dados[bk]
Is the same as
*(camadas_dados + bk)

Which one to use is purely up to the programmer.

I Want atoi to do this:

atoi(camadas_dados[bk]);

but it gives me warnings at compilation.

atoi(*(camadas_dados+bk)); gives the same warning

atoi(&camadas_dados[bk]); returns strange addresses.


Edit: And atoi(camadas_dados+bk); returns Zero everytime :(

The last line is correct. But as to the problem, it can be many things. It's better to show the code so we can do a diagnostic.
(Why is it correct? Because atoi wants a pointer to char [char*], and [] derferences the pointer [or array] [and the same with *], so putting a & [address of operator] there takes the address from that element forwards.)

Quote:

---

Originally Posted by Milhas

I Want atoi to do this:

atoi(camadas_dados[bk]);

but it gives me warnings at compilation.

atoi(*(camadas_dados+bk)); gives the same warning

atoi(&camadas_dados[bk]); returns strange addresses.

---

Assuming that camadas_dados is declared as:

Code:

---

char camadas_dados[X];

---

then this form is the correct one.

Code:

---

atoi(&camadas_dados[bk]);
// or
atoi(camadas_dados + bk);

---

If you get strange results from that, perhaps your string isn't correctly terminated, or the string is not a number in some way.

--
Mats

Quote:

---

&camadas_dados[bk] and camadas_dados + bk would generate exactly the same code [and both produce the address of the element immediately after the array memory provided if bk == number of array elements.

---

In practice, I think that is what will happen, but semantically speaking, I thought that &camadas_dados[bk], where bk is equal to the number of elements of camadas_dados, is undefined.

However, the C99 Standard states:

Quote:

---

Originally Posted by Section 6.5.3.2

The unary & operator returns the address of its operand. (...) Similarly, if the operand is the result of a [] operator, neither the & operator nor the unary * that is implied by the [] is evaluated and the result is as if the & operator were removed and the [] operator were changed to a + operator.

---

So I am wrong to think that &camadas_dados[bk] would take the address of a non-existent object under the circumstances described.

Quote:

---

Originally Posted by laserlight

In practice, I think that is what will happen, but semantically speaking, I thought that &camadas_dados[bk], where bk is equal to the number of elements of camadas_dados, is undefined.

However, the C99 Standard states:


So I am wrong to think that &camadas_dados[bk] would take the address of a non-existent object under the circumstances described.

---

But as soon as you USE the pointer produced by camdados_dados + bk, you are in an equally "undefined behaviour" situation.

--
Mats

If i have char array[3] = "123"

and give atoi(&array[1]), atoi will give me int '2' or int '23' ?

It will return 23 since &array[1] is the address starting at the second element, which is the "2".
Atoi will the scan until it finds the end of the string, which is after the "3". So it will return 23.

Quote:

---

Originally Posted by Elysia

It will return 23 since &array[1] is the address starting at the second element, which is the "2".
Atoi will the scan until it finds the end of the string, which is after the "3". So it will return 23.

---

any way to atoi only give '2' to me instead of '23'? (without placing \0 after 2)


Thanks.

Quote:

---

But as soon as you USE the pointer produced by camdados_dados + bk, you are in an equally "undefined behaviour" situation.

---

That is not true, assuming that the use is restricted to pointer arithmetic and comparison.

Quote:

---

any way to atoi only give '2' to me instead of '23'? (without placing \0 after 2)

---

In that case you may not want to use atoi() at all, but instead just array[0], or array[0] - '0' if you want the integer corresponding to that digit.

Quote:

---

Originally Posted by Milhas

any way to atoi only give '2' to me instead of '23'? (without placing \0 after 2)


Thanks.

---

No, not unless you truncate the array by replacing the '3' with 0. This is a typical way of getting only the data you want. You can simply make a copy of the current value at array[2], then replacing it with 0, calling atoi and then restoring the previous value.

Also note that laserlight's suggestion will work on individual digits, but if it's a long string in question, the truncate option may work better.

You should really not use atoi(), use strtol og strtoi instead...

Thanks! :D

Quote:

---

Originally Posted by Milhas

If i have char array[3] = "123"

and give atoi(&array[1]), atoi will give me int '2' or int '23' ?

---

There's no telling what atoi() will give you because your array isn't large enough to hold the string "123" with a null-terminator.

Without that null-terminator on the end, atoi() will plow right past the end of your string and process whatever it finds. In most cases these probably won't be valid ASCII digits and you might get the correct result, but I wouldn't rely on that.

If you're going to use a literal string in your program, don't specify the size of the array and let the compiler figure it out for you (char array[] = "123", sizeof(array) == 4).

Actually, the code wouldn't compile in the first place, and if you manually copied the string into the buffer, you'd get a buffer overrun, perhaps a crash, but otherwise the NULL char would be there, and it would still work right.

Quote:

---

Originally Posted by Elysia

Actually, the code wouldn't compile in the first place, and if you manually copied the string into the buffer, you'd get a buffer overrun, perhaps a crash, but otherwise the NULL char would be there, and it would still work right.

---

Interesting considering I just compiled it. I think perhaps you meant to say, "In Visual Studio, the code won't compile in the first place," because MinGW allows this with no errors even with -Wall and -pedantic. I assume gcc in general probably behaves the same way.

No, according to C. If the compiler compiles it, the compiler is faulty.
char[4] can't be implicitly converted to char[3].
(Don't quote me on that.)
(Btw, it's likely Visual Studio would compile it, as well, due to its poor C compiler.)

Quote:

---

Originally Posted by Elysia

No, according to C. If the compiler compiles it, the compiler is faulty.
char[4] can't be implicitly converted to char[3].
(Btw, it's likely Visual Studio would compile it, as well, due to its poor C compiler.)

---

You might find 6.7.8p32 of ISO/IEC 9899:TC2 to be of interest.

Quote:

---

EXAMPLE 8 The declaration

Code:

---

char s[] = "abc", t[3] = "abc";

---

defines ‘‘plain’’ char array objects s and t whose elements are initialized with character string literals.
This declaration is identical to

Code:

---

char s[] = { 'a', 'b', 'c', '\0' },
    t[] = { 'a', 'b', 'c' };

---

---

Pfft again, stupid C :rolleyes:

Okay... http://c-faq.com/ansi/nonstrings.html

-- Edit --
Well then. Two posts above mine huh? Where did THOSE come from!?

-- Double Edit --
Interestingly enough, the code does not compile in Visual Studio. It complains of a buffer overrun. Hehe.

I was wrong. Again, C surprises me with all the stupid things it allows.