ZZ>
  >    Ok, so what exactly is the most intelligent way to allocate memory if yo
  > don't know exactly what you requirements will be?  Apparently malloc isn't
  > giving me any single allocations larger than 32K (Watcom v.10.0),
ZZ>

  I'd complain, or use the 32-bit compiler.  (-:

  malloc() and ::operator new are both be able to allocate enormous
  amounts of memory.

ZZ>
  > that I have to use DosAllocateMem, assign this memory with DosSubSetMem,
  > and then allocate it with DosSubAllocMem.
ZZ>

  This is useful for special purpose allocators (in C++), but for more
  general use I'd stick to malloc() if I were you.

ZZ>
  >                                         Should you just pick a goodly large
  > number (say, 100Meg) leaving the memory uncommitted till you need it, then
  > grow the suballoced heap?
ZZ>

  For what it's worth, malloc() in Borland C++ allocates the heap in
  multiples of 4Mb using DosAllocMem and uses DosSetMem to commit pages
  as needed.

ZZ>
  >    Do you handle memory differently depending on the application?
ZZ>

  As I said above, you can always use special-purpose allocators in C++
  by overriding operator new and operator delete. These are useful if
  you are working with data structures that are multiples of (or factors
  of) the page size, since you can dispense with some of the generality
  of malloc() to create a faster allocator.

  This only applies to a small number of data structures, however.  With
  a string class, for example, where the data are going to be of
  arbitrary length, and page alignment isn't important to performance,
  you would be better off sticking with the general purpose allocator
  provided in the run-time library.

  > JdeBP <
___
 X MegaMail 2.10 #0:

--- Maximus/2 2.02