This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: C++ PATCH: PR 15815
Mark Mitchell wrote:
> Jason Merrill wrote:
>
>
>>The PR is about misleading documentation. Removing the feature seems like
>>a significant overreaction.
>
>
> Well, OK.
>
> I was just doing what the PR said to do, based on what seemed to have
> been agreed on the mailing list, as referenced by the PR...
>
> Let's go ahead and revert the patch. I actually asked Andrew to help
> with that yesterday, since I had ridiculously poor network access, but
> if it hasn't already happened, I'll take care of it now.
Sorry Mark, it was not my intention to get you to revert
the patch at all - I was just trying to understand if there's
an equivalent "conformant" way of doing what these #pragma-s
did *with the same ease of use*. If there is, I'm willing
to work out a patch for Java that implements the alternative.
I like #pragma proliferation as much as your neighbour's dog
and I would be happy if you deprecate these for 3.5 (but not
for 3.4) and if you remove it in 3.6 *provided* you (or anyone
else) can tell me how it can be done with the same ease
of use.
With respect to inlining, these two #pragma-s inline functions
defined in the class declaration while creating a single
backup implementation. Alternatives could be:
1. Manually write a non-inlined stub that calls the inlined
function as you suggested. However, this is cumbersome and
IMHO is something that a compiler should do for me - you can
say that I've been spoiled by these #pragma-s. ;-)
2. Always generate a backup copy for inlined functions for
each compilation unit (or each compiler invocation). This
might not work with linkers that do not understand linkonce
semantics.
I do not know C++ that well - someone please correct me if
I'm horribly mistaken.
BTW, for the purpose of these #pragma-s, the C++ front end
seems to treat each header file separately (i.e. not go with
the abstraction of considering a fully-preprocessed source
file for compilation) - does the same apply for inlining
functions defined in class declarations? That is, would
functions defined in class declarations in indirectly included
headers also be inlined?
Thanks,
Ranjit.
--
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA. Web: http://ranjitmathew.tripod.com/