Hi Robert,
The reason that qualifiers, such as __attribute__, are often seen on the right side of the symbol that the attribute is being applied to is because the rule goes:
a qualifier binds to the thing to its immediate left
Hence:
int const i = 0;
Or:
class Foo
{
public:
virtual Bar() const;
};
The exception to the rule is:
unless the qualifier is the very first thing (and as such, there is no thing to its immediate left), then it binds to the thing to its immediate right
Hence:
const int i = 0; // The exception to the general rule.
In my experience, for "simple" declaration and definitions, the qualifier is quite often done first. That's not the way I do it, but it is the way that 90%+ (maybe 99%+) of C++ developers do it.
The exception tends to not be used when a) it's more confusing to use it, or b) it cannot be used.
char const* const* * const* * ptr;
The first 'const' could, optionally, be put first before the 'char'.
But something like this reads better as is, when read right-to-left:
a pointer to a pointer to a const pointer to a pointer to a const pointer to a const char.
(I've never actually needed some monstrosity like that. Just for over-the-top exemplary purposes. At least I didn't use a function pointer. Hmmm, ever notice that you can't tell which of those pointers are pointers to thingies and which are pointers to arrays of thingies? Oh well. Doesn't matter for this example, although I was keeping that in mind when I wrote it.)
The point of a __attribute__((noreturn)) function from <http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html>...
- - - - - - - - - - - - - - - - -
The noreturn keyword tells the compiler to assume that fatal cannot return. It can then optimize without regard to what would happen if fatal ever did return. This makes slightly better code. More importantly, it helps avoid spurious warnings of uninitialized variables.
- - - - - - - - - - - - - - - - -
HTH,
--Eljay
