(v13) RDR Example: De-coupling run-time resource discovery from compile-time linkage

This page applies to Harlequin v13.1r0 and later; both Harlequin Core and Harlequin MultiRIP

To have code access data located elsewhere, a symbol must be exported from the data provider and linked to the consumer. This kind of linkage can cause build difficulties, and is entirely inflexible the data cannot be optional unless the consumer is build-variant, and if there is a variable number of chunks of data, further complexity arises.

Registering data as an RDR, even when the supplier and consumer are within the same file, has many advantages including the ability to have that data overridden by some other system, or for further RDRs of that type to be defined.

For example, a module that displays the authors of all systems and modules in the build might be as simple as this:

                      void init_credits() {
                        static char me[] = "Fred Bloggs\0" ;
                      SwRegisterRDRandID(RDR_CLASS_MISC, RDR_MISC_AUTHOR, 0, me, sizeof(me), 0) ;
                      }
                      ...
                      void credits() {
                      sw_rdr_iterator * iterator = SwFindRDRbyType(RDR_CLASS_MISC, RDR_MISC_AUTHOR) ;
                        if (iterator) {
                          void * ptr ; /* because a void* may not be the same size as char**
                      */
                            while (SwNextRDR(iterator, 0, 0, 0, &ptr, 0) == SW_RDR_SUCCESS) { char * author = (char *) *ptr ;
                            printf("%s\n",author) ;
                          }
                          SwFoundRDR(iterator) ;
                        }
                      }

Anything that wanted to output such a message would register an RDR of the appropriate type and the RDR system does all the work. Note the usage of SwRegisterRDRandID () to ensure each registration has a unique ID such that all registrations are visible.