Migrating away from Boost

[cantordust]

Context

In general, reducing the number of dependencies is good for both maintainability and usability. Both corticalsim and corticalsim3d depend on Boost, which is known to cause issues when upgrading between versions. Since all of the functionality provided by Boost is now available in the standard library, it should be possible to remove Boost as a dependency.

I have made some trivial changes to reduce this dependency (such as using casting and filesystem functions from std), but there is one main 'stronghold' that remains: the DLList class, where it is used for custom allocation of new entries in a doubly linked list. Technically, there is also the CompactList class, but the use case there is identical, so I will focus on DLList.

Status quo

I have made an initial attempt to refactor the DLList class to remove the Boost dependency. It is much more compact and does not rely on complex pointer casts (see lns. 289-287, particularly the comment acknowledging that this is a hack). The refactored version has not been tested, but that can be done separately.

However, the real problem is not with the DLList class but how it is used. Inserting a new element is done by one of the create methods (lns. 165-194), which returns a pointer to the newly inserted element. The handling of the previous and next elements is handled manually by using the previousElement and nextElement attributes in DLBaseItem. For that reason, classes that need to use DLList must derive from DLBaseItem.

By replacing the Boost version of the memory pool with an STL variant, the handling of element linkage is not handled manually any more. This makes it impossible to remove an element by using the pointer to the element. We need a new strategy.

Proposed solution

The solution that I propose is to use the memory resources that have been made part of the C++17 standard. Specifically, I propose that we use the following:

• Unsynchronised or synchronised pool resources. The latter is thread-safe, so it can be used in a multithreaded scenarios.
• Monotonic buffer resource for managing the allocation.
• The pool-managed version of the STL list class (std::pmr::list) in combination with the above resources.

To be discussed

The main point of this discussion is to work through the changes that need to be implemented. The main point to be discussed is moving some methods from one class to another, which would be mandated by the new DLList class. For instance, Microtubule::wall() would need to be moved to the System class and take a DLList<Microtubule> iterator as an argument).

Justification

There are many advantages to using the proposed approach:

• Using only STL resources (future-proof).
• The DLList class would be vastly simplified (and very likely faster due to the removal of manual checks).
• Existing std::list iterators are not invalidated when adding or removing items.
• Classes no longer need to inherit from a custom base (DLBaseItem) to use DLList.
• It can be made thread-safe, paving the way for parallelisation.
• We can gradually move away from using raw pointers (that is a separate topic in itself).

[cantordust]

I made a PR implementing some of the proposed changes. It serves as an example - of course, not everything there is set in stone. It's also work in progress, so currently it doesn't compile.

The most notable change is in include/DLList.h, which is much simpler and cleaner now. That has a flow-on effect, but I think it would be fairly contained and straigthforward to implement.

[cantordust]

@JaroCamphuijsen @HiBandan @eedeinum 🙂

[JaroCamphuijsen]

@cantordust Thank you for all this work and starting this discussion (already more than a month ago!), sorry for not getting back to it earlier. I had a look at the related PR today and will take a look at your proposed solution and the links you shared tomorrow. I think we can indeed find a better solution than what is currently there.