You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by "Adrian Dick (JIRA)" <ax...@ws.apache.org> on 2006/04/03 11:03:49 UTC

[jira] Closed: (AXISCPP-202) enums cause name clashes

     [ http://issues.apache.org/jira/browse/AXISCPP-202?page=all ]
     
Adrian Dick closed AXISCPP-202:
-------------------------------


> enums cause name clashes
> ------------------------
>
>          Key: AXISCPP-202
>          URL: http://issues.apache.org/jira/browse/AXISCPP-202
>      Project: Axis-C++
>         Type: Bug

>   Components: Basic Architecture
>     Versions: 1.3 Final
>     Reporter: Mark Whitlock
>     Assignee: Mark Whitlock
>      Fix For: 1.5 Alpha

>
> > --- Valentin Kuznetsov <vk...@yahoo.com> wrote:
> > 
> > > 2) Add namespace around all enums. I found that Axis
> > > conflicts with other software we use who also have
> > > enum with CRITICAL, INFO, WARN keywords. If we'll wrap
> > > those enum in axis into axis specific namespace all
> > > existing and potential future problems will go away.
> > > 
> > 
> > +1
> > 
> > Samisa...
> > 
> Simply putting namespaces around these enums would break C applications, since C does not support namespaces. I agree this is the right solution for C++. For C, it would be good to prefix all enums with AXIS_. I don't think AXIS_SEVERITY_LEVEL needs to be externalised anyway, since it is only used by trace and AxisTrace.h is not external. There is also a problem with some externalised #defines like XML_Ch and SOAPACTIONHEADER which could also clash.
> So I propose move AXIS_SEVERITY_LEVEL to AxisTrace.h, for C++ put namespaces around all enums, for C prefix all enums with AXIS_, and for *both* C and C++ prefix all #defines with AXIS_.
> Unfortunately this will require applications changing, WSDL2WS changes and stubs being regenerated when users move to 1.3. Is this critical for 1.3 or should we just move AXIS_SEVERITY_LEVEL to AxisTrace.h in 1.3 and fix it all properly for 1.4? 
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira