Comment by benreesman

Comment by benreesman 6 months ago

3 replies

It's a daily thing we all do: decide if this problem is better solved by a big chunk of code that is probably well tested but probably satisfies a bunch of requirements and other constraints or a smaller chunk of code that I can write or vendor in and has other advantages or maybe I just prefer how its spelled. Sometimes there's a "right" answer, e.g. you should generally link in your TLS implantation unless you're a professional TLS pereon, but usually its a judgement call, and the aggregate of all those micro-decisions are a component of the intangible ideal of "good taste" (also somewhat subjective but most agree on the concept of an ideal).

In this instance the maintainer of a useful piece of software has made a choice that's a little less common in C++ (totally standard practice in C) and it seems fine, its on the bubble, I probably default the other way, but std::function is complex and there are platforms where that kind of machine economy is a real consideration, so why not?

In a zillion contributor project I'd be a little more skeptical of the call, but even on massive projects like the Linux kernel they make decisions about the house style that seem unorthodox to outsiders and they have their reasons for doing so. I misplaced the link but a kernel maintainer raised grep-friendliness as a reason he didn't want a patch. At first I was like, nah you're not saying the real reason, but I looked a little and indeed, the new stuff would be harder to navigate without a super well-configured LSP.

Longtime maintainers have reasons they do things a certain way, and the real test is the result. In this instance (and in most) I think the maintainer seems to know what's best for their project.

akdev1l 6 months ago

I guess the point is that the articule does not prove what he did is better in any of the ways he claimed except for the “I understand it” part

Making changes like this claiming it will result in faster code or more smaller code without any test or comparison before vs after seems to be not the best way of engineering something

I think this is why the thread has seen a lot of push back overall

Maybe the claims are true or maybe they are not - we cannot really say based on the article (though I’m guessing not really)

  • benreesman 6 months ago

    Yeah, it seems unlikely that the typical target machine would have either a word or cache line size that spilled a std::function via overhead on a realistic closure, but who knows, I would bet real money either way without a profile.

    And I think it is less than ideal as concerns the fragile abd nascent revival of mainstream C++ to have this sort of a gang tackle over a nitpick like this. The approach is clearly fine because its how most every C program works.

    The memes of C++ as too hard for the typical programmer and C++ programmers as pedantic know-it-all types are mostly undeserved, but threads like this I think reinforce those negative stereotypes.

    The real S-Tier C++ people who are leading the charge on getting C++ back in the mindshare game (~ Herb Sutter's crew) are actively fighting both memes and I think it behooves all of us who want the ecosystem to thrive should follow their lead.

    The danger of C++ becoming unimportant in the next five or ten years is zero, C and C++ are what the world runs on in important ways.

    But in 20? 30? The top people are working with an urgency I haven't seen in decades and the work speaks for itself: 23 and 26 are coming together "chef's kiss" as Opus would say.

    The world is a richer place with Rust and Zig in it, but it would be a poorer place with C++ gone, and that's been the long term trend until very recently.

    • akdev1l 6 months ago

      I don’t think it’s necessarily a C++ thing

      If the post was about rust and it was using unsafe code and casting function pointers then everyone would quickly jump to try and correct it all the same