This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: throw(), pure and const flags on functions
On Wed, Apr 15, 2009 at 1:32 PM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> Hi,
>> I'd go so far as to suggest __GLIBCXX_PURE, but that's of course a call
>> for the libstdc++ maintainers to make. ?I'd try to use as small a chunk
>> of the macro namespace as possible... ?Do macros get expanded inside
>> attributes? ?If so, can we use "__attribute__ ((__pure__))" instead of
>> "pure"?
>>
> Mark, first thanks for your advice, two days ago, I'm trying to adhere
> to it ;)
>
> Indeed, I think the macro should use __pure__ in the C++ library. As for
> the name, we are in fact consistently prepending _GLIBCXX_ (single
> underscore at the beginning). Honza can find many examples in c++config.
>
> Paolo.
>
Since macro expansion don't know anything about language level
scopes and attribute scope, using plain"pure" is indeed not
to be recommended. I think Mark's abstraction layer __GLIBCC_PURE
should be applied regardless of the rest.
I'm very much interested in data before this go in.
There are claims out there that 'throw()' makes code much bigger.
I'm also puzzled that the compile cannot deduce that a function
that only only a function with 'throw()' is itself
conceptually 'throw()' therefore does not need annotation.
I guess my point is that we should aim at keeping annotations
minimum and teaching the compiler more about some
composition things.
- References:
- throw(), pure and const flags on functions
- Re: throw(), pure and const flags on functions
- Re: throw(), pure and const flags on functions
- Re: throw(), pure and const flags on functions
- Re: throw(), pure and const flags on functions
- Re: throw(), pure and const flags on functions
- Re: throw(), pure and const flags on functions
- Re: throw(), pure and const flags on functions
- Re: throw(), pure and const flags on functions
- Re: throw(), pure and const flags on functions