You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the implementation of CS2::TableOf does a few of things that
hinder the ability to reason about the code. 1) To increase the terse-
ness of the code, it makes prolific use of preprocessor macro substi-
tutes for class and function template parameters. 2) It uses inheri-
tance rather than composition to bring in the implementation of its
underlying storage. 3) When providing a function template parameter for
initializing entires, it passes the parameter by non-const reference,
preventing the use of r-values for initialization.
The second point is particularly problematic, as it leads to scenarios
like the following:
```
class Allocator;
class TakesAnAllocator {
TakesAnAllocator(Allocator a);
}
TableOf<TakesAnAllocator> myTable(someAllocator);
myTable.addElement(myTable);
```
In the final line of this example, the user of TableOf takes advantage
of TableOf's inheriting from its underlying container to initialize
objects as if it were an Allocator.
To solve 1), this change set expands the preprocessor macros, purging
them from existence. To solve 2) this change set refactors TableOf to
use composition to import the functionality of the underlying storage
rather than inheritance, plus the required changes to the rest of the
code-base to support this new model. Finally, to solve 3) we change the
signature of both TableOf's AddEntry, as well as the constructor for
BaseArrayOf::DerivedElement to take the initializer object by const
reference. Furthermore, we update TR_BitVector's copy constructor and
assignment operator such that they also take const references, to cause
TR_RegisterCandidate's implicit copy constructor to use const referen-
ces.
Signed-off-by: Luc des Trois Maisons <lmaisons@ca.ibm.com>
0 commit comments