Suggestions for using attributes outside of [[noreturn]]?

Question

Based on discussions about the use of specific supplier attributes in another question, I asked myself: "what rules should we specify for people to use attributes that are not specified in the standard ?"

Two attributes that are defined: [[ noreturn ]] and [[ carries_dependencies ]] . The standard leaves open how compilers should respond to unknown attributes - thus, by the standard, they can stop with an error message. This is not what, for example, GCC does, it issues a warning and continues. This is probably the behavior expected from most common compilers. For this reason, I would like to read "should" in the standard, but we do not have it.

Document N2553 displays flexible attributes. It lists additional attributes used by GCC ( unused , weak ) and MSVC ( dllimport ). for OpenMP, a widely supported parallelizing structure, cloud attributes are offered, for example. omp::for(clause, clause) , omp::parallel(clause,clause) . Thus, it is very likely that we will use some specific attributes for providers very soon after they generally support the syntax.

Therefore, when we now “go out into the world” and tell people about C ++ 11, what should be advice on the use of attributes?

• Use only noreturn and carries_dependencies
• Use the old compiler syntax instead. __attribute__((noreturn)) and define a macro when transferring code (current situation)
• Use the attributes that your favorite compiler freely supports, knowing that this code cannot be portable to another standard compiler, because if the standard allows the compiler to stop with an error, you should think that this will happen. It sounds a bit like propaganda for writing non-portable code.
• Or, I suppose, we expect the most used compilers to warn about unknown attributes, so you can use vendor-specific attributes, bearing in mind that in rare cases you may have problems.

Note the slight difference in the last two markers. Although both say that “use the attributes you need,” the item3 message “does not care about other compilers”, while item4 implicitly rephrases the standard texts “implementation-defined behavior”, “the compiler should issue a diagnostic message”.

What could be the suggestion for the upcoming best practice here?

Answer 1

The best practice - the only one that is reasonably tolerated in practice, not to mention the ambiguity in the standard - is the use of macros. Many years have passed before we can forget about compilers that do not support attributes.

The number of compilers and the number of custom __keywords__ defined by these compilers will always increase, and it makes sense for the language to determine how to contain the damage. There is no need to revolutionize the way people write disproportionate code or make portable code portable (although standard attributes do this). The advantage is to give caffeine-based compiler engineers a sandbox software environment when they want to expand the grammar.

It is somewhat disturbing, however, that no attribute markers are reserved for implementation or language other than those that are currently standard. So there will be problems when they decide to standardize more of them.