From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12772 invoked by alias); 29 Jul 2009 17:30:03 -0000 Received: (qmail 12710 invoked by uid 22791); 29 Jul 2009 17:30:02 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 29 Jul 2009 17:29:53 +0000 Received: from mailhost4.vmware.com (mailhost4.vmware.com [10.16.67.124]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id BDAEE1B007; Wed, 29 Jul 2009 10:29:51 -0700 (PDT) Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) by mailhost4.vmware.com (Postfix) with ESMTP id B45CFC9B68; Wed, 29 Jul 2009 10:29:51 -0700 (PDT) Message-ID: <4A70854E.9080106@vmware.com> Date: Wed, 29 Jul 2009 17:30:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: "tromey@redhat.com" CC: Vladimir Prus , "gdb@sources.redhat.com" Subject: Re: Private data members References: <200907291245.32359.vladimir@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-07/txt/msg00231.txt.bz2 Tom Tromey wrote: >>>>>> "Volodya" == Vladimir Prus writes: > > Volodya> I have run into a case when it's desirable that all > Volodya> modifications of a certain structure field in GDB codebase go > Volodya> via function that can enforce necessary invariants. > > Volodya> At the moment, there are at least 3 places that directly assign > Volodya> a value to that field, and while I can convert them easily, > Volodya> nothing will prevent a direct assignment to appear in future. > > In the past somebody solved this same problem for struct value by > putting the struct definition into value.c and adding a bunch of > accessors. > > I'm lukewarm about this technique, but it can be made to work. > > Daniel's suggested approach would also be fine with me. How about combining the two? Define struct breakpoint in breakpoint.h, put any public members in there, and then include a member "struct breakpoint_private" that is only a forward declaration. Then define "struct breakpoint_private" in breakpoint.c, so that its members will be invisible outside of that module.