Provided by: libcoin80-doc_3.1.4~abc9f50-4ubuntu2_all bug

NAME

       SoMemoryError -

       The SoMemoryError class is used to inform of problems with memory allocation.

       Modern operating systems takes care of handling most out of memory conditions for you, but
       in certain situations it can be wise to do some manual checking and intervention. This
       class is provided as an aid to help out in these situations.

SYNOPSIS

       #include <Inventor/errors/SoMemoryError.h>

       Inherits SoError.

   Public Member Functions
       virtual SoType getTypeId (void) const

   Static Public Member Functions
       static void setHandlerCallback (SoErrorCB *const callback, void *const data)
       static SoErrorCB * getHandlerCallback (void)
       static void * getHandlerData (void)
       static SoType getClassTypeId (void)
       static void post (const char *const whatWasAllocated)
       static void initClass (void)

   Protected Member Functions
       virtual SoErrorCBPtr getHandler (void *&data) const

   Additional Inherited Members

Detailed Description

       The SoMemoryError class is used to inform of problems with memory allocation.

       Modern operating systems takes care of handling most out of memory conditions for you, but
       in certain situations it can be wise to do some manual checking and intervention. This
       class is provided as an aid to help out in these situations.

       The basic design of the Coin library is to pass on the responsibility for handling failed
       attempts at memory allocation to the application programmer. If you want to detect and
       take care of these, you should compile Coin with the C++ exception throwing on and wrap
       your code within try{} and catch{} blocks. The most you can do if you get a failed
       allocation is typically to notify the user and then exit the application, though, and this
       is something most operating systems will do for you, so you probably need not consider
       this at all.

       So, where does the SoMemoryError class come in handy? There are certain things which could
       happen within the library which are best taken care of by internally handling failed
       attempts at memory allocation. An example: the user tries to load a model file which
       contains a filename pointer to a huge bitmapfile with a texture map. The end-user's system
       does not provide enough memory to load the file and prepare the texture image for
       rendering, though. This is a case where it is possible to just emit a warning and
       continue. The warning will then be passed through this class.

       Note that SoMemoryError is probably not of much use to the application programmer.

Member Function Documentation

   SoType SoMemoryError::getTypeId (void) const [virtual]
       This method returns the SoType of a particular object instance.

       See Also:
           getClassTypeId()

       Reimplemented from SoError.

   void SoMemoryError::post (const char *constwhatWasAllocated) [static]
       Posts a warning about a failed memory allocation. whatWasAllocated should contain a
       description of what we tried to allocate.

   SoErrorCB * SoMemoryError::getHandler (void *&data) const [protected],  [virtual]
       This is just a convenience wrapper around the getHandlerCallback() and getHandlerData()
       methods.

       Reimplemented from SoError.

Author

       Generated automatically by Doxygen for Coin from the source code.