1 byte int, not using char

**Elkvis** · 07-27-2010

since this is the C++ forum, why not just write a class that implements the functionality that you require? you could have it still only take 1 byte of storage (ideally) if you only have a char as your only private data member.

here's just the beginning of such a class, still missing much of its functionality:

Code:

#include <iostream>

class TinyInt
{
public:
	TinyInt(char c);

	bool operator == (char c);
	bool operator == (const TinyInt& ti);

	int GetValue() const { return m_char; }
private:
	char m_char;
}

std::ostream& operator << (std::ostream& os, const TinyInt& ti)
{
	return os << ti.GetValue();
}

just an idea, and a bit of code to get you started.

**brewbuck** · 07-27-2010

I know a good anger management counselor...

**anon** · 07-27-2010

Minimally the class could be just

Code:

#include <iostream>

class Int8
{
    signed char value;
public:
    Int8() {}
    Int8(signed char value): value(value) {}
    operator signed char() const { return value; }
};

std::ostream& operator<< (std::ostream& os, Int8 value)
{
    return os << static_cast<int>(static_cast<signed char>(value));
}

std::istream& operator>> (std::istream& is, Int8& value)
{
    //this is actually the tricky part
    return is;
}

int main()
{
    Int8 a = 10, b = 20, c;
    c = a + b;
    if (c == 30) {
        std::cout << c << '\n';
    }
}

You just want a separate type, so you can overload operators<< and >>, otherwise it is no different from a signed char.

**laserlight** · 07-27-2010

I do not see the point of defining a class when defining a function would suffice. (Okay, unless that class was for a function object, and you were trying for a better chance at function inlining.)

My point is this: if you are really wholly concerned about C++ the language rather than solving a problem in the context of C++, then you need to recognise that I/O is delegated to the standard library, not the core language. Therefore, talking about the state of C++ with respect to "a 1 Byte data type which, by default, will display as an integer" does not make sense.

Now, if you approach this as a problem to solve in the context of C++, you can see that the key is to use some library functionality that prints a char the way you want it to. It turns out that converting the char to an integer type of greater rank allows you to use existing standard library functionality to solve the problem, so you might as well go ahead and extend this functionality with your own function. You could go further along the lines of "a 1 byte data type", but that is more work for no benefit when we consider what you actually want to solve.

**kermit** · 07-27-2010

Originally Posted by since

char a = 96;
cout << a << endl;

What do you think the output is? I want it to be the integer 96, but it just won't be.

Here you go

:

Code:

#include <cstdio>

int main()
{
        char c = 96;

        printf("%d\n", c);

        return 0;
}

**cpjust** · 07-27-2010

Originally Posted by since

Anyone know of a library which defines a 1 byte int? The problem I have with using char is that the output (cout << charvar) is interpreted as a character. I don't like having to cast unsigned/signed chars as an int or short int.

There has to be a way to do arithmetic with 1 byte data types and display the integer values (cout << onebyteint) without needing to cast the char to a 2 or 4 byte data type.

Anyone?

If you would've done a simple search, you would've found an answer to your question here:

