OSDev.org

hckr83 wrote:according to some doc I read by microsoft about how to keep 32bit apps portable to 64 bit...

it said that char is 8bit(of course) short is 16bit, int is 32bit(to avoid wasting space) long is 64bit, didn't say anything on long long

hckr83 wrote:that was all done for example sake, but ptr=ptr+core is what gives the error, now I know I could do something like ptr=(unsigned int)ptr+(unsigned int)core; but this won't work when I port it to 64bit so is there a way to do this portably?

ret = PointerOp(ptr1,+,ptr2);

void *AddPointers(void* ptr1, void *ptr2)
{
unsigned char *c_ptr1, *c_ptr2;
c_ptr1 = (char*)ptr1;
c_ptr2 = (char*)ptr2;
return (void*)(c_ptr1+cptr2);
}

hckr83 wrote:What I use this for is for my emulator..
core points to allocated memory which is for the emulators ram
basically this is only an example thing to access a byte of memory

ret = PointerOp(ptr1,+,ptr2);

that's just too ugly for me...I want for my code to be at least half readable for people that want to look at my code...

void *AddPointers(void* ptr1, void *ptr2)
{
unsigned char *c_ptr1, *c_ptr2;
c_ptr1 = (char*)ptr1;
c_ptr2 = (char*)ptr2;
return (void*)(c_ptr1+cptr2);
}

that puts too much overhead..even if I did it inline then it still has to create a stack frame and add 8 to ebp....which though is only a few clock cycles..if I did that for every pointer it would add up to millions of extra clock cycles that are wasted in a normal emulated program...

template <class T>
class safe_ptr {
    public:
        inline safe_ptr<T> operator+(const safe_ptr<T> &other) {
            return safe_ptr<T>(_ptr + other._ptr);
        }
        inline operator safe_ptr<U>() {
            return safe_ptr<U>(_ptr);
        }
    private: 
        T _ptr;
};

safe_ptr<char *> lpchar1, lpchar2((char *)0xB8000);

lpchar1 = lpchar2 + (char*)0x240;

hckr83 wrote:according to some doc I read by microsoft about how to keep 32bit apps portable to 64 bit...

it said that char is 8bit(of course) short is 16bit, int is 32bit(to avoid wasting space) long is 64bit, didn't say anything on long long

Ready4Dis wrote:Just wanted to show you a quick link, notice the long long data type, and the size of a regular long, etc. Keep in mind, these are specific to the microsoft compiler (vc++), but the basic types are identical on gcc x86-32 as far as I can see . Ok, just read a quick thing on the gcc compiler in 64-bit mode, lol, they use 32-bit ints and 64-bit longs.

http://msdn2.microsoft.com/en-us/librar ... S.80).aspx


Here is the actual standard defining the types:
http://msdn2.microsoft.com/en-us/librar ... S.80).aspx

Notice it says int must be greater than or equal to short, and must be smaller than or equal to a long. This explains why gcc 64 used a 32-bit int. Notice there are no hard definitions or predefined sizes, a char could be 16-bits, and a short,int,long could all be 64-bits, and a long long could be 512-bits, it would still fit the 'standards'. I bet it would break tons of pre-existing code though. Like I said a bunch of times already, define your own sizes, or use the pre-existing ones (someone else pointed out that there are types that have their sizes in them, but they don't define a default size for arithmetic types that deal with pointers, so you'd have to add that one).

Candy wrote: Guys - Microsoft did not define nor invent C++! Nor do they hold any authority over it whatsoever.

Try ISO 9899 or ISO 14882.


For your information:
Char must hold at least 256 different values, short must hold at least 65536 different values, int must be larger than or equal to short, long must be larger than or equal to int and long long must be larger than or equal to long. Note that long long is only defined in C99, so in C89 or in c++ there is no long long (which should explain the warnings/errors you get when turning on warnings for c++ code).

So, all in all, you can't assume you can add two shorts and fit it in a long long.

Ready4Dis wrote:Sorry if my post was misleading, I know that is the MS interpretation of the standard, and not a link to the standard itself. But, it states the exact same info you have stated...

"Type short int (or simply short) is an integral type that is larger than or equal to the size of type char, and shorter than or equal to the size of type int."

"Type long long Larger than an unsigned long."

This is consistant with the standard, even if it is a m$ document. The other parts of the document are specific to their implementation (at the bottom where it says sizes of fundamental types, those are specific to msvc), and can be different under other compilers and still fit the above descriptions. Notice on the page however, it actually states Microsoft Specific before that section, and End Microsoft Specific at the bottom, so I figured it'd be an easy to read link for people. We do agree that you cannot assume sizes based on 'standard' data types, which is why I define my own, and use the # of bits in the name, so anybody reading will always know it's size and type. s8 = signed 8-bit, u8 = unsigned 8bit, sX = signed X bits, uX = unsigned X bits. Anybody reading my code will easily know what the size of all data types being passed around are.

IIRC, char can be defined larger than short. Not sure on this one. It also DOES specify a minimum size for a short, which Microsoft doesn't.