[omniORB] omni3.0.2: string sequence _var lacksconstoperator[]

[randy.shoup@tumbleweed.com]

I knew I should have looked at the spec! :-)

Thanks for the clarification.

-- Randy

"Gary D. Duzan" wrote:
> 
> In Message <3A4A2B1D.E3A617AF@tumbleweed.com> ,
>    randy.shoup@tumbleweed.com wrote:
> 
> =>I did a little research on my own, and it looks like this is a bug.
> =>
> =>In section 6.19.1 of "Advanced CORBA Programming in C++", it claims that
> =>the _var class of a sequence<T> should contain both of the following
> =>methods:
> =>
> =>      T & operator[](CORBA:ULong);
> =>      const T & operator[](CORBA::ULong) const;
> 
>    Ah, but that book is not the spec. In the IDL/C++ Mapping v2.3.1,
> we have:
> 
>   1.13.4   Sequence T_var and T_out Types
> 
>   In addition to the regular operations defined for T_var and T_out
>   types, the T_var and T_out for a sequence type also supports an
>   overloaded operator[] that forwards requests to the operator[]
>   of the underlying sequence. [footnote 12] This subscript operator
>   should have the same return type as that of the corresponding
>   operator on the underlying sequence type.
> 
>   [12] Note that since T_var and T_out types do not handle const
>        T*, there is no need to pro-vide the const version of
>        operator[] for Sequence_var and Sequence_out types.
> 
> So omniORB is correct.
> 
>                                         Gary Duzan
>                                         Verizon Laboratories
> 
> =>randy.shoup@tumbleweed.com wrote:
> =>>
> =>> We have been using omni2.* for a while, and now we are looking into
> =>> moving to omni3.  I encountered the following problem:
> =>>
> =>> We have the following in our IDL:
> =>>         typedef sequence<string> StringArray;
> =>>
> =>> omni2 mapped StringArray in the following way:
> =>>   typedef _CORBA_Unbounded_Sequence<CORBA::String_member > StringArray;
> =>>   typedef _CORBA_Sequence_Var<StringArray, CORBA::String_member >
> =>> StringArray_var;
> =>>
> =>> StringArray_var ended up with an operator[] const.  And we made use of
> =>> the fact in our code that we could extract elements from a const
> =>> StringArray_var.
> =>>
> =>> However, omni3 maps these types to new classes:
> =>>   class StringArray : public _CORBA_Unbounded_Sequence__String {
> =>>         ...
> =>>   class StringArray_var {
> =>>         ...
> =>>
> =>> and does not generate an operator[] const.  The only
> =>> StringArray_var::operator[] is
> =>>     inline _CORBA_String_element operator [] (_CORBA_ULong s) {
> =>>       return (*_pd_seq)[s];
> =>>     }
> =>>
> =>> which is non-const.
> =>>
> =>> Because it seems to use the StringArray directly, and *that* class has
> =>> an operator[] const, why does the StringArray_var not have an operator[]
> =>> const?
> =>>
> =>> Is this a bug, or a CORBA 2.3 mapping change?
> =>>

_________________________________________________________________  
Randy Shoup                                     (650)216-2038  
Senior Architect                                rshoup@tumbleweed.com  
Tumbleweed Communications Corporation