Programming Forums > Application Development > C++

iradic · Dec 19th, 2006, 12:20 AM

Can someone explain what's going on here:

#include <iostream>

using namespace std;

int to_int ( char ch );

int main ()
{
    char test = 0xff;

    cout << to_int (test) << endl;
    cout << (int) test << endl;
    cout << int (test) << endl;
    cout << static_cast<int> (test) << endl;
    int i = reinterpret_cast<char> (test);
    cout << i << endl;
    cout << (unsigned int) test << endl;
    // error: expected primary-expression before "unsigned"
    // error: expected `;' before "unsigned"
    //cout << unsigned int (test) << endl;
    cout << static_cast<unsigned int> (test) << endl;
    unsigned int ui = reinterpret_cast<char> (test);
    cout << ui << endl;
}

int to_int ( char ch )
{
    int ret = 0;
    for (int i = 0x01; i < 0xff; i++)
      ret = ret | ( ch & i);

    return ret;
}

// output:
//  255
//  -1
//  -1
//  -1
//  -1
//  4294967295
//  4294967295
//  4294967295

I would like to know if there is a way to cast as "to_int()"?

And: why is unsigned int casted to the max, plus a compiler error explanation if possible? Are those bugs?

os: windows 2000
cc: gcc 3.4.2

grumpy · Dec 19th, 2006, 1:09 AM

No they're not bugs.

It is implementation defined whether char is signed or unsigned. If it is signed for your compiler, it is quite possible that the maximum value that can be stored in a char (another implementation defined value) is only 127. 0xff has a value of 255, which is greater than 127, so storing it into a char will probably yield a negative value. And converting a negative value to a signed int .....

bl00dninja · Dec 19th, 2006, 2:09 AM

you must understand your platform.

iradic · Dec 19th, 2006, 6:38 AM

Ok, let's say I'm ok with that...

But why is then:

(Toggle Plain Text)

  istream &read( char *buffer, streamsize num );

How do you read binary then, properly? No way...

Or is this the only way...

(Toggle Plain Text)

 unsigned char buf[buf_size];
 file.read (reinterpret_cast<char *> (&buf), buf_size);

Is there any other way? Thanks...

DaWei · Dec 19th, 2006, 6:58 AM

All input is binary, even text. If you want to make sure that binary codes that equate to newlines and such are not treated specially, open the stream in binary mode (see ios). This is only necessary on Windows systems, where the default mode is text, which dinks with your input/output. Unix and derivatives don't even have such a mode.

I really don't understand exactly what you are asking. I would suggest that you give an example of the data representing the input and explain exactly what you want to do with it.

A question such as "can someone explain what is going on here?" is not a good question. It requires your (volunteer) respondents to peruse your code in great detail without really knowing why they are doing so. Most likely, anottagonnahappen.

Explain what your code is supposed to do, how it is failing to meet your expectations, the error or warning messages you get, and where they occur. Information is key. If you don't have enough, resort to your debugger or to sprinkling output statements around to gain more. You might even discover the problem in the process.

Try not to include copious amounts of code, although sometimes one must. Try to make a small snippet that reproduces the problem.

iradic · Dec 19th, 2006, 7:12 AM

Well, there are questions below the code and error message is inside code comments (following with the error expression)...

Anyway, it's just confusing a bit for me all this stuff...

For example if your data is mixed chars and ints what you do to read it properly?

I'm using this (under windows):

(Toggle Plain Text)

  unsigned char buf[buf_size];
  ifstream file (argv[i], ios::in | ios::binary);
  if (file.fail()) {
    cout << "Couldn't open file..." << endl;
    return 1;
  }
  file.read (reinterpret_cast<char *> (&buf), buf_size);

After this I have better control over data I read... which is why I don't get why "read" method accepts only "char*"

grumpy · Dec 19th, 2006, 7:12 AM

The reason is that it is implementation defined whether char is signed or unsigned; that choice generally depends on what works for the target system. The result of conversion from either signed char or unsigned char to char is also implementation dependent, meaning it won't make sense on all machines. So it doesn't make sense, in general, for binary I/O to be specified in terms of either signed char or unsigned char. It may make sense on yoru machine to work with an array of unsigned char, but won't necessarily work on another machine.

