On Thu, 14 Jun 2018, Bernd Edlinger wrote: > On 06/14/18 15:43, Richard Biener wrote: > > On Fri, 8 Jun 2018, Bernd Edlinger wrote: > > > >> Hi! > >> > >> > >> This patch converts the splay-tree internals into a template, and makes > >> the typed_splay_tree template really type-safe. Previously everything > >> would break apart if KEY_TYPE or VALUE_TYPE would not be pointer types. > >> This limitation is now removed. > >> > >> I took the freedom to add a remove function which is only for > >> completeness and test coverage, but not (yet) used in a productive way. > >> > >> > >> Bootstrapped and reg-tested on x86_64-linux-gnu. > >> Is it OK for trunk? > > > > It looks OK to me but I wonder if we can avoid some of the code > > duplication due to template instantiation by deriving from a non-templated > > base class somehow? The cc1* binaries keep growing with more and > > more template use :/ > > > > > No problem. The first version used an approach where splay-tree > exposes an extended interface with a context pointer. > > See: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00178.html > > But it has also a limitation when the value or type is a class, it will > not be possible to cast to uintptr_t, it will fail to compile, which is > still an improvement since the current version just casts incompatible > function pointers, and since I had to silence the -Wcast-function-type > the warning would not help either. > > > If you like the original patch better than the template, I can cleanup > the original patch as an alternative?
No, I like the template more but wondered if we can somehow outline some of the main worker code? Thanks, Richard.