$npx -y skills add easyzoom/aix-skills --skill plooc-integrationUse when integrating, refactoring, or debugging PLOOC object-oriented C - def_class encapsulation, private_member protection, vtable dispatch, or inheritance-style structs
| 1 | # PLOOC Integration |
| 2 | |
| 3 | ## Overview |
| 4 | |
| 5 | Use this skill when PLOOC (Protected Low-overhead Object-Oriented Programming with ANSI-C, by GorgonMeducer) is used to structure embedded C code. PLOOC mimics classes with masked structures: outside the class `.c` file, `private_member`/`protected_member` regions appear as an opaque byte array, so the real work is getting the per-file `__<NAME>_CLASS_IMPLEMENT`/`__<NAME>_CLASS_INHERIT__` guards, member visibility, and vtable/interface dispatch correct. Apply it only where object-style boundaries reduce real complexity. |
| 6 | |
| 7 | ## When To Use |
| 8 | |
| 9 | Use this skill when: |
| 10 | |
| 11 | - The user mentions PLOOC, `def_class`/`end_def_class`, `private_member`/`protected_member`/`public_member`, `implement()`-style inheritance, or vtable-based dispatch (`def_interface`) in embedded C. |
| 12 | - A legacy driver/module is being wrapped into an encapsulated class with `plooc_class.h`. |
| 13 | - The issue involves the masked-struct layout, the `__..._CLASS_IMPLEMENT` guard, `__OOC_DEBUG__`, initialization order, object lifetime, or callback/vtable dispatch. |
| 14 | |
| 15 | Do not use this skill for simple drivers where plain C structs and functions are clearer. |
| 16 | |
| 17 | ## First Questions |
| 18 | |
| 19 | Ask for: |
| 20 | |
| 21 | - PLOOC version (`private_method()`/`protected_method()`/`public_method()` were added in v4.6.4) and target compiler. |
| 22 | - C standard: PLOOC needs ANSI-C99; C90 requires `__OOC_DEBUG__` (private-member protection is disabled in that mode); overload/`_Generic` features need C11. |
| 23 | - Which template is selected: `__PLOOC_CLASS_USE_STRICT_TEMPLATE__` (strict), simple, simple_c90, or black_box. |
| 24 | - Module being refactored and whether it uses single or multiple inheritance (`implement()`). |
| 25 | - Memory policy: static objects vs `__new_class()`/`__free_class()` / `__plooc_malloc_align()`. |
| 26 | |
| 27 | ## Integration Checklist |
| 28 | |
| 29 | 1. Set up the header guard pattern. |
| 30 | In the class header, map the module macro to the framework macro before including `plooc_class.h`, e.g. `#if defined(__BYTE_QUEUE_CLASS_IMPLEMENT) # define __PLOOC_CLASS_IMPLEMENT__ #elif defined(__BYTE_QUEUE_CLASS_INHERIT__) # define __PLOOC_CLASS_INHERIT__ #endif`. |
| 31 | |
| 32 | 2. Declare then define the class. |
| 33 | Use `dcl_class(foo_t)` / `declare_class(foo_t)` (expands to `typedef struct foo_t foo_t;`), then `def_class(foo_t, ...)` ... `end_def_class(foo_t)`. Group members with `public_member(...)`, `protected_member(...)`, `private_member(...)` (any order allowed). |
| 34 | |
| 35 | 3. Define the implement macro in exactly one `.c` file. |
| 36 | The class `.c` does `#define __BYTE_QUEUE_CLASS_IMPLEMENT` before `#include "./byte_queue.h"`, so only that file sees real private members; every other translation unit sees the masked byte array. |
| 37 | |
| 38 | 4. Access `this` inside methods correctly. |
| 39 | Use `class_internal(ptObj, ptThis, foo_t)` to obtain the typed `ptThis`, and the `#define this (*ptThis)` convention for member access. Mark unused args with `PLOOC_UNUSED_PARAM`. |
| 40 | |
| 41 | 5. Handle inheritance explicitly. |
| 42 | Embed a base with `implement(base_t)` in the derived `def_class`; the framework generates a `use_as__<base>` member for the embedded base. Define `__<NAME>_CLASS_INHERIT__` in a consumer that only needs to read the base's protected members. Access base functionality by passing the address of the `use_as__<base>` member to the base-class functions. |
| 43 | |
| 44 | 6. Keep dispatch inspectable. |
| 45 | Define vtables with `def_interface(i_foo_t)` ... `end_def_interface(i_foo_t)` and a single const interface instance; verify each function pointer is assigned. |
| 46 | |
| 47 | ## Common Failures |
| 48 | |
| 49 | - Forgetting `#define __<NAME>_CLASS_IMPLEMENT` in the class `.c`, so the implementation only sees the opaque mask and member access fails to compile. |
| 50 | - Defining the implement macro in more than one file, breaking encapsulation. |
| 51 | - Mismatched template selection: header uses `__PLOOC_CLASS_USE_STRICT_TEMPLATE__` but a consumer includes with a different template, corrupting struct layout. |
| 52 | - C90 or non-C99 toolchain without `__OOC_DEBUG__`, so masked structs do not size correctly. |
| 53 | - `implement(base_t)` omitted, so no `use_as__<base>` member is generated and base-class functions cannot be reached from the derived object. |
| 54 | - Private members invisible in the debugger because `__OOC_DEBUG__` is not defined for the debug build. |
| 55 | - Missing include order: `plooc.h`/`plooc_class.h` (and `<stdlib.h>` for `__new_class`) not reachable on the include path. |
| 56 | |
| 57 | ## Verification |
| 58 | |
| 59 | Before claiming PLOOC integration works: |
| 60 | |
| 61 | - State the PLOOC version, C standard, and which class template (`strict`/`simple`/`black_box`) is used. |
| 62 | - Confirm the header maps `__<NAME>_CLASS_IMPLEMENT`/`__<NAME>_CLASS_INHERIT__` before including `plooc_class.h`, and the implement macro is defined in exactly one `.c`. |
| 63 | - Confirm `sizeof(foo_t)` is identical inside and outside the implementing file (mask size matches real struct). |
| 64 | - Confirm |