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 Nadir Amra <am...@us.ibm.com> on 2005/05/18 20:13:23 UTC
use of wide-character literals
When porting the code to OS/400, I had to eliminate the use of wide
character literal characters in common/BasicTypeSerializer.h and
soap/xsd/IAnySimpleType.hpp. In both these header files there is the
following:
enum
{
GREATER_THAN_CHAR = L'>', /* Greater than character */
LESSER_THAN_CHAR = L'<', /* Less than character */
SINGLE_QUOTE_CHAR = L'\'', /* Single quotation character
*/
DOUBLE_QUOTE_CHAR = L'\"', /* Double quotation character
*/
AMPERSAND_CHAR = L'&' /* Ampersand character */
};
I want to remove the L so that these are character literals and not
wide-character. I could not figure out why these were declared as wide
character and wanted to make sure that it is OK to make them character
declares before I commit the changes. On ASCII-based systems the
wide-character declaration is OK, but on ebcdic-based systems the
declaration causes problems since wide-character is unicode.
Nadir K. Amra
Re: use of wide-character literals
Posted by Adrian Dick <ad...@uk.ibm.com>.
Hi,
In the case of IAnySimpleType.hpp - this was simply a copy-paste job.
I've taken a look through the history of BasicTypeSerializer.h - it would
appear this was initially introduced as a performance improvement, but I
notice the L's have since been removed from a couple of other places they
were introduced at the same time, so I would guess it's safe to take them
out.
I've just done a quick test on Windows - and had no problems.
_______________________________________
Adrian Dick (adrian.dick@uk.ibm.com)
Nadir Amra <am...@us.ibm.com> wrote on 18/05/2005 19:13:23:
> When porting the code to OS/400, I had to eliminate the use of wide
> character literal characters in common/BasicTypeSerializer.h and
> soap/xsd/IAnySimpleType.hpp. In both these header files there is the
> following:
>
> enum
> {
> GREATER_THAN_CHAR = L'>', /* Greater than character */
> LESSER_THAN_CHAR = L'<', /* Less than character */
> SINGLE_QUOTE_CHAR = L'\'', /* Single quotation character
> */
> DOUBLE_QUOTE_CHAR = L'\"', /* Double quotation character
> */
> AMPERSAND_CHAR = L'&' /* Ampersand character */
> };
>
> I want to remove the L so that these are character literals and not
> wide-character. I could not figure out why these were declared as wide
> character and wanted to make sure that it is OK to make them character
> declares before I commit the changes. On ASCII-based systems the
> wide-character declaration is OK, but on ebcdic-based systems the
> declaration causes problems since wide-character is unicode.
>
>
>
> Nadir K. Amra
>
Re: Platform abstraction layer thoughts
Posted by John Hawkins <HA...@uk.ibm.com>.
Ohh - hadn't thought of creating classes for the functions.
I'd thought that we'd have classes for each platform and those classes
would have methods for the function e.g.
PlatformSpecificWindowsUtils
#doMutexStuff()
# getErrorMessage()
etc.
Then we would have a hierarchy of PlatformSpecific classes as in the
attached file.
This would mean that if all Unix platforms are the same then only the base
UnixPlatformSpecific class has to implement it.
This model still gives the ability to override the methods with APR or
non-APR versions.
I think we've fundamentally got the same idea but you're making functions
the classes whereas I'm putting the function into platform specific
classes (which happens to be more like what we have today).
Nadir Amra <am...@us.ibm.com>
18/05/2005 22:33
Please respond to
"Apache AXIS C Developers List"
To
axis-c-dev@ws.apache.org
cc
Subject
Platform abstraction layer thoughts
My thoughts on the platform abstractions layer is as follows. Note that I
will initially focus on the client-side of things, but I hope to also
eventually get to the server side to see what needs to be abstracted.
Just to level-set, the goal is to attempt to concentrate as much as
possible any platform differences in one area - code will be located in
the platforms/ directory. There occasionally will be times when this
cannot be done, but hopefully those occasions will be few and any
platform-specific code changes required outside of platforms/ directory
will be minimal.
I have initially identified several areas that need to be abstracted: DLL
loading, mutex, socket, and obtaining OS errors. There may be more (such
as event log for FFDC kinds of stuff - on Unix maybe syslog() will be
used, on windows to the event log), but that will be identified and done
later.
The idea is to have classes for the various platform-specific stuff. The
header files and default implementation would be in platforms/ directory
as follows:
platforms/AxisPsLibraryLoader.hpp
platforms/AxisPsLibraryLoader.cpp
platforms/AxisPsMutex.hpp
platforms/AxisPsMutex.cpp
platforms/AxisPsSocket.hpp
platforms/AxisPsSocket.cpp
platforms/AxisPsOSError.hpp
platforms/AxisPsOSError.cpp
The default implementation of these classes will be patterned after Unix
and packaged in a DLL/share library called, for lack of a better name,
axis_platformservices.so. The AXIS engine will need to link to this
DLL/shared library and thus it will need to be created first prior to
creating any other DLLs/shared libraries.
The implementation code for other platforms will be in each platform
directory. For example, OS/400 will need to have its own
AxisPsLibraryLoader.cpp file so one will be located as follows:
platforms/os400/AxisPsLibraryLoader.cpp
When building the axis_platformservices DLL/shared library, which files
are build is dependent on the platform. For example, OS/400 would build
everything in platforms/os400/ and would also build
platforms/AxisPsMutex.cpp, platforms/AxisPsSocket.cpp and
platforms/AxisPsOSError.cpp.
The creation of the classes and implementation will be done as part of
stage one. I will also attempt to modify the ant build scripts to build
the DLL/shared library. However, I have no expertise with makefiles so
someone would need to do that. Stage one would just be putting the stuff
in CVS and for all of you to look at and comment on. Everything should
still build as it does now.
Stage two would be to change the Axis engine to use the above classes and
link to the service program. Again, someone would need to volunteer to
update makefiles. At this point in time the ant build would work but the
make would fail unless someone updates the makefile.
For stage three, if we still want to go to APR, the default implementation
can be changed to use the APR APIs, and if a platform wants to go that way
they can, otherwise, a platform can still have its own implementation of
the classes. This will protect platforms that may not have all the APR
APIs, or do not have APR at all.
So what do you think?
Nadir K. Amra
Platform abstraction layer thoughts
Posted by Nadir Amra <am...@us.ibm.com>.
My thoughts on the platform abstractions layer is as follows. Note that I
will initially focus on the client-side of things, but I hope to also
eventually get to the server side to see what needs to be abstracted.
Just to level-set, the goal is to attempt to concentrate as much as
possible any platform differences in one area - code will be located in
the platforms/ directory. There occasionally will be times when this
cannot be done, but hopefully those occasions will be few and any
platform-specific code changes required outside of platforms/ directory
will be minimal.
I have initially identified several areas that need to be abstracted: DLL
loading, mutex, socket, and obtaining OS errors. There may be more (such
as event log for FFDC kinds of stuff - on Unix maybe syslog() will be
used, on windows to the event log), but that will be identified and done
later.
The idea is to have classes for the various platform-specific stuff. The
header files and default implementation would be in platforms/ directory
as follows:
platforms/AxisPsLibraryLoader.hpp
platforms/AxisPsLibraryLoader.cpp
platforms/AxisPsMutex.hpp
platforms/AxisPsMutex.cpp
platforms/AxisPsSocket.hpp
platforms/AxisPsSocket.cpp
platforms/AxisPsOSError.hpp
platforms/AxisPsOSError.cpp
The default implementation of these classes will be patterned after Unix
and packaged in a DLL/share library called, for lack of a better name,
axis_platformservices.so. The AXIS engine will need to link to this
DLL/shared library and thus it will need to be created first prior to
creating any other DLLs/shared libraries.
The implementation code for other platforms will be in each platform
directory. For example, OS/400 will need to have its own
AxisPsLibraryLoader.cpp file so one will be located as follows:
platforms/os400/AxisPsLibraryLoader.cpp
When building the axis_platformservices DLL/shared library, which files
are build is dependent on the platform. For example, OS/400 would build
everything in platforms/os400/ and would also build
platforms/AxisPsMutex.cpp, platforms/AxisPsSocket.cpp and
platforms/AxisPsOSError.cpp.
The creation of the classes and implementation will be done as part of
stage one. I will also attempt to modify the ant build scripts to build
the DLL/shared library. However, I have no expertise with makefiles so
someone would need to do that. Stage one would just be putting the stuff
in CVS and for all of you to look at and comment on. Everything should
still build as it does now.
Stage two would be to change the Axis engine to use the above classes and
link to the service program. Again, someone would need to volunteer to
update makefiles. At this point in time the ant build would work but the
make would fail unless someone updates the makefile.
For stage three, if we still want to go to APR, the default implementation
can be changed to use the APR APIs, and if a platform wants to go that way
they can, otherwise, a platform can still have its own implementation of
the classes. This will protect platforms that may not have all the APR
APIs, or do not have APR at all.
So what do you think?
Nadir K. Amra