problem with boolean

[exterminator]

What compiler had you used? I get the same behavior with Visual Studio 2008. I would have thought that the integral value should get implicitly converted to a boolean. In fact when I debugged the code in VC++, I do see that it is able to get the value of the user input (say 8) but then there is a certain check which then fails and results in setting of the failbit of the stream. If you check the status of the cin stream post that read, you should see the failbit set which means the read had failed.

VC++ code (file: xlocnum, function: do_get)

 			{	// get zero or nonzero integer
			char _Ac[_MAX_INT_DIG], *_Ep;
			int _Errno = 0;
			const unsigned long _Ulo = ::_Stoulx(_Ac, &_Ep,
				_Getifld(_Ac, _First, _Last, _Iosbase.flags(),
					_Iosbase.getloc()), &_Errno);
			if (_Ep != _Ac && _Errno == 0 && _Ulo <= 1)
				_Ans = _Ulo;
			}

The check _Ulo <= 1 is what fails. _Ulo is an unsigned long which does get successfully evaluated to 8 (the input). So, it is basically only allowing inputs as 0 and 1 via the stream.

As has been written above, it is incorrect to say that a bool can only be assigned a value "true" or "false". Whatever value you try to assign, for example, an integral value say != 0, that value should get converted to a boolean and then that value set up as the value of the bool. So, it should be perfectly legal to do that.

Could this be a bug in VC++? I am not sure but I would have thought that it would have considered any non-zero value as true. Because, if I just simply set the value of boolean as 8 instead of reading from the stream, the automatic conversion rules kick in and the code works as expected. I don't have any other compiler but can anyone check what behavior is there with g++ or any other compiler?

[Paul McKenzie]

What compiler had you used? I get the same behavior with Visual Studio 2008. I would have thought that the integral value should get implicitly converted to a boolean. In fact when I debugged the code in VC++, I do see that it is able to get the value of the user input (say 8) but then there is a certain check which then fails and results in setting of the failbit of the stream.

Possibly the explanation is that streams work differently than operator =.

I don't have the standard in front of me, but, I know that other types will do things differently if you use input streams as opposed to using assignment. A clear example of the different behaviour is char arrays. Arrays cannot be assigned to, but a stream is able to assign characters to a char array.

Regards,

Paul McKenzie

[abc++]

Why when I cout characters like &#232;,&#231;,&#242;,&#236; aren't interpretated correctly?
What can I do?

thanks!

[S_M_A]

When you cout characters like that they are coded in a way that does not correspond to the character coding used by the console.

If you use MBCS settings in your projects the "easiest" way out (unless you can use MFC/ATL http://msdn.microsoft.com/en-us/libr...a3(VS.80).aspx) is to open a console, start edit.exe, type the characters you want to use and then save the file. Now open the file using a hex-viewer and use the hex values instead of the original ones.

Just as a demonstration, I created a file (saved as ANSI) containing the swedish characters &#229;&#228;&#246;&#197;&#196;&#214; using notepad, then I re-opened the same file in a console using edit and added the same character string on a new line. The content of the file is now:

In edit   in notepad     in hex
σΣ÷┼─╓    åäöÅÄÖ      E5 E4 F6 C5 C4 D6
åäöÅÄÖ    †„”Ž™      86 84 94 8F 8E 99

Now, if I would like to cout the swedish text "S&#229;nt h&#228;r &#228;r irriterande!" (These things are annoying!) in a console I would have to do

cout << "S\x86nt h\x84r \x84r irriterande!"

but the string would only be properly presented if the default codepage for the console is set to one that print swedish characters from my hex values.

To set the code page use SetConsoleCP (console reference http://msdn.microsoft.com/en-us/libr...87(VS.85).aspx)

Coding the output like in the above code is not very practical. A slightly better way of doing it could be like

#define å "\x86"
#define ä "\x84"
#define ä "\x84"

cout << "S"&#229;"nt h"&#228;"r "&#228;"r irriterande!" << endl;

[exterminator]

Possibly the explanation is that streams work differently than operator =.

I don't have the standard in front of me, but, I know that other types will do things differently if you use input streams as opposed to using assignment. A clear example of the different behaviour is char arrays. Arrays cannot be assigned to, but a stream is able to assign characters to a char array.

Thanks, Paul. True. I think me taking promotion rules to how stream treats inputs is stretching it a bit too far. Couldn't find anything concrete on this. I did not search too extensively but am fine accepting the behavior.

[abc++]

why is necessary write them in hex?
if I do this, will not work in other computers, right?

[Paul McKenzie]

why is necessary write them in hex?
if I do this, will not work in other computers, right?

The reason for hex constants is so that other programmers can easily see what is being done. There is nothing stopping you from using decimal, octal, or character values.

Regards,

Paul McKenzie