From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32374 invoked by alias); 16 Aug 2004 20:53:26 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 32365 invoked from network); 16 Aug 2004 20:53:25 -0000 Received: from unknown (HELO lon-mail-5.gradwell.net) (193.111.201.131) by sourceware.org with SMTP; 16 Aug 2004 20:53:25 -0000 Received: (qmail 20706 invoked from network); 16 Aug 2004 20:53:18 -0000 Received: from digraph.polyomino.org.uk (postmaster%pop3.polyomino.org.uk@81.187.227.50) by lon-mail-5.gradwell.net with SMTP; 16 Aug 2004 20:53:18 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.41) id 1BwoTm-0002IQ-Hn; Mon, 16 Aug 2004 20:53:18 +0000 Date: Mon, 16 Aug 2004 20:54:00 -0000 From: "Joseph S. Myers" X-X-Sender: jsm28@digraph.polyomino.org.uk To: Ziemowit Laski cc: Mark Mitchell , Zack Weinberg , GCC Patches Subject: Re: In-Reply-To: <918394DF-EFB7-11D8-8323-000393673036@apple.com> Message-ID: References: <918394DF-EFB7-11D8-8323-000393673036@apple.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-08/txt/msg01128.txt.bz2 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)