home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / os / msdos / programm / 10401 < prev    next >
Encoding:
Internet Message Format  |  1992-11-08  |  3.3 KB
  1. Xref: sparky comp.os.msdos.programmer:10401 comp.msdos.programmer:87 comp.os.ms-windows.programmer.tools:1360
  2. Newsgroups: comp.os.msdos.programmer,comp.msdos.programmer,comp.os.ms-windows.programmer.tools
  3. Path: sparky!uunet!spool.mu.edu!yale.edu!ira.uka.de!slsvaat!us-es.sel.de!reindorf
  4. From: reindorf@us-es.sel.de (Charles Reindorf)
  5. Subject: Re: BC++ far* default in medium model
  6. Message-ID: <1992Nov7.140122.2542@us-es.sel.de>
  7. Sender: news@us-es.sel.de
  8. Organization: SEL-Alcatel Line Transmission Systems Dept. US/ES
  9. References: <1992Nov4.090359.21666@hellgate.utah.edu> <1992Nov5.031544.5264@sequent.com> <1992Nov5.053551.20533@emr1.emr.ca> <1992Nov5.084656.10427@sequent.com> <1992Nov6.171236.1394@rei.com>
  10. Date: Sat, 7 Nov 92 14:01:22 GMT
  11. Lines: 52
  12.  
  13. In article <1992Nov6.171236.1394@rei.com>, fox@rei.com (Fuzzy Fox) writes:
  14. |> >>>In your data declarations, if you do not specifically specify the
  15. |> >>>keyword far, then the declaration is left in the default data
  16. |> >>>segment, which can be a problem if you have more than 64k of global
  17. |> >>>data.
  18. |> 
  19. |> This is true except in BC++ 3.1, where an option can be set which forces
  20. |> all data declarations larger than a certain threshold to be
  21. |> automatically moved into another segment.  The option is -Ff=nnnn, I
  22. |> believe.  I use -Ff=1024 in all my programs.  In the IDE, this option is
  23. |> set as the "Automatic Far Data" option and threshold.
  24. |> 
  25. |> >If you want to have arrays or structures that explicity
  26. |> >store > 64k of data in one instance then you have to use the HUGE
  27. |> >model,
  28. |> 
  29. |> You do not have to use huge model, you just need to use the 'huge'
  30. |> keyword when declaring the data item.  In fact, a common misconception
  31. |> is that the Huge model forces all pointers to be huge by default.  This
  32. |> is not true.  Huge model is just like Large model, except that each
  33. |> individual source file gets its own data segment automatically.  A
  34. |> single source file program will compile exactly the same under Huge and
  35. |> Large models.
  36.  
  37. I believe it is the case that virtual function table pointers are 4 bytes in the
  38. huge model as opposed to 2 bytes in the large model. This is because in the huge
  39. model they point to "any old" data segment whereas in the large model they point
  40. to the "default" data segment, so the segment information is not required in the
  41. latter case. Hence the compilation of a huge model program can be different and
  42. in particular you will probably get linkage problems if you try to mix, just in
  43. case you were thinking of doing so.
  44.  
  45. I think similar highly confusing scenarios arise when considering whether the
  46. "this" pointer is near or far in mixed memory model programming between small data
  47. and large data models, and I have seen bugs in earlier versions of BC++ in connection 
  48. with this.
  49.  
  50. I realise I may be fragmenting this thread of argument somewhat, but I would be
  51. interested if anyone out there knows a bit more about this aspect of C++ programming
  52. on PCs.
  53.  
  54. |> Huge pointers are frought with problems, and you need to know what
  55. |> you're doing in order to use them properly.
  56. |> 
  57. |> -- 
  58. |> #ifdef TRUE        | Fuzzy Fox (a.k.a. David DeSimone)       fuzzy@netcom.com
  59. |> #define  TRUE   0  |
  60. |> #define  FALSE  1  |     "History doesn't repeat itself, but it rhymes."
  61. |> #endif             |                                   -- Mark Twain
  62.  
  63. All of my opinions are mine
  64. --- Charles Reindorf
  65.