On 9/10/2009 12:12 AM, [email protected] wrote:
> Hi Sebastian,
>
> I had something similar with VC2005). If I remember correctly it was a
> problem when compiling PoDoFo with /Zc:wchar_t- (don't use wchar_t as
> integrated type).
Yep, I can reproduce errors with that option set.
Why don't you want wchar_t as an integrated type?
Anyway, now that I know how to reproduce the problem, what's causing it
is immediately obvious. The error message:
1>c:\developer\podofo\src\PdfString.h(130) : error C2535:
'PoDoFo::PdfString::PdfString(const wchar_t *)' : member function
already defined or declared
1> c:\developer\podofo\src\PdfString.h(101) : see declaration of
'PoDoFo::PdfString::PdfString'
points to these lines:
PdfString( const pdf_utf16be* pszStringUtf16 );
PdfString( const wchar_t* pszString );
in the declaration of the PdfString class.
If wchar_t isn't a built-in type, what is it? It's a typedef. And
clearly, the typedef for wchar_t is the same as we're using for pdf_utf16be:
#define PDF_UINT16_TYPENAME unsigned short // podofo_config.h
typedef PDF_UINT16_TYPENAME pdf_uint16; // PdfCompilerCompat.h
typedef pdf_uint16 pdf_utf16be; // PdfDefines.h
According to MSDN:
http://msdn.microsoft.com/en-us/library/dh8che7s%28VS.80%29.aspx
wchar_t is typically typedef'd as an unsigned short if it's not a
built-in type.
C++ cannot overload on a typedef, instead resolving to the underlying type.
So, after typedefs, the PoDoFo code resolves to:
PdfString( const unsigned short* pszStringUtf16 );
PdfString( const unsigned short* pszString );
Tada! That's why it hasn't been building for you guys.
Possible solutions include:
- just use wchar_t as a built-in type, ie don't support use of
/Zc:wchar_t-
- strip wchar_t use from PoDoFo and force people to use a cast between
pdf_utf16be and wchar_t. Unsafe, as wchar_t may also be 32 bits
wide.
- Attempt to detect the use of this compiler option and hide the
problematic methods. Ugly, as the user may not be consistent with
the use of the option, and if (eg) they build podofo with it then
their project without it they'll get linkage errors because the
overload resolution changes. Also fails to cover the case where
some other compiler typedef's wchar_t .
- Require that, if /Zc:wchar_t- is used, it's enabled in PoDoFo
via a CMake flag so we can hide the problem methods. Think:
-DPODOFO_WCHAR_T_IS_TYPEDEF:BOOL=TRUE
PoDoFo adds the flag its self. No project file hacking allowed.
This handles other compilers that may have the same issue if we
run into it down the track, and allows PoDoFo to cleanly
hide the problem methods.
It'll still be a problem if the user then links to PoDoFo without
using /Zc:wchar_t-.
We might need a to introduce some kind of
"build key" a-la Qt, where we have an informatively-named symbol
constructed using token-pasting macros from various config options
that <podofo.h> forces linkage to when !defined(BUILDING_PODOFO).
So, instead of a weird error about a missing wchar_t method in
PdfString, you'd get an error like:
symbol not found: podofo_static_wcharinternal
Alternately, just document it and expect people to read the manual.
It could happen, right? :-P
- Magic hand waving! (in other words: someone got a better idea?)
--
Craig Ringer
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Podofo-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/podofo-users
