Initializing the Runtime

You must intialize the Duck runtime before using the library. You should (but aren't absolutely required to) do this from the main thread. Whichever thread calls DKRuntimeInit() becomes the "main" thread so far as the library is concerned.

#include <Duck/Duck.h>

int main( int argc, const char * argv[] )
{
    // OPTIONAL -- Register custom logging callbacks (all use the vprintf prototype)
    DKSetPrintfCallback( my_printf_callback );
    DKSetWarningCallback( my_warning_callback );
    DKSetErrorCallback( my_error_callback );
    DKSetFatalErrorCallback( my_fatal_error_callback );

    // OPTIONAL -- Register custom malloc/free
    DKSetExternalAllocator( my_custom_malloc, my_custom_free );

    // Initialize the runtime
    DKRuntimeInit( 0 );

    // Do Stuff Here
    // ...

Zombie Objects

To help debug reference counting you can also enable zombie objects. When enabled, a deallocated object is turned into a zombie object instead of being freed. Any calls to the zombie's interfaces or message handlers will produce an error.

#include <Duck/Duck.h>

int main( int argc, const char * argv[] )
{
    // Initialize the runtime with Zombie Objects
    DKRuntimeInit( DKRuntimeOptionEnableZombieObjects );

Initialize classes and selectors (Optional)

Classes and Selectors are added to the reflection tables the first time they're accessed. If you have code that relies on DKClassFromString() or DKSelectorFromString() you may want to make sure the relevant classes are touched during initialization to populate those tables.