Bo Persson schrieb:
>>
>> Olaf Krzikalla schrieb:
>>
>>> 2. =A77.6.1.5 states, that attibute tokens not being specified
>>> behave implementation-defined. Shouldn't we restrict this in a
>>> way, that attibutes unknown to an particular implementation shall
>>> be ignored. Like: an implementation is not allowed to refuse
>>> compilation only because a syntactically correct attribute-token
>>> is unknown. Maybe someone can rephrase this to standard speak.
>>>
>> During a discussion about adding attributes to clang I noticed that
>> section 7.6.1.5 as written IMHO opens a can of worms. If everybody
>> is
>> allowed to add arbitrary attributes then we can't extend the set of
>> predefined attributes in the future without the danger of breaking
>> standard-conform code. Thus I would propose that the use of
>> attributes in the global and std attribute-namespace cause
>> undefined behavior unless they are defined in the standard. This
>> keeps the freedom to standardize more attributes in the future. For
>> attributes in other namespaces the behavior is still implementation
>> defined. But as I wrote in my previous post, we should add the
>> sentence:
>> "Any attribute (not in the global and std attribute-namespace) that
>> is not recognized by the implementation is ignored."
>>
>
> Including misspelled attributes? Could introduce interesting new bugs!

For unknown attributes in the global and std namespace we can change
from ub to ill-formed. Thus the issue exists (if at all) for
implementation specific attributes only - as it does for pragmas.
The attribute namespace makes things even better, since an
implmentation can simply define, that any attribute in a particular
namespace is recognized (and in case it is misspelled makes the
program ill-formed).
By all means I consider sec. 7.6.1.5 underspecified.

Best regards
Olaf Krzikalla

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Apr 30, 11:24 pm, Olaf Krzikalla <krzika...@gmx.de> wrote:
>
> For unknown attributes in the global and std namespace we can change
> from ub to ill-formed. Thus the issue exists (if at all) for
> implementation specific attributes only - as it does for pragmas.
> The attribute namespace makes things even better, since an
> implmentation can simply define, that any attribute in a particular
> namespace is recognized (and in case it is misspelled makes the
> program ill-formed).

If we ever get a reflection API for C++ (and I hope we do and am
working towards it), I think one very essential feature will be to
have attributes that are defined by metadata processing libraries.
This scheme has proven to be extraordinarily successful in Java, with
annotations for unit testing, object-relational mapping, object-XML
mapping, automatic generation of web services, transaction scope
management, and endless more things.

Thus, while marking the global, std, and some implementation-defined
namespaces as off-limits for extension is useful, I believe it to be
absolutely essential for arbitrary attribute token sequences to be
permitted in general.

Sebastian


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Hi again,

and sorry for responding to my own posting. Nevertheless I hope someone else
is reading.

Olaf Krzikalla schrieb:

> 2. =A77.6.1.5 states, that attibute tokens not being specified behave
> implementation-defined. Shouldn't we restrict this in a way, that attibutes
> unknown to an particular implementation shall be ignored. Like: an
> implementation is not allowed to refuse compilation only because a
> syntactically correct attribute-token is unknown.
> Maybe someone can rephrase this to standard speak.
>
During a discussion about adding attributes to clang I noticed that section
7.6.1.5 as written IMHO opens a can of worms. If everybody is allowed to add
arbitrary attributes then we can't extend the set of predefined attributes
in the future without the danger of breaking standard-conform code. Thus I
would propose that the use of attributes in the global and std
attribute-namespace cause undefined behavior unless they are defined in the
standard. This keeps the freedom to standardize more attributes in the
future. For attributes in other namespaces the behavior is still
implementation defined. But as I wrote in my previous post, we should add
the sentence:

"Any attribute (not in the global and std attribute-namespace) that is not
recognized by the implementation is ignored."

(this was just taken from section 16.6 (pragmas)).


Best regards
Olaf Krzikalla

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Olaf Krzikalla wrote:
> Hi again,
>
> and sorry for responding to my own posting. Nevertheless I hope
> someone else is reading.
>
> Olaf Krzikalla schrieb:
>
>> 2. =A77.6.1.5 states, that attibute tokens not being specified
>> behave implementation-defined. Shouldn't we restrict this in a
>> way, that attibutes unknown to an particular implementation shall
>> be ignored. Like: an implementation is not allowed to refuse
>> compilation only because a syntactically correct attribute-token
>> is unknown. Maybe someone can rephrase this to standard speak.
>>
> During a discussion about adding attributes to clang I noticed that
> section 7.6.1.5 as written IMHO opens a can of worms. If everybody
> is
> allowed to add arbitrary attributes then we can't extend the set of
> predefined attributes in the future without the danger of breaking
> standard-conform code. Thus I would propose that the use of
> attributes in the global and std attribute-namespace cause
> undefined behavior unless they are defined in the standard. This
> keeps the freedom to standardize more attributes in the future. For
> attributes in other namespaces the behavior is still implementation
> defined. But as I wrote in my previous post, we should add the
> sentence:
> "Any attribute (not in the global and std attribute-namespace) that
> is not recognized by the implementation is ignored."
>

Including misspelled attributes? Could introduce interesting new bugs!


Bo Persson



--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Hi,

I have two issues regarding attributes:

1. The syntax does not allow the chaining of attribute-specifiers. That is,
you can write:

[[attribute1, attribute2]] for (;;) {}

but you can't write:

[[attribute1]] [[attribute2]] for (;;) {}

IMHO the second version should be allowed too and it should be semantically
equal to the first one. This allows for easier creation of
implementation-dependent constructs as follows:

#ifdef NEW_CPP
#define parfor [[some_parallel]] for
#else
#define parfor for
#endif

#ifdef EVEN_NEWER_CPP
#define parfor_aligned [[align(4)]] parfor
#else
#define parfor_aligned parfor
#endif

With the current syntax it would be difficult to define parfor_aligned on
top of parfor while keeping parfor indepedendent from parfor_aligned.


2. =A77.6.1.5 states, that attibute tokens not being specified behave
implementation-defined. Shouldn't we restrict this in a way, that attibutes
unknown to an particular implementation shall be ignored. Like: an
implementation is not allowed to refuse compilation only because a
syntactically correct attribute-token is unknown.
Maybe someone can rephrase this to standard speak.


Best regrads
Olaf Krzikalla


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]