On Wed, 21 Feb 2024 at 21:38, apoenitz <apoen...@t-online.de> wrote: > > Use unnamed namespaces for all internal/non-exported entities. Functions > > can > > alternatively be marked `static` in the global namespace. Marking > > functions > > `static` also in the unnamed namespace can help readability, > > particularly in reviews. > > That's technically an option, but again not a good one in my book. There is no > advantage /known to me/ /for functions/ to be in the anonymous namespace > instead > of being 'static', and I listed a few cases where there are disadvantages. > > This change also does not solve the "problem" of having /different/ rules than > the (self-proclaimed...) "Core Guidelines" which was - to me - the main reason > for the proposed change.
Well.. ..a recognized problem with the Core Guidelines is that not all of the guidelines in it come with the strongest of rationale, some of them are highly stylistic, and biased towards certain author preferences that don't exactly withstand hard scrutiny. The cost of symbols in intermediate build artifacts is one of the things that a particular origin of some of these guidelines, namely portions of "C++ Coding Standards: 101 Rules, Guidelines, and Best Practices" was somewhat ill-equipped to consider in sufficient detail. So, I highly recommend taking the Core Guidelines with quite a pinch of salt, in fact a bucket, not a pinch. They haven't been field-tested in serious anger. They might look like good ideas, but they might not work where the real rubber hits the road. My favorite example is https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rh-dynamic_cast It basically bans static_cast downcasts in a class hierarchy, so despite quickly mentioning "using CRTP carefully", it makes very strong insinuations of CRTP being banned. The problem is You Can't Do That, you can't use a dynamic_cast in a whole lot of class hierarchies because they aren't polymorphic, and the rule is very unclear about what using CRTP "carefully" means. The C++23 "deduced this" fixes the problem, removes the need to do such static downcasts, and removes the need for C, R, and P in CRTP. :) Nevertheless, that's a golden example of a Core Guidelines rule that you, after considering adopting it everywhere in your code, must deem nonsense, despite all the lofty hopes of the authors of these rules being infallible expert programmers who know exactly what it's like to face real-life engineering problems day in day out. I trust you can figure from all those colorful words whether I really think those authors are exactly that, or perhaps sometimes less so. :) -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
