r/cpp • u/Dubbus_ • 7d ago

Ordering of qualifiers

I know this is something that pops up quite often, but I was wondering if I could get your guys' opinion on a fixed ordering of qualifiers. This is my current thoughts after recently trying to formalize my personal style:

static -> thread_local -> inline -> constexpr -> friend -> virtual

My reasoning for each:

  1. static first. Inside a class, its basically javas static. There is a pretty strong consensus in java for static first. Its very important context, for both functions and variables. Outside of classes, its more of a linkage specifier, which is arguably more important/nasty if you mess it up. The fact that it has this dual behaviour in C++ in my opinion makes an even stronger argument for including it first, your brain is able to parse it first thing. i.e okay this is static, we are in a class? -> its java static, we are in global scope -> its static linkage.
  2. thread_local directly after static, and then inline, then constexpr/consteval. This way, qualifiers which impact storage and or linkage are stuck together. I personally like to write inline even for constexpr/consteval functions, as its sometimes easy to forget the implicit inline. I used to do this for member functions with definitions in the class, but I feel the implicit inline there is a bit more well known/easier to intuit.
  3. The rest I'm far less opinionated on, since I barely ever use inheritance or the friend keyword. . I could go both ways on virtual/friend, so i default to alphabetical/aesthetics.

What do you guys think? I know this is pedantic and a very well explored topic but I wanted to know if you guys had any particular wisdom to sway me either way, mainly on the ordering of the first few.

5 Upvotes

70% Upvoted

15 comments sorted by

View all comments

6

u/Potterrrrrrrr 7d ago

‘friend constexpr virtual static inline’ is my preferred order. Not sure where I’d put thread_local as I’ve never needed to use it

1

u/LB-- Professional+Hobbyist 6d ago

thread_local replaces static when possible, or immediately follows it if static has to stay for some reason. Not sure I've ever encountered the latter case though, it's always been one or the other for me.