Sorry for the linking error. That wasn't me doing optimization or anything, but just not testing the latest rebase of my patch enough --- my dev environment was a big busted, and I was compiling the file not but linking. I haven't fixed that yet, but I just did a full from scratch build and that linked and run fine.
On Wed, Aug 20, 2025, at 11:05 PM, Jason Merrill wrote: > On 8/13/25 2:48 PM, John Ericson wrote: > > A follow-up from "driver: Rework for_each_path using C++" > > > > These types are, for all intents and purposes, single-use closure > > environment types. It is much more ergonomic to just use lambdas for > > this. > > > > On IRC there was concern about static dispatch and compile times with > > lambdas, > > As I mentioned in a previous reply, I think those concerns were > overblown; it would be worth comparing the 'size' of xgcc before and > after such a change, but I wouldn't expect it to be significant. I'll look into that next > > but I have kept the class hierarchy and virtual methods from > > the previous commit that keeps `find_within_paths::for_each_path` > > untemplated, and I believe that addresses the issue. > > But it leaves us with a weird mash-up of static and dynamic polymorphism > that doesn't strike me as clearer. I'd rather have just one or the other. I know these things are matters of opinion, but let me just throw this out from my perspective as primarily/originally a functional programmer who has happened to write a lot of C++ these past few years: In terms of language construct we have: classes, inheritance, abstract methods vs higher order functions. In terms of implementation/compilation strategy we have dynamic vs static static dispatch. Neverminding other characteristics of C++ in particular, these are orthogonal concepts: one can imagine each language construct compiled with each strategy. [0] So therefore it doesn't seem like a confusing mix to me, it feels just like the best attempt one has in C++ to do higher order functions (and anonymous function arguments) with dynamic dispatch. (Or perhaps I am misreading, and the main issue is spec_path wasn't also converted, so even on the language construct level there are two styles left over?) In any event, I'll resubmit both patches now, but feel free to just apply the first one, and e.g. encourage me to go for the templated option. (I will do those measurements right away.) I rather get something landed now that feels better than the status quo, even if I end up rewriting it completely after. (It's not like other people are touching this code frequently so I think a little bit of "churn" is fine.) Cheers, John [0]: Static dispatch with classes is the hardest to imagine, but a sufficiently aggressive optimizer could try to inline/specialize find_within_paths::for_each_path, inferring in essence the templating that one could have written for it.
