Issue 1726:  TypeCode complexity for value types (obv-rtf)
Source:  (, )
Nature:  Uncategorized Issue
Severity: 
Summary: Summary: The OBV design for the "CORBA::tk_value" TypeCode defines a
 potentially recursive constructed type that involves ValueMembers.
 The "tk_value" TypeCode defines the entire complexity of the types
 within the Value.  
 
 It is our understanding that when the ORB code that handles "Anys" for
 C++ detects a tk_value TypeCode and needs to encode/decode the associated
 Value object -- (e.g., for Any::replace(TypeCode, void *) -- it will
 need to invoke a method on that object that understands the object 
 instance data and the associated state information.  Further 
 examination of the TypeCode complexity will not be necessary by the
 Any implementation, since this code would not have knowledge of or 
 ability to set the state information within the Value object itself.
 
 The reason why the layout of the state information within a value
 cannot be known by external code is that virtual inheritance of 
 abstract values and/or abstract interfaces makes it impossible to 
 calculate the offsets of the data members in a compiler
 independent manner.
 
 

Resolution: 
Revised Text: 
Actions taken:
July 23, 1998: received issue
July 30, 1998: closed issue
Discussion: 

End of Annotations:=====
Return-Path: <nash@sp3at21.hursley.ibm.com>
Date: Thu, 23 Jul 1998 10:57:50 +0100
From: Simon Nash <nash@hursley.ibm.com>
Reply-To: nash@hursley.ibm.com
Organization: IBM
To: obv-rtf@omg.org
Cc: issues@omg.org
Subject: TypeCode complexity for value types

The following issue was raised by the implementers of the IBM
C++ ORB.

The OBV design for the "CORBA::tk_value" TypeCode defines a
potentially recursive constructed type that involves ValueMembers.
The "tk_value" TypeCode defines the entire complexity of the types
within the Value.  

It is our understanding that when the ORB code that handles "Anys" for
C++ detects a tk_value TypeCode and needs to encode/decode the
associated
Value object -- (e.g., for Any::replace(TypeCode, void *) -- it will
need to invoke a method on that object that understands the object 
instance data and the associated state information.  Further 
examination of the TypeCode complexity will not be necessary by the
Any implementation, since this code would not have knowledge of or 
ability to set the state information within the Value object itself.

The reason why the layout of the state information within a value
cannot be known by external code is that virtual inheritance of 
abstract values and/or abstract interfaces makes it impossible to 
calculate the offsets of the data members in a compiler
independent manner.  For example, given the following simple test:

    #include <stdio.h>

    /* simulates abstract interface/value */
    class abstr {
    public:
        virtual void foo(){
            printf("abstr foo\n");
        }
    };

    /* value that supports abstract interface/abstract value */
    class val2 :  virtual public abstr {
    public:
        virtual void offsets(){
            printf("s: %d\n", (long)&s - (long)this);
            printf("t: %d\n", (long)&t - (long)this);
        }
    private:
        short s;
        long t;
    };

    void main(){
        val2 v2;
        v2.offsets();
    }

When compiled under VisualAge C++, the output for the offsets is:
    s: 12
    t: 16

When compiled under Microsoft C++, the output for the offsets is:
    s: 8
    t: 12

Looking at the problem from another perspective, the C++ bindings spec
allows the emitted setters/getters of the value states members to
be over-ridden by concrete value implementation.  If we were to
get/set
the data members directly, we would lose whatever side-effects
that are intended by the over-ridden getters/setters.

If the above assumptions are correct, of what use are the tk_value
and tk_value_box constructed TypeCodes with their associated
complexity?
It appears that it would be sufficient for each of these TypeCodes
to be much simpler TypeCodes which just include the TypeCode "kind",
and possibly the name and RepositoryId (similar to CORBA::tk_objref).

   Simon
-- 
Simon C Nash, IBM Java Technology Centre, Hursley, UK
MailPoint 146, x245156  Tel. 01962 815156 or +44-1962-815156
Internet: nash@hursley.ibm.com  Notes mail: Simon Nash@ibmgb