Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!wuarchive!uunet!microsoft!davidds
From: davidds@microsoft.UUCP (David D'SOUZA)
Newsgroups: comp.windows.ms.programmer
Subject: Re: DLLs, C++, and Constructors
Message-ID: <72519@microsoft.UUCP>
Date: 23 May 91 06:09:51 GMT
References: <1647@msa3b.UUCP>
Reply-To: davidds@microsoft.UUCP (David D'SOUZA)
Organization: Microsoft Corp., Redmond WA
Lines: 29

In article <1647@msa3b.UUCP> kevin@msa3b.UUCP (Kevin P. Kleinfelter) writes:
>I'd like to put my class libraries in a DLL.  This sounds nice, except
>that the constructor allocats the storage for the class.  If the
>constructor is in the DLL, then the memory allocated comes from
>the DLL's near heap -- if I have lots of applications using my DLL,
>I could run out of near heap.

My guess is, Windows will probably run out of system resources before you
run out of heap space for your DLL and its clients.  You could also
be smart about using global memory for storing large data ex. contents of 
your own listbox class could be stored in global memory.  This may help
you get away  with just using the local heap.

Another idea is to use global memory for multiple instances of a class.
For  example, all type foo controls (no matter what the app) are
stored as an array in one global alloced block.  All type bar controls 
(no matter what the app) are stored in another global alloced block.

Finally, another thing is to assume apps that call you are ds==ss.  You
could simply switch onto the app's ds (getting it from ss), do the
LocalAllocs etc, and then switch back when you need your own ds.  You then
have to make sure the window extra words contain the proper stuff to retrive
this data again...

-Dave