[EMAIL PROTECTED] wrote:
*Type* required
*Title* Changed getCppuType
*Posted by* [EMAIL PROTECTED]
*Affected* ,-
*Effective from* CWS sb40
/*Summary*/
- getCppuType(T const *) // for all relevant T
+ template<typename T> getCppuType(T const *) // not defined
+ template<> getCppuType(T const *) // for all relevant T
/*Description*/
Our existing code base is not conforming to The C++ Standard, and one
such nonconformity is now complained on by the forthcomming GCC 4.1,
see the thread at
<http://porting.openoffice.org/servlets/BrowseList?list=dev&by=thread&from=1124803>.
To solve that, getCppuType(T const *) (declared/defined in
com/sun/star/uno/Type.h, com/sun/star/uno/Type.hxx, and the .hdl and
.hpp files generated by cppumaker) has been changed from a set of
function overloads to a (declared but not defined) function template
together with a set of explicit specializations of that template.
That causes lookup of getCppuType in those places to work correctly
now where it previously had caused trouble.
However, that is a compile-time--incompatible change, in that code
like the following no longer works:
struct Derived: com::sun::star::beans::PropertyValue {};
...
com::sun::star::uno::Any a;
a <<= Derived();
That is, if a non-UNO C++ type is derived from (the C++
representation) of a UNO type, getCppuType (which is used internally
by Any::operator<<=, for example) used to work for the derived type,
but no longer does. This can be fixed by calling
a <<= static_cast< com::sun::star::uno::Any >(Derived());
The above should read
a <<= static_cast< com::sun::star::beans::PropertyValue >(Derived());
instead, of course. Thanks to Jörg for pointing out the typo.
-Stephan
instead, or by fixing your design and not deriving a C++ type from a
UNO type. There were three different places in the SRC680m140 OOo
code base where this problem occurred, see
connectivity/source/drivers/jdbc/Connection.cxx 1.23.30.1
connectivity/source/drivers/jdbc/ResultSet.cxx 1.24.34.1
connectivity/source/drivers/jdbc/Statement.cxx 1.25.34.1
toolkit/source/controls/unocontrolmodel.cxx 1.39.34.1
ucb/source/ucp/ftp/ftpcontentcaps.cxx 1.7.22.1
Still, even though compile-time incompatible, I think this is the best
way to solve the problem, as any alternatives are problematic too (see
below), and deriving a C++ type from a UNO type can probably be
considered bad design, anyway.
The two alternatives that were considered but rejected:
1 Move the overloads of getCppuType from the global namespace into
the appropriate namespaces, i.e., move
getCppuType(com::sun::star::uno::XInterface const *) to namespace
com::sun::star::uno. This too is compile-time incompatible, as there
is (lots of) existing code that calls ::getCppuType explicitly from
the global namespace. Placing the overloads of getCppuType into both
namespaces would lead to compilation errors in combination with using
declarations.
2 Replace the problematic uses of getCppuType with uses of a newly
introduced template (or use the already existing template<typename T>
getCppuType(), with no function parameter). One disadvantage is that
all problematic uses of getCppuType would have to be changed. The
other disadvantage is that the current getCppuType is non-optimal in
that it works for the deprecated UNSIGNED SHORT UNO type (sal_uInt16),
but not for the CHAR UNO type (sal_Unicode); a newly introduced
replacement should be designed the other way around (as the no
function parameter template<typename T> getCppuType() already is);
however, replacing uses of getCppuType with a substitute that has
slightly different semantics is error prone.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
