Issue 3567: Any insertion for Boolean/Octet/Char (cxx_revision) Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com) Nature: Uncategorized Issue Severity: Summary: The mapping is currently a bit ambiguous about the insertion/extraction operators for Any. It says: Assuming that boolean, char, and octet all map the C++ type unsigned char, the private and unimplemented operator<<= and operator>>= functions for unsigned char will cause a compile-time error if straight insertion or extraction of any of the boolean, char, or octet types is attempted. This is ambiguous. It is not clear what is qualified by the first part of the sentence "Assuming that...". It could qualify all of the paragraph, in which case the interpretation is: Only on platform where these three types indeed map to the same C++ type will it be necessary to have these unimplemented operators. // C++ Octet oct = 040; Any any; any <<= oct; // this line will not compile any <<= Any::from_octet(oct); // but this one will This is unambiguous, but it doesn't make it clear whether this will be the case for all mapping implementations, or only those where the IDL types map to ambiguous C++ types. It is important to note that the previous example is only one possible implementation for these helpers, not a mandated one. Other compliant implementations are possible, such as providing them via in-lined static any member functions if boolean, char, and octet are in fact mapped to distinct C++ types. All compliant C++ mapping implementations must provide these helpers, however, for purposes of portability. Again, this is slightly ambiguous because, even though it requires the presence of the helpers, it doesn't make any statement about whether the prohibition of the direct insertion operators is mandatory for all implementations. I would suggest to clarify the text to state that direct insertion/extraction of Bool, Octet, and Char must fail with a compile-time error, regardless of how these types are mapped. Resolution: Revised Text: Actions taken: April 18, 2000: received issue Discussion: deferred in June 2011 to the next RTF End of Annotations:===== Date: Tue, 18 Apr 2000 14:06:15 +1000 (EST) From: Michi Henning Reply-To: C++ Revision Task Force To: C++ Revision Task Force cc: issues@omg.org Subject: Any insertion for Boolean/Octet/Char Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 9=W!!0%>!!b7Qe9p8od9 The mapping is currently a bit ambiguous about the insertion/extraction operators for Any. It says: Assuming that boolean, char, and octet all map the C++ type unsigned char, the private and unimplemented operator<<= and operator>>= functions for unsigned char will cause a compile-time error if straight insertion or extraction of any of the boolean, char, or octet types is attempted. This is ambiguous. It is not clear what is qualified by the first part of the sentence "Assuming that...". It could qualify all of the paragraph, in which case the interpretation is: Only on platform where these three types indeed map to the same C++ type will it be necessary to have these unimplemented operators. // C++ Octet oct = 040; Any any; any <<= oct; // this line will not compile any <<= Any::from_octet(oct); // but this one will This is unambiguous, but it doesn't make it clear whether this will be the case for all mapping implementations, or only those where the IDL types map to ambiguous C++ types. It is important to note that the previous example is only one possible implementation for these helpers, not a mandated one. Other compliant implementations are possible, such as providing them via in-lined static any member functions if boolean, char, and octet are in fact mapped to distinct C++ types. All compliant C++ mapping implementations must provide these helpers, however, for purposes of portability. Again, this is slightly ambiguous because, even though it requires the presence of the helpers, it doesn't make any statement about whether the prohibition of the direct insertion operators is mandatory for all implementations. I would suggest to clarify the text to state that direct insertion/extraction of Bool, Octet, and Char must fail with a compile-time error, regardless of how these types are mapped. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: Paul Kyzivat To: "'C++ Revision Task Force'" Subject: RE: Any insertion for Boolean/Octet/Char Date: Tue, 18 Apr 2000 08:27:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: e^G!!o4Od9~O4e9Hfm!! > From: Michi Henning [mailto:michi@ooc.com.au] > I would suggest to clarify the text to state that direct > insertion/extraction > of Bool, Octet, and Char must fail with a compile-time error, > regardless > of how these types are mapped. This seems to be unnecessarily harsh and unfriendly. It seems to me that it would be better to state that direct insertion/extraction may be provided if unambiguous in the mapping, but must cause a compile error if ambiguous. But either way, the helper functions should be available. This permits a portable application to always use the helpers, while permitting someone who isn't so concerned with portability to use the more convenient notation if it works. Since bool is now widely available, this could certainly simplify its use in many cases. Paul Date: Wed, 19 Apr 2000 07:15:27 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: "'C++ Revision Task Force'" Subject: RE: Any insertion for Boolean/Octet/Char In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BDF4@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: CAid9- This seems to be unnecessarily harsh and unfriendly. > It seems to me that it would be better to state that direct > insertion/extraction may be provided if unambiguous in the mapping, > but must cause a compile error if ambiguous. But either way, > the helper functions should be available. > > This permits a portable application to always use the helpers, > while permitting someone who isn't so concerned with portability > to use the more convenient notation if it works. > > Since bool is now widely available, this could certainly > simplify its use in many cases. Hmmm... I considered this too, but I think taking this stance would be singularly unhelpful. On a platform where the inserters are supported, I would never know that I'm doing something that's potentially non-portable, only to find out that I have to change my code when I move it to a different ORB. Unless we want to take further steps toward deprecating non-standard C++ compilers, I think the strict behavior is preferable because it doesn't allow programmers to fall into this trap. At any rate, whatever we decide, I think we should update the spec to make it clear what we mean because, right now, it's ambiguous. Cheers, Michi. From: Paul Kyzivat To: "'Michi Henning'" , Paul Kyzivat Cc: "'C++ Revision Task Force'" Subject: RE: Any insertion for Boolean/Octet/Char Date: Tue, 18 Apr 2000 17:57:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: cUk!!W=k!!DF4!!)+B!! Michi, The language mapping is already not very user friendly. I believe we should try to make it more friendly when we can. If somebody first uses the friendly form and then ports to a platform that doesn't support it, it is a small matter to make the change, and it will be a compatible change. With luck, lots of users will never notice. We have similar cases with the in, inout, out operations on _var types - with a nice compiler you usually don't need them. Paul > -----Original Message----- > From: Michi Henning [mailto:michi@ooc.com.au] > Sent: Tuesday, April 18, 2000 5:15 PM > To: Paul Kyzivat > Cc: 'C++ Revision Task Force' > Subject: RE: Any insertion for Boolean/Octet/Char > > > On Tue, 18 Apr 2000, Paul Kyzivat wrote: > > > This seems to be unnecessarily harsh and unfriendly. > > It seems to me that it would be better to state that direct > > insertion/extraction may be provided if unambiguous in the mapping, > > but must cause a compile error if ambiguous. But either way, > > the helper functions should be available. > > > > This permits a portable application to always use the helpers, > > while permitting someone who isn't so concerned with portability > > to use the more convenient notation if it works. > > > > Since bool is now widely available, this could certainly > > simplify its use in many cases. > > Hmmm... I considered this too, but I think taking this stance would be > singularly unhelpful. On a platform where the inserters are > supported, I > would never know that I'm doing something that's potentially > non-portable, > only to find out that I have to change my code when I move it to a > different ORB. Unless we want to take further steps toward deprecating > non-standard C++ compilers, I think the strict behavior is > preferable because > it doesn't allow programmers to fall into this trap. > > At any rate, whatever we decide, I think we should update the spec to > make it clear what we mean because, right now, it's ambiguous. > > Cheers, > > Michi. > Date: Wed, 19 Apr 2000 10:49:38 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: "'C++ Revision Task Force'" Subject: RE: Any insertion for Boolean/Octet/Char In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BE03@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ?K/!!!4K!!1>?e9H'h!! On Tue, 18 Apr 2000, Paul Kyzivat wrote: > The language mapping is already not very user friendly. > I believe we should try to make it more friendly when we can. > If somebody first uses the friendly form and then ports to > a platform that doesn't support it, it is a small matter to > make the change, and it will be a compatible change. > > With luck, lots of users will never notice. Hmmm... I'm not sure I want to rely on luck here. Basically, I think that the mapping should actively prevent people from doing non-portable things as much as possible. That was the intent of the hidden operators for octet, boolean, and char. By all means, we may decide to no longer hide these operators. However (at least in my mind), that implies a commitment to no longer supporting non-standard compilers and moving the mapping more and more in a direction where it relies on standard C++ features. We have to be clear about whether this is the right time to make such a commitment. (My personal feeling is that it is still a bit early.) But I'm not particularly happy about allowing things in the mapping that simply won't port to other environments. Given that the mapping is all about portability, I think it's better to force everyone to use a helper function than to only have the helper function present in some environments, so people who don't use the helper get bitten when they port. > We have similar cases with the in, inout, out operations on > _var types - with a nice compiler you usually don't need them. I think these were simply concessions to the reality that many compilers have problems applying the default conversions. Sure, with a working compiler, you won't need them. However, that's of little consolation to people who don't have a working compiler... Cheers, Michi. From: Paul Kyzivat To: "'C++ Revision Task Force'" Subject: RE: Any insertion for Boolean/Octet/Char Date: Wed, 19 Apr 2000 08:50:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: [~p!!SjK!!E4]!!D^*!! I guess we will just have to agree to disagree. It is up to the user to decide if he cares about platforms that don't use bool. The penalty for deciding wrong is minimal. And to me this is exactly the same as the operations on _vars - by your philosophy we ought to remove the implicit casts and require the use of those operations. Paul > -----Original Message----- > From: Michi Henning [mailto:michi@ooc.com.au] > Sent: Tuesday, April 18, 2000 8:50 PM > To: Paul Kyzivat > Cc: 'C++ Revision Task Force' > Subject: RE: Any insertion for Boolean/Octet/Char > > > On Tue, 18 Apr 2000, Paul Kyzivat wrote: > > > The language mapping is already not very user friendly. > > I believe we should try to make it more friendly when we can. > > If somebody first uses the friendly form and then ports to > > a platform that doesn't support it, it is a small matter to > > make the change, and it will be a compatible change. > > > > With luck, lots of users will never notice. > > Hmmm... I'm not sure I want to rely on luck here. Basically, > I think that > the mapping should actively prevent people from doing > non-portable things > as much as possible. That was the intent of the hidden operators for > octet, boolean, and char. By all means, we may decide to no > longer hide > these operators. However (at least in my mind), that implies > a commitment > to no longer supporting non-standard compilers and moving the > mapping more > and more in a direction where it relies on standard C++ > features. We have > to be clear about whether this is the right time to make such > a commitment. > (My personal feeling is that it is still a bit early.) > > But I'm not particularly happy about allowing things in the > mapping that > simply won't port to other environments. Given that the mapping is all > about portability, I think it's better to force everyone to > use a helper > function than to only have the helper function present in > some environments, > so people who don't use the helper get bitten when they port. > > > We have similar cases with the in, inout, out operations on > > _var types - with a nice compiler you usually don't need them. > > I think these were simply concessions to the reality that > many compilers > have problems applying the default conversions. Sure, with a > working compiler, > you won't need them. However, that's of little consolation to > people who > don't have a working compiler... > > Cheers, > > Michi. > Date: Thu, 20 Apr 2000 07:24:39 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: "'C++ Revision Task Force'" Subject: RE: Any insertion for Boolean/Octet/Char In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BE0B@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: '3Me9'Qk!!2bUd9~ko!! On Wed, 19 Apr 2000, Paul Kyzivat wrote: > I guess we will just have to agree to disagree. > > It is up to the user to decide if he cares about platforms that > don't use > bool. The penalty for deciding wrong is minimal. And to me this is > exactly > the same as the operations on _vars - by your philosophy we ought to > remove > the implicit casts and require the use of those operations. I see what you mean. What do other people think? Jon, Steve? Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html