-
Notifications
You must be signed in to change notification settings - Fork 0
License
hejohns/kiku
Folders and files
Name | Name | Last commit message | Last commit date | |
---|---|---|---|---|
Repository files navigation
------------------------------------------------------------ kiku ------------------------------------------------------------ Defined behavioral requirements for generic C programming ------------------------------------------------------------ Many ideas are taken from C++ and the naming convention certainly reflects that. C++ is fast, but the debugging experience can be painful. The goal of kiku is to standardize type requirements to allow for generic programming while being easy to debug and seamless for users to extend with their own types. The goal is NOT raw performance. Go to C++ for that. This is promote code reuse without suffering from excessive code bloat and difficult to read type identifiers. Notice of course that the casts to (void *) ditch all notions of static typing. While this consequence is not desirable, hopefully a malformed program will crash extremely quickly. All function pointers are const to reduce accidental corruption. **Naming rules** Type requirements always begin with an uppercase letter such as OneTwoThree while realized types always begin with a lowercase letter such as oneTwoThree Standard type functions follow the format TypeRequirement_functionName(void *, ...) where the first argument is always the address of the type instance Type requirements are NOT realized types. To avoid using the same namespace, DO NOT TYPEDEF TYPE REQUIREMENTS. Realized types must provide a _init() inline function that returns the same type, and a _free() inline function that properly deallocates resources captured in _init(). i.e. all type instances must be able to be declared as type type_inst = type_init(...); and deallocated as type_free(&type_inst); Benchtests are specific to each type requirement. A caveat is that different realized types often have different _init() signatures. Thus, benchtests have s ifdef block at the beginning to properly initialize each type instance. New realized types wishing to run the test must append their own ifdef section and create a new MAKEFILE target. This is the interim solution until something better is found.
About
No description, website, or topics provided.
Resources
License
Stars
Watchers
Forks
Releases
No releases published
Packages 0
No packages published