On Wed, 2009-07-22 at 10:21 +0200, Mirco Babin wrote: > *****The new: > #if (defined(_MSC_VER) && _MSC_VER <= 1200) > # define PODOFO__FUNCTION__ (__FILE__ ":" __LINE__) > #elif defined(__BORLANDC__) || defined(__TURBOC__) > # define PODOFO__FUNCTION__XSTR(x) PODOFO__FUNCTION__STR(x) > # define PODOFO__FUNCTION__STR(x) #x > # define PODOFO__FUNCTION__ (__FILE__ ":" > PODOFO__FUNCTION__XSTR(__LINE__)) > #else > # define PODOFO__FUNCTION__ __FUNCTION__ > #endif
WTF? Does that work on Borland? (Searches) Yep, looks like it. Weird. This is uglier than I thought, though: http://www.delorie.com/gnu/docs/gcc/gcc_78.html "By this definition, __func__ is a variable, not a string literal. In particular, __func__ does not catenate with other string literals. In C ++, __FUNCTION__ and __PRETTY_FUNCTION__ are variables, declared in the same way as __func__." ... so we can't use __PRETTY_FUNCTION__ / __FUNCTION / __func__ this way on supporting compilers either. We must use it as a printf argument or iostream out operator argument. To do anything with it we must allocate memory for a temporary std::string for it, using something like: #define PODOFO__FUNCTION__() PODOFO__FUNCTION__1(__LINE__) /* Call first macro to expand __LINE__ */ #define PODOFO__FUNCTION__1(li) PODOFO__FUNCTION__2(li) /* Call second macro to stringify and use expanded __LINE__ */ #define PODOFO__FUNCTION__2(li) (::std::string("file " __FILE__ ", ") +\ __PRETTY_FUNCTION__ + ":" + #li) So - I'm just going to do something like this: #if defined(__GNUC__) # define PODOFO_FUNC __PRETTY_FUNCTION__ #elif defined(_MSC_VER) && _MSC_VER > 1200 # define PODOFO_FUNC __FUNCTION__ #else # define PODOFO_FUNC "(unknown)" #endif so PODOFO_FUNC must be used separately at the calling site, as must __FILE__ and __LINE__ . Everything else is just too ugly when compiler portability comes into it. If borland has __func__, __FUNC__ or __FUNCTION__ it'd be nice to add them there. > 2.1) Looking at the default PdfPainter constuctor there is a C++ > construct I didn't know off, instantiating class variables after the > ':'. This is hard to debug. It's called an initializer list, and is absolutely standard C++. It's more efficient to initialize an object's direct members with const expressions this way, since the instance of the object is created in memory pre-initialized instead of having to be initialized by the ctor. It's also, IMO, more readable, as it separates mere member initialization from the _logic_ of the constructor, if any. > PdfPainter::PdfPainter() > : Mirco8(8), Mirco7(7), Mirco6(6), > m_pCanvas( NULL ), Mirco5(5), > m_pPage( NULL ), Mirco4(4), > m_pFont( NULL ), Mirco3(3), > m_nTabWidth( 4 ), Mirco2(2), > m_curColor( PdfColor( 0.0, 0.0, 0.0 ) ), Mirco1(1), > m_isTextOpen( false ), Mirco0(0) > { > printf("PdfPainter::PdfPainter\n"); > > The output I see is: > Constructing PdfPainter > Mirco 0 > Mirco 1 > Mirco 2 > Mirco 3 > Mirco 4 > PdfColor C > PdfColor C end > Mirco 5 > Mirco 6 > > So the "std::ostringstream m_oss" must be the problem. > > Because I recompiled the whole bunch with Borland, I'm assuming I did > something terribly wrong. Not that I can see, though it's not unlikely that Borland did. Maybe it doesn't like ostringstream being a direct member for some reason? Without access to the compiler in question and useful backtraces and/or disassembly of the affected address(es) it's really hard to tell what's actually going on. Is there a free version of the Borland monster around? I have a Windows XP VM I can install it in. Or can you send me a debugger backtrace from the error site and a disassembly of the error site? Is there a reason you can't just use MSVC++9 Express Edition? It's a nice modern compiler and HAS A DECENT DEBUGGER. The VC6 users I can understand because they're trying to support legacy (and presumably horribly compiler-specific) code that would require even more work to make upward-compatible with modern MS compilers. Is that the situation you're encountering too? > I'm going to switch back to MinGW to cross reference this is a Borland > problem. Urk. MinGW is almost as bad. An old hacked-up gcc with a broken/incomplete C++ STL, half the win32 APIs missing, and glacially slow as well. -- Craig Ringer ------------------------------------------------------------------------------ _______________________________________________ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
