diff --git a/doc/ISSUES.org b/doc/ISSUES.org index 440444e9..1e4545b0 100644 --- a/doc/ISSUES.org +++ b/doc/ISSUES.org @@ -2,11 +2,35 @@ *Long term issues* ------------------ +* TODO #25 : Support of error code model for error handling. :ENHANCEMENT: + +Find a way to support error return code for the API in case of allocation +failure. + +==> Any service that returns void shall return a "int". +==> In case of allocation failure, it shall return an error. +==> M_CALL macro shall stop its execution if the service returns an error code +and the error code represents an error (avoid rewritting everything). + +services returning already something shall not be modified. + +This model should be applied at the container level only and not globally. +Different containers may need different levels of error handling. + +New operator: ERROR_MODEL which value is 0 (abort on error), 1 (throw on error) +or 2 (return code on error). + +Find a way to make it while making the code too complex to ready +(try to keep as simple as possible). + + * TODO #24 : Add MIN-MAX-HEAP container :ENHANCEMENT: See https://en.wikipedia.org/wiki/Min-max_heap as DPRIORITY_QUEUE_DEF ? +NOTE: Needs for such container? + * TODO #23: Force MOVE semantic :ENHANCEMENT: @@ -42,45 +66,6 @@ defined with [1] tricks but without an explicit INIT_MOVE / MOVE operators as it uses MOVE_DEFAULT which is not (fully compatible). ==> Analyse limitation and possible constraint usages. -* DONE #22: Enhanced services for SPSC Queue :ENHANCEMENT: - -Add services: - -** DONE _push_bulk -Test the capacity of the queue and push as much as possible in the queue -with one check of the atomic structure. - -** DONE _pop_bulk -Test the capacity of the queue and push as much as possible in the queue -with one check of the atomic structure. - -** DONE _push_force: - -If the capacity of the queue is full, pop one element and push it: -push always succeed and the queue always keep the youngest element. - - -* DONE #21: Generic Binary serialization :ENHANCEMENT: - - Based on issue #26 of https://github.com/P-p-H-d/mlib/issues/26 - - Some kind of "binary serialization" on the model of get_str/parse_str - could be possible. It would be a great feature from the application - point-of-view: binary representation is more bandwidth-efficient if - used on network communications. - - It will be good to have import/export methods to the - XML/JSON/MSGPACK/PROTOBUF/BINARY format. - However, adding all of them on by one in the M*LIB containers - doesn't seem satisfactory. - - Instead, adding a generic interface for the serialization of data - that may be customized by the user to perform the import/export of - objects in whatever format they want into what they want (FILE/memory/...). - To simplify it, this interface could only support one kind of import/export - per compilation unit. - - * TODO #20: Bucket priority queue :ENHANCEMENT: @@ -102,6 +87,7 @@ implementation. * TODO #19: Intrusive Red Black Tree :ENHANCEMENT: Add intrusive red black tree. + Look also for AVL tree (NOTE: Is there a performance difference between the two?) * TODO #18: Missing methods :ENHANCEMENT: @@ -166,10 +152,11 @@ http://htmlpreview.github.io/?https://github.com/P-p-H-d/mlib/blob/master/doc/Co (NULL if not logically deleted) ? TBC -* TODO #15: Constructor / Destructor Prologue / Epilogue for Stack Exception Handling :ENHANCEMENT: +* TODO #15: Prologue / Epilogue for Constructor / Destructor for error handling :ENHANCEMENT: Constructor (and destructor) need to use user-defined prologue / epilogue. -This is in order to register the constructed object into a proper Stack Exception Handling so that exceptions throwing may work reliably. +This is in order to register the constructed object into a proper Exception +Handling Stack so that throwing exceptions may work reliably. Proposal: @@ -178,15 +165,18 @@ Proposal: - M_DESTRUCTOR_PROLOGUE(object, oplist); - M_DESTRUCTOR_EPILOGUE(object, oplist); -Object creation will need to add all sub-objects into the stack, then unstack all to push instead the root object (which will recursively remove them). +Object creation will need to add all sub-objects into the stack, +then unstack all to push instead the root object (which recursively remove them). See also http://freetype.sourceforge.net/david/reliable-c.html#cseh +How to handle like allocation of the object? +How to avoid calling the destructor multiple times? (It is needed?) * TODO #14: Memory allocation enhancement :ENHANCEMENT: -Enhancement of the memory allocation scheme to find way to deal properly with advance allocators: +Enhancement of the memory allocation scheme to find way to deal properly with advanced allocators: - non-default alignment requirements for types, - instance-based allocator (may need instance based variable access), @@ -218,6 +208,7 @@ Needs some formal operator in the oplist to support it fully and an example. It is a kind of object inheritance where the container inherits some extra data from its base. + * TODO #12: Atomic shared pointer :ENHANCEMENT: Add an extension to the SHARED_PTR API: @@ -342,3 +333,44 @@ Not sure it will really help. To analyse. A good way maybe Open Addessing table used only for indirection and a freelist memory reclamation container for handle the entries (like a transaction). + +* DONE #22: Enhanced services for SPSC Queue :ENHANCEMENT: + +Add services: + +** DONE _push_bulk +Test the capacity of the queue and push as much as possible in the queue +with one check of the atomic structure. + +** DONE _pop_bulk +Test the capacity of the queue and push as much as possible in the queue +with one check of the atomic structure. + +** DONE _push_force: + +If the capacity of the queue is full, pop one element and push it: +push always succeed and the queue always keep the youngest element. + +* DONE #21: Generic Binary serialization :ENHANCEMENT: + + Based on issue #26 of https://github.com/P-p-H-d/mlib/issues/26 + + Some kind of "binary serialization" on the model of get_str/parse_str + could be possible. It would be a great feature from the application + point-of-view: binary representation is more bandwidth-efficient if + used on network communications. + + It will be good to have import/export methods to the + XML/JSON/MSGPACK/PROTOBUF/BINARY format. + However, adding all of them on by one in the M*LIB containers + doesn't seem satisfactory. + + Instead, adding a generic interface for the serialization of data + that may be customized by the user to perform the import/export of + objects in whatever format they want into what they want (FILE/memory/...). + To simplify it, this interface could only support one kind of import/export + per compilation unit. + + + +