Calling C++ code from Python

I have a C++ class like this:

#ifndef PATHING_H
#define PATHING_H

#include "pandabase.h"
#include "CartGraph.cxx"
#include "MinHeap.cxx"


		CartGraph townGraph;
		MinHeap<Vertex> openSet;

The corresponding cxx file:

#include "Pathing.h"




Both of these files, Pathing.cxx and Pathing.h are in the ‘panda\src\skel’ folder. I have also included the Pathing.cxx file within the skel_composite1.cxx file. In my Python file, I have this line of code:

from pandac.PandaModules import *;

When I try to create an object of type ‘Pathing’, it tells me “NameError: name ‘Pathing’ is not defined”. I have written another class almost identical to this which works. Any ideas?

You’ll find your “skel” classes defined in the module libskel, not in PandaModules. So import libskel instead. (Though come to think of it, this might have some issues on Windows right now.)

Alternatively, run the script:

genPyCode libskel

This will rebuild PandaModules to include your skel classes.


I realized that we are getting some file parsing errors when compiling.


#include "Graph.h"

//       Class : Graph
// Description : The base class for a Graph Data Structure
class CartGraph : Graph
		CartGraph(int rows, int columns, int spaceRows, int spaceColumns, int shiftX, int shiftY);



		void Construct();
		void MatchSiblings();
		float* IndexToWorld(int* xy);
		int* WorldToIndex(float* pos);

		Vertex::State GetStartState(int* index2D);

		Vertex* ReturnVertex(int indexX, int indexY);


The parsing error occurs on the line that reads “class CartGraph : Graph”
Any reason that you think there would be a parsing error?

Yeah, what about this:

class CartGraph : public Graph 

Depends whether you want to publicly or privately (or even protected) inherit from Graph.

Incase you guys haven’t caught on yet, Lesnaubr and I are working on the same project.

We caught that slip with the inheritance and fixed that. Then we recieved a parse error on the line with the #include “MinHeap.cxx” so I commented out the include and the member variable and it’s call in the class constructor/destructor.

Then we recieved this parse error( which is almost the exact same as every other one we’ve recieved except it has no file listed not colums/line numbers):

1>cl /wd4996 /Fobuilt/tmp/skel_composite.obj /nologo /c /Ipanda/src/skel /I"thirdparty/win-python/include" /I"built/tmp" /I"built/include" /MD /Zi /O2 /Ob2 /DFORCE_INLINING /Fdbuilt/tmp/skel_composite.pdb /DBUILDING_PANDASKEL /EHsc /Zm300 /DWIN32_VC /DWIN32 /W3 panda/src/skel/skel_composite.cxx


1>CAUTION: file dependencies changed: [‘built/pandac/input/’]

1>built/bin/interrogate -srcdir panda/src/skel -Ipanda/src/skel -DCPPPARSER -D__STDC__=1 -D__cplusplus -D__inline -longlong _int64 -D_X86 -DWIN32_VC -D_WIN32 -D_MSC_VER=1400 -D"_declspec(param)=" -D_near -D_far -D__near -D__far -D__stdcall -DFORCE_INLINING -oc built/tmp/libskel_igate.cxx -od built/pandac/input/ -fnames -string -refcount -assert -python-native -Sbuilt/include/parser-inc -Ipanda/src/skel -S"thirdparty/win-python/include" -S"built/tmp" -S"built/include" -DBUILDING_PANDASKEL -module pandaskel -library libskel CartGraph.h Derived.h Graph.h Interface.h MinHeap.h Pathing.h Vertex.h basicSkel.h config_skel.h myClass.h skel_composite.cxx typedSkel.h

1>*** Error in near line 0, column 0:

1>parse error

1>Error parsing file: ‘Pathing.h’

My appologies on the how awful that looks, that’s just the way it came out. I feel it prudent to mention we are compiling with VS 2008. This erros doesn’t show up in the error list and instead only shows up in the output for the Build.

We greatly appreciatte the help we’ve receieved so far and any we may get.


This error message is coming from interrogate, not from the compiler. Interrogate is our own tool that reads the code and generates the appropriate Python wrappers, and it therefore has to be able to successfully parse the C++ code, similar to the way the compiler parses it.

Since it is complaining about line 0, column 0, which is the very first byte of the file, it makes me suspect that you have saved the file with some Windows program that writes those weird Microsoft-specific header bytes to the first two bytes of the file, which is supposed to indicate the character encoding of the file. Many Windows programs transparently read and interpret these two bytes when they load up a text file. Trouble is, non-Windows programs (like interrogate) don’t know anything about these bytes, and stumble over them instead.

That’s just a guess, of course. There might be something else weird about the first byte of the file.


Thanks for the suggestion. Any ideas on how to save a file in windows without those preceding bytes? Should I just use a non-Microsoft text editor? We saved all of our files using Visual Studio 2008 by the way. It also seems strange that other similar parse errors gave a file name of the file which the error occured in but this error gives no information as to what file the error actually occurs in.

Thanks for all of your help so far. Timeisaparallax and I are working on integrating an A* algorithm into the engine. If all goes well, we would gladly share our progress with the rest of the Panda3d community so that others can hopefully use it.

Hmm, well, maybe my guess is wrong–I don’t believe VS2008 writes these encoding bytes, unless maybe it thinks you’re using an international character set and require them. (Might that be the case?) In any case, you could test this by opening the file in some non-Microsoft editor, or even reading it in Python, to see what’s actually in the file.

You’re right, it is weird that it says “Error in near line 0”. Maybe there’s something else going wrong altogether. Maybe it’s not even able to open Pathing.h? You could try temporarily replacing that file with an empty file to see what happens.


Just to add another variable to the question, we are also using SVN to share these files. I’m wondering if it’s writting something into the files for versioning??

Nope, svn stores all the info in a hidden “.svn” directory.

thought I’d just mention how lesnaubr got it working…

Not sure how or why it solved the problem but by putting all of our classes in one .h file and one .cxx file seems to have fixed the problem. Not really the solution we’d have liked but whatever works works I guess.

But yes, Thanks for the help you two; we’d have been up a creek without a paddle on our semester long project without the help.

When we’re done with it I’ll make it available to the community at large!


Interrogate has thrown us a ton of parse issues again.
Is there anyone who would be interested in looking at our code and seeing if the know why interrogate is choking on it please let me know

Currently it’s all in one .h and one .cxx, sadly, since this had appeared to work for awhile.

if someone feels like they may be able to help :