Issue 2222: Is public _ptr member mandatory? (cxx_revision) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: In a number of places in the sample code for the C++ binding, the symbol _ptr is used as a member variable in _var types. In all of these the actual member is shown as private, so it is clear that actual implementations could use something else. The one exception to this is in section 20.10 on the Mapping for Struct Types. This discusses (without sample code) the mapping for string and object reference members of structs. Resolution: Revised Text: Actions taken: November 19, 1998: received issue Discussion: deferred in June 2011 to the next RTF End of Annotations:===== Return-Path: Date: Wed, 18 Nov 1998 19:32:55 -0500 From: Paul H Kyzivat Organization: NobleNet To: issues@omg.org, cxx_revision@omg.org Subject: Is public _ptr member mandatory? In a number of places in the sample code for the C++ binding, the symbol _ptr is used as a member variable in _var types. In all of these the actual member is shown as private, so it is clear that actual implementations could use something else. The one exception to this is in section 20.10 on the Mapping for Struct Types. This discusses (without sample code) the mapping for string and object reference members of structs. This section then says: "... one can access the member directly as a pointer using the _ptr field accessor. This usage is dangerous and generally should be avoided." Subsequently there is an example (10) that shows this usage: str1.name._ptr = str2.name; // 10: no free, no copy It seems that this language is mandating that the self managed type for a member string or object reference must have a public member named _ptr. If this is intended it is done in a particularly obscure way. And mandating this for a feature that is strongly discouraged seems very unwise. The _out types have an accessor function ptr(). It would seem preferable to provide this for the managed members if this functionality is needed. The real reason I ask about this is that there are problems using the name _ptr on some platforms - specifically the cxx_revision chair's former employer. On that platform, stdio.h does the favor of providing the following: #define _ptr __ptr There are many work-arounds for this problem - most of them nearly as ugly as the problem itself. (In polite company I cannot say what I really think about the person who committed the above travesty!) But the simplest work-around would be to stop using this name for a member that should never be exposed in any case. Really, nothing is required to get this functionality. Example 10 could have been coded as follows: str1.name._retn(); str1.name = str2.name.in(); This is more contorted, but it should be because the logic for doing it is also contorted. Return-Path: X-Sender: vinoski@mail.boston.iona.ie Date: Wed, 18 Nov 1998 23:57:20 -0500 To: Paul H Kyzivat From: Steve Vinoski Subject: Re: Is public _ptr member mandatory? Cc: cxx_revision@omg.org At 07:32 PM 11/18/98 -0500, Paul H Kyzivat wrote: >The one exception to this is in section 20.10 on the Mapping for Struct >Types. This discusses (without sample code) the mapping for string and >object reference members of structs. This section then says: > > "... one can access the member directly as a pointer > using the _ptr field accessor. This usage is dangerous > and generally should be avoided." > >Subsequently there is an example (10) that shows this usage: > str1.name._ptr = str2.name; // 10: no free, no copy > >It seems that this language is mandating that the self managed type for >a member string or object reference must have a public member named >_ptr. If this is intended it is done in a particularly obscure way. And >mandating this for a feature that is strongly discouraged seems very >unwise. You're talking about something that has been in the C++ mapping ever since the very first draft was composed. Yes, it's intended, and yes, it's mandatory. Unfortunately. Are you formally proposing (hint, hint) that we get rid of it in the next revision of the C++ mapping? If so, I second that motion! I don't mean deprecate it, given that it's effectively already deprecated; I mean remove it altogether. I seriously doubt anybody uses it, and even if we get rid of it, vendors that wish to continue to support it are free to do so. >The _out types have an accessor function ptr(). It would seem preferable >to provide this for the managed members if this functionality is needed. Actually, the managed types have the full suite of in(), inout(), out() and _retn() explicit conversion functions, one of which is sure to suffice for any situation where the _ptr member might be used today. >The real reason I ask about this is that there are problems using the >name _ptr on some platforms - specifically the cxx_revision chair's >former employer. (Actually, on a side note, we do not formally have a C++ RTF at this time. At the Burlingame meeting someone invoked some useless P&P rule that TFs, including RTFs, could not be formed without a three-week notice. Nothing like using the P&P for useful purposes! I have requested the start of a TC email vote to bring our humble RTF back into existence (and yes, Paul, I put your name on it). Until that vote completes, I propose we continue to conduct our business as usual even though we don't officially exist (except for formal voting, of course). Martin Chapman is going to propose a change to the P&P to exempt RTFs from that particular rule.) >On that platform, stdio.h does the favor of providing >the following: > #define _ptr __ptr Ah yes, I remember it well. I believe it's there to maintain some obscure way of reaching into a FILE structure or something like that. --steve Return-Path: Date: Thu, 19 Nov 1998 08:23:50 -0500 From: Paul H Kyzivat Organization: NobleNet To: Steve Vinoski CC: cxx_revision@omg.org Subject: Re: Is public _ptr member mandatory? References: <199811190458.XAA04087@boston.iona.ie> Steve Vinoski wrote: > > You're talking about something that has been in the C++ mapping ever > since > the very first draft was composed. Yes, it's intended, and yes, it's > mandatory. Unfortunately. > > Are you formally proposing (hint, hint) that we get rid of it in the > next > revision of the C++ mapping? If so, I second that motion! I don't > mean > deprecate it, given that it's effectively already deprecated; I mean > remove > it altogether. I seriously doubt anybody uses it, and even if we get > rid of > it, vendors that wish to continue to support it are free to do so. Yes, I am formally proposing that we get rid of it. > Actually, the managed types have the full suite of in(), inout(), > out() and > _retn() explicit conversion functions, one of which is sure to > suffice > for > any situation where the _ptr member might be used today. Yeah, after I posted the message it dawned on me that the same effect as the example use of _ptr in the spec can be achieved using inout(). > > >The real reason I ask about this is that there are problems using > the > >name _ptr on some platforms - specifically the cxx_revision chair's > >former employer. > > (Actually, on a side note, we do not formally have a C++ RTF at this > time. > At the Burlingame meeting someone invoked some useless P&P rule that > TFs, > including RTFs, could not be formed without a three-week notice. > Nothing > like using the P&P for useful purposes! I have requested the start > of > a TC > email vote to bring our humble RTF back into existence This was a strange issue. At the Seattle meeting the state of the C++ RTF was discussed and it was concluded that it couldn't yet be re-chartered because it hadn't yet expired. Some sort of catch-22 I guess. > (and yes, Paul, I put your name on it). Thank you! Return-Path: X-Sender: vinoski@mail.boston.iona.ie Date: Thu, 19 Nov 1998 09:02:22 -0500 To: Paul H Kyzivat From: Steve Vinoski Subject: Re: Is public _ptr member mandatory? Cc: cxx_revision@omg.org References: <199811190458.XAA04087@boston.iona.ie> At 08:23 AM 11/19/98 -0500, Paul H Kyzivat wrote: >> (Actually, on a side note, we do not formally have a C++ RTF at >> this >> time. >> At the Burlingame meeting someone invoked some useless P&P rule >> that >> TFs, >> including RTFs, could not be formed without a three-week notice. >> Nothing >> like using the P&P for useful purposes! I have requested the start >> of >> a TC >> email vote to bring our humble RTF back into existence > >This was a strange issue. At the Seattle meeting the state of the C++ >RTF was discussed and it was concluded that it couldn't yet be >re-chartered because it hadn't yet expired. Some sort of catch-22 I >guess. Well, the Seattle meeting was a different story. At that point, we were still in existence because our previous charter ran longer than other 2.3 RTFs. Therefore, they were right not to recharter it (in fact I wasn't aware that anyone was trying to do so). We definitely expired before the Burlingame meeting, though, so we should have been rechartered there, and would have been if this silly rule had not been invoked. As I told Richard Soley, rules are meant to help progress, not hinder it, and this is clearly a case where a broken rule is hindering progress. Hopefully Martin Chapman's proposal to revise the P&P to fix this problem will be accepted. --steve Return-Path: Date: Fri, 20 Nov 1998 07:14:16 +1000 (EST) From: Michi Henning To: Paul H Kyzivat cc: Steve Vinoski , cxx_revision@omg.org Subject: Re: Is public _ptr member mandatory? Organization: Triodia Technologies Content-ID: On Thu, 19 Nov 1998, Paul H Kyzivat wrote: > Yes, I am formally proposing that we get rid of it. I second that! I've been annoyed at this hangover for a long time too -- "Gee, let's just slap in a public data member so we can violate encapsulation to our heart's content." Not. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Date: Thu, 04 Mar 1999 14:54:19 -0500 From: Paul H Kyzivat Organization: NobleNet To: cxx_revision@omg.org Subject: RE: Issue 2222: Is public _ptr member mandatory? I raised the issue, so I guess it is fair that I propose the resolution. Issue 2222: Is public _ptr member mandatory? (cxx_revision)Click here Source: NobleNet (Mr. Paul Kyzivat, paulk@noblenet.com) Nature: Uncategorized Issue Severity: Summary: In a number of places in the sample code for the C++ binding, the symbol _ptr is used as a member variable in _var types. In all of these the actual member is shown as private, so it is clear that actual implementations could use something else. The one exception to this is in section 20.10 on the Mapping for Struct Types. This discusses (without sample code) the mapping for string and object reference members of structs. Resolution: Remove references to the _ptr member in section 20.10. Replace with references to the accessor functions. Remove warning directly as a pointer using the _ptr field accessor. This usage is dangerou directly as a pointer using the inout() accessor. On the next page, replace "_ptr" with "inout()" in example 10, and replace the following sentence of explanation with: Finally, line 10 uses the inout() accessor, so no freeing or copying takes place. Actions taken: November 19, 1998: received issue s and generally should be avoided. with: When the old storage must not be freed (for example, it is part of the functions about danger - this isn't dangerous. Revised Text: In Section 20.10 (Mapping for Struct Types), on pg 20-36, replace the paragraph: When the old storage must not be freed (for example, it is part of the function Date: Mon, 28 May 2001 16:12:55 +1000 (EST) From: Michi Henning Reply-To: C++ Revision Task Force To: C++ Revision Task Force Subject: Proposal for 2222 Message-ID: Organization: IONA Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: L@jd9g"D!!0`h!!Fj;!! Status: RO This proposal mostly follows Paul's proposal in the issue archive. (I decided to delete example 10 of section 1.10 instead of changing it to inout() as suggested by Paul because that results in two String_vars owning the same string, which is rather bad news...) Remove the following text in 1.10, page 1-30: When the old storage must not be freed (for example, it is part of the function's activation record), one can access the member directly as a pointer using the _ptr field accessor. This usage is dangerous and generally should be avoided. Near the end of 1.10, page 1-32, delete the example marked "// 10", together with the para that follows it. Cheers, Michi. -- Michi Henning +61 7 3324 9633 Chief CORBA Scientist +61 4 1118 2700 (mobile) IONA Technologies +61 7 3324 9799 (fax) Total Business Integration http://www.ooc.com.au/staff/michi