Issue 123: Fixed structs (cxx_revision) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: Should the ORB hide the difference between fixed and variable length structs from the application developer? Resolution: Close no change. This change is too intrusive and would break too much existing code. Revised Text: Actions taken: September 23, 1996: Received issue June 13, 2000: closed issue Discussion: End of Annotations:===== >From klavin@iona.com Tue Sep 17 14:04:04 1996 Received: from operation.dublin.iona.ie by amethyst.omg.org.omg.org (5.4R2.01/1.34) id AA09691; Tue, 17 Sep 1996 14:04:04 -0400 Received: from ultra (ultra [192.122.221.136]) by dublin.iona.ie (8.7.5/jm-1.01) with ESMTP id TAA10059 for ; Tue, 17 Sep 1996 19:01:02 +0100 (BST) From: Karen Lavin Received: (klavin@localhost) by ultra (SMI-8.6/8.6.9) id TAA14040 for cxx_revision@omg.org; Tue, 17 Sep 1996 19:00:50 +0100 Date: Tue, 17 Sep 1996 19:00:50 +0100 Message-Id: <199609171800.TAA14040@ultra> To: cxx_revision@omg.org Subject: Fixed structs X-Sun-Charset: US-ASCII Hi, I'm Karen Lavin from Iona Technologies, and I have taken over from Paul O Neill with regard to the IDL compiler. I have a question for you with respect to fixed vs variable length structs. Should we, as an orb developer, be hiding the difference between fixed and variable length structs from the application developer. For instance... If you have a varaible length struct you can do the following... 1: STRUCT_var mtsytuct_var = ret_struct(); where STRUCT* ret_struct()... is the sig of ret_struct. If the struct was a fixed length struct then this would not be possible without the addition of a function of the following function to the STRUCT_var class. STRUCT_var& operator=(STRUCT& rhs) 2: You can use a STRUCT_var as an out parameter if its variable length as follows STRUCT_var mystruct; mt_ptr->my_op(mystruct); If its a fixed length struct you can not do this. You first have to new the struct. Should we be hiding these differences from the user or shold the user write code differently depending on the nature of the struct. Regards Karen ----- End Included Message ----- >From linton@vitria.com Wed Sep 18 13:35:23 1996 Received: from gorgon.vitria.com by amethyst.omg.org.omg.org (5.4R2.01/1.34) id AA19558; Wed, 18 Sep 1996 13:35:23 -0400 Received: from hydra.vitria.com (hydra.vitria.com [10.206.138.5]) by vitria.com (8.7.4/8.7.3) with ESMTP id KAA07687 for ; Wed, 18 Sep 1996 10:32:15 -0700 (PDT) Received: from glider (glider.vitria.com [10.206.138.16]) by hydra.vitria.com (8.7.4/8.7.3) with SMTP id KAA13725 for ; Wed, 18 Sep 1996 10:32:14 -0700 (PDT) Message-Id: <1.5.4.32.19960918173317.00b15d30@hydra.vitria.com> X-Sender: linton@hydra.vitria.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 18 Sep 1996 10:33:17 -0700 To: cxx_revision@omg.org From: Mark Linton Subject: Re: Fixed structs Karen Lavin writes: >Should we, as an orb developer, be hiding the difference >between fixed and variable length structs from the >application developer. Some of the assumptions implied by this message seem wrong to me, so I'd suggest you make sure you have your examples picked correctly. All you need to do is for a fixed-length struct S, define S_var as a typedef to S. I thought the mapping already said this, but if not that was certainly the intent. The developer can tell the difference because s.field works on a fixed S_var but not on a variable S_var, but they can get transparency by using s->field. >1: > >STRUCT_var mtsytuct_var = ret_struct(); >where >STRUCT* ret_struct()... is the sig of ret_struct. > >If the struct was a fixed length struct then this would not >be possible without the addition of a function of the following >function to the STRUCT_var class. >STRUCT_var& operator=(STRUCT& rhs) C++ implicitly defines this operator= as member-wise copy, which is appropriate for a fixed-length struct. Your example has a return value for STRUCT*, which is not what a mapped IDL method would have for a fixed-length struct (return type would be STRUCT). BTW, your example really uses a copy constructor rather than assignment. >2: >You can use a STRUCT_var as an out parameter if its variable length as follows >STRUCT_var mystruct; >mt_ptr->my_op(mystruct); > >If its a fixed length struct you can not do this. You first have to >new the struct. Fixed-length structs are passed as STRUCT& for outs, so again I think if you typedef STRUCT_var to STRUCT the calling code works with STRUCT_var in both the fixed and varying cases. >From jon@sems.com Wed Sep 18 16:07:06 1996 Received: from ns.sems.com by amethyst.omg.org.omg.org (5.4R2.01/1.34) id AA20896; Wed, 18 Sep 1996 16:07:06 -0400 Received: from vaccine-bb.netlabs.com (vaccine-bb.sems.com) by proxy.netlabs.com (4.1/SMI-4.1) id AA20965; Wed, 18 Sep 96 11:59:15 PDT Received: from clamp.netlabs.com by vaccine-bb.netlabs.com (4.1/SMI-4.1) id AA04269; Wed, 18 Sep 96 13:04:57 PDT Received: from clamp by clamp.netlabs.com (SMI-8.6/SMI-SVR4) id NAA01772; Wed, 18 Sep 1996 13:04:54 -0700 Sender: jon@sems.com Message-Id: <324055E5.67B2@sems.com> Date: Wed, 18 Sep 1996 13:04:53 -0700 From: Jonathan Biggar Organization: Seagate Enterprise Management Software X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4m) Mime-Version: 1.0 To: Mark Linton Cc: cxx_revision@omg.org Subject: Re: Fixed structs References: <1.5.4.32.19960918173317.00b15d30@hydra.vitria.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Linton wrote: > > Karen Lavin writes: > >Should we, as an orb developer, be hiding the difference > >between fixed and variable length structs from the > >application developer. > > Some of the assumptions implied by this message seem wrong to me, so > I'd > suggest you make sure you have your examples picked correctly. > > All you need to do is for a fixed-length struct S, define S_var as a > typedef > to S. I thought the mapping already said this, but if not that was > certainly the intent. The developer can tell the difference because > s.field > works on a fixed S_var but not on a variable S_var, but they can get > transparency by using s->field. That is certainly NOT the way I read the spec. 16.8.1 par. 14 states that "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." There is certainly nothing in the spec to suggest that Karen's interpretation is wrong--thus the spec needs to be clarified. There appears to be two approaches to making the T_var for fixed size structs more transparent: 1. Karen's approach, is to add additional member functions to handle the conversions necessary: T_var &operator=(const T&) and changing the conversion operator used for in & in-out parameters to automatically allocate memory if the T_var currently has a NULL pointer. 2. Mark's approach, which is to typedef T T_var, and add to T the following operator: T *operator->() { return this }; Either approach appears it will work, we just need to decide if the spec must mandate one or the other, and if so, which one. Jon >From linton@vitria.com Wed Sep 18 20:21:52 1996 Received: from gorgon.vitria.com by amethyst.omg.org.omg.org (5.4R2.01/1.34) id AA22607; Wed, 18 Sep 1996 20:21:52 -0400 Received: from hydra.vitria.com (hydra.vitria.com [10.206.138.5]) by vitria.com (8.7.4/8.7.3) with ESMTP id RAA09408 for ; Wed, 18 Sep 1996 17:18:47 -0700 (PDT) Received: from glider (glider.vitria.com [10.206.138.16]) by hydra.vitria.com (8.7.4/8.7.3) with SMTP id RAA17173 for ; Wed, 18 Sep 1996 17:18:44 -0700 (PDT) Message-Id: <1.5.4.32.19960919001947.00b1d250@hydra.vitria.com> X-Sender: linton@hydra.vitria.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 18 Sep 1996 17:19:47 -0700 To: cxx_revision@omg.org From: Mark Linton Subject: Re: Fixed structs At 01:04 PM 9/18/96 -0700, Jonathan Biggar wrote: >16.8.1 par. 14 states >that "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." You are right. The term "same semantics" is not clear. I had assumed it meant usage with respect to parameter passing, while I see it could be interpreted with respect to managing a pointer. >1. add additional member functions to handle >the conversions necessary: > >T_var &operator=(const T&) > >and changing the conversion operator used for in & in-out parameters to >automatically allocate memory if the T_var currently has a NULL pointer. > >2. typedef T T_var, and add to T the >following >operator: > >T *operator->() { return this }; > >Either approach appears it will work, we just need to decide if the spec >must mandate one or the other, and if so, which one. Seems to me the spec should specify one or the other, as it can affect how people write app code. Assuming T is a fixed-length struct in IDL and idl_call returns a T, the 1st approach will make the statement T_var s = idl_call(); dynamically allocate memory and do a copy. In the 2nd approach the memory is statically allocated. Also the 1st approach allows the following statement whereas the 2nd approach does not T_var s = new T; The 1st approach also requires T_var machinery for fixed structs whereas the second approach adds no code in that case (perhaps not a problem if one uses templates for this, though we never had much luck mixing templates and DLLs). I guess the issue is whether you think of T_var as a general way to manage memory or a specific solution to managing memory for IDL parameter passing. >From geoff Mon Sep 23 11:18:40 1996 Received: by amethyst.omg.org.omg.org (5.4R2.01/1.34) id AA05075; Mon, 23 Sep 1996 11:18:40 -0400 Date: Mon, 23 Sep 1996 11:18:40 -0400 From: geoff (Geoffrey Speare) Message-Id: <9609231518.AA05075@amethyst.omg.org.omg.org> To: klavin@iona.com Cc: cxx_revision@omg.org, issues In-Reply-To: Karen Lavin's message of Tue, 17 Sep 1996 19:00:50 +0100 <199609171800.TAA14040@ultra> Subject: Fixed structs This is issue 123. > Hi, > I'm Karen Lavin from Iona Technologies, and I have taken over > from Paul O Neill with regard to the IDL compiler. > I have a question for you with respect to fixed vs variable > length structs. > Should we, as an orb developer, be hiding the difference > between fixed and variable length structs from the > application developer. > For instance... > If you have a varaible length struct you can do the following... > 1: > STRUCT_var mtsytuct_var = ret_struct(); > where > STRUCT* ret_struct()... is the sig of ret_struct. > If the struct was a fixed length struct then this would not > be possible without the addition of a function of the following > function to the STRUCT_var class. > STRUCT_var& operator=(STRUCT& rhs) > 2: > You can use a STRUCT_var as an out parameter if its variable > length as follows > STRUCT_var mystruct; > mt_ptr->my_op(mystruct); > If its a fixed length struct you can not do this. You first have to > new the struct. > Should we be hiding these differences from the user or shold the user write > code differently depending on the nature of the struct. > Regards > Karen > ----- End Included Message ----- Geoff Speare OMG geoff@omg.org