* Paul Wankadia writes to Paul Edwards, on Thursday October 10 1996
   at 20:32:

 FA>> So sizeof() will return the length of the pointer.
 PW>> I seem to get 2...
 PE>> In small memory model you will get that.  Try compiling in large,
 PE>> and you'll get 4.

 PW> What sort of pointers does large model use?  Far?  Does huge model use
 PW> huge pointers?

Tiny:           Code and Data both fit within the same 64K segment.
[near pointers]

Small:          Code and Data each fit within their own 64K segments.
[near pointers]

Compact:        Code fits in a 64K segment but Data doesn't.
[far pointers]

Medium:         Data fits in a 64K segment but Code doesn't.
[near pointers]

Large:          Neither Code nor Data will fit in a 64K segment.
[far pointers]

Huge:           Same as large, but individual object may be over 64K.
[far/huge pointers]

Huge pointers are far pointers which are 'normalised' (ie: 0xb000:8000 is
normalised to 0xb800:0000) before each access to avoid segment overwrap,
meaning you can address more than 64k with them. Due to this extra
conversion overhead, you should only use the huge model if you really have
to. (In general, very broadly, the smaller the model, the less overhead and
memory used).

 FA>> Perhaps if the string is global it may also work, but i didn't try
 FA>> or
 PW>> What's wrong with global variables? :)
 PE>> Nothing more than global functions.

 PW> I was told (prior to this) that global variables should be cut down as
 PW> much as possible.

Presumably global means a static variable, accessable across different
modules. These often occupy static (as the name suggests) space in the data
area (which on some platforms such as DOS may have a relatively limited
amount of space), rather than transient space allocated on the stack.

 PW> BTW the way you said "global functions" -- is it possible
to declare
 PW> (this is a silly question) a "local" function, accessible
from inside
 PW> another function ONLY???

Why would you want to do that? It's inline code then. :)

 PW>> BTW I'd rather keep the code as portable as possible (between
 PE>> Good to see.  You should have a bloody good reason not to make it
 PE>> portable, rather than the other way around.  And isolate out the

 PW> When you say portable, do you mean portable between DOS compilers, or
 PW> between DOS and Unix, or usable on any platform, or what?  I have
 PW> always been a tad confused about that term.  BTW what non-portable
 PW> functions and stuff exist in Turbo C++ v3.0 that I should be aware of?

Oh, heaappppssss. The online help in BCC 3.1 shows quite clearly how
portable things are. For example, heapwalk:

  Portability:
  Ι DOS Ρ UNIX Ρ Windows Ρ ANSI C Ρ C++ Only »
  Ί Yes ³      ³         ³        ³          Ί
  ΘΝΝΝΝΝΟΝΝΝΝΝΝΟΝΝΝΝΝΝΝΝΝΟΝΝΝΝΝΝΝΝΟΝΝΝΝΝΝΝΝΝΝΌ

Obviously not very portable at all. :)

 PE>> a #ifdef around it (and make the #ifdef the non-default, and make
 PE>> it still do *something* on an ISO-only environment).  BFN.  Paul.

 PW> I have used #ifdef before...  BTW you seem rather knowledgeable -- if
 PW> you haven't already replied about this, what EXACTLY does "extern
 PW> \"C\"" do and mean???

The way I understand it, that's just a wrapper for C++... you see it a lot
in header files:

#ifdef __cplusplus
extern "C" {
#endif

void _Cdecl _FARFUNC __assertfail( char _FAR *__msg,
                                   char _FAR *__cond,
                                   char _FAR *__file,
                                   int __line);

#ifdef  __cplusplus
}
#endif

If you're just doing a C compile, the 'extern "C" {' and '}' is
never seen by the compiler.

Cheers.

---