From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3357 invoked by alias); 5 Jan 2003 02:21:17 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 3258 invoked from network); 5 Jan 2003 02:21:16 -0000 Received: from unknown (HELO mcncgw.mariani.ws) (64.3.144.100) by 209.249.29.67 with SMTP; 5 Jan 2003 02:21:16 -0000 Received: from chaincast.com (IDENT:gianni@bulli.mariani.ws [216.98.238.112]) by mcncgw.mariani.ws (8.11.6/8.11.6) with ESMTP id h052PZu13488; Sun, 5 Jan 2003 02:25:35 GMT Message-ID: <3E17968F.7020807@chaincast.com> Date: Sun, 05 Jan 2003 02:55:00 -0000 From: Gianni Mariani Reply-To: gmariani@chaincast.com Organization: Chaincast, Inc User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Dewar CC: gcc@gcc.gnu.org Subject: Re: c++ "with" keyword References: <20030104223552.724F0F28C4@nile.gnat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-01/txt/msg00181.txt.bz2 Robert Dewar wrote: >>Any language construct that fails in this regard (like with) is very bad >>- period. >> >> > >But look carefully at what you are saying. We are talking about a structure >or class whose members are visible to the client of the library. The change >we are talking about is adding a new member to the structure. You cannot >possibly think that such a change can be done in a guaranteed 100% >upwards compatible manner. That's absurd. > >(for example, at the very least the size of an instance will change). > >Furthermore, the situations under which adding this member will cause >specifically a difficulty with WITH are very marginal. It is indeed >far more likely that the addition of a member will cause other compatibility >differences. > >If you disagree, give a specific realistic example of what you are talking >about. I certainly can't think of one! > You talk about binary compatability. I'm more concerned about source compatability however there are issues with binary compatability as well - in the case, use of enums or typedefs in a class may cause binary issues. Think a little harder, they are there. > > > >>Again, our perspectives on what is important is different, as a library >>maintainer, I see this as much more important an issue than you do. >> >> >> >> > >Again, remember we are talking not about the writer of the library but the >user. > Hey - I'm talking about both - in any case, almost moderately sized project will have libraries and in a software development house, you want source level compatability. The distinction of library producer and consumer is mute. >Suppose the user obtains an offset of a member of the structure, and >you add a new member. Well then the offset changes, and that could cause >arbitrary chaos of a really difficult nature. Would you use this to argue >that it should be impossible to obtain the offset of a structure member. >Of course not. > >If a user uses WITH on one of your structs, then it is still extremely >unlikely that your change will cause trouble. > >I really think that you need to give an example. Talking in generalities >is always misleading. If you think something is dangerous don't just go >around sounding red alert. Instead give a specific technical example :-) > > Robert, we have different perspectives on the same problem. Obviously issues I see as critical, you see as mute. I've given examples. They still stand. G