Hi Craig, >> 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? > >
I know some toolkits using these options. In most cases these toolkit exists in versions from VC6 to VC... - so perhaps the conversion from VC6 to newer versions was easier to do? > > 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 > I personally would prefer the CMake solution... Best regards, Patrik ------------------------------------------------------------------------------ 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
