2009/7/24 Craig Ringer <cr...@postnewspapers.com.au>

> 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
>
> If borland has __func__, __FUNC__ or __FUNCTION__ it'd be nice to add
> them there.


Borland defines a __FUNC__


>
> > 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.


It looks clean, and after thinking about it, it is faster and not harder to
debug as other class variables that are automatically instantiated.


> > PdfPainter::PdfPainter()
> > So the "std::ostringstream m_oss" must be the problem.
> >
> 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?
>

Yep, at http://www.codegear.com/downloads/free/cppbuilder download version
5.5, this is the free version.


>
> 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?
>

Yep, I'm working for a company that has tons of legacy code.


Update on the Memory Exception:
I managed to create a Codegear project, so now I'm able to visual debug the
dll.


The PdfPainter is not the problem, but the CreatePage() is.

1)  void PdfPagesTree::InsertPage( int nAfterPageNumber, PdfObject* pPage )
PdfObject* pPageBefore = this->GetPageNode( nAfterPageNumber,
this->GetRoot(), lstParents ); //MEMORY EXCEPTION

I have traced it down into PdfPagesTree.
The constructor reads:
PdfPagesTree::PdfPagesTree( PdfVecObjects* pParent )
    : PdfElement( "Pages", pParent ),
      m_cache( 0 )
{
    GetObject()->GetDictionary().AddKey( "Kids", PdfArray() ); //
kids->Reference()
    GetObject()->GetDictionary().AddKey( "Count", PdfObject(
static_cast<pdf_int64>(0LL) ) );
}

The problem resides in the PdfArray(). This does construct an empty array,
but at the function end, this array is also automatically destroyed. But the
pointer to the destroyed array is stored in the Dictionary.

I adjusted this to:
PdfPagesTree::PdfPagesTree( PdfVecObjects* pParent )
    : PdfElement( "Pages", pParent ),
      m_cache( 0 )
{
    PdfArray* kids_array = new PdfArray();
    PdfObject* kids_object = new PdfObject(kids_array);
    PdfObject* count_object = new PdfObject( static_cast<pdf_int64>(0LL) );
    GetObject()->GetDictionary().AddKey( "Kids", kids_object ); //
kids->Reference()
    GetObject()->GetDictionary().AddKey( "Count", count_object );
}
2)
 void PdfPagesTree::InsertPage( int nAfterPageNumber, PdfObject* pPage )
InsertPageIntoNode( m_pObject, lstPagesTree, -1, pPage ); //EXCEPTION

calls:
void PdfPagesTree::InsertPageIntoNode( PdfObject* pParent, const
PdfObjectList & rlstParents,
                                       int nIndex, PdfObject* pPage )
    const PdfArray oldKids = pParent->GetDictionary().GetKey(
PdfName("Kids") )->GetArray(); //throws Not an array


Regards,
Mirco
------------------------------------------------------------------------------
_______________________________________________
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Reply via email to