There are two configuration options which may be chosen concerning memory allocation. By default, where objects from library classes are constructed on free store by either the library or the user, they are created using the global operator new()/new[]() functions. However, glib memory slices provide an efficient small object allocator (likely to be significantly more efficient than global operator new/new[]), and if the --with-glib-memory-slices-compat or --with-glib-memory-slices-no-compat compilation configuration options are chosen when './configure' is run, so far as relevant library classes will be constructed in glib memory slices (both by the library itself and when the user calls the new or new[] expression with respect to them). If the --with-glib-memory-slices-compat option is chosen, binaries which were originally compiled against this library as installed with a default configuration will continue to link and run correctly. However, if the --with-glib-memory-slices-no-compat option is chosen, the library will use glib memory slices more aggressively and any programs compiled against the library as installed without that option will need to be recompiled.

If you want to use glib memory slices, choose --with-glib-memory-slices-no-compat unless you want to avoid having to recompile programs already compiled against c++-gtk-utils in a case where c++-gtk-utils was installed without that compilation option.

For these compatibility reasons, if the following classes are constructed in freestore, they will only be constructed in glib memory slices with the --with-glib-memory-slices-no-compat option: Callback::CallbackArg<> and derivatives, WinBase and derivatives, FilePrintManager, TextPrintManager, Thread::Mutex and Thread::Thread.

Objects of the following classes will never be constructed in glib memory slices even if that option is chosen: GobjHandle, GobjWeakHandle, GvarHandle, Thread::TaskManager::IncHandle, SharedPtr, SharedLockPtr, SharedHandle, SharedLockHandle, ScopedHandle and IntrusivePtr (because, whilst such objects can be constructed on free store, that would be highly unusual), IntrusiveCounter and IntrusiveLockCounter (because it is for the derived class to decide policy on how it should be allocated) and any built in types (such as char arrays or strings) returned by library functions to the user. In addition, where a library class uses a standard C++ container in its implementation, it does not pass the container a glib-memory-slice implemented allocator (in-container memory allocation will normally have been optimized by the standard C++ library implementation).