Andreas Vox wrote:
> Hi!
>
> I'm kind of puzzled because I can't find the definition of
> PdfObject::GetParent(),
> just it's inline declaration (no body).
>
> I'm even more puzzled because g++ still compiles code which uses that
> method.
test.cxx:
----
#include <podofo/podofo.h>
int main()
{
PoDoFo::PdfObject p;
p.GetParent();
}
----
g++ -I/home/craig/build/podofo -L/home/craig/build/podofo-build/src \
test.cxx -lpodofo -lfreetype -lfontconfig -ljpeg
./podofo/../src/PdfObject.h:233: warning: inline function
âPoDoFo::PdfObject* PoDoFo::PdfObject::GetParent() constâ used
but never defined
/tmp/cc6Dmlle.o: In function `main':
test.cxx:(.text+0x24): undefined reference to
`PoDoFo::PdfObject::GetParent() const'
collect2: ld returned 1 exit status
So it looks like the compiler will merely warn about it, presumably
treating it as an out-of-line definition instead (after all, inline is
only a hint) but the linker will catch the undefined symbol and fail.
In any case, the PdfObject::GetParent() is not in fact defined. A little
digging reveals the following commit:
----
r361 | domseichter | 2007-01-26 08:15:13 +0900 (Fri, 26 Jan 2007) | 9 lines
Refactor PdfObject::GetParent to PdfObject::GetCreator.
Because it returns not the actual parent, but the PdfVecObjects who
created the object. That's why it is Get/SetCreator now, maybe+
I'll change it to Get/SetOwner later. While writing this message, it
seems to be a more logical name.
This refactoring was done so that a real GetParent method can be
introduced without any troubles. This method will return the real+
parent in the hierarchy.
----
See "svn diff -r360:361 PdfObject.h" for the full patch text.
I didn't think there was any infrastructure for tracking parentage of
direct objects as yet so that matches what I'd expect. It's unfortunate
that the method remained defined though.
> BTW: I'm want to use that method for looking up the /Resources in the
> page tree. Maybe PdfPage::GetResources() should do that
> automatically? Same with other inherited attributes?
GetResources() obtains access to the resources object its self, allowing
the user to manipulate it. It'd certainly be very useful to have a
separate method to obtain a list of all required resource, both local
and inherited, though.
I'm not sure how podofoimpose handles this, and I have to head out now.
I wouldn't be too surprised if it's relying on podofo's unused indirect
object garbage collection.
--
Craig Ringer
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Podofo-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/podofo-users
