On Monday 14 November 2005 10:41, Stephan Bergmann wrote:
> After sending my last mail, it also dawned on me that I had not taken
> into account the namespace problem.
>
> A solution that should work is to replace uses of
>
> getCppuType(static_cast< T * >(0));
>
> with uses of
>
> getCppuType<T>();
>
> That function call is handled at template instantiation time in a way
> that its correct specialization is found, for any kind of T defined in
> whatever namespace. The only problem is that getCppuType<T>() has a
> slightly different semantic than getCppuType(T const *), see the comment
> in com/sun/star/uno/Type.h. Filed
> <http://www.openoffice.org/issues/show_bug.cgi?id=57855>.
I hope I understood what you said :-)
It seems that it is not necessary to use getCppuType<T>(); The problem is with
getCppuType(T const *), in fact. I tried to define also this function as a
template in com/sun/star/uno/Type.h:
template< typename T > inline const ::com::sun::star::uno::Type & SAL_CALL
getCppuType( const T* ) SAL_THROW( () );
Note that it was necessary to mark it as a template/specialization in any
other location, even in the .hdl, .hpp files. It was enough to add the line:
template <>
before each declaration/definition. The compiler was not able to link the
final library otherwise. It seems that a template specialization or a
function definition are different symbols from the compiler point of view.
Then the sources can be compiled. Even it is not necessary to use
getCppuType<T> when the function is used.
You talked about the problem that is described in com/sun/star/uno/Type.h. I
expect that it was this comment:
--- cut ---
/** Gets the meta type of an IDL type.
The difference between this function template (with a type parameter) and
the overloaded getCppuType function with a single (dummy) parameter of a
specific type is that this function template may not work for the UNO type
"unsigned short" (sal_uInt16 in C++), while the overloaded one-parameter
function may not work for the UNO type "char" (sal_Unicode in C++, which
may
have the same underlying C++ type as sal_uInt16 on certain platforms).
@return type of the given IDL type
@since UDK 3.2.0
*/
template< typename T > inline const ::com::sun::star::uno::Type & SAL_CALL
getCppuType() SAL_THROW(());
--- cut ---
I expect that it means that sal_Unicode is represented with the same type as
sal_uInt16 on some platforms, so the symbols are the same. And they are
different on some platforms, so we need two implementations. Am I right
or is there another problem? I still do not understand why it works when the
symbols are not derived from a template.
Last thing. I improved our example to show what I spoke about. The function f
is now declared as a template. It can be compiled with gcc-4.1 even when the
specialization for NS::C is declared after the definition of the function g.
namespace NS
{
struct A {};
struct B {};
struct C {};
}
template<class T>
void f(T t);
template<>
void f(NS::A *) {}; // line 11
namespace NS { void ff(A *); }
template<>
void f(NS::B *); // line 14
namespace NS { void ff(B *); }
template<class T> void g(T &t)
{
f(&t); // unqualified lookup - this fails //line 19
ff(&t); // argument-dependent lookup - this successds
}
template<>
void f(NS::C *);
namespace NS { void ff(C *); }
void h(NS::C c) { g(c); } //line 27
--
Best Regards,
Petr Mladek
software developer
---------------------------------------------------------------------
SuSE CR, s.r.o. e-mail: [EMAIL PROTECTED]
Drahobejlova 27 tel:+420 296 542 373
190 00 Praha 9 fax:+420 296 542 374
Czech Republic http://www.suse.cz/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
