Prev: Use of facet codecvt for indenting output text
Next: Is this exception-safe code template correct?
From: Öö Tiib on 9 Jan 2010 08:10
On Jan 8, 3:39 pm, leonleon77 <leonleo...(a)gmail.com> wrote:
> Hello,
>
> given that C++ standard has 3 distinct types for a char: plain, signed
> and unsigned; and given that such a distinction is perfectly
> achievable in function overloading and/or template specialization --
> what are the reasons for representing each of such types in the same
> ('print the binary value as is') way during "cout <<" calls (i.e.
> without converting relevant type of char into a numeric representation
> first)?

Dump all three and use wchar_t, std::wcout and L"string literal" when
dealing with textual I/O.

Char is too short even for representing characters. 256 values cannot
describe the color of one of dots on your display. As for modern
processors, these are inefficient when forced to work with single
bytes. sometimes you may gain little positive effect from bit-packing
something into unsigned chars or shorts but that is exceptionally rare
occasion in modern world of giga- and terabytes.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Seungbeom Kim on 11 Jan 2010 07:16
Nick Hounsome wrote:
>
> Anyway arithmetic operations on characters ARE meaningless:
>
> What is 'a' + 'b'?
> Even '0'+1 is not necessarily '1' (and anyway this is arithmetic on
> int NOT char)

The values of the digits '0'...'9' are guaranteed to be contiguous,
so '0'+1 == '1' always holds.

> Using char for storing small ints is really equivalent to something
> like using reinterpret_cast to store ints in doubles - You can do it
> (although there is no good reason to try because you can just use
> integer types) but when you cout the double it will still come out as
> a floating point number:
>
> char c1 = reinterpret_cast<char>(42);
> c1 = reinterpret_cast<char>( (reinterpret_cast<int>(c1) + 1 )
> cout << c1; // defintely not 43
>
> double d1 = reinterpret_cast<double>(42);
> d1 = reinterpret_cast<double>( reinterpret_cast<int>(d1) + 1 );
> cout << d1; // defintely not 43
>
> Both should hold the integer representation of 43 but neither will
> output 43.

These reinterpret_cast's don't even compile.

--
Seungbeom Kim

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: George Neuner on 12 Jan 2010 06:54
On Mon, 11 Jan 2010 18:16:42 CST, Seungbeom Kim <musiphil(a)bawi.org>
wrote:

>Nick Hounsome wrote:
>>
>> Anyway arithmetic operations on characters ARE meaningless:
>>
>> What is 'a' + 'b'?
>> Even '0'+1 is not necessarily '1' (and anyway this is arithmetic on
>> int NOT char)
>
>The values of the digits '0'...'9' are guaranteed to be contiguous,
>so '0'+1 == '1' always holds.

Guaranteed by what? It so happens that decimal digits are contiguous
in the ASCII and EBCDIC character sets ... but that need not be the
case. It is certainly not the case in EBCDIC that 'I'+1 == 'J'.

I could be wrong, but AFAIK, C++ does not assume any particular
underlying character set. The standard discusses ASCII as a reference
set, but I don't believe it requires ASCII conformance.

George

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 | 
Pages: 1
Prev: Use of facet codecvt for indenting output text
Next: Is this exception-safe code template correct?