Under UNIX, memory allocation isn't a problem. Under Windows, the only really viable way to go is to use the large model, which uses the global heap instead of the local heap for memory allocation. Unless more than one read-write data segment is used (see large data below), large model programs may still have multiple instances under MS C/C++ 7. Microsoft give the following guidelines for producing multiple-instance large model programs:
Even with the single-instance limitation, the productivity benefit is worth it in the majority of cases. Note that some other multi-platform class libraries also have this restriction. (If more than one instance really is required, create several copies of the program with different names.)
Having chosen the large model, just use C++ 'new', 'delete' (and if necessary 'malloc' and 'free') in the normal way. The only restrictions now encountered are a maximum of 64 KB for a single program segment and for a single data item, unless huge model is selected.
For Borland users, use the data threshold switch, and the following is also recommended:
See also the Frequently Asked Questions document for further details on using Borland with wxWindows.
Allocating and deleting wxWindows objects
In general, classes derived from wxWindow must dynamically allocated with new and deleted with delete. If you delete a window, all of its children and descendants will be automatically deleted, so you don't need to delete these descendants explicitly.
Don't statically create a window unless you know that the window cannot be deleted dynamically. Modal dialogs, such as those used in the dialogs sample, can usually be created statically, if you know that the OK or Cancel button does not destroy the dialog.
Most drawing objects, such as wxPen, wxBrush, wxFont, and wxBitmap, should be created dynamically. They are cleaned up automatically on program exit. wxColourMap is an exception to this rule (currently). In particular, do not attempt to create these objects globally before OnInit() has a chance to be called, because wxWindows might not have done essential internal initialisation (including creation of lists containing all instances of wxPen, wxBrush etc.)
If you decide to allocate a C++ array of objects (such as wxBitmap) that may be cleaned up by wxWindows, make sure you delete the array explicitly before wxWindows has a chance to do so on exit, since calling delete on array members will cause memory problems.
wxColour can be created statically: it is not automatically cleaned up and is unlikely to be shared between other objects; it is lightweight enough for copies to be made.
Beware of deleting objects such as a wxPen or wxBitmap if they are still in use. Windows is particularly sensitive to this: so make sure you make calls like wxDC::SetPen(NULL) or wxDC::SelectObject(NULL) before deleting a drawing object that may be in use. Code that doesn't do this will probably work fine on some platforms, and then fail under Windows.