Another PR to prepare for the removal of range-v3.
The tree::Tape, tree::File, tree::Section and the parsed equivalents all use std::map or std::multimap to store their information and we use views::keys and views::elements to access the data as ranges (bidirectional ones).
Trials with the replacement of range-v3 have shown issues with the views::keys and views::elements replacements that cause compilation errors. Since these are basically implementation details, I decided to replace the maps and multimaps with lists. This does not break the interface as the entire interface still behaves in the same way (we can iterate over materials, files, sections, etc. as bidirectional ranges).
I did try using vector instead of list but the removal and insertion of sections/files/materials was broken by this change. Lists allow elements to be inserted without invalidating iterators while vectors do not. As a result, keeping a reference around to an element after inserting an element in a vector may be dangerous. Because of this, I went back to lists which maintains the current interface.
Another PR to prepare for the removal of range-v3.
The tree::Tape, tree::File, tree::Section and the parsed equivalents all use std::map or std::multimap to store their information and we use views::keys and views::elements to access the data as ranges (bidirectional ones).
Trials with the replacement of range-v3 have shown issues with the views::keys and views::elements replacements that cause compilation errors. Since these are basically implementation details, I decided to replace the maps and multimaps with lists. This does not break the interface as the entire interface still behaves in the same way (we can iterate over materials, files, sections, etc. as bidirectional ranges).
I did try using vector instead of list but the removal and insertion of sections/files/materials was broken by this change. Lists allow elements to be inserted without invalidating iterators while vectors do not. As a result, keeping a reference around to an element after inserting an element in a vector may be dangerous. Because of this, I went back to lists which maintains the current interface.