Date: Sat, 23 Dec 2023 16:50:16 +0800
The code behaves as expected. There is really nothing to discuss about, as
far as the standard is concerned.
If you have questions about the code behaviour, StackOverflow is the right
place to go.
If you think the standard is flawed, I could concur. But 1) there are
always trade-offs, where C compatibility and backward compatibility are
concerned; 2) no one is proposing a change right now....
On Sat, 23 Dec 2023 at 15:15, Olavi Esker via Std-Discussion <
std-discussion_at_[hidden]> wrote:
> Hello, here are the full code demonstrations below:
>
> 1. For <iostream> demonstration 1
> /*-------------------------------------------------*/
>
> #include <cstdint>
> #include <iostream>
>
> int main()
> {
> std::int8_t myInt{65};
> std::cout << "Takes ASCII char " << myInt << '\n';
> std::cout << "(static_cast): " << static_cast<int>(myInt) << '\n';
> std::cout << "(int): " << (int)myInt << '\n';
>
> return 0;
> }
> // First prints the ASCII character for 65, which is "A"
> // (int) and static_cast print 65 correctly.
> // The programmer learns to use (int) to print out int8_t
>
> /*-------------------------------------------------*/
> 2. <iostream> demonstration 2
> /*-------------------------------------------------*/
>
> #include <cstdint>
> #include <iostream>
>
> int main()
> {
> std::cout << "Enter a number between 0 and 127: ";
> std::int8_t myInt{};
> std::cin >> myInt;
> std::cout << "You entered (no cast): " << myInt << '\n';
> std::cout << "You entered (static_cast): " << static_cast<int>(myInt)
> << '\n';
> std::cout << "You entered ( (int) ): " << (int)myInt << '\n';
> return 0;
> }
>
> // *User input:* 35
> // You entered: 3 // this is the first char given
> onlly. The second one is ignored.
> // You entered (static_cast): 51 // this is when the programmer assumes
> (int) or static_cast<int> should be used
> // You entered ( (int )): 51 // 51 is the ASCII number for '3' .
>
>
> /*-------------------------------------------------*/
> 3. <cstdio> demonstration 3
> /*-------------------------------------------------*/
>
> #include <iostream>
> #include <cstdint>
> #include <cstdio>
> int main()
> {
> std::int8_t num{};
> std::scanf("%hhd", &num); // Read the number and
> store it in num
> std::printf("%d this for cstdio.h\n", num); // Print the value of num
> std::cout << sizeof(num) * 8;
> return 0;
> }
> //*User input*: 100
> // prints correctly 100
> // size is still int8_t.
>
> On Sat, Dec 23, 2023 at 7:45 AM Yongwei Wu <wuyongwei_at_[hidden]> wrote:
>
>> int8_t is just an alias of signed char, and char, signed char, and
>> unsigned char are all character types (as the names imply). Your first code
>> snippet behaves as expected, as far as the current C++ standard is
>> concerned. I believe you were mistaken somewhere about the second code
>> snippet, and I cannot reproduce what you described.
>>
>> You might regard the problem as a design defect, but this is a fact
>> already (partly as the price we paid for C compatibility). If one needs an
>> 8-bit integer type that does not behave like a char, a new user-defined
>> type is then needed, as well as some utility functions to support stream
>> input/output. They are quite easy to write (though it is a regret that they
>> do not exist in the standard library).
>>
>
far as the standard is concerned.
If you have questions about the code behaviour, StackOverflow is the right
place to go.
If you think the standard is flawed, I could concur. But 1) there are
always trade-offs, where C compatibility and backward compatibility are
concerned; 2) no one is proposing a change right now....
On Sat, 23 Dec 2023 at 15:15, Olavi Esker via Std-Discussion <
std-discussion_at_[hidden]> wrote:
> Hello, here are the full code demonstrations below:
>
> 1. For <iostream> demonstration 1
> /*-------------------------------------------------*/
>
> #include <cstdint>
> #include <iostream>
>
> int main()
> {
> std::int8_t myInt{65};
> std::cout << "Takes ASCII char " << myInt << '\n';
> std::cout << "(static_cast): " << static_cast<int>(myInt) << '\n';
> std::cout << "(int): " << (int)myInt << '\n';
>
> return 0;
> }
> // First prints the ASCII character for 65, which is "A"
> // (int) and static_cast print 65 correctly.
> // The programmer learns to use (int) to print out int8_t
>
> /*-------------------------------------------------*/
> 2. <iostream> demonstration 2
> /*-------------------------------------------------*/
>
> #include <cstdint>
> #include <iostream>
>
> int main()
> {
> std::cout << "Enter a number between 0 and 127: ";
> std::int8_t myInt{};
> std::cin >> myInt;
> std::cout << "You entered (no cast): " << myInt << '\n';
> std::cout << "You entered (static_cast): " << static_cast<int>(myInt)
> << '\n';
> std::cout << "You entered ( (int) ): " << (int)myInt << '\n';
> return 0;
> }
>
> // *User input:* 35
> // You entered: 3 // this is the first char given
> onlly. The second one is ignored.
> // You entered (static_cast): 51 // this is when the programmer assumes
> (int) or static_cast<int> should be used
> // You entered ( (int )): 51 // 51 is the ASCII number for '3' .
>
>
> /*-------------------------------------------------*/
> 3. <cstdio> demonstration 3
> /*-------------------------------------------------*/
>
> #include <iostream>
> #include <cstdint>
> #include <cstdio>
> int main()
> {
> std::int8_t num{};
> std::scanf("%hhd", &num); // Read the number and
> store it in num
> std::printf("%d this for cstdio.h\n", num); // Print the value of num
> std::cout << sizeof(num) * 8;
> return 0;
> }
> //*User input*: 100
> // prints correctly 100
> // size is still int8_t.
>
> On Sat, Dec 23, 2023 at 7:45 AM Yongwei Wu <wuyongwei_at_[hidden]> wrote:
>
>> int8_t is just an alias of signed char, and char, signed char, and
>> unsigned char are all character types (as the names imply). Your first code
>> snippet behaves as expected, as far as the current C++ standard is
>> concerned. I believe you were mistaken somewhere about the second code
>> snippet, and I cannot reproduce what you described.
>>
>> You might regard the problem as a design defect, but this is a fact
>> already (partly as the price we paid for C compatibility). If one needs an
>> 8-bit integer type that does not behave like a char, a new user-defined
>> type is then needed, as well as some utility functions to support stream
>> input/output. They are quite easy to write (though it is a regret that they
>> do not exist in the standard library).
>>
>
Received on 2023-12-23 08:50:29