i want to know about far heap and near heap
and far poniter and hug poniter
thx
i want to know about far heap and near heap
and far poniter and hug poniter
thx
As far as I know, hug ponitor was the yellow bear from Care Bears. far ponitor was his girlfriend. There wasn't much character development so I can't say too much more about them.
If you understand what you're doing, you're not learning anything.
har har
m_adel I assume you are using a compiler like Turbo C? Well don't and you won't even have to worry about far and huge.
Far and huge pointers are hold-overs from the era of 16 bit computing. Back in the day of DOS and Win3.11 CPU registers were 16 bits, and pointers were only 16 bits as well. If your program needed more than 64K of addressable memory, a 16 bit pointer would not work (remember 16 bits can only count to 65535). Therefore there were far and huge pointers which were 32 bits in size and which used two registers. Once computers passed into the realm of 32 bit computing, far and huge pointers became redundant since now all pointers are 32 bits.
I wouldn't go that far. I'm sure you've heard that there are 64bit processors out?far and huge pointers became redundant since now all pointers are 32 bits.
Quzah.Originally Posted by AMD
Hope is the first step on the road to disappointment.
ptrdiff_t should be a suitable datatype type for a pointer under all architectures.
On HPUX PA RISC boxes ptrdiff_t correctly defined in both 32 and 64 bit implementations. And on the same machine. For example.
Huh?
Code:itsme@dreams:~/C$ cat ptrdiff.c #include <stdio.h> int main(void) { ptrdiff_t foo; return 0; } itsme@dreams:~/C$ gcc -Wall ptrdiff.c -o ptrdiff ptrdiff.c: In function `main': ptrdiff.c:5: `ptrdiff_t' undeclared (first use in this function) ptrdiff.c:5: (Each undeclared identifier is reported only once ptrdiff.c:5: for each function it appears in.) ptrdiff.c:5: parse error before `foo' itsme@dreams:~/C$
If you understand what you're doing, you're not learning anything.
Code:#include <stddef.h>
7. It is easier to write an incorrect program than understand a correct one.
40. There are two ways to write error-free programs; only the third one works.*
Ahh...works now =)
If you understand what you're doing, you're not learning anything.
