axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samisa Abeysinghe <>
Subject Re: AXISCPP-148 and nillable
Date Tue, 16 Nov 2004 11:43:22 GMT
I too think that Type1 **m_Array;  is the corret solution; but I agree with you that it is
much of work before end of Nov. (And it is even hard to emagine what the side effects would

Hence +1 for memsetting to 0 in case of nillable for the time being.

Do you think it is possible for us to take up Type1 **m_Array; style solution for 1.5? (Because
that is the most natual C++ solution)


--- Mark Whitlock <> wrote:

> Hi,
> For an array of complex types, the Axis C++ client can't set an array
> element to nil="true" in the soap message and it can't deserialize a soap
> message with one of the complex types nil. The same problem happens setting
> a complex type to nil when it is nested inside another complex type. For
> instance in the RecurseTypes testcase...
> <xsd:complexType name="Type1">
>       <xsd:sequence>
>             <xsd:element name="followings" maxOccurs="unbounded"
> minOccurs="0" type="tns:Type1" />
>             <xsd:element name="index" type="xsd:int" />
>       </xsd:sequence>
> </xsd:complexType>
> gets represented as...
> class Type1
> {
> public:
>       Type1_Array followings;
>       int index;
>       Type1();
>       ~Type1();
> };
> typedef struct Type1_ArrayTag
> {
>       Type1* m_Array;
>       int m_Size;
> } Type1_Array;
> So if the followings array has a length of 10, you always get 10 instances
> of Type1 within it. You can't set m_Array[3]=NULL because m_Array is an
> array of Type1, not an array of pointers to Type1. In the same way if the
> returned soap message says that the 3rd Type1 in the followings array
> should be nil, our deserializer can't cope. Of course Axis/Java doesn't
> have this problem since in Java, complex types are objects which are passed
> and embedded by address, so any object reference can be null.
> There doesn't seem to be any easy solution to this problem. I could change
> the way complex types are represented in C++ so that nested complex types
> have their address in the outer complex type or array. So in the above
> example Type1 **m_Array; or Type1* m_Array[];. This is a big change and I'm
> not proposing it. Or Axis C++ does not support nillable properly by never
> sending nil=true and if it is ever returned a soap message with nil=true in
> it, it creates an object (where there should be none) and memset's it to
> all zeroes.
> This problem is the subject of AXISCPP-148 and AXISCPP-260.
> Does anybody have any comments on this?
> Mark
> Mark Whitlock

Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 

View raw message