home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / os / msdos / programm / 10495 < prev    next >
Encoding:
Text File  |  1992-11-10  |  3.7 KB  |  85 lines
  1. Xref: sparky comp.os.msdos.programmer:10495 comp.lang.c++:16074 comp.lang.c:16308
  2. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!natinst.com!news.dell.com!math.utexas.edu!ut-emx!jamshid
  3. From: jamshid@ut-emx.uucp (Jamshid Afshar)
  4. Newsgroups: comp.os.msdos.programmer,comp.lang.c++,comp.lang.c
  5. Subject: Re: 'new'ing >64K Objects in BC++
  6. Summary: "new huge char[80000]" returns a "char huge*"
  7. Message-ID: <83366@ut-emx.uucp>
  8. Date: 11 Nov 92 04:57:11 GMT
  9. References: <1992Nov8.181852.21103@piccolo.cit.cornell.edu>
  10. Reply-To: jamshid@emx.utexas.edu
  11. Followup-To: comp.os.msdos.programmer
  12. Organization: The University of Texas at Austin; Austin, Texas
  13. Lines: 70
  14.  
  15. Followups have been directed to comp.os.msdos.programmer only (hint,hint).
  16.  
  17. In article <1992Nov8.181852.21103@piccolo.cit.cornell.edu> sl14@crux3.cit.cornell.edu (Stephen Lee) writes:
  18. >Is there an equivalent of farmalloc() in BC++ for 'new'?  It seems
  19. >that the BC++ uses size_t to calculate the size of the memory chunk
  20. >it's getting with 'new', thus limiting it to 64K-1 in size.  (size_t,
  21. >I believe, is unsigned int in BC++)
  22.  
  23. Right, and BC++ defines an int as 16 bits.  If you want to work with
  24. arrays over 64K in BC++ you must use the non-standard 'huge' keyword.
  25. When allocating an array >64K you must use farmalloc() which takes an
  26. 'unsigned long' or 'new huge' which calls 
  27.     void* operator new(unsigned long);
  28. instead of
  29.     void* operator new(size_t);
  30.  
  31.     // for arrays
  32.     extern char huge array[];  // in header file
  33.     char huge array[80000];    // in .c or .cpp file
  34.  
  35.     // for pointers to arrays
  36.     extern char huge* p;       // in header file
  37.     char huge* p = new huge char[80000];  // in .cpp file
  38.  
  39. Be careful when using 'huge' pointers.  Turn on and pay attention to
  40. all compiler warnings; don't blindly cast to shut the compiler up.
  41.  
  42. >Given the fact that BC++ uses a signed int for an array index, and
  43. >you'll find maintaining a large array is difficult.
  44.  
  45. Well, you can index an array with any integral type, signed or
  46. unsigned, with BC++ or with any other working C compiler.  As long as
  47. the arithmetic results[1] in reference to a valid element of the
  48. array, you're fine.
  49.  
  50. >Perhaps I should switch to djgpp :(
  51.  
  52. Maybe.  At least then you can write real C code without relying on
  53. compiler extensions.  Btw, PharLap sells a DOS Extender that works
  54. with BC++ or MSC.  I believe that a 16-bit Extender allows you to
  55. access all your machine's memory (up to 16MB), but size_t and int are
  56. still 16-bits, so each object is limited to 64K.  A 32-bit Extender
  57. (like the one in DJGPP) makes them 32-bits so there are no 64K limits.
  58.  
  59. Currently I just don't use single arrays larger than 64K.  I do most
  60. of my programming under MS Windows (which is why I don't use DJGPP),
  61. so at least I have access to all my machines memory (Windows functions
  62. as a 16-bit DOS Extender).  A 16-bit Extender requires a 286 or
  63. better; a 32-bit extender requires a 386 or better.  Let me know if
  64. I'm wrong about any of this.
  65.  
  66. >P.S.  What's the difference between djgpp and g++ other than that
  67. >they're maintained by different people?  The g++ source have files
  68. >like something.com in it so is it possible to compile g++ under DOS?
  69.  
  70. DJGPP is the port by DJ Delorie of GNU gcc 2.x (gcc 2.x includes the
  71. C++ compiler) to MS-DOS.  It uses a DOS Extender which DJ Delorie also
  72. wrote.  He recently posted in c.o.m.p that 1.09 has been released.
  73. See its readme and faq for more info.
  74.  
  75. [1] Not only must the result point into the array (or at most one element
  76.     off the end), but each subexpression must result in a valid pointer.
  77.     For example array[-1+1] is not correct because it might be evaluated
  78.     as *((array-1)+1), and (array-1) might cause an addressing exception.
  79.  
  80. Jamshid Afshar
  81. jamshid@emx.utexas.edu
  82.  
  83.  
  84.  
  85.