From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eli Zaretskii" To: kevinb@cygnus.com Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH RFC] process/thread/lwp id patch - phase 3 Date: Fri, 04 May 2001 07:39:00 -0000 Message-id: <1190-Fri04May2001173922+0300-eliz@is.elta.co.il> References: <1010504090641.ZM7298@ocotillo.lan> X-SW-Source: 2001-05/msg00045.html > Date: Fri, 4 May 2001 02:06:41 -0700 > From: Kevin Buettner > > I know from conversations with some of my colleagues that this > representation is not unanimously favored. One of the alternate > suggestions was to make struct ptid somewhat more opaque by making it > more difficult to associate meaning with the various components. (I > guess this could be called "opacity through obscurity".) Such a > representation might look like this: > > struct ptid > { > long ids[3]; > } I don't like such techniques. They don't really work (how many seconds will it take to understand what does each element of ids[] serve for?). I think it's good enough to encapsulate access to these entities in a bunch of functions, like you did, and leave the rest to be enforced by the coding standards. Plus, we can add something to the ARI script to help reveal any ``bad'' practice that succeeds to sneak in, if that's a real danger. > +int > +ptid_equal (ptid_t ptid1, ptid_t ptid2) > +{ > + return (ptid1.pid == ptid2.pid && ptid1.lwp == ptid2.lwp > + && ptid1.tid == ptid2.tid); > +} You could have passed pointers to the objects instead, and gain a bit more performance. In particular, you could compare the pointers first, and if they are equal, skip the rest. But that is not a very important consideration, I think.