It depends on how you've written the data to the file in the first place but, yes, if you're using binary I/O it is necessary to convert the address of your data to a pointer to char. Whether reading or writing. In your example, there is no obvious need to work with an array of unsigned char; you might was well work with straight char.

Some other things to watch;
1) As a rough rule, the method of reading data needs to be the reverse of the process of writing it. So if you write a struct that happens to be of size 25 bytes, you will not successfully read it back in one byte at a time and be sure of being able to reconstruct the original data.

2) Binary I/O is implementation dependent (i.e. the results varybetween compilers). The code that does the reading and the code that does the writing must usually be compiled with the same compiler.

3) Binary I/O often does not work correctly with C++ class or struct types: it is only guaranteed to work with basic types and POD structs (in rough terms, another name for structs defined in a manner a C compiler will understand).

iradic · Dec 19th, 2006, 7:32 AM

Thanks, for now I will use what works...

Bye...

PS: In the future whenever I find something not clear to me I will say: "Ah, it's probably implementation defined".

Narue · Dec 19th, 2006, 8:06 AM

>PS: In the future whenever I find something not clear to me I will say: "Ah, it's probably implementation defined".
That sounds like a good way to jump into the realm of "undefined", which is something like implementation-defined, but much much more dangerous. How about instead of making assumptions when something isn't clear, you do research to make it clear?

Jessehk · Dec 19th, 2006, 11:22 AM

I think he is implying that grumpy and DaWei are unsure of the reason, so they are making the excuse that it is implementation defined.

I may just be reading this with a very cynical mind-set, though.

Dec 19th, 2006, 12:20 AM	#1
iradic Programmer Join Date: Feb 2006 Posts: 36 Rep Power: 0	Casting? Can someone explain what's going on here: (Toggle Plain Text) #include <iostream> using namespace std; int to_int ( char ch ); int main () { char test = 0xff; cout << to_int (test) << endl; cout << (int) test << endl; cout << int (test) << endl; cout << static_cast<int> (test) << endl; int i = reinterpret_cast<char> (test); cout << i << endl; cout << (unsigned int) test << endl; // error: expected primary-expression before "unsigned" // error: expected `;' before "unsigned" //cout << unsigned int (test) << endl; cout << static_cast<unsigned int> (test) << endl; unsigned int ui = reinterpret_cast<char> (test); cout << ui << endl; } int to_int ( char ch ) { int ret = 0; for (int i = 0x01; i < 0xff; i++) ret = ret \| ( ch & i); return ret; } // output: // 255 // -1 // -1 // -1 // -1 // 4294967295 // 4294967295 // 4294967295 #include <iostream> using namespace std; int to_int ( char ch ); int main () { char test = 0xff; cout << to_int (test) << endl; cout << (int) test << endl; cout << int (test) << endl; cout << static_cast<int> (test) << endl; int i = reinterpret_cast<char> (test); cout << i << endl; cout << (unsigned int) test << endl; // error: expected primary-expression before "unsigned" // error: expected `;' before "unsigned" //cout << unsigned int (test) << endl; cout << static_cast<unsigned int> (test) << endl; unsigned int ui = reinterpret_cast<char> (test); cout << ui << endl; } int to_int ( char ch ) { int ret = 0; for (int i = 0x01; i < 0xff; i++) ret = ret \| ( ch & i); return ret; } // output: // 255 // -1 // -1 // -1 // -1 // 4294967295 // 4294967295 // 4294967295 I would like to know if there is a way to cast as "to_int()"? And: why is unsigned int casted to the max, plus a compiler error explanation if possible? Are those bugs? os: windows 2000 cc: gcc 3.4.2

Dec 19th, 2006, 2:09 AM	#3
bl00dninja Programming Guru Join Date: Oct 2004 Location: namespace std Posts: 1,246 Rep Power: 5	you must understand your platform. __________________ i put on my robe and wizard hat... Have you ever heard of Plato, Aristotle, Socrates?...Morons.

Dec 19th, 2006, 6:38 AM	#4
iradic Programmer Join Date: Feb 2006 Posts: 36 Rep Power: 0	Ok, let's say I'm ok with that... But why is then: (Toggle Plain Text) istream &read( char buffer, streamsize num ); istream &read( char buffer, streamsize num ); How do you read binary then, properly? No way... Or is this the only way... (Toggle Plain Text) unsigned char buf[buf_size]; file.read (reinterpret_cast<char > (&buf), buf_size); unsigned char buf[buf_size]; file.read (reinterpret_cast<char > (&buf), buf_size); Is there any other way? Thanks... Last edited by iradic; Dec 19th, 2006 at 7:00 AM.

