c++调用Python问题求解

[upbiuGIS]

问题描述：
程序执行至调用函数前都没有错误，但返回的结果为空，即pReturn为空。想请教各位这是什么原因？另外，在释放python对象指针代码处，VS2010编译报错（之前灰掉这块了）：
“ 无法解析的外部符号 __imp___Py_Dealloc，该符号在函数 _main 中被引用
1>TT.obj : error LNK2019:
无法解析的外部符号 __imp___Py_NegativeRefcount，该符号在函数 _main 中被引用
1>TT.obj : error LNK2001: 无法解析的外部符号 __imp___Py_RefTotal”
请大神指点！以下是代码块。
python代码
```
#-*- coding:gb2312 -*-
def hello(a,b) :
return a+b
```
c++代码
```
#include<iostream>
#include<Python.h>
using namespace std;
int main()
{
Py_Initialize();//使用python之前，要调用Py_Initialize();这个函数进行初始化
PyObject * pModule = NULL;//声明变量

PyObject * pFunc = NULL;// 声明变量
PyObject *pDict = NULL;
PyObject *pArgs = NULL;
pModule =PyImport_ImportModule("test_call");//这里是要调用的文件名
if ( !pModule )
{
printf("can't find pytest.py");
getchar();
return -1;
}

pDict = PyModule_GetDict(pModule);
//pFunc= PyObject_GetAttrString(pModule, "hello");//这里是要调用的函数名
pFunc = PyDict_GetItemString(pDict, "hello");

if ( !pFunc || !PyCallable_Check(pFunc) )
{
printf("can't find function [hello]");
getchar();
return -1;
}

pArgs = Py_BuildValue("i",3);
pArgs = Py_BuildValue("i",4);

PyObject *pReturn = NULL;
pReturn = PyEval_CallObject(pFunc, pArgs);//调用函数

if(!pReturn)
{
cout<<"null.\n";
return -1;
}

int result = -1;
if (pReturn && PyArg_ParseTuple(pReturn,"i", &result))
{
cout << "3+4 = " << result << endl;
}

Py_DECREF(pModule);
Py_DECREF(pFunc);
Py_DECREF(pDict);
Py_DECREF(pArgs);

Py_Finalize();//调用Py_Finalize，这个根Py_Initialize相对应的。

return 0;
}
```

[Wildwolf]

如果调用的是Python是Release版本的，C++工程必须使用Release版本。C++工程使用Debug版本的话需要自己重新编译python源码Debug版本。

[赵4老师]

不要做A语言代码修改为B语言代码的无用功。 也不要做用A语言代码直接调用B语言代码库这样复杂、这样容易出错的傻事。 只需让A、B语言代码的输入输出重定向到文本文件，或修改A、B语言代码让其通过文本文件输入输出。 即可很方便地让A、B两种语言之间协调工作。 比如： A将请求数据写到文件a.txt，写完后改名为aa.txt B发现aa.txt存在时，读取其内容，调用相应功能，将结果写到文件b.txt，写完后删除aa.txt，改名为bb.txt A发现bb.txt存在时，读取其内容，读完后删除bb.txt 以上A可以替换为任何一种开发语言或开发环境，B可以替换为任何一种与A不同的开发语言或开发环境。 除非A或B不支持判断文件是否存在、文件读写和文件更名。 但是谁又能举出不支持判断文件是否存在、文件读写和文件更名的开发语言或开发环境呢？ 可以将临时文件放在RamDisk上提高效率减少磨损磁盘。 数据的结构很复杂的话，文本文件的格式问题可参考json或xml 共享临时文本文件这种进程之间的通讯方法相比其它方法的优点有很多，下面仅列出我现在能想到的： ·进程之间松耦合 ·进程可在同一台机器上，也可跨机，跨操作系统，跨硬件平台，甚至跨国。 ·方便调试和监视，只需让第三方或人工查看该临时文本文件即可。 ·方便在线开关服务，只需删除或创建该临时文本文件即可。 ·方便实现分布式和负载均衡。 ·方便队列化提供服务，而且几乎不可能发生队列满的情况（除非硬盘空间满） ·…… “跨语言、跨机，跨操作系统，跨硬件平台，跨国，跨*.*的”苦海无边， 回头是“使用共享纯文本文件进行信息交流”的岸！