[wsf-c-dev] [C++] Question on data types

[Senaka Fernando]

Yes, that would be the scenario. Boolean types would invariably be
having two states and thus, wouldn't be much of a problem if you test
the Axis/C implementation for false, because false is always zero. I
guess that would be a good idea.

Question No. 2, is about char * and std::string. Typically, a C++ user
would like to do some string manipulation on std::string types. And, it
is not necessary to give him pointer access, using char *. So I guess it
would be better to use std::string for occasions where char * points
ONLY to data which is a string.

But, we have another alternative, which is wchar_t *, which supports
unicode, which may be a future requirement. Therefore, we can define a
new type instead of std::string, or char * or wchar_t *, which can then
be customized according to changing requirements.

What would your opinion be?

Thanks,

Senaka

On Wed, 2007-10-17 at 08:21 +0530, Uthaiyashankar wrote:
> Damitha Kumarage wrote:
> > Senaka Fernando wrote:
> >
> >> Yes, that is a good choice, but don't we miss out in defining boolean
> >> types using integers?
> >>
> >> Because C++ defines bool, we instead can use a subset of types defined
> >> in axis, and use the new additions from C++
> >>
> >> BTW, this only affects the interaction through the API. The internal
> >> core will remain the same as C.
> >>
> >> Therefore the C++ developers will feel more comfortable dealing with
> >> types derived from bool, when it is a true-false scenario instead of the
> >> AXIS implementation
> >>  
> >>
> > hmmm,
> > Say axis2c api function function foo is
> > axis2_bool_t foo()
> > and it is wrapped in c++ function bool bar()
> >
> On the other hand,
> 
> if api function foo is
> void foo(axis2_bool_t status)
> {
>     if (status == AXIS2_TRUE)
>           do something;
> }
> 
> and bar is
> void bar(bool status)
> {
>     return foo(status);
> }
> 
> and the call is
> bar(true);
> 
> then, foo might or might not work. C++ specification tells "true has to 
> be non zero value and false has to be zero value". However,  it does not 
> specify a specific integer value for true. Most of the compilers are 
> using true = 1, but it is not a must. I don't know whether there are any 
> compilers which are specifying other values for true. So, for the safe 
> side, bar has to be
> void bar(bool status)
> {
>     if (status)
>           return foo(AXIS2_TRUE);
>     else
>        return foo(AXIS2_FALSE);
> }
> 
> if that is the case, then can use bool. Otherwise, it is better to stick 
> to axis2_bool_t.
> 
> Shankar.
> >
> > axis2_bool_t
> > foo(void)
> > {
> >    return AXIS2_FALSE;
> > }
> >
> > bool bar(void)
> > {
> >    std::cout << "In C++ wrapper function \n";
> >    return foo();
> > }
> >
> > Then C++ user experience would be
> >
> >    bool ret;
> >    ret = bar();
> >    if(ret == true)
> >        std::cout << "Success \n";
> >    if(ret == false)
> >        std::cout << "Failure \n";
> >
> > OK. I agree with you
> >
> > Damitha
> >
> >
> >
> >
> >> What do you say?
> >>
> >> On Tue, 2007-10-16 at 16:27 +0530, Damitha Kumarage wrote:
> >>  
> >>
> >>> Senaka Fernando wrote:
> >>>
> >>>   
> >>>> Is it better to proceed with the addition of C++ primitive types
> >>>> sparingly, or only with types defined in AXUTIL_..? (for instance, the
> >>>> bool type can be re-defined or the existing definition in
> >>>> AXUTIL_UTILS_DEFINES.h can be used which is derived from int)
> >>>>
> >>>> Which would be better and why?
> >>>>
> >>>>
> >>>>     
> >>> Since you are going to write a set of C++ wrapper functions over C I 
> >>> think it is better to adhere to existing typing instead of doing 
> >>> type mapping between C++ and C.
> >>> Damitha
> >>>
> >>>   
> >>>> Regards,
> >>>>
> >>>> Senaka
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Wsf-c-dev mailing list
> >>>> Wsf-c-dev at wso2.org
> >>>> http://wso2.org/cgi-bin/mailman/listinfo/wsf-c-dev
> >>>>
> >>>>
> >>>>
> >>>>     
> >>> _______________________________________________
> >>> Wsf-c-dev mailing list
> >>> Wsf-c-dev at wso2.org
> >>> http://wso2.org/cgi-bin/mailman/listinfo/wsf-c-dev
> >>>   
> >>
> >>
> >> _______________________________________________
> >> Wsf-c-dev mailing list
> >> Wsf-c-dev at wso2.org
> >> http://wso2.org/cgi-bin/mailman/listinfo/wsf-c-dev
> >>
> >>  
> >>
> >
> >
> >
> > _______________________________________________
> > Wsf-c-dev mailing list
> > Wsf-c-dev at wso2.org
> > http://wso2.org/cgi-bin/mailman/listinfo/wsf-c-dev
> >
> 
> 
> _______________________________________________
> Wsf-c-dev mailing list
> Wsf-c-dev at wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/wsf-c-dev