This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]