Aug.22.2016 -- CAlive to introduce type-ii and type-i functions, as well as i {..} blocks

[Rick C. Hodgin]

CAlive will follow a protocol allowing a function to be flagged as type-i or type-ii.

As a natural naming convention, functions that are type-i should be prefixed with i, and those which are type-ii should be prefixed with ii.  However, type-ii functions can also contain an i { .. } header block which is normally bypassed, but is traversed when called using an type-i name, allowing for type-ii functions to contain and maintain code for both types.

type-i functions are internal functions not visible to an external api which must still validate parameters passed into them, because it's possible they could be NULL, or need fixing up if they are passed as NULL, before being used.  type-i functions are typically the workhorses of exposed api functions, sometimes merely pass-thru.

type-ii functions are functions which are internal to internal functions, and are of the kind which do not require the extra validations as they have already been performed.  Use of type-ii functions provides a speedup in cases where the extra validation is not required

    function iiExample
    |params void* p, int a, f32* f
    |returns int r
    {
        f32 lf;


        // Validate in the case of iExample()
        i {
            if (!p)   return r = -1;   // An external p is required
            if (!f)   f = &lf;         // An external f is not required, but needed locally
        }
    }

In this example, the function can be called in code as either iiExample() or iExample() (because iiExample() contains an i { .. } block).  If it's called as iiExample(), then the i { .. } block is never traversed.  If it's called as iExample(), then the i { .. } block is traversed and the extra test is performed.

Multiple i { .. } blocks can be included in a single function.  Each will be traversed when encountered, as is proper for the type of call.

Best regards,
Rick C. Hodgin