Vivian Meazza wrote:
> I have the same problem with Main/renderer.cxx. Your solution (or
> one very like it) solves the problem. I guess near/far are reserved
> words in Cygwin?
Goodness, that brings back memories. The near and far keywords are
holdovers from 16 bit DOS compilers. They are still defined (as
noops) for compatibility with ancient code.
Basically, the 8086 had 16 bit registers, so a single instruction
could only address memory within a 64k range (which was defined by the
appropriate segment register). This 16 bit object was called a "near"
pointer. If you wanted to see things outside that range, you needed
to use multiple instructions to first load a segment register and then
execute the load.
(This really wasn't so insane if you think about it -- the original
idea for a typical was that all the code would go in a 64k segment,
the heap data in another and the stack in a third; this 192k address
space was larger than that available to Unix programs running on a
PDP-11, for instance. It seemed like a good solution at the time. It
didn't become a problem until typical interactive PC applications
started needed hundreds of kilobytes of address space. For 1976, it
was actually pretty elegant.)
In C, this notion was implemented by using a "far" pointer -- a 32 bit
object consisting of both a segment value and a pointer. The compiler
would know which instruction sequence to used based on the "type" of
the pointer it was using.
Anyway, yes: "near" and "far" aren't portably useful as variable names
if you want to compile on windows. I'm sure the MSVC headers have the
same problem that the cygwin one does.
Flightgear-devel mailing list