On Wed, Feb 21, 2024 at 06:56:41PM +0000, Jøger Hansegård via Development wrote: > >> Our Qt coding conventions ([1]https://wiki.qt.io/Coding_Conventions) > >> has a statement on the use of unnamed (anonymous) namespaces. As far as > >> I understand, this statement is now outdated. > > > [I'll assume we are talking about functions here.] > > Anonymous namespaces can be quite helpful to avoid name clashes of > non-function types.
Non-function types are practically not covered by the current rule, as it has an 'static [...] if possible' and there's no possibility to have 'static' on enums and types, and it has a different meaning for e.g. class members. > Quite often I see both local functions and other local entities in the same > cpp > file. I don't want to recommend against moving local functions into the > unnamed > namespace unless there is a technical reason why we shouldn't. I gave some numbers in the previous mail that I considered at the time of its writing a technical reason. What would be an acceptable 'technical reason' here? > > It would be a change to the worse in my book which I personally would not > > like. > > Anonymous namespaces are harder to set up and to maintain and produce at > > best > > identical results compared to static' > > Would an option be to change from: > > Avoid the use of anonymous namespaces in favor of the static keyword > if possible. A name localized to the compilation unit with static is > guaranteed to have internal linkage. For names declared in anonymous > namespaces the C++ standard unfortunately mandates external linkage. > (7.1.1/6, or see various discussions about this on the gcc mailing > lists) > > to > > 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. Andre' -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
