home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / cplus / 16105 < prev    next >
Encoding:
Text File  |  1992-11-11  |  1.4 KB  |  29 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!secapl!Cookie!frank
  3. From: frank@Cookie.secapl.com (Frank Adams)
  4. Subject: Re: Using 64k objects
  5. Message-ID: <1992Nov11.163605.114187@Cookie.secapl.com>
  6. Date: Wed, 11 Nov 1992 16:36:05 GMT
  7. References: <1992Nov4.011604.5884@piccolo.cit.cornell.edu> <BxH4p6.8Bn@research.canon.oz.au> <1992Nov10.102746.12514@us-es.sel.de>
  8. Organization: Security APL, Inc.
  9. Lines: 18
  10.  
  11. In article <1992Nov10.102746.12514@us-es.sel.de> reindorf@us-es.sel.de (Charles Reindorf) writes:
  12. >In article <BxH4p6.8Bn@research.canon.oz.au>, colin@cole.research.canon.oz.au (Colin Pickup) writes:
  13. >|> Borland is one of the few C/C++ compilers that handles arrays bigger that
  14. >|> 64K. To do it either use the huge memory model for the whole program or  
  15. >|> just make the pointers to the arrays huge (read the manuals on how to do  
  16. >|> this). The second option will give better run-time performance.
  17. >
  18. >Is it not the case that the "huge" memory model does not imply huge pointers
  19. >by default? According to my understanding of the "huge" memory model, the
  20. >only difference between it and large memory models is that a separate data
  21. >area is allocated [...]
  22.  
  23. This is true for Borland's C++ (which was the compiler in question).  For
  24. most other PC C/C++ compilers, the "huge" memory model *does* imply huge
  25. pointers.
  26.  
  27. So, to answer the original question, to get arrays over 64K with BC++, you
  28. have to declare them huge and use the appropriate allocation functions.
  29.