Using built-in user data

// Create a sample application data container:
typedef struct
{
  int _data1;
  int _data2;

} Container;

Container* container = new Container();

// Create a REDsdk user data raw container. Use Redsdk's built-in memory allocators if the shape is to own the data:
RED::UserDataRaw* rawdata = rnew RED::UserDataRaw( container, sizeof( Container ), "MyUserData", true );

// Create a sample shape (a transform shape here):
RED::Object* transform = RED::Factory::CreateInstance( CID_REDTransformShape );

// Assign user data to the shape:
RED::IUserData* itransformdata = transform->As< RED::IUserData >();
itransformdata->SetUserData( rawdata, true );

// ...

// Destroy everyone when finished. Access our current transaction:
RED::Object* resmgr = RED::Factory::CreateInstance( CID_REDResourceManager );
RED::IResourceManager* iresmgr = resmgr->As< RED::IResourceManager >();

// Here due to the ownership flags, the destruction of the 'transform' shape will destroy the data container.
RC_TEST( RED::Factory::DeleteInstance( transform, iresmgr->GetState() ) );

REDsdk only provides a simple 'raw' data container in its default class hierarchy. It can be used to store a chunk of memory managed by the application. Using user data is straightforward, except that caution must be paid to the memory management. User data may be released by REDsdk or may be released by the application. If the application decides on managing the memory, it's up to it to handle user data sharing of data pointers. There's no garbage collection mechanism in REDsdk, and there's no reference counting.

If the application lets REDsdk destroy user data along with the destruction of shapes, then user data must be allocated using REDsdk's memory allocators (see the RED::MemoryAllocator class for details).

Computing an automatic white balance reference