Upto now the only different I can notice is the vary of the size of data type. At home I have a 64-bit CPU, running a 64-bit linux OS, my school equip with an also 64-bit CPU, but 32-bit Window version.
When I use dev-C++ on school's PC, runing the code
I get:

On my home PC with GCC 4 and Fedora 8 64-bit, things are different.
I can remember that
size of int is still 4, but size of long is 8, size of long double is 16 and size of int* is 8.
I will post the details output here when I come home. And If I have time, I may post the output produce by Turbo C 3.0 running on ntvdm (nt virtual dos machine) as well.

But anyone please explain why do we get that different? how can we cope with it, I mean do I have to memorize all the size on every system?
Is there any more different that I have to notice?

But that's a pretty big difference. For instance, the address-space is bigger.

The only place you will really feel the difference is in machine code... which is as it should be.

http://en.wikipedia.org/wiki/64-bit

Technically you can have 64-bit instructions too... increasing the theoretical number of machine instructions available.

There are all kinds of sneaky things this difference can bring about. From the various things i've picked up on my days browsing the gentoo AMD64 forums, the biggest improvements come in database access and encryption. This makes sense because these all crunch huge amounts of numbers.

As for C and C++ (I only know C at the moment) there are some ways to programm for any environment. For example, don't bother memorizing the length of a str on each system. Instead always use sizeof() this way if you need to port your system to different environment it is easy. If your worried about the processor overhead of calling the function everytime (which I imagine is nominal) you could set the double size or int size as a constant using sizeof(). The places where 32-64bit comes in are when you start bitshifting or masking. As it is if you need to use a single int for multiple purposes (like holding several different values) which I've done in the past, 64bit will allow you more room. sneaky sneaky

Here is the size of some data types on my 64-bit system at home.
Compile the above code with g++
Target: x86_64-redhat-linux
gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
so the question is why on my 64-bit box size of int is still 4, I think it sould be twice the size of int on 32-bit box?
Moreover, on the 32-bit box size of int and size of long is equal?

And if we looking forward, Visual C++ 6.0 compile that code and out put different from Dev-C++, on VC 6.0 size of long double is 8 (equal to double).
And if I use Turbo C on NT Virtual Dos machine, I get:

Does it exist an explanation for all these above question? Do I have to memorize all these size on every system? And would I cope with that problem, may anything happen if I code something at home, it run fine, but when my teacher test it at school and things go wrong?

sizeof() is not a function, the compiler will replace sizeof() with the appropriate value when compiling.

See http://en.wikipedia.org/wiki/C_varia...larations#Size
You should write your programs so that it doesn't matter what the exact size of each type is. You should always test it at school before your teacher marks it.

[QUOTE=TruongAn;2993155]Here is the size of some data types on my 64-bit system at home.
Compile the above code with g++
Target: x86_64-redhat-linux
gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
so the question is why on my 64-bit box size of int is still 4, I think it sould be twice the size of int on 32-bit box?
Moreover, on the 32-bit box size of int and size of long is equal?
QUOTE]

Hi

I believe that there is no prescribed size for an integer in the C programming language, and I've always maintained that the size of an INT is processor-dependent. Whether your impression is correct or not doesn't really matter; a far better approach to any problem is to define your own types either as:

typedef int32 int,

or//

#define int32 int

And these definitions, along with others (e.g. you may have a variety of unsigned and signed integer types such as:

int8, int16, int32
uint8, uint16, uint32

and maybe even a bool that only takes 8 bits of storage instead of the usual 32. (Compiler dependent)

If you follow this approach you should put these definitions into a header file and establish a convention that EVERY source file must include this header file at a minimum. That way, your code becomes more portable; during testing, if you discover that int32 is no longer an int on your machine/compiler - i.e. maybe it's suddenly 8 bytes instead of 4, then you only need to rewrite your header file and then recompile the whole system. That should fix the problem.

Never depend upon the compiler's built-in types in "C" if it matters to your solution that the size of a variable must be 1, 2, 4 or 8 bytes.

My $.02

Regards

Peatmoss/Alleria

TruongAn: what you are saying is that different compilers have different default data sizes. Why should this not be the case? You'll notice that wheel size is different on different cars...

Thanks ntubski that is good to know.

Here is a good article which shows the problems and how to overcome them when coding for 32 and 64 bit systems. See the link to the author's site for more of the same.