<div dir="auto">Hi,</div><div dir="auto">  I generally agree on the proposal. Any difference in opinion I have  is trivial and not worth discussing</div><div dir="auto"><br></div><div dir="auto">Regarding the ML filter, thanks for letting me know. I’ll have to figure out what keyword triggered the anti spam filter</div><div dir="auto"><br></div><div dir="auto">Francesco</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 23 Jun 2022 at 15:37, Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com">rousskov@measurement-factory.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
     Amos and I disagreed[1] regarding the existing guidelines for <br>
section/member order in C++ class declarations. To resolve that <br>
disagreement, this email proposes the order for future use.<br>
<br>
-----<br>
<br>
1. Class "sections" order (by member access specifiers): public, <br>
protected, private. Each section, if present, declared once. Omit <br>
sections that would be empty. Rationale: List most commonly reused, most <br>
important things fist. In this context, those are public class <br>
interfaces. The private section is the least important implementation <br>
detail as far as the notion of a C++ class is concerned.<br>
<br>
<br>
2. Within each section, the recommended member order is defined below. <br>
Rationale: Group similar things together to facilitate searching and <br>
highlight differences. List things most likely to be reused (by other <br>
class members) and most important/influential things higher.<br>
<br>
* friendship declarations<br>
* type and aliases declarations; nested classes/structs/unions<br>
* static member functions<br>
* constructors and assignment operators<br>
* destructors (just one until C++20)<br>
* other/regular non-static member functions except overrides<br>
* overrides (see item 3 below)<br>
* static data members<br>
* non-static data members<br>
<br>
<br>
3. Overrides are a special case where we do not expect member <br>
descriptions but do expect a reference to the corresponding API as <br>
sketched below. Overrides are grouped by the (direct or indirect) parent <br>
that _introduced_ the corresponding API method(s) (i.e. the parent class <br>
that declared the virtual method but could _not_ use an override keyword <br>
in that declaration). Rationale: Provide API context and facilitate <br>
searching for member descriptions without chasing overrides through parents.<br>
<br>
     /* Baz API */<br>
     overrides for Baz-introduced methods (excluding destructors)<br>
<br>
     /* Bar API */<br>
     overrides for Bar-introduced methods (excluding destructors)<br>
<br>
<br>
4. Caveats<br>
<br>
The above rules are not meant to force authors to include any access <br>
specifiers or members that the code does not actually need (except the <br>
"private" specifier should be mentioned explicitly in class declarations <br>
that have only private members -- do not rely on the class default <br>
access specifier being "private").<br>
<br>
Squid has some legacy code that forces CBDATA-related declarations to be <br>
hoisted to the very top of the class, into the "unnamed" section. This <br>
is an exception to the above rules. Eventually, we will stop doing that, <br>
but we should continue doing that for consistency sake until the <br>
offending CBDATA macros are gone.<br>
<br>
Like any style rules, these rules are not comprehensive. If your use <br>
case is not explicitly covered, then look around for similar Squid code <br>
and try to be consistent and/or reasonable.<br>
<br>
-----<br>
<br>
Most of the above rules are arbitrary but common in the industry[2,3].<br>
<br>
[1] <a href="https://github.com/squid-cache/squid/pull/1067#discussion_r889864925" rel="noreferrer" target="_blank">https://github.com/squid-cache/squid/pull/1067#discussion_r889864925</a><br>
[2] <a href="https://stackoverflow.com/q/308581" rel="noreferrer" target="_blank">https://stackoverflow.com/q/308581</a><br>
[3] <a href="https://google.github.io/styleguide/cppguide.html#Declaration_Order" rel="noreferrer" target="_blank">https://google.github.io/styleguide/cppguide.html#Declaration_Order</a><br>
<br>
<br>
HTH,<br>
<br>
Alex.<br>
P.S. This is my Nth attempt to get through the mailing list filter. You <br>
may have received a pretty much the same message as an attachment to the <br>
previous mailing list post. Sorry about the noise!<br>
_______________________________________________<br>
squid-dev mailing list<br>
<a href="mailto:squid-dev@lists.squid-cache.org" target="_blank">squid-dev@lists.squid-cache.org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-dev" rel="noreferrer" target="_blank">http://lists.squid-cache.org/listinfo/squid-dev</a><br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">@mobile</div>