Templates issues on axis (XML lib) compilation with UDK 8

[Alon Blayer-Gat]

Hi,

Problems with templates when compiling axis on unixware 7.1.1 with UDK 8
(not UDK 8.1).
Please help.

Regards,
Alon Blayer-Gat.

source='TypeMapping.cpp' object='TypeMapping.lo' libtool=yes \
depfile='.deps/TypeMapping.Plo' tmpdepfile='.deps/TypeMapping.TPlo' \
depmode=none /bin/ksh ../../depcomp \
pping.lo TypeMapping.cpp
rm: cannot remove `.' or `..'

CC -DHAVE_CONFIG_H -I. -I. -I../.. -I/users/mkfir/Unix/axis-c-src-1-0-linux/
include -DUNW -DCOMP_SDK -DARCH_X86AT_UDK_8 -DXBYTE_ORDER -DTEMPLATE_INLINE=
"-DTEMPLATE_DECL=template<>" -Kpentium_pro -Tlocal -c
TypeMapping.cpp -DPIC -o .libs/TypeMapping.o
"/usr/include/CC/xmemory", line 75: error: function
"std::allocator<_Ty>::address(std::allocator<_Ty>::reference) const [with
_Ty=std::_Tree<std::_Tmap_traits<const std::basic_string<char,
std::char_traits<char>, std::allocator<char>>, XSDTYPE, std::less<const
std::basic_string<char, std::char_traits<char>, std::allocator<char>>>,
std::allocator<std::pair<const std::basic_string<char,
std::char_traits<char>, std::allocator<char>>, XSDTYPE>>,
false>>::key_type]" has already been declared
const_pointer address(const_reference _Val) const
^
detected during:
instantiation of class "std::allocator<_Ty> [with
_Ty=std::_Tree<std::_Tmap_traits<const std::basic_string<char,
std::char_traits<char>, std::allocator<char>>, XSDTYPE, std::less<const
std::basic_string<char, std::char_traits<char>, std::allocator<char>>>,
std::allocator<std::pair<const std::basic_string<char,
std::char_traits<char>, std::allocator<char>>, XSDTYPE>>,
false>>::key_type]" at line 106 of "/usr/include/CC/xtree"
instantiation of class "std::_Tree<_Traits> [with
_Traits=std::_Tmap_traits<const std::basic_string<char,
std::char_traits<char>, std::allocator<char>>, XSDTYPE, std::less<const
std::basic_string<char, std::char_traits<char>, std::allocator<char>>>,
std::allocator<std::pair<const std::basic_string<char,
std::char_traits<char>, std::allocator<char>>, XSDTYPE>>, false>]" at line
71 of "/usr/include/CC/map"
instantiation of class "std::map<_Kty, _Ty, _Pr, _Alloc> [with
_Kty=const std::basic_string<char, std::char_traits<char>,
std::allocator<char>>, _Ty=XSDTYPE, _Pr=std::less<const
std::basic_string<char, std::char_traits<char>, std::allocator<char>>>,
_Alloc=std::allocator<std::pair<const std::basic_string<char,
std::char_traits<char>, std::allocator<char>>, XSDTYPE>>]" at line 75 of
"TypeMapping.cpp"

make: *** [TypeMapping.lo] Error 1

[J. L. Schilling]

Post by Alon Blayer-Gat
Problems with templates when compiling axis on unixware 7.1.1 with UDK 8
(not UDK 8.1).
Please help.
[...]

The following small test case gives the same error message:

$ cat xxx.cpp
#include <map>
class Listener;
typedef long OBJECT_TAG;
std::map<OBJECT_TAG, Listener*> m1; // compiler says ok
std::map<const OBJECT_TAG, Listener*> m2; // compiler says error

$ CC -c xxx.cpp
"/usr/include/CC/xmemory", line 75: error: function
"std::allocator<_Ty>::address(std::allocator<_Ty>::reference) const
[with _Ty=std::_Tree<std::_Tmap_traits<const OBJECT_TAG, Listener *,
std::less<const OBJECT_TAG>, std::allocator<std::pair<const
OBJECT_TAG, Listener *>>, false>>::key_type]" has already been
declared
const_pointer address(const_reference _Val) const
^
detected during: [...]

The problem with the last line is that map<> instantiates an
allocator<>
with const OBJECT_TAG as the template parameter, but the allocator
wants to
overload its member function address() on what comes out to
const OBJECT_TAG& and const const OBJECT_TAG&, which are the same
type.
Thus the overload is no good and the error.

So a work-around would be to instantiate the map with OBJECT_TAG
rather
than const OBJECT_TAG, as shown above, if that makes sense
application-wise.

SGI STL, g++ 2.95.3, and Sun C++ 5.0 all let this test case go through
without error, which is why this code has compiled on other platforms.

The C++ standard is unclear on the point of the allocator. However,
the ANSI/ISO C++ standards committee is intending to issue a defect
report
that clarifies this. Section 20.1.5 /3 will be amended to say that
the
allocator type must be a non-const and non-reference type. The
rationale
is that const value types don't work in containers, therefore there is
no
need to support them with allocators.

Which brings up the point that the applications's map<> usage is
incorrect;
all container types must be assignable (23.1 /5), which const
OBJECT_TAG isn't.

We have investigated whether we could play tricks in our library to
allow
this anyway, such as Sun and GNU appear to do, but it turned out to be
too
complicated to warrant the risk.

Jonathan Schilling