Why doesn't uint8_t and int8_t work with file and console streams?

Question

$ file testfile.txt
testfile.txt: ASCII text

$ cat testfile.txt 
aaaabbbbccddef

#include <iostream>
#include <fstream>
#include <string>
#include <cstdint>
typedef uint8_t byte; // <-------- interesting
typedef std::basic_ifstream<byte> FileStreamT;
static const std::string FILENAME = "testfile.txt";
int main(){
    FileStreamT file(FILENAME, std::ifstream::in | std::ios::binary);
    if(!file.is_open())
        std::cout << "COULD NOT OPEN FILE" << std::endl;
    else{
        FileStreamT::char_type buff;
        file.read(&buff,1);
        std::cout << (SOMECAST)buff; // <------- interesting
    }
    std::cout << "done" << std::endl;
}

Depending on what is in the typedef and what is it casted to (or not casted), it does all sorts of stupid things.

It happens to work with 'typedef char' and no cast. (97 when casted to int, as expected)

Both uint8_t and int8_t will print

nothing without cast
nothing when casted to char or unsigned char
8 when casted to int or unsigned (although ASCII 'a' should be 97)

I somehow managed to print a "�" character, but forgot which case it was.

Why do I get these strange results?

notes for the future reader:

takeaway from the answer given: only instantiate streams with char (or one of the wide characters also mentioned by the standard), otherwise you get no compiler warning and silent failure

it is very sad that the standard warrants these things

moral of the story: avoid C++

@Rapptz: what you linked is helpful, thanks, remark: uint8_t is not by definition equivalent to unsigned char, it just happens to be the most common way of implementing it in the cstdint header — user1358, Jul 26 '13 at 07:05
@Rapptz: But that question did not answer everything I asked. Especially why am I getting the number 8, instead of 97. And I would like someone to confirm that typedef influences whether template specialization gets chosen or not. — user1358, Jul 26 '13 at 07:18
Have you confirmed that you can emulate this with using `int8_t` rather than `uint8_t`? — Rapptz, Jul 26 '13 at 07:30
typedef int8_t byte; ...; cout << buff << endl << (char)buff << endl << (int)buff << endl; results in � � -73 — user1358, Jul 26 '13 at 09:06

Mike Kinghan · Accepted Answer · 2013-07-30T21:38:41.810

The declaration of template std::basic_ifstream is:

template< 
    class CharT, 
    class Traits = std::char_traits<CharT>
> class basic_ifstream;

The C++03 Standard (21.1/1) requires the library to define specializations of std::char_traits<CharT> for CharT = char, wchar_t.

The C++11 Standard (C++11 21.2/1) requires the library to define specializations of std::char_traits<CharT> for CharT = char,char16_t,char32_t,wchar_t.

If you instantiate std::basic_ifstream<Other> with Other not one of the 2[4] types nominated by the Standard to which you are compiling then the behaviour will be undefined, unless you yourself define my_char_traits<Other> as you require and then instantiate std::basic_ifstream<Other,my_char_traits<Other>>.

CONTINUED in response to OP's comments.

Requesting an std::char_traits<Other> will not provoke template instantiation errors: the template is defined so that you may specialize it, but the default (unspecialized) instantiation is very likely to be wrong for Other or indeed for any given CharT, where wrong means does not satisfy the the Standard's requirements for a character traits class per C++03 § 21.1.1/C++11 § 21.2.1.

You suspect that a typedef might thwart the choice of a template specialization for the typedef-ed type, i.e. that the fact that uint8_t and int8_t are typedefs for fundamentals character types might result in std::basic_ifstream<byte> not being the same as std::basic_ifstream<FCT>, where FCT is the aliased fundamental character type.

Forget that suspicion.typedef is transparent. It seems you believe one of the typedefs int8_t and uint8_t must be char, in which case - unless the typedef was somehow intefering with template resolution - one of the misbehaving basic_ifstream instantiations you have tested would have to be std::basic_ifstream<char>

But what about the fact that typedef char byte is harmless? That belief that either int8_t or uint8_t = char is false. You will find that int8_t is an alias for signed char while uint8_t is an alias for unsigned char. But neither signed char nor unsigned char is the same type as char:

C++03/11 § 3.9.1/1

Plain char, signed char, and unsigned char are three distinct types

So both char_traits<int8_t> and char_traits<uint8_t> are default, unspecialized, instantiations of template char_traits and you have no right to expect that they fulfill that Standard's requirements of character traits.

The one test case in which you found no misbehaviour was for byte = char. That is because char_traits<char> is a Standard specialization provided by the library.

The connection between all the misbehaviour you have observed and the types that you have substituted for SOMECAST in:

std::cout << (SOMECAST)buff; // <------- interesting

is none. Since your testfile contains ASCII text, basic_ifstream<char> is the one and only instantiation of basic_ifstream that the Standard warrants for reading it. If you read the file using typedef char byte in your program then none of the casts that you say you substituted will have an unexpected result: SOMECAST = char or unsigned char will output a, and SOMECAST = int or unsigned int will output 97.

All the misbehaviour arises from instantiating basic_ifstream<CharT> with CharT some type that the Standard does not warrant.

but my Other type was a typedef of char in one of the test cases and it failed silently, I did not get template instantiation errors (used -std=c++0x with g++ 4.6.3), ? do typedefs prohibit proper template specialization ? — user1358, Jul 26 '13 at 09:10

Why doesn't uint8_t and int8_t work with file and console streams?

notes for the future reader:

moral of the story: avoid C++

1 Answers1

Linked