Issue 1521: Spec is too verse in defining the T_var types for fixed length (cxx_revision) Source: (, ) Nature: Revision Severity: Summary: Summary: 3. The spec is too terse in defining the T_var types for fixed length structured types as having "the same semantics as T_var types for variable-length types." This is not quite true, since the signatures for out and return values of these types are different, thus changing the semantics of the implicit and explicit (out() and _retn()) conversion operations. The spec should show the definition of the out() and _retn() operations for fixed length types as: T &T_var::out() { return ptr_; } T &T_var::_retn() { return ptr_; } Resolution: closed/resolved Revised Text: On page 1-25 of formal/99-07-41, change the paragraph beginning with "The T_var types are also produced for fixed-length structured types..." to the following: The T_var types are also produced for fixed-length structured types for reasons of consistency. These types have the same semantics as T_var types for variable-length types. This allows applications to be coded in terms of T_var types regardless of whether the underlying types are fixed- or variable-length. T_var types for fixed-length structured types have the following general form: class T_var { public: T_var() : m_ptr(0) {} T_var(T *t) : m_ptr(t) {} T_var(const T& t) : m_ptr(new T(t)) {} T_var(const T_var &t) : m_ptr(0) { if (t.m_ptr != 0) m_ptr = new T(*t.m_ptr); } ~T_var() { delete m_ptr; } T_var &operator=(T *t) { if (t != m_ptr) { delete m_ptr; m_ptr = t; } return *this; } T_var &operator=(const T& t) { if (&t != m_ptr) { T* old_m_ptr = m_ptr; m_ptr = new T(t); delete old_m_ptr; } return *this; } T_var &operator=(const T_var &t) { if (this != &t) { T* old_m_ptr = m_ptr; if (t.m_ptr != 0) m_ptr = new T(*t.m_ptr); else m_ptr = 0; delete old_m_ptr; } return *this; } T* operator->() { return m_ptr; } const T* operator->() const { return m_ptr; } const T& in() const { return *m_ptr; } T& inout() { return *m_ptr; } T& out() { if (m_ptr == 0) m_ptr = new T; return *m_ptr; } T _retn() { return *m_ptr; } private: T* m_ptr; }; Actions taken: June 10, 1998: received issue June 13, 2000: closed issue Discussion: End of Annotations:===== Return-Path: Sender: jon@floorboard.com Date: Wed, 10 Jun 1998 12:15:04 -0700 From: Jonathan Biggar To: issues@omg.org, cxx_revision@omg.org Subject: Problems related to _var & _out types in C++ language mapping 3. The spec is too terse in defining the T_var types for fixed length structured types as having "the same semantics as T_var types for variable-length types." This is not quite true, since the signatures for out and return values of these types are different, thus changing the semantics of the implicit and explicit (out() and _retn()) conversion operations. The spec should show the definition of the out() and _retn() operations for fixed length types as: T &T_var::out() { return ptr_; } T &T_var::_retn() { return ptr_; } Actually, I think the semantics of _retn() is problematical, because it performs two purposes now. The definition I proposed above is correct for using it to supply the return value of an IDL operation, but looses the ownership transfer semantics of the variable length T_var type. Perhaps it would be good to define a T_var::_release() operation as well that performs the ownership transfer the same way for both fixed and variable length types? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 9 Dec 1999 12:43:04 +1000 (EST) From: Michi Henning Reply-To: C++ Revision Task Force To: C++ Revision Task Force cc: issues@omg.org Subject: _var types for fixed-length underlying types Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: NT[d9A)^d9AOGe9*#=e9 Hi, the spec currently is extremely vague about how _var types for fixed-length underlying types are supposed to work. The only words are: The T_var types are also produced for fixed-length structured types for reasons of consistency. These types have the same semantics as T_var types for variable-length types. This allows applications to be coded in terms of T_var types regardless of whether the underlying types are fixed- or variable-length. This has long been a source of confusion to me. In particular, it doesn't answer questions such as - Can a _var for a fixed-length type be initialized with a pointer to the fixed-length type? If so, does the _var adopt it? - Can a _var for fixed-length type be initialized with a value? - What does assignment between _vars for fixed-length types do? - Does the _var for a fixed-length type work like a reference and remain bound to the same block of memory? - What does default-initialization of such a _var do? - etc, etc. Rather than playing guessing games, Steve++ and myself hacked up a template that is meant to illustrate how these things are supposed to work. The suggestion is to add this to the spec and make it explicit what the semantics of _var types for fixed-length underlying types are. Here is the template: class T_var { public: T_var() : m_ptr(0) {} T_var(T *t) : m_ptr(t) {} T_var(const T& t) : m_ptr(new T(t)) {} T_var(const T_var &t) : m_ptr(0) { if (t.m_ptr != 0) m_ptr = new T(*t.m_ptr); } ~T_var() { delete m_ptr; } T_var &operator=(T *t) { if (t != m_ptr) { delete m_ptr; m_ptr = t; } return *this; } T_var &operator=(const T& t) { if (&t != m_ptr) { delete m_ptr; m_ptr = new T(t); } return *this; } T_var &operator=(const T_var &t) { if (this != &t) { delete m_ptr; if (t.m_ptr != 0) m_ptr = new T(*t.m_ptr); else m_ptr = 0; } return *this; } T* operator->() { return m_ptr; } const T* operator->() const { return m_ptr; } const T& in() const { return *m_ptr; } T& inout() { return *m_ptr; } T& out() { if (m_ptr == 0) m_ptr = new T; return *m_ptr; } T _retn() { return *m_ptr; } private: T* m_ptr; }; Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) PO Box 372 +61 7 3891 5009 (fax) Annerley 4103 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jon@floorboard.com Message-ID: <384F22BB.ADB6922B@floorboard.com> Date: Wed, 08 Dec 1999 19:32:11 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: C++ Revision Task Force CC: issues@omg.org Subject: Re: _var types for fixed-length underlying types References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: +&Q!!Gf > Hi, > > the spec currently is extremely vague about how _var types for > fixed-length > underlying types are supposed to work. The only words are: > > The T_var types are also produced for fixed-length > structured > types for reasons of consistency. These types have the same > semantics as T_var types for variable-length types. This > allows > applications to be coded in terms of T_var types regardless > of > whether the underlying types are fixed- or variable-length. > > This has long been a source of confusion to me. In particular, it > doesn't > answer questions such as > > - Can a _var for a fixed-length type be initialized with a > pointer > to the fixed-length type? If so, does the _var adopt it? > > - Can a _var for fixed-length type be initialized with a > value? > > - What does assignment between _vars for fixed-length types > do? > > - Does the _var for a fixed-length type work like a > reference > and remain bound to the same block of memory? > > - What does default-initialization of such a _var do? > > - etc, etc. > > Rather than playing guessing games, Steve++ and myself hacked up a > template that is meant to illustrate how these things are supposed > to work. > The suggestion is to add this to the spec and make it explicit what > the > semantics of _var types for fixed-length underlying types are. > > Here is the template: > > class T_var > { [SNIPPED] > }; Modulo any undetected bugs in my first pass proof-read, this is exactly what I expect a T_var for a fixed-length type should do. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jon@floorboard.com Message-ID: <384F2368.F286F811@floorboard.com> Date: Wed, 08 Dec 1999 19:35:04 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: C++ Revision Task Force CC: issues@omg.org Subject: Re: _var types for fixed-length underlying types References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: \;:e9k\O!!YAf!!^4?!! Michi Henning wrote: > > Hi, > > the spec currently is extremely vague about how _var types for > fixed-length > underlying types are supposed to work. The only words are: > > The T_var types are also produced for fixed-length > structured > types for reasons of consistency. These types have the same > semantics as T_var types for variable-length types. This > allows > applications to be coded in terms of T_var types regardless > of > whether the underlying types are fixed- or variable-length. > > This has long been a source of confusion to me. In particular, it > doesn't > answer questions such as > > - Can a _var for a fixed-length type be initialized with a > pointer > to the fixed-length type? If so, does the _var adopt it? > > - Can a _var for fixed-length type be initialized with a > value? > > - What does assignment between _vars for fixed-length types > do? > > - Does the _var for a fixed-length type work like a > reference > and remain bound to the same block of memory? > > - What does default-initialization of such a _var do? > > - etc, etc. [I hit send to soon.] This is issue 1521 in the database. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 9 Dec 1999 14:30:22 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: C++ Revision Task Force , issues@omg.org Subject: Re: _var types for fixed-length underlying types In-Reply-To: <384F22BB.ADB6922B@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Q+c!!ZkB!!l<6!!k/He9 On Wed, 8 Dec 1999, Jonathan Biggar wrote: > > class T_var > > { > [SNIPPED] > > }; > > Modulo any undetected bugs in my first pass proof-read, This template was compiled and tested, don't you worry about that! :-) > this is exactly > what I expect a T_var for a fixed-length type should do. Great minds think alike! :-) Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) PO Box 372 +61 7 3891 5009 (fax) Annerley 4103 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html X-Lotus-FromDomain: QATRAIN From: "Kevlin Henney" To: "C++ Revision Task Force" Message-ID: <80256842.001D7DCC.00@smtp.qatraining.com> Date: Thu, 9 Dec 1999 05:29:45 +0000 Subject: Re: _var types for fixed-length underlying types Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: ^1 Rather than playing guessing games, Steve++ and myself hacked up a > template that is meant to illustrate how these things are supposed > to work. > The suggestion is to add this to the spec and make it explicit what > the > semantics of _var types for fixed-length underlying types are. > > Here is the template: A small tweak would make the copying assignment operators exception safe, which might be a gtee and recommended practice worth including: [...] T_var &operator=(const T& t) { if (&t != m_ptr) { T* old_m_ptr = m_ptr; m_ptr = new T(t); delete old_m_ptr; } return *this; } T_var &operator=(const T_var &t) { if (this != &t) { T* old_m_ptr = m_ptr; if (t.m_ptr != 0) m_ptr = new T(*t.m_ptr); else m_ptr = 0; delete old_m_ptr; } return *this; } [...] Kevlin X-Sender: vinoski@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 09 Dec 1999 00:26:31 -0500 To: Michi Henning From: Steve Vinoski Subject: Re: _var types for fixed-length underlying types Cc: Jonathan Biggar , C++ Revision Task Force In-Reply-To: References: <384F22BB.ADB6922B@floorboard.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: 19Fe9I%md9R12!!-eod9 At 02:30 PM 12/9/99 +1000, Michi Henning wrote: >On Wed, 8 Dec 1999, Jonathan Biggar wrote: > >> > class T_var >> > { >> [SNIPPED] >> > }; >> >> Modulo any undetected bugs in my first pass proof-read, > >This template was compiled and tested, don't you worry about that! :-) And Purified. >> this is exactly >> what I expect a T_var for a fixed-length type should do. > >Great minds think alike! :-) Indeed! --steve X-Sender: vinoski@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 09 Dec 1999 00:27:48 -0500 To: cxx_revision@omg.org From: Steve Vinoski Subject: Fwd: Re: _var types for fixed-length underlying types Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: p'P!!^Ia!!?fI!!lh`d9 I wrote: >At 02:30 PM 12/9/99 +1000, Michi Henning wrote: >>On Wed, 8 Dec 1999, Jonathan Biggar wrote: >> >>> > class T_var >>> > { >>> [SNIPPED] >>> > }; >>> >>> Modulo any undetected bugs in my first pass proof-read, >> >>This template was compiled and tested, don't you worry about that! :-) > >And Purified. Oops, also forgot to mention that we PureCoveraged it too, to make sure our tests exercised everything. --steve Sender: jon@floorboard.com Message-ID: <384F53D9.B0892D25@floorboard.com> Date: Wed, 08 Dec 1999 23:01:45 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Kevlin Henney CC: C++ Revision Task Force Subject: Re: _var types for fixed-length underlying types References: <80256842.001D7DCC.00@smtp.qatraining.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: OM6!!HXMe96&U!!al,!! Kevlin Henney wrote: > A small tweak would make the copying assignment operators exception > safe, > which might be a gtee and recommended practice worth including: > > [...] > T_var &operator=(const T& t) { > if (&t != m_ptr) { > T* old_m_ptr = m_ptr; > m_ptr = new T(t); > delete old_m_ptr; > } > return *this; > } > > T_var &operator=(const T_var &t) { > if (this != &t) { > T* old_m_ptr = m_ptr; > if (t.m_ptr != 0) > m_ptr = new T(*t.m_ptr); > else > m_ptr = 0; > delete old_m_ptr; > } > return *this; > } Good! -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org X-Sender: vinoski@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 04 Jan 2000 15:24:21 -0500 To: C++ Revision Task Force From: Steve Vinoski Subject: Re: _var types for fixed-length underlying types In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: 4bWd9VX#e9H93!!!nHe9 Nobody ever made a formal proposal for 1521 and 3101 (duplicates, really), so please find my attempt at it below. --steve On page 1-25 of formal/99-07-41, change the paragraph beginning with "The T_var types are also produced for fixed-length structured types..." to the following: The T_var types are also produced for fixed-length structured types for reasons of consistency. These types have the same semantics as T_var types for variable-length types. This allows applications to be coded in terms of T_var types regardless of whether the underlying types are fixed- or variable-length. T_var types for fixed-length structured types have the following general form: class T_var { public: T_var() : m_ptr(0) {} T_var(T *t) : m_ptr(t) {} T_var(const T& t) : m_ptr(new T(t)) {} T_var(const T_var &t) : m_ptr(0) { if (t.m_ptr != 0) m_ptr = new T(*t.m_ptr); } ~T_var() { delete m_ptr; } T_var &operator=(T *t) { if (t != m_ptr) { delete m_ptr; m_ptr = t; } return *this; } T_var &operator=(const T& t) { if (&t != m_ptr) { T* old_m_ptr = m_ptr; m_ptr = new T(t); delete old_m_ptr; } return *this; } T_var &operator=(const T_var &t) { if (this != &t) { T* old_m_ptr = m_ptr; if (t.m_ptr != 0) m_ptr = new T(*t.m_ptr); else m_ptr = 0; delete old_m_ptr; } return *this; } T* operator->() { return m_ptr; } const T* operator->() const { return m_ptr; } const T& in() const { return *m_ptr; } T& inout() { return *m_ptr; } T& out() { if (m_ptr == 0) m_ptr = new T; return *m_ptr; } T _retn() { return *m_ptr; } private: T* m_ptr; }; Date: Mon, 28 May 2001 13:06:19 +1000 (EST) From: Michi Henning Reply-To: C++ Revision Task Force To: C++ Revision Task Force Subject: Issue 1521 cleanup Message-ID: Organization: IONA Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: fg,!!7ba!!(5Pe9A'8e9 Status: RO Hi, we voted on 1521 in the previous RTF, so 1521 is closed in the issue database. However, the edits didn't make it into the document. Again, unless someone objects, I will treat these as editorial changes and simply apply the resolution shown in http://cgi.omg.org/issues/issue1521.txt. 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 Date: Mon, 28 May 2001 13:09:40 +1000 (EST) From: Michi Henning To: C++ Revision Task Force Subject: Re: Issue 1521 cleanup In-Reply-To: Message-ID: Organization: IONA Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: GG=e9%kX!!\`Rd9jK]!! Status: RO On Mon, 28 May 2001, Michi Henning wrote: > Hi, > > we voted on 1521 in the previous RTF, so 1521 is closed in the issue > database. > However, the edits didn't make it into the document. > > Again, unless someone objects, I will treat these as editorial > changes > and simply apply the resolution shown in > http://cgi.omg.org/issues/issue1521.txt. Oops, forget it -- brainlock on my part. I was looking at the wrong document version. Edit is already applied. 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