near, far and huge pointers

Please tell me if i am right in my understanding of these terms:

near pointer : If the size of the program is very large the program may create a near pointer to a piece of frequently accessed memory so as to enhance performance.

But i am curious to know that so the near pointer is allocated/ created by the system rather than the user.

far pointer: If the program requires a lot of data, then a separate space is allocated for it outside the program data segment. So then a far pointer is used to access these memory locations so that the speed remains fast.

huge pointer: In an 8086 family of processors, the max. size of one data item can be 64k. But to override this default setup we can make use of huge pointers to have an object of size larger than 64k.

So this sums up what i tried to understand as i was reading a section on malloc. Also when the program executes an executable file is created. The memory allocation is that there is a code segment, data segment, space for global variables, free space for memory allocation and a stack where in the variables can reside as needed. So a separate stack is reserved for each program or is there a common stack area where partitions are done between the differetn progrrams?

Near and far pointers were part of the old Turbo C set up, for working within the limitations of DOS and the 16 bits per word, that was available at that time. The program had to request what it wanted, it didn't just "happen". You always got a near pointer unless you specifically requested otherwise.

I want to say it was AMD and their 80386 cpu design, that made this possible, but I could be wrong.

Those days are LONG gone. Whether your memory is flat or not, it should appear to the programmer, that the memory is flat. Of course, there will be holes in the memory, for every peripheral device on the system, and for the system itself. The powerful new graphics boards being particularly noted for this! :p

That much, hasn't changed much.

Your compiler creates the object file, the linker takes that and creates the executable, and you run the executable file. Yes, we still have stacks, and etc., reserved for the programs use, by the compiler.

But apparently you're using a 32-bit OS and a 32-bit compiler.
So the easy thing to do is just forget about it.

roann, like me, must be reading old books that are still pertinent about C, but reference (and sometimes dwell on) OS architectures of old.

near and far indicate that the pointer is relatively indexed or absolutely indexed, respectively. These concepts are relevant outside the context of 16-bit x86 segmentation. However, they are not a part of the C standard.

"huge" pointers, on the other hand, were an awful x86-only concept which emulated a 20-bit pointer which could be used to access anything in the first megabyte of memory. These pointers were extremely inefficient to use.

Quote:

---

Originally Posted by Dino

roann, like me, must be reading old books that are still pertinent about C, but reference (and sometimes dwell on) OS architectures of old.

---

I m reading A complete Reference on C by Herbert Schildt. But yes i suppose that the edition is old and thats why i sometimes use the turbo c stuff as well only to be pinpointed that its not valid anymore :-(

Quote:

---

Originally Posted by roaan

I m reading A complete Reference on C by Herbert Schildt. But yes i suppose that the edition is old and thats why i sometimes use the turbo c stuff as well only to be pinpointed that its not valid anymore :-(

---

Dude, since your location is the U S of A, you can order some relatively recent (last 5 years) C reference from amazon, used in paperback, for probably <$10 and get it by next Monday. All you need is a bank account.

I actually just checked and the 4th edition of that very book (2000 AD) is there for $8.79 -- but maybe you want to look around at some other stuff instead...just for fun ;)

http://www.amazon.com/gp/offer-listi...condition=used

In case you are worried, I've bought used things thru amazon; it's a third party thing, but users rate the resellers so your chances of getting ripped off are slim.

Probably yes you are right. The thing is that i got the book issued from the library. And if the books are cheap then it makes sense to order them instead of reading the old crappy stuff which does not hold true.

Oh,

this brings back memories of Turbo C and MS Quick C, back in 1988 when I started playing with C.

Even with those far pointers you could not play with memory above 640 K, so they invented extended and expanded memory but that was all just a big pain in the axx. Then windows came, but I missed that story because in 1992 I moved to Mac which never had these problems.

Here's a story by Larry Osterman I found today on reddit.

Quote:

---

Originally Posted by roaan

I m reading A complete Reference on C by Herbert Schildt. But yes i suppose that the edition is old and thats why i sometimes use the turbo c stuff as well only to be pinpointed that its not valid anymore :-(

---

Herbert Schildt is *infamous* for his errors in his C books. I read one of his books before I knew of this problem, and didn't find it too bad - but if you get into the details, that's where Herbert fails frequently. As far as I know, neither he nor his published/editor, have done anything to correct those errors, from edition to edition.

Let me recommend Ivor Horton's "Beginning C". It's easy reading, accurate, and shows how real world problems can be solved, from start to finish, at the end of each chapter. Two things it seems to miss (and most books on C seem to), is a good professional index (publishers now use indexing programs to save money and they're not great), and the fact that different struct instances can be copied (with all members), directly. Even K&R's white book just vaguely refers to it.

Quote:

---

Originally Posted by Adak

Herbert Schildt is *infamous* for his errors in his C books.

---

This is scary. But now i feel that one of the other books that i was using was as well full of some stupid errors. Let me try finding the book you suggested in the library.

Quote:

---

Originally Posted by roaan

This is scary. But now i feel that one of the other books that i was using was as well full of some stupid errors. Let me try finding the book you suggested in the library.

---

Or you could just wait for "More-or-Less Everything You Wanted to Know About C", by MK27, to hit the shelves. I am thinking it will have a scratch n' sniff component in the multiple choice quiz sections, for evaluating the reader's choices :p Hopefully all the money we save on indexing can pay for that.

Quote:

---

Originally Posted by MK27

Or you could just wait for "More-or-Less Everything You Wanted to Know About C", by MK27, to hit the shelves :p I am thinking it will have a scratch n' sniff component in the multiple choice quiz sections, for evaluating the reader's choices :p

---

Are you kidding or really authoring a book. Then we can have a compulsory registration that whoever wants to register on this forum needs to purchase that book as well
;)

Quote:

---

Originally Posted by roaan

Are you kidding or really authoring a book. Then we can have a compulsory registration that whoever wants to register on this forum needs to purchase that book as well
;)

---

No you will all be getting one in the mail and an appropriate deduction made from your credit card. Thanks gang!

ps. if you think I don't have the addresses yet, guess again :p

Quote:

---

Originally Posted by roaan

Probably yes you are right. The thing is that i got the book issued from the library. And if the books are cheap then it makes sense to order them instead of reading the old crappy stuff which does not hold true.

---

Unless you're into 20th-century-computer-history, you're probably wasting more time=money by reading that book than it's $0 pricing can make up for. You'll probably also pick up some stuff that you'll have to unlearn again, once your reading reaches the present :(.