Persistent Objects

A persistent object is anything that typically gets stored in an SSlib database. Examples are sets, fields, relations, templates thereof, etc. For each class of persistent object SSlib creates a link datatype, which is akin to a C pointer in that it’s a lightweight piece of data (a small C struct with no dynamically allocated components). But it’s also more than a C pointer because it can point to disk-resident objects, and the links can be stored in files. Also like C pointers, the object to which a link points must be dereferenced in order to get to to the actual object, and SSlib provides macros for doing such. In fact, SSlib provides three macros for each persistent object class.

SS_FIELD: Takes one argument, field, of type ss_field_t and dereferences that link to obtain a pointer to

the C struct that implements the field object. The returned value is of type ss_fieldobj_t. The same pattern is followed for other persistent classes.

SS_FIELD_M: Just like SS_FIELD except it also takes a member name whose value it returns via C’s arrow

operator. There really isn’t much point in using this macro but it’s supplied for completeness.

SS_FIELD_P: Just like SS_FIELD_M except it returns the address of the member instead of the member value.

This macro is used most often to obtain a pointer to a link that’s stored in some object because objects store links but almost all SSlib functions take pointers to links. It’s only supplied for completeness because one can do the same thing by using the “address of” (ampersand) C operator in front of SS_FIELD_M.

Generally the SAF library will pass around links to objects and dereference the link whenever access to members of the actual object’s struct is necessary. The primary reason for passing around links instead of object pointers is that it allows SSlib to relocate objects in memory in order to do certain memory management tasks and optimizations. However, it’s not really a big performance penalty to repeatedly dereference links because the link caches the pointer in such a way that most dereferencing operations will incur only two memory comparisons. And precisely for that reason it is normal practice to pass non-const-qualified pointers to links when calling most functions: it allows SSlib library to update the link itself and propagate that change up through the call stack.

Members

• ss_pers_new [Public function]
• ss_pers_copy [Public function]
• ss_pers_reset [Public function]
• ss_pers_dest [Public function]
• ss_pers_deref [Public function]
• ss_pers_update [Public function]
• ss_pers_refer [Public function]
• ss_pers_scope [Public function]
• ss_pers_file [Public function]
• ss_pers_iswritable [Public function]
• ss_pers_topscope [Public function]
• ss_pers_eq [Public function]
• ss_pers_equal [Public function]
• ss_pers_state [Public function]
• ss_pers_cmp [Public function]
• ss_pers_cmp_ [Public function]
• ss_pers_cksum [Public function]
• ss_pers_find [Public function]
• ss_pers_modified [Public function]
• ss_pers_unique [Public function]
• ss_pers_debug [Public function]
• ss_pers_decode_cb [Public function]
• SS_PERS_DEST [Public macro]
• SS_PERS_NEW [Public macro]
• SS_PERS_COPY [Public macro]
• SS_PERS_FIND [Public macro]
• SS_PERS_EQ [Public macro]
• SS_PERS_EQUAL [Public macro]
• SS_PERS_MODIFIED [Public macro]
• SS_PERS_ISNULL [Public macro]
• SS_PERS_UNIQUE [Public macro]