|
Hi Experts,
How can I read a byte in unsigned variable. Because this value may be nagetive.
I tried like this
<br />
short signed int m_nOneByte=0;<br />
memcpy(&m_nOneByte,btBuffer+0x40,1);<br />
Hex value is 0xf6 which is -10.But it is dispalying 246.
|
|
|
|
|
pther wrote: How can I read a byte in unsigned variable. Because this value may be nagetive.
Sorry, you seem confused: Bytes *ARE* unsigned types. Range 0-255.
0xf6 is 246. It is NOT negative.
int (the signed is the default) can hold all positive values a byte can have.
Are you perchance missing the char-type?
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
If your array is a char array, you can simply assign it:
short newValue = *(btBuffer+0x40);
BTW, you should use the prefix "m_" on class members only (m stands for member).
|
|
|
|
|
pther wrote: How can I read a byte in unsigned variable. Because this value may be nagetive.
Simple, for instance:
unsigned char buff[]={0xff, 0xf6, 0x01};
int i;
i = *((char *) &buf[1]);
<pre>
:)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Hello everyone,
Suppose we defined a string buffer (array), like this,
char array[] = "hello world";
char buf[256]
Sometimes, I noticed that we either use,
1. array (buf)
or use,
2. &array (&buf)
or use
3. &array[0] (&buf[0])
as the beginning address of the array,
example like,
strcpy (buf, array);
strcpy (&buf, array);
...
I am wondering the differences between the 3 approaches, and which approach is the most correct?
thanks in advance,
George
|
|
|
|
|
array and buf both denote pointers to chars (char*).
In fact, array is a const char*, as you can not alter the content of the string (well, even if you could, it would be wrong to try).
By convention, strings in C++ are null terminated, and it is your responsibility to count the \0 in. I the string literal "Hello World!", the \0 is appended automagically by the runtime. Go try and check the string lenght!
So, &buf is denoting the address of a pointer to a string of chars. When that is what you want, you want exactly that.
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
Thanks jhwurmbach,
So you mean buf is not the same as $buf? But in my experience buf and &buf always have the same effect, examples,
1. strcpy (buf, "Hello World");
2. strcpy (&buf, "Hello World");
regards,
George
|
|
|
|
|
George_George wrote: n my experience buf and &buf always have the same effect, examples,
1. strcpy (buf, "Hello World");
2. strcpy (&buf, "Hello World");
And this *DOES* work? 
I would bet that given
char buf[256];
buf is of type char*
&buf is of type char** - that is a pointer to a char pointer.
OTOH, &buf[0] would be the same as buf, as you are dereferencing on pointer by using the operator[]
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
Hi jhwurmbach,
I have tested that buf and &buf are of the same value -- means same effect. Here is my program to test. Any comments?
int main()
{
char buf[] = "Hello World";
int p1 = buf;
int p2 = &buf;
return 0;
}
regards,
George
|
|
|
|
|
This:
#include "stdafx.h"
#include "iostream"
int _tmain(int argc, _TCHAR* argv[])
{
char array[] = "Hello World!";
if( array == &array) {
std::cout << "Equal" << std::endl;
}
else {
std::cout << "Inequal" << std::endl;
}
char* p1 = array;
char* p2 = (char*)&array;
char* p3 = &array[0];
int pI1 = (int)array;
int pI2 = (int)&array;
int pI3 = (int)&array[0];
return system("pause");
}won't compile:
test.cpp(21): error C2446: '==' : no conversion from 'char (*__w64 )[13]' to 'char *'
test.cpp(21): error C2040: '==' : 'char [13]' differs in levels of indirection from 'char (*__w64 )[13]'
So array is of type char*, wheras &array is of type char[13].
But you are right, both point to the same chunk of memory.
It seems like the runtime is doing some magic with the adress-of-operator.
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
Thanks jhwurmbach,
I have tested that you are correct. My further finding is when you rename the extension from .cpp to .c, then C compiler will be used and there will not be any compile error.
What magics do you think runtime or compiler is making? I am very confused why the value of address of a variable is the same as that the variable itself.
jhwurmbach wrote: But you are right, both point to the same chunk of memory.
It seems like the runtime is doing some magic with the adress-of-operator.
regards,
George
|
|
|
|
|
jhwurmbach wrote: array and buf both denote pointers to chars (char*).
In fact, array is a const char*, as you can not alter the content of the string (well, even if you could, it would be wrong to try).
Actually both are const pointers to char (i.e. const char *). That means you cannot change their value (i.e. pointed address) while it is perfectly legal to change their content.
hence:
array++;
while:
array[0] = 'H';
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Cool CPallini,
You are correct and I have tested it.
What about your comments about buf and &buf?
I have tested that buf and &buf are of the same value -- means same effect. Here is my program to test. Any comments?
int main()
{
char buf[] = "Hello World";
int p1 = buf;
int p2 = &amp;amp;buf;
return 0;
}
regards,
George
|
|
|
|
|
|
CPallini wrote: And (surprisingly to me) they indeed hold the same address.
I am glad that I am not the only one who is surprised.
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
Often a little test is worthy to do.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
I did[^], but it was you who found the bit of explanation.
Thanks!
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
|
George_George wrote: The address of operator (& does nothing when applied to array names (see discussion below), but does with pointers..
Yes. The overall point is it.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Thanks for your confirmation CPallini!
regards,
George
|
|
|
|
|
Your examples aren't all that correct. But I think I get the idea of the question.
This will be brief. For a longer version, read a C book. The Kernigan & Richie one taught me loads in a small book.
char array [] = "hello world";
ends up with a constant pointer to chunk of memory holding hello world followed by a zeroed character (NULL).
Same with buf, but it's a constant pointer to a chunk of memory 256 characters long - which could hold anything.
buf is a pointer.
buf [37] is the value in the 37th character in the chunk of memory pointed to by buf.
array[buf] would be the character pointed to by array + an offset of the amount of buf. If buf = 0x12344, this is a big offset.
array(buf) will get the compiler moaning at you, because array is not a function.
Going to array...
array is a pointer to the start of memory holding "hello world".
array[4] is the 4th character in that array. ie 'o', not 'l'.
*array is the character pointed to by array, ie 'h'.
*array and array [0] are equivalent.
array+4 is the pointer to the memory of helloe world, with 4 added to it. So it points to 'o'.
&array[4] is the pointer to the 4th char in the array. same as above.
So...
&array[x] is the same as array+x. The only difference is how similar it looks to the code around it. If the memory is allocated as an array, and that's how you're working on it, &array[0] may be more readable.
If you working on pointers to structures, and your function doesn't know how they're allocated, using array may be more readable.
I hope this helps a little!
Iain.
|
|
|
|
|
Thanks Iain,
How about array and &array, are they always the same?
(in your reply, I have not seen any discussion about &array).
regards,
George
|
|
|
|
|
Erm, no, they're never the same. That's like asking "Is 'Bob' the same as '#1 The Street, Townsville'?"
The & means pointer to.
So, &array is a pointer to a pointer to chars.
This can make the brain hurt, but is very useful when you get the hang of it.
Iain.
|
|
|
|
|
Hi Iain,
I have tested that buf and &buf are of the same value -- means same effect. Here is my program to test. Any comments?
int main()
{
char buf[] = "Hello World";
int p1 = buf;
int p2 = &amp;buf;
return 0;
}
regards,
George
|
|
|
|
|
CPallini's answer was good, and correct.
All it means though is the value of array and &array are the same as C nicely hacks it that way.
BUT...
They are of different types, as no doubt C will complain if you try to do this...
char array [] = "hello world";
char *p;
char **pp
p = array;
ASSERT(*p == 'h';
p = &array;
pp = &array;
ASSERT(**p == 'h');
Getting there?
Iain.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