[Don't overdo it - CornedBee]

**iMalc** · 07-28-2010

Originally Posted by since

So what you're telling me is that in C++ there is no such thing as a 1 Byte data type which, by default, will display as an integer?

To be direct, and factual... the issue you have here is not to do with the data type itself. The issue is that the authors of the language have chosen to make the operator << char overload of an ostream display the byte as it's printable ASCII representation. You can easily write your own wrapper over top of cout which has a different behaviour for its own operator <<.
If you would like help with how to do that then just ask nicely

**new_ink2001** · 07-28-2010

Since,

From what I recall about Computer Architecture, the size of the integer is based on the memory management unit of the computer. A pointer and an integer are the same size (period)...not something that one can quickly modify. Of course, I think that the 8086's were using 16/20 bits (Intel 8086 - Wikipedia, the free encyclopedia), but that's beside the point.

Thus, if one were counting bits, I would suggest writing an eight bit bit field (or even using a char) and then providing wrappers for it. Wrappers for addition, subtraction, etc and of course I/O. Unless you're working on an emulator...more on that later.

When you do the cast, to which you seem to so object, you are merely telling the I/O library how to format the "variable," whether it's size less than or equal to the size of the indicated format isn't relevant -- it's only going to use the lesser of the format's size or variable's size. Such is the case with the printf("%d", c) suggestion made earlier by Kermit...the I/O library isn't going to use more than the 8 bits associated with the variable 'c' from the program's data section (period). Test it out on a long sometime, printing it as a char...that would be a sort of masking -- only printing a char's width of the long from memory.

I am speculating now, but I believe it has something to do with the alignment of the atom in memory (back to the pointer/integer nostalgia). I determine this from the various screen modes, 640x480x8 and so on.... I imagine that the graphics programmers may have encountered such a library (that uses a one byte whole number for color metrics), but I don't recall one at the moment. I'll go root around in the copy of OpenMESA that I keep around and see. They wouldn't call it an integer though, I'd expect their lexicon to use something like pixel or color.

At any rate it would be a misnomer to demand a one-byte integer, as the integer is a "numeric" interpretation -- like an element of Z (Zahlen) or C (Complex) from Algebra. But rather to solicit the hardware to print one-byte of an arbitrary piece of memory (in the case of I/O). In the sense of architecture one would be talking about a memory management unit that can only access about 512 words each 1-byte long.

(The emulator stuff) One can manipulate the compiler library to use one byte representations for pointers/words (I think that the professor used word to distinguish the collection of bits from it's interpretation) -- I imagine that such would be useful for emulators. The old console game stations for example used small word sizes at the assembly/hardware level. That would require manipulating the compiler's source code, and recompiling it for the intended application -- like my Atari program compiler for example. Similar to the embedded practices of today.

In summary, I have to agree with laserlight and advise you to "...just do [the cast]." It doesn't sound like you're writing emulators, and I would be concerned for my computer hardware trying to execute something with an unorthodox memory arrangement. Memory management units/processors can be broken...I've done it.

Best Regards,

New Ink -- Henry

**Elysia** · 07-28-2010

Originally Posted by new_ink2001

...A pointer and an integer are the same size (period)...

That is incorrect. A pointer and an int does not necessarily have to be the same size.
Windows x64's integers are 4 bytes and its pointers are 8 bytes. That disproves that right there.

**new_ink2001** · 07-28-2010

Thank goodness some one found a contradiction....

I wonder if the "x64" to which we refer are running legacy mode or not, that is what compiled (32-bit or 64-bit) the program being loaded onto the processor. Because (void *p) looks a lot like int p when I tell the compiler to do that...is what I meant to convey. I apologize that I failed to do that during the discussion about Architecture. The contrast was to inquire about clarification on the thread.

A few years ago (three or four), the pointer and the integer (machine word and a whole number) were symmetric for points like backward compatibility or demonstration. But I found synchronizing parallel processors interesting, and I haven't spent a lot of time with the new stuff (like adding cables to the bus for more bits or cores that aren't used by the executable). The most accessible reference I have for current executable format and usage of space -- Object file - Wikipedia, the free encyclopedia although Silbersach and Gavin did mention them and provide insight.

The Wikipedia is all that I can afford to use as a reference at the moment for information about 64-bit processors -- assuming/acting the good stuff is still obscured under proprietary license. Although, I keep some nice books with copyrights in the first half of 2010, and I muse about implementation of 64 bits -- I do really like to read about this.

The article that I pulled was: x86-64 - Wikipedia, the free encyclopedia, but it doesn't say what compiler was used for the size of a register/interpretation...just the size of the hardware implementing it -- notably in the section about "Differences between AMD64 and Intel 64" ...a hardware issue. That was the point to which I progressed later.

Best Regards,

new_ink2001

**Sebastiani** · 07-28-2010

Originally Posted by since

Anyone know of a library which defines a 1 byte int? The problem I have with using char is that the output (cout << charvar) is interpreted as a character. I don't like having to cast unsigned/signed chars as an int or short int.

There has to be a way to do arithmetic with 1 byte data types and display the integer values (cout << onebyteint) without needing to cast the char to a 2 or 4 byte data type.

Anyone?

Code:

typedef signed char sbyte;
    
inline ostream& operator << ( ostream& out, sbyte val )
{
    return out << int( val );
}

typedef unsigned char ubyte;

inline ostream& operator << ( ostream& out, ubyte val )
{
    return out << unsigned( val );
}
    
int main( void )
{
    sbyte s = -128;
    cout << s << endl;
    ubyte u = 128;
    cout << u << endl;
}

**cyberfish** · 07-28-2010

On x86-64, a pointer is 8 bytes and an int SHOULD be 8 bytes also because that's the register size (and the architecture's natural width). But all compilers I know uses 4 bytes ints on x86-64 for backward compatibility. And long would be 32-bit or 64-bit depending on compiler, but long long is always 64-bit.

Making int 8 bytes would also make it impossible to have a smaller type.

If int is 8 bytes, short int would have to be 4 bytes, and char 1 byte by definition. What do we call a 2 bytes int then? short short?

We will have even more fun when we switch to 128-bits.

I personally believe it's an oversight in the design of the language, but of course, I wouldn't have thought of this 30 years ago either when 32-bit machines were unthinkable.

**anon** · 07-28-2010

Sebastiani, that's simple but doesn't that also interfere if you actually wanted to print characters?

Code:

int main( void )
{
    sbyte s = -128;
    cout << s << endl;
    ubyte u = 128;
    cout << u << endl;
    char d = 'a';
    cout << d << endl;  //outputs 97!!
}

If int is 8 bytes, short int would have to be 4 bytes, and char 1 byte by definition. What do we call a 2 bytes int then? short short?

long char?

**Elysia** · 07-28-2010

Originally Posted by cyberfish

On x86-64, a pointer is 8 bytes and an int SHOULD be 8 bytes also because that's the register size (and the architecture's natural width). But all compilers I know uses 4 bytes ints on x86-64 for backward compatibility. And long would be 32-bit or 64-bit depending on compiler, but long long is always 64-bit.

Making int 8 bytes would also make it impossible to have a smaller type.

If int is 8 bytes, short int would have to be 4 bytes, and char 1 byte by definition. What do we call a 2 bytes int then? short short?

We will have even more fun when we switch to 128-bits.

I personally believe it's an oversight in the design of the language, but of course, I wouldn't have thought of this 30 years ago either when 32-bit machines were unthinkable.

Hmmm. C++0x defines data types that depends on its size.
Like int8_t is an integer with 8 bits (I don't know what they're actually called in the standard, though).
That should "solve" this problem.
I don't know if any compilers implement these types.

**Sebastiani** · 07-28-2010

Originally Posted by anon

Sebastiani, that's simple but doesn't that also interfere if you actually wanted to print characters?

Code:

int main( void )
{
    sbyte s = -128;
    cout << s << endl;
    ubyte u = 128;
    cout << u << endl;
    char d = 'a';
    cout << d << endl;  //outputs 97!!
}

long char?

Yes, that does pose a problem, doesn't it?