47

What is difference between our usual pointers(ones which we normally use), near pointers and far pointers and is there a practical usage for near and far pointers in present day C/C++ systems? Any practical scenario which necessiates use of these specific pointers and not other c,c++ semantics will be very helpful.

Alok Save
  • 202,538
  • 53
  • 430
  • 533
  • 1
    @sbi Exactly, never seen or used them over my professional experience and just ensuring I am not missing out on not knowing about them :) – Alok Save Oct 06 '10 at 06:06
  • But they are in `C` and not in `C++`... isn't?? Or am missing something?? – liaK Oct 06 '10 at 06:14
  • 4
    @liaK: They're not in either. They're in some bogus implementations of both, and such implementations are nonconformant if they use `near` and `far` as keywords (whereas they could be conformant if they use `__near` and `__far` or `_Near` and `_Far`). – R.. GitHub STOP HELPING ICE Oct 06 '10 at 06:17

2 Answers2

64

The near and far keywords have their origin in the segmented memory model that Intel had before. The near pointers could only access a block of memory originally around 64Kb in size called a segment whereas the far pointers could go outside of that range consisting of a segment and offset in that segment. The near pointers were much faster than far pointers so therefore in some contexts it paid off to use them.

Nowadays with virtual memory near and far pointers have no use.

EDIT:Sorry if I am not using the correct terms, but this is how I remembered it when I was working with it back in the day :-)

A Guest
  • 1
  • 2
AndersK
  • 35,813
  • 6
  • 60
  • 86
  • 3
    Nowadays, "near" pointers are still useful -- in fact, that's the kind of pointer that we just call a "pointer" now. It's still possible to create a far pointer, but it's nearly useless in most 32- or 64-bit OSes. – cHao Oct 06 '10 at 06:15
  • 6
    @cHao: Actually, no. In C and C++ they are called __pointers, and only pointers__. It was but one processor architecture that required compilers tailored for it to introduce non-standard extensions. – sbi Oct 06 '10 at 06:23
  • 10
    @sbi: They were common enough to be a de-facto standard, ISO and ANSI be damned. Thank gawd they're gone, but while they were around, every useful C and C++ compiler in the x86 world (read: one of the most common and most important architectures in existence) had to have them. That they weren't in the ISO/ANSI standards doesn't make them any less important, or any less "standard" in the real world. – cHao Oct 06 '10 at 06:36
  • 5
    @cHao: I disagree. Every useful compiler back then had a "huge" memory model, and if you compiled with that, the `far` keyword was completely unnecessary and you could basically just write sane C code and pretend you had a halfway-usable amount of linear memory. – R.. GitHub STOP HELPING ICE Oct 06 '10 at 06:48
  • 6
    @R.. Except that doing so would lead to pointers being a lot slower, as (1) they were far pointers anyway, whether you needed one or not, and (2) there was always some adjustment going on to preserve that illusion of a huge chunk of linear memory. I'd personally think the "huge" memory model to be the last of last resorts for anyone who really had to care about performance (which, back then, was just about everyone). And either way, the `far` keyword was there, and any 16-bit compiler that didn't have it was 'substandard'. – cHao Oct 06 '10 at 07:55
  • And I'd think writing `far` in code would be the last of last resorts for anyone who put any worth on portable code, which sadly was the vast minority of x86 coders... – R.. GitHub STOP HELPING ICE Oct 06 '10 at 08:05
  • 2
    Portability isn't worth sacrificing that kind of performance, especially when you're writing code *for a PC*. Almost every PC on earth runs x86. There simply weren't other platforms worth caring about at the time, and even today it's still a stretch (though 32-bit x86 CPUs leveled the playing field, making segments less blatant and almost useless). If your program is for DOS and/or Win3.x and/or some DOS extender and/or whatever other 16-bit environment on x86, and you don't take that platform into account, your code will be slow as balls. – cHao Oct 06 '10 at 18:42
  • I just saw the far pointer in windef.h in Windows Mobile 5.0 SDK R2 Arm4i, so still used – Snake Sanders Aug 20 '13 at 09:02
  • 1
    @cHao: "There simply weren't other platforms worth caring about at the time" -- Back when `near` and `far` pointers were relevant for x86, I was doing most of my programming on Sun SPARC systems. – Keith Thompson May 13 '15 at 15:36
  • 4
    @KeithThompson: I'm sure there were a few of you guys. I remember wanting a SPARC myself once upon a time. But i'm also pretty sure most of the world didn't even know Sun existed til Java happened. :) – cHao May 14 '15 at 11:56
3

Near and far is spoken in the context of machine architecture (x86, x64, 640kb + model of memory, x32 in mean of the protected mode and segmented, x86 in terms of segmented memory)

Example: Given a system with 32 bit "long" addressing and 8-bit relative addressing. The relative distance would allow for at least 127 bytes in the forward (positive value) or previous (negative) direction. If the target is 1024 bytes away, a full 32-bit pointer must be used.

Nowadays only x86 x32 addressing - a long pointer and x64 64 bit addressing are having and taking (permanent) place. Yes, a x64 in windows is compiled by MS VC the way it "sees" still like x86 x32 application ONLY 4Gb of memory. So you do not know by the default the difference between near and far or some other addressation. BUT x64 target has the ability to address the memory using the other, long long type of pointer.

As you see there is no practical scenario in MS VC if you do not "see" the variant of the x64 addressing over x32 in the different pointers. Just a hypotetics.

Staying away from this practical uses are LP_STRING - long pointer towards the string and INT_PTR - integer holding a value of pointer.

First you must understand, that CPU and compiler accepts the set of pointers-to-use sizes. And only them. You can't find a way round them without additional compilers/linkers/hardware. INT_PTR - is just for storage of the pointers that does not exceed int in length (a value of pointer, where pointer length is not greater than int). and LP_STRING - is just long type of pointer of the compiler/processor (they both like abstractions and compiler is not equal in the behaviour to the compiler, as well as x64 can be Intel rarely used one and widely used AMD).

ANY size of variable can be a pointer.

You just need a practical example against AMD x64 and LLP (long long pointer).

Angelic C
  • 41
  • 3