Re: New developer with a couple of questions

On Jun 15, 8:23 am, Mingos <dominikmarc...@xxxxxxxxx> wrote:
On 15 Cze, 06:52, Ray <b...@xxxxxxxxx> wrote:





Gelatinous Mutant Coconut wrote:
On Jun 14, 12:26 pm, Ray <b...@xxxxxxxxx> wrote:
Gerry Quinn wrote:
Say your map is 60x60 (typical), then you only have 3600 x 2 = 7200
pointers = 30 Kb.  A trivial amount!

I get 56.25 kbytes, unless you're using "near" pointers (only 4 bytes
wide).

I thought that 32-bit systems only needed 4 byte pointers?

Oh, right.  If you're still on a 32-bit system, then pointers are
indeed just four bytes.

(Say, is there an easy way to specify that "near" pointers should be
used, or does one need to code their own? Or is that an optimization
best left to the compiler?)

This isn't portable,  but the "near" keyword can be used to qualify the
declaration of an automatic pointer variable, at least for one AMD
compiler.  Instead of saying

actortype *killer;
  you say
near actortype *killer;

and you get a four-byte pointer.  But they're rarely useful because they
cannot be used in the definition of heap-allocated objects, and also
cannot be used to point to heap objects; a near pointer must be
stack-allocated and may only point at other stack-allocated locations.

                                Bear

I remember using the "far" keyword in a Borland compiler quite a few
years back, still in DOS, but it worked in no other compiler. IIRC,
near pointers were 16 bits long. Correct me if I'm wrong, but isn't
that a feature of Turbo C compilers only?

Mingos

The near/far specification for pointers is only applicable to
segmented architectures. How wide they are depends entirely on the
processor architecture. Compiler support is obviously a requirement as
well (the keywords are non-standard), and I'd say that unless you
actually *know* what the difference between near and far pointers is
(hint: it's not the bit width), you shouldn't be using them at all.
Just eat the extra memory consumption, and be glad you don't have to
worry about hardware details.
.

Relevant Pages

  • Re: new IL: C (sort of...).
    ... only for "recent" Pascals, ... far pointers weren't really limited, ... in my compiler, I made wchar_t a builtin type (in most cases, aliased to ... I could very well include builtin "managed strings" in the new IL. ...
    (comp.lang.misc)
  • Re: new IL: C (sort of...).
    ... and the frontend compiler needs to be able ... Having very limited pointers is a fact of life in a VM language though, ... vague claims about Pascal's pointer support. ... That is pretty normal for standards (the ...
    (comp.lang.misc)
  • Re: code optimiation
    ... Given that the compiler can often optimise the generated code to use the best sized types available, it's seldom worth specifying "fast" types explicitly. ... pointers and floating point types whose "zero value" might not be all- ... instruction, so the assembler produced for *p++ when used as the ... It will do the same job, and let you write the source code using proper array constructs. ...
    (comp.arch.embedded)
  • Re: Forward declaring classes
    ... the compiler will prepare for the worst and assume it ... MS specific __keyword I should write there in order ... What you're thinking of applies to pointers to members. ...
    (microsoft.public.vc.language)
  • Re: A taxonomy of types
    ... I am describing how to represent the representation (and, ... if the system follows static typing rules (such as in a compiler), ... so, the hardware sees pointers and pointer arithmetic, but the compiler ... "Besides the char types, up to three sizes of integer, declared short int, ...
    (comp.lang.misc)