Re: positioning compiler attributes

[Rik]

On 12/29/2015 01:33 PM, John W. Eaton wrote:
> On 12/29/2015 03:56 PM, Rik wrote:
>
>> I think it's a good idea to rename to OCTAVE_ATTR_NORETURN.  But, I would
>> prefer to keep this attribute at the end of the declaration if possible.
>
> It is possible to place (the C++11 standard) [[noreturn]] attribute at
> either the beginning or end of the declaration or definition.  For the
> GCC-specific __attribute__((noreturn)), it can't go at the end of
> definitions, so then we must provide a separate declaration if we want to
> put the attribute at the end.  So do we sometimes put these attributes at
> the beginning and sometimes at the end?  It seems complicated to remember
> and describe this in our coding standards.  It would be much simpler to
> just say "put them at the beginning".

I was looking into the C++11 standard for doing this and I thought at first
that the beginning or the end were equally suitable places for attributes. 
Unfortunately, the standard actually seems to mandate that the attribute
appear at the beginning of the declaration or after the identifier.  There
is an online web interface to gcc 5.2 implementing C++14 at
http://en.cppreference.com/w/cpp/language/attributes.  I used that to test
a few different combinations and the following is actually illegal.

void fcn (int arg1, double arg2) [[noreturn]];

Instead, it would have to be

void fcn [[noretun]] (int arg1, double arg2)

if the attribute were to follow the identifier.  I think this looks ghastly
and would only get worse if you added more attributes.

Thus, I propose that we do move attributes to the front of declarations or
definitions.  This will work with the existing GCC attributes and also
allow for an eventual transition to non-compiler specific attributes. 

>
> Yeah, it does get kind of messy if we are writing things like
>
>   extern OCTAVE_ATTR_NORETURN OCTAVE_API void
>   foobar (args, ...);
>

According to my tests, this would need to be written as

OCTAVE_ATTR_NORETURN extern OCTAVE_API void
foobar (args, ...);

I think this obfuscates what is happening.  It would be nice if we could at
least segregate all the attributes so it would be something like

OCTAVE_ATTR_NORETURN OCTAVE_API
extern void
foobar (args, ...);

or maybe as Lachlan suggested

OCTAVE_ATTR_NORETURN OCTAVE_API extern
void
foobar (args, ...);

But I don't know if the __declspec that OCTAVE_API expands to on Windows
systems can be placed before the extern keyword.

--Rik