OSDev.org

Posted: **Tue Sep 04, 2007 6:59 am**

As i said it is just a small enoyance.

Posted: **Tue Sep 04, 2007 7:09 am**

Perhaps you misunderstood the

smiley. I meant I am mad at me when I start <my favorite emulator> and see a char popping up instead of an number. And I am pretty much aware of the fact that C++ had to be backwards compatible with C and am not mad at C++ for that. And I am aware that stdint.h is not standard C++ as of 2003, but iirc it will be in C++0x. I think I also read somewhere or saw it somewhere on google video that there will be a way to do strong typedefs, but I am not very sure about this...

Posted: **Tue Sep 04, 2007 4:03 pm**

Solar wrote:The only place I could think of where the "char-ness" of uint8_t actually makes a difference is exactly your cout example. And let's face it, if your application is primitive enough (not using "primitive" to be derogatory) to use cout for output, you can be expected to do those couple of casts instead of turning half the language inside out to "fix" what is a minor nuisance.

That was my point, because uint8_t is defined as

Code: Select all

typedef unsigned char uint8_t;

The operator for "<<" in cout takes a char argument (among others) - guess what uint8_t translates into?

I must ask though, what is the context for using such a small type, why not just use a 32-bit integer (unless size is important, in which case I think cout is not the way forward).

I really must stop replying to this thread....

Posted: **Tue Sep 04, 2007 4:10 pm**

pcmattman wrote:I must ask though, what is the context for using such a small type, why not just use a 32-bit integer (unless size is important, in which case I think cout is not the way forward).

I believe i have allready answered that question, but basicly im a perfectionist. Yes its true, the use of cout is not the best way of doing things, but i am somewhat inexperienced.

Again i do not NEED an 8 bit integer type, it is just curious that it doesnt exist. Again i know that char is an integer type, but it still acts different, and it just seems wrong!

I really should allso stop replying...

Posted: **Tue Sep 04, 2007 4:13 pm**

Zacariaz wrote: Again i do not NEED an 8 bit integer type, it is just curious that it doesnt exist. Again i know that char is an integer type, but it still acts different, and it just seems wrong!

This is my last one (I hope)...

OK, the type does not act differently, the cout class uses it differently. The type is nothing more than a way of saying what type of data at the memory address.

Posted: **Tue Sep 04, 2007 4:20 pm**

Yes i figured that out by now, but thats not the point. I dont supose it would be hard to get the cout class to treat fx. uint8_t as an 8 bit ingeter instead of a 8 bit char? Why not have both?

Posted: **Tue Sep 04, 2007 11:00 pm**

bluecode wrote:And I am aware that stdint.h is not standard C++ as of 2003, but iirc it will be in C++0x.

No, cstdint is the standard header for that purpose, with all the contents in namespace STD as they should be.

I think I also read somewhere or saw it somewhere on google video that there will be a way to do strong typedefs, but I am not very sure about this...

Code: Select all

template <class T>
class StrongTypedef {
  private:
    T _val;
  public:
    StrongTypedef(const T &val) { _val = val; }
    const T &value() { return _val; }
    // other operators as required, probably lots
};

typedef StrongTypedef<uint8_t> byte;
[/quote]

Your optimizer will remove this class and just use it as a typedef. I think if you add a back conversion operator it'll break down (since you can ad-hoc convert back & forth, so it won't bother doing the right thing). You can make the constructor explicit but it makes it a bit more tedious.

Posted: **Tue Sep 04, 2007 11:44 pm**

Zacariaz wrote:Yes i figured that out by now, but thats not the point. I dont supose it would be hard to get the cout class to treat fx. uint8_t as an 8 bit ingeter instead of a 8 bit char? Why not have both?

Because the typedef of uint8_t translates into unsigned char... It's like doing this:

Code: Select all

#define uint8_t (unsigned char) // the same as typedef unsigned char uint8_t

Posted: **Tue Sep 04, 2007 11:56 pm**

Zacariaz wrote:Again i know that char is an integer type, but it still acts different, and it just seems wrong!

Again: It's not "char" that behaves different, it's cout. Because in 99% of the cases you cout a 8-bit-value, you want the character printed, not the value, so that this is the default behaviour.

Posted: **Wed Sep 05, 2007 10:19 am**

Solar wrote:
Zacariaz wrote:Again i know that char is an integer type, but it still acts different, and it just seems wrong!
Again: It's not "char" that behaves different, it's cout. Because in 99% of the cases you cout a 8-bit-value, you want the character printed, not the value, so that this is the default behaviour.

You should be able to add overloads to cout for unsigned and signed chars, as the default char is neither and the three types should be treated as separate (for purposes of name mangling and overloading). I do expect unsigned char to degenerate to char.

OSDev.org

int versus long