List view
Geogram is difficult to use in other projects because it has several mechanisms driven by global variables / command line arguments @jdumas, @const-me, [fasttetwild](https://github.com/Const-me/fTetWild/blob/master/MeshRepair/GeogramDelaunay/geogram/Shims/LinkerShims.cpp) (please tell me if I forgot something in what follows). This concerns: - logger - process - command line arguments - file system - factories - bibliography The problems are: - difficult for the user to know what to initialize and how - integration in large systems (node-based,multithreaded) needs to know who initializes what and when - in particular, modification of global state needs to be made thread-safe Also, Geogram changes global process state: - signal handlers - LC_LOCALE Redesign goals: - client code just sees an API of classes, does not have to care about the initialization of any globals. - there can be a global state, but it is automatically initialized (for instance, internally, by the first class that uses it), and it is done in a thread-safe manner - no global process state (signal handlers, LC_LOCALE...) is modified without explicit client code request (except floating point rounding mode as required by exact predicates, but ideally it should be saved and restored after exiting the coarse-grained algorithmic blocs that use it)
No due date•2/4 issues closed