Hi Akim, > > What do you think? Do you think the list-of-lists use-case makes sense? > > Do you think configuring the list at run time is something people may want > > to do? > > You have a strong point here. But I don’t know if there would > be actual users for such dynamic timers.
OK, no dynamically allocated timevars then. But what about the list-of-lists use-case? I think it's pretty natural that, when a computation consists of several phases, each (or at least some) of the phases consists of several sub-phases. > I guess I should have said > ’set’ instead of ‘list’, the order does not matter, except for > the order used to display the result. Since the order matters for printing, it's a 'list', not a 'set'. > > Approaches (b), (c), (d) have the advantage that the abstraction is easier > > to understand, because it follows common C idioms (define structs and > > reference > > them through pointers instead of IDs). > > I disagree here. You seem to claim that an abstraction is easier > to understand when you understand the implementation, which kind > of defeats the point of the abstraction. I like abstractions too. But I also see that many people have problems grokking abstractions when they don't see the implementation or when the abstractions are not well explained. > > (d) has the further big advantage that the list can be configured at run > > time. > > For example, if a compiler has dynamically loadable passes (like GNU ld), > > Really? ld is dlopening some of its passes? Yes. I meant the link-time optimization. See '-fuse-linker-plugin' in https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Optimize-Options.html Bruno
