Re:

["Joseph S. Myers" <jsm@polyomino.org.uk>]

On Mon, 16 Aug 2004, Ziemowit Laski wrote:

> This is the part that I find problematic. :-(  The work contained in the
> two patches I posted last night, in addition to a couple of patches I
> committed previously (and a few more I have yet to offer) is all part
> of my ObjC++ integration (approved by the Steering Committee for 3.5
> integration).  Furthermore, these bits already live in
> objc-improvements-branch, available for the bootstrapping pleasure of all.

If you don't like the proposed split, one you could try would be 
separating out the patch to stop the ObjC front end depending on 
particular structures for declarators, which is the part of the merge 
currently blocking a replacement of those structures.

I have looked at the C front end changes and believe that they only affect 
ObjC, and have no comments on them beyond those Zack has made, but don't 
think changes only affecting ObjC are for me to review.

> > Most objc_* functions are designed not to need guarding with
> > c_dialect_objc(), therefore I think it best if all of them don't; in
> > other words, please cause objc_is_public to always return true when
> > !c_dialect_objc, so this change will be unnecessary.
> 
> Again, perhaps Mark can issue a ruling here.  I thought that c_dialect_objc()
> should be used because (1) it offers a clear demarcation point (i.e., "this is
> ObjC-specific functionality") and (2) it improves performance (checking a bit
> is a lot quicker than calling a function).

Where is the evidence that this is, or is likely to be, of any measurable 
performance difference, compiling any source code whatever?  It looks like 
premature micro-optimization without such evidence.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)