Dec 19th, 2006, 6:58 AM	#5
DaWei Resident Grouch Join Date: Jun 2005 Posts: 6,453 Rep Power: 10	All input is binary, even text. If you want to make sure that binary codes that equate to newlines and such are not treated specially, open the stream in binary mode (see ios). This is only necessary on Windows systems, where the default mode is text, which dinks with your input/output. Unix and derivatives don't even have such a mode. I really don't understand exactly what you are asking. I would suggest that you give an example of the data representing the input and explain exactly what you want to do with it. A question such as "can someone explain what is going on here?" is not a good question. It requires your (volunteer) respondents to peruse your code in great detail without really knowing why they are doing so. Most likely, anottagonnahappen. Explain what your code is supposed to do, how it is failing to meet your expectations, the error or warning messages you get, and where they occur. Information is key. If you don't have enough, resort to your debugger or to sprinkling output statements around to gain more. You might even discover the problem in the process. Try not to include copious amounts of code, although sometimes one must. Try to make a small snippet that reproduces the problem. __________________ Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code. Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

Dec 19th, 2006, 7:12 AM	#6
iradic Programmer Join Date: Feb 2006 Posts: 36 Rep Power: 0	Well, there are questions below the code and error message is inside code comments (following with the error expression)... Anyway, it's just confusing a bit for me all this stuff... For example if your data is mixed chars and ints what you do to read it properly? I'm using this (under windows): (Toggle Plain Text) unsigned char buf[buf_size]; ifstream file (argv[i], ios::in \| ios::binary); if (file.fail()) { cout << "Couldn't open file..." << endl; return 1; } file.read (reinterpret_cast<char > (&buf), buf_size); unsigned char buf[buf_size]; ifstream file (argv[i], ios::in \| ios::binary); if (file.fail()) { cout << "Couldn't open file..." << endl; return 1; } file.read (reinterpret_cast<char > (&buf), buf_size); After this I have better control over data I read... which is why I don't get why "read" method accepts only "char*"

Dec 19th, 2006, 1:09 AM	#2
grumpy Programming Guru Join Date: Jun 2005 Location: Adelaide, South Australia Posts: 1,207 Rep Power: 5	No they're not bugs. It is implementation defined whether char is signed or unsigned. If it is signed for your compiler, it is quite possible that the maximum value that can be stored in a char (another implementation defined value) is only 127. 0xff has a value of 255, which is greater than 127, so storing it into a char will probably yield a negative value. And converting a negative value to a signed int .....

Dec 19th, 2006, 7:32 AM	#8
iradic Programmer Join Date: Feb 2006 Posts: 36 Rep Power: 0	Thanks, for now I will use what works... Bye... PS: In the future whenever I find something not clear to me I will say: "Ah, it's probably implementation defined". Last edited by iradic; Dec 19th, 2006 at 7:46 AM.

Dec 19th, 2006, 8:06 AM	#9
Narue Professional Programmer Join Date: Sep 2005 Posts: 419 Rep Power: 3	>PS: In the future whenever I find something not clear to me I will say: "Ah, it's probably implementation defined". That sounds like a good way to jump into the realm of "undefined", which is something like implementation-defined, but much much more dangerous. How about instead of making assumptions when something isn't clear, you do research to make it clear? __________________ Even if the voices aren't real, they have some pretty good ideas.

Dec 19th, 2006, 11:22 AM	#10
Jessehk The Oblivious One Join Date: May 2005 Location: Ontario, Canada Posts: 641 Rep Power: 4	I think he is implying that grumpy and DaWei are unsure of the reason, so they are making the excuse that it is implementation defined. I may just be reading this with a very cynical mind-set, though. __________________ Dr. Zoidberg: [ecstatic] I'm going to a movie... with FRIENDS!

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Casting a struct to s aimilar struct	shoeyfighter	C	6	Oct 27th, 2006 2:59 PM
Question regarding Malloc() and Type casting	sparda	C	6	Sep 29th, 2005 4:12 AM

Programming Forums > Application Development > C++

Casting?