Re: Suggestions for using attributes beyond [[noreturn]]?
Am 17.09.2011 04:42, schrieb towi:
I'd like to tell people what the intentions of the standardizing
committee were when they reached the solution for attributes as they
are now in the FCD. Especially the vendor-specific attributes cause me
troubles.
In the following I refer to the most recent state of the C++11 standard
(IMO N3242 contains all you needs in sub-clause 7.6 [dcl.attr]) and the
last update of the attribute proposal paper, N2761. I think that both
texts answer most of your questions to a very good extend.
The original proposing paper makes clear that one important reason why
attributes where invented was to define a uniform syntactic form to
allow for integrating existing non-standard language extensions into the
language grammar consistently. Also, attributes where considered as one
possible way to extend the language without the need to define new
keywords. Further, recommendations where given (see e.g. chapter 7 in
N2762) for providing guidance *which* forms of extensions or official
standard proposals are useful for attributes and which are not.
What is the "vision" for how users should put into their code? I was
expected that the system should be easy-expendable, but this would
cause other problems.
What "system" are you talking about? It was clear from begin on that
attributes should be "ignorable" in the sense that there lack or
addition should not change the type system and should not change the
meaning of a program. During the standardization of C++11 several
original attributes were removed from them later because they obviously
violated these criteria (e.g. alignment control and the nothrow
attribute). This is the first standardization of attributes and we will
see whether this basic idea can still hold for the future.
An investigation in the Std-Papers did not
reveal to me, what I should advocate. Mainly, of course, because there
is no implementation, yet. But who knows: Among those I try to teach
what to do with attributes is maybe the author of a future
compiler :-)
Here is my question from Stackoverflow, which may not have been the
right place for the question.
http://stackoverflow.com/q/7441951/472245
----
Coming from the discussions about the *use of vendor specific
attributes* in another [question][1] I asked myself, **"what rules
should we tell people for using attributes that are not listed in the
standard"**?
First, read the N2761 and especially chapter 7 again - seriously. This
is not nitpicking, but I really think that this text gives a good hint
on the idea for attributes - also for extension attributes - and it is
too long to quote it here.
The two attributes that are defined are `[[ noreturn ]]` and
`[[ carries_dependencies ]]`. The standard leaves open how compilers
should react on unknown attributes -- thus, by the standard they may
stop with an error message.
This is correct, but IMO not sufficient. The standard says that the
behavior is implementation-defined.
This is not what e.g. *GCC* does, it emits
a warning and continues.
It would be nice, if we could discuss a concrete example. It is hard to
argue about a compiler which has not implemented a new language feature.
Are you trying to say that gcc does not honor [[ noreturn ]] or [[
carries_dependencies ]]? If so, which tests did you to verify that? Here
a simple test: If the following program is well-formed, attribute
[[noreturn]] is either not yet implemented or it is incorrectly implemented:
void f();
[[noreturn]] void f() { throw 0; }
int main() {
try {
f();
} catch (int) {
}
}
This must be ill-formed according to 7.6.3 [dcl.attr.noreturn] p1:
"[..] The first declaration of a function shall specify the noreturn
attribute if any declaration of that function specifies the noreturn
attribute. [..]"
If you are talking about non-standard attributes, it would still be
interesting to have an example for it. I assume that the compiler
describes it's semantics, otherwise I find it hard to argue about it
except that gcc needs to define how it handles unknown attributes. Does
the compiler honor this description?
This is probably a behavior to be expected by
the most-common compilers.
I find it hard to argue this based on a single, yet incomplete compiler
implementation. But let's assume we could.
For this reason I would have like to read a
"should" in the standard, but we don't have it.
I don't think that a single good answer to this question can be given
now, just after the first standardization of a formal grammar for
attributes in C++. For some implementations, a non-diagnostic is
probably not such a bad idea. For others, it is bad. I expect that
several compilers will make this policy depending on compiler flags. The
future will show how compilers will evolve. But given the fact, that an
attribute should not affect the type system and should not change the
meaning of a program, a non-diagnostic default behaviour is probably not
a bad guidance.
The paper N2553 brings up flexible attributes. It lists further
attributes used by GCC (
`unused`, `weak`) and MSVC (`dllimport`). for OpenMP, the widely
supported parallelizing framework, scoped attributes are suggested,
eg. `omp::for(clause, clause)`, `omp::parallel(clause,clause)`. So, it
is very likely that we will se some vendor specific attributes very
soon after they support the syntax at all, indeed.
I agree.
**Therefore, when we now go "out in the world" and tell people about C+
+11, what should the advice be about using attributes?**
* Only use `noreturn` and `carries_dependencies`
Why? I have not tested any standard or non-standard attribute in
compilers. How should I give an advice without such a test? The general
idea from the attribute proposal was to define a grammar within C++ for
such extensions. So I can only ask back to you: Why shouldn't compiler
users use non-standard attributes in their C++ code?
* Use your compilers *old syntax* instead, eg.
`__attribute__((noreturn))` and define a macro when you port the code
(the current situation)
I find this suggestion a bit awkward: The grammar for attributes was
defined to allow for integrating such extensions into pure C++ code.
*Why* should one recommend to still use the non-standard syntactic form?
What I can agree for sure is the following: In the current transition
phase you will probably often need to use macros if you want to support
different compilers. So until those implementations, you are interested
in, have the complete standard attribute support realized, you may need
to use macros to:
- define a C++11 attribute like [[noreturn]] for compilers that support it
- or to wrap the non-standard syntactic form in other cases.
The grammar for attributes was defined to make this possible (But
of-course it cannot be done, if the standard grammar and the extension
grammar are incompatible).
* Use those attributes your favorite compiler supports freely,
knowing this code might not be portable to another standard-conforming
compiler, because if the standard allows a compiler to stop with an
error, you have to consider this will happen. This sounds a bit like
advocating writing non-portable code.
* Or, my guess, expect the most-used compilers to *warn* about
unknown attributes, so you can use vendor-specific attributes, keeping
in mind that in rare cases you may get problems.
Note the slight difference in the last two bullet-items. While both
say "use those attributes you need", item3's message is "do not care
about other compilers", while item4 implicitly rephrases the standard
texts "implementation defined behavior" to "the compiler *should* emit
a diagnostic message".
**What could be the suggestion for an upcoming *Best Practice* here?**
It is IMO hard to give a simple and general rule at this point of time.
It also depends, *how* important the effects of the compiler extension
is for you. If it is important, I suggest to use macros for both
standard and non-standard attributes (Otherwise the required work
wouldn't be worth the effort). I also would suggest to motivate your
compiler vendor to provide at least a flag that ensures that unknown
attributes are diagnosed.
HTH & Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]