m_Size vs. __size [Re: returning array of string from service

[Aleksander Slominski <as...@cs.indiana.edu>]

susantha@opensource.lk wrote:

>>BTW: maybe it would be good idea to have consistent naming for example
>>xsd__base64Binary::__size and xsd__string_Array::m_Size - shouldnt both
>>use m_Size? that makes this method asymmetrical to all other methods
>>handling arrays:
>>    
>>
>
>xsd__xxxx are Axis defined types
>and
>xsd__xxxx_Array are Axis defined array structures.
>
>  
>
let me rephrase questions: what is design rationale to have two names 
(m_Size and __size) for essentially the same functionality. moreover i 
think "length" would be better name as you are concerned about number of 
elements in array and not array size in bytes ...

BTW: why did you use double underscore and m_* naming g conventions? i 
do not see in this case how there could be a name conflict and need to 
use such hacks as __name (which should be reserved only for standard libs?)

alek

>>xsd__base64Binary Benchmark1PortType::sendBase64(int length)
>>{
>>    xsd__base64Binary arr;
>>    arr.__size = length;
>>    arr.__ptr = new xsd__unsignedByte[length];
>>    for (int i=0; i < length; i++) {
>>        arr.__ptr[i] = (xsd__unsignedByte)i;
>>    }
>>    return arr;
>>}
>>
>>--
>>The best way to predict the future is to invent it - Alan Kay
>>
>>
>>
>>    
>>
>
>  
>


-- 
The best way to predict the future is to invent it - Alan Kay

RE: m_Size vs. __size [Re: returning array of string from service

[Susantha Kumara <su...@opensource.lk>]

Yes this has to be changed. Thanks Alek for pointing it out.

As this defined types are common for both C and C++ web services
(skeletons and stubs) I would like to change them to have C style as
follows.

typedef struct {
    xsd__unsignedByte* _ptr;
    xsd__int _size;
} xsd__base64Binary;
typedef struct{
    xsd__unsignedByte* _ptr;
    xsd__int _size;
} xsd__hexBinary;

and

#define AXIS_DEFINED_ARRAY(type) \
    struct {\
        type * _array;\
        int _size;\
    }

what do you think ?.

---
Susantha Kumara
Virtusa (pvt) Ltd.
Office : +94112714385
Mobile : +94777420453

> -----Original Message-----
> From: Aleksander Slominski [mailto:aslom@cs.indiana.edu]
> Sent: Thursday, June 03, 2004 11:19 PM
> To: Apache AXIS C Developers List
> Subject: m_Size vs. __size [Re: returning array of string from service
> 
> susantha@opensource.lk wrote:
> 
> >>BTW: maybe it would be good idea to have consistent naming for
example
> >>xsd__base64Binary::__size and xsd__string_Array::m_Size - shouldnt
both
> >>use m_Size? that makes this method asymmetrical to all other methods
> >>handling arrays:
> >>
> >>
> >
> >xsd__xxxx are Axis defined types
> >and
> >xsd__xxxx_Array are Axis defined array structures.
> >
> >
> >
> let me rephrase questions: what is design rationale to have two names
> (m_Size and __size) for essentially the same functionality. moreover i
> think "length" would be better name as you are concerned about number
of
> elements in array and not array size in bytes ...
> 
> BTW: why did you use double underscore and m_* naming g conventions? i
> do not see in this case how there could be a name conflict and need to
> use such hacks as __name (which should be reserved only for standard
> libs?)
> 
> alek
> 
> >>xsd__base64Binary Benchmark1PortType::sendBase64(int length)
> >>{
> >>    xsd__base64Binary arr;
> >>    arr.__size = length;
> >>    arr.__ptr = new xsd__unsignedByte[length];
> >>    for (int i=0; i < length; i++) {
> >>        arr.__ptr[i] = (xsd__unsignedByte)i;
> >>    }
> >>    return arr;
> >>}
> >>
> >>--
> >>The best way to predict the future is to invent it - Alan Kay
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> 
> 
> --
> The best way to predict the future is to invent it - Alan Kay