Issue 1747: from_string issue (cxx_revision) Source: (, ) Nature: Revision Severity: Summary: Summary: The latest C++ mapping (document orbos/98-05-08) defines the Any::from_string type as struct from_string { from_string(char* s, ULong b, Boolean nocopy = FALSE) : val(s), bound(b) {} ... }; In ANSI C++, this disallows the following code: any <<= Any::from_string("string literal"); This is because string literals in ANSI C++ are const char[], not char[]. Therefore, from_string should have an additional constructor to allow insertion of a const char* as well. Resolution: Close as duplicate of 2453. Revised Text: Actions taken: July 28, 1998: received issue March 19, 1999: closed issue Discussion: End of Annotations:===== Return-Path: X-Sender: vinoski@mail.boston.iona.ie Date: Tue, 28 Jul 1998 11:04:40 -0400 To: cxx_revision@omg.org, issues@omg.org From: Steve Vinoski Subject: from_string issue The latest C++ mapping (document orbos/98-05-08) defines the Any::from_string type as struct from_string { from_string(char* s, ULong b, Boolean nocopy = FALSE) : val(s), bound(b) {} ... }; In ANSI C++, this disallows the following code: any <<= Any::from_string("string literal"); This is because string literals in ANSI C++ are const char[], not char[]. Therefore, from_string should have an additional constructor to allow insertion of a const char* as well. --steve Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Thu, 6 Aug 1998 07:05:14 +1000 (EST) From: Michi Henning To: cxx_revision@omg.org Subject: Re: issue 1747 -- C++ Issue > In ANSI C++, this disallows the following code: > > any <<= Any::from_string("string literal"); > > This is because string literals in ANSI C++ are const char[], not > char[]. > Therefore, from_string should have an additional constructor to > allow > insertion of a const char* as well. I think it might be easier to change the signature of the existing from_string function to accept a const char *. That way, we don't need to overload the function. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: X-Sender: vinoski@mail.boston.iona.ie Date: Wed, 05 Aug 1998 17:59:25 -0400 To: Michi Henning From: Steve Vinoski Subject: Re: issue 1747 -- C++ Issue Cc: cxx_revision@omg.org References: <3.0.32.19980805164440.00b70d34@emerald.omg.org> At 07:05 AM 8/6/98 +1000, Michi Henning wrote: >> In ANSI C++, this disallows the following code: >> >> any <<= Any::from_string("string literal"); >> >> This is because string literals in ANSI C++ are const char[], not >> char[]. >> Therefore, from_string should have an additional constructor to >> allow >> insertion of a const char* as well. > >I think it might be easier to change the signature of the existing >from_string function to accept a const char *. That way, we don't >> need >to overload the function. We can't do that because from_string also allows its first argument to be adopted (that's why it's not a const char* already). --steve Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Thu, 6 Aug 1998 08:58:22 +1000 (EST) From: Michi Henning Reply-To: Michi Henning To: Steve Vinoski cc: cxx_revision@omg.org Subject: Re: issue 1747 -- C++ Issue On Wed, 5 Aug 1998, Steve Vinoski wrote: > >I think it might be easier to change the signature of the existing > >from_string function to accept a const char *. That way, we don't > need > >to overload the function. > > We can't do that because from_string also allows its first argument > to be > adopted (that's why it's not a const char* already). Hmmm... Does that really stop it? After all, if I'm silly enought to write a <<= CORBA::Any::from_string("Hello", 1); I deserve what I get, no? The implementation of from_string can always cast away the constness internally if it has adopted the string. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: X-Sender: vinoski@mail.boston.iona.ie Date: Wed, 05 Aug 1998 19:15:16 -0400 To: Michi Henning From: Steve Vinoski Subject: Re: issue 1747 -- C++ Issue Cc: cxx_revision@omg.org References: <199808052207.SAA03673@boston.iona.ie> At 08:58 AM 8/6/98 +1000, Michi Henning wrote: >Hmmm... Does that really stop it? After all, if I'm silly enought to write > > a <<= CORBA::Any::from_string("Hello", 1); > >I deserve what I get, no? I wasn't worried about folks who are silly enough to try this. Rather, I just think signatures should not be misleading. If something has a chance of being adopted, declaring it as const is not good form, IMO. >The implementation of from_string can always >cast away the constness internally if it has adopted the string. True, but casting away constness should be avoided if at all possible. Avoiding it in this case is trivial by providing another constructor that takes only a const char*, and no adoption boolean. That makes it clear that one constructor is for possible adoption, the other doesn't. --steve Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Thu, 6 Aug 1998 09:25:40 +1000 (EST) From: Michi Henning To: Steve Vinoski cc: cxx_revision@omg.org Subject: Re: issue 1747 -- C++ Issue On Wed, 5 Aug 1998, Steve Vinoski wrote: > I wasn't worried about folks who are silly enough to try this. Rather, I > just think signatures should not be misleading. If something has a chance > of being adopted, declaring it as const is not good form, IMO. Fair enough -- you've convinced me. > >The implementation of from_string can always > >cast away the constness internally if it has adopted the string. > > True, but casting away constness should be avoided if at all > possible. > Avoiding it in this case is trivial by providing another constructor > that > takes only a const char*, and no adoption boolean. That makes it > clear that > one constructor is for possible adoption, the other doesn't. Yep, I agree. Cheers, Michi. Date: Sun, 21 Feb 1999 10:38:00 +1000 (EST) From: Michi Henning To: C++ Revision Task Force Subject: Proposal for 1747 Organization: Triodia Technologies Fix issue as described in the archive. The same change must be applied for wstring as well. 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: Wed, 10 Mar 1999 10:59:37 -0500 From: Paul H Kyzivat Organization: NobleNet To: Steve Vinoski CC: ian@aptest.ie, dan.frantz@beasys.com, michi@triodia.com, jon@floorboard.com, jis@fpk.hp.com, jmischkinsky@inprise.com, mcheng@austin.ibm.com, ml@ooc.com, bill.beckwith@ois.com, jhierro@tid.es, janssen@parc.xerox.com, cxx_revision@omg.org Subject: Re: C++ issues for Vote 2 References: <4.1.19990309123019.00baf8c0@mail.boston.iona.ie> NobleNet (Rogue Wave) votes as follows: YES: Issue 1686: resolve_initial_references missing from ORB interface, Issue 1777: DSI C++ issue: Note: this implies that set_result and set_exception copy their arguments. And that requires the orb to be able to copy an exception. This capability is not an explicit part of the mapping for exceptions. (Nor need it be.) Issue 2234: String sequence and allocbuf Issue 2346: Any inserters and extractors Issue 2351: CORBA2.3 C++ mapping for the TypeCode class Issue 2354: CustomMarshal mapping typo Issue 2355: ORB mapping re Policy NO: Issue 800: Missing mappings for Object I don't see a compelling need to make this change. Issue 1657: Section 7.3.5 ValueBase editorial changes I don't understand what I am voting for. What missing return values are to be added? Issue 1747: from_string issue The proposed change appears to be incorrect. The initializer val(s) shouldn't compile when s is const, because val is not const. Perhaps in this case the initializer should be val(CORBA::string_dup(s)). ABSTAIN: Issue 1776: New C++ issue about T_out classes I don't believe this code is intended to be normative. It should be within the implementor's latitude to fix this, in this way or some other way, if it needs fixing. As long as it isn't normative, it is also ok with me if this is changed. Issue 2226: Errors in example code for boxed struct Issue 2350: boxed types for floating point values