python調用ctypes
『壹』 如何讓python調用C和C++代碼
二、Python調用C/C++1、Python調用C動態鏈接庫Python調用C庫比較簡單，不經過任何封裝打包成so，再使用python的ctypes調用即可。（1）c語言文件：pycall.c[html]viewplain/***gcc-olibpycall.so-shared-fPICpycall.c*/#include#includeintfoo(inta,intb){printf("youinput%dand%d\n",a,b);returna+b;}（2）gcc編譯生成動態庫libpycall.so：gcc-olibpycall.so-shared-fPICpycall.c。使用g++編譯生成C動態庫的代碼中的函數或者方法時，需要使用extern"C"來進行編譯。（3）Python調用動態庫的文件：pycall.py[html]viewplainimportctypesll=ctypes.cdll.LoadLibrarylib=ll("./libpycall.so")lib.foo(1,3)print'***finish***'（4）運行結果：2、Python調用C++(類)動態鏈接庫需要extern"C"來輔助，也就是說還是只能調用C函數，不能直接調用方法，但是能解析C++方法。不是用extern"C"，構建後的動態鏈接庫沒有這些函數的符號表。（1）C++類文件：pycallclass.cpp[html]viewplain#includeusingnamespacestd;classTestLib{public:voiddisplay();voiddisplay(inta);};voidTestLib::display(){cout#include#includeintfac(intn){if(n<2)return(1);/*0!==1!==1*/return(n)*fac(n-1);/*n!==n*(n-1)!*/}char*reverse(char*s){registerchart,/*tmp*/*p=s,/*fwd*/*q=(s+(strlen(s)-1));/*bwd*/while(p
『貳』 如何在Python中創建一個CFUNCTYPE-python，回調callback，ctypes
1. 我忘了ctypes的操作方法是：
下面是從復制
因此，我們的回調函數接收整型指針，並且必須返回一個整數。首先，我們創建了回調函數的類型：
CMPFUNC = CFUNCTYPE(c_int, POINTER(c_int), POINTER(c_int))
對於優先個回調函數中，我們簡單地列印出我們得到，並返回0（;-)：
def py_cmp_func(a, b):
print "py_cmp_func", a, b
return 0
創建C可調用的回調函數：
cmp_func = CMPFUNC(py_cmp_func)
『叄』 python用ctypes調用dll時如何得知dll的方法
這個，Depends可以看出來函數名字。ctypes調用的時候也可以按照序號調用函數。不過你什麼細節資料都沒有，就不要調用了，畢竟要構造參數的對不對？你知道人家參數類型嗎？字元串參數緩沖區要多長嗎？ 搞錯了就是個異常。
『肆』 python ctypes 怎麼處理函數返回的一般指針
test.c(動態庫源代碼)
[cpp] view plain
// 編譯生成動態庫: gcc -g -fPIC -shared -o libtest.so test.c
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
typedef struct StructPointerTest
{
char name[20];
int age;
}StructPointerTest, *StructPointer;
StructPointer test() // 返回結構體指針
{
StructPointer p = (StructPointer)malloc(sizeof(StructPointerTest));
strcpy(p->name, "Joe");
p->age = 20;
return p;
}
編譯：gcc -g -fPIC -shared -o libtest.so test.c
call.py(python調用C語言生成的動態庫):
[python] view plain
#!/bin/env python
# coding=UTF-8
from ctypes import *
#python中結構體定義
class StructPointer(Structure):
_fields_ = [("name", c_char * 20), ("age", c_int)]
if __name__ == "__main__":
lib = cdll.LoadLibrary("./libtest.so")
lib.test.restype = POINTER(StructPointer)
p = lib.test()
print "%s: %d" %(p.contents.name, p.contents.age)
最後運行結果：
[plain] view plain
[zcm@c_py #112]$make clean
rm -f *.o libtest.so
[zcm@c_py #113]$make
gcc -g -fPIC -shared -o libtest.so test.c
[zcm@c_py #114]$./call.py
Joe: 20
[zcm@c_py #115]$
『伍』 python的ctypes可以調用c++編譯生成的dll文件中的類函數嗎
可以的，python中一般有兩種方法調用DLL中的函數。
1.直接使用函數名，函數名可以用dependency walker等工具查看。（這個工具在vc或者vs的工具包中）
[python] view plain
import ctypes
dll = CTYPES.CDLL("test.dll")
res = test(3, 4)
2.使用Ordinal，Ordinal可以用dependency walker等工具查看。
[python] view plain
import ctypes
dll = CTYPES.CDLL("test.dll")
res = dll[1](3, 4)
為了方便查詢啊，你還可以下載一個LORDPE，這是一個逆向PE分析工具，可以方便的查到需要的信息。。
『陸』 python 怎麼調用c語言介面
ctypes: 可直接調用c語言動態鏈接庫。
使用步驟：
1> 編譯好自己的動態連接庫
2> 利用ctypes載入動態連接庫
3> 用ctype調用C函數介面時，需要將python變數類型做轉換後才能作為函數參數，轉換原則見下圖：
#Step1:test.c#include<stdio.h>
intadd(inta,intb)
{
returna+b;
}#Step2:編譯動態鏈接庫(如何編譯動態鏈接庫在本文不詳解，網上資料一大堆。)gcc-fPIC-sharedtest.c-olibtest.so
#Step3:test.py
fromctypesimport*mylib=CDLL("libtest.so")或者cdll.LoadLibrary("libtest.so")add=mylib.add
add.argtypes=[c_int,c_int]#參數類型，兩個int（c_int是ctypes類型，見上表）
add.restype=c_int#返回值類型，int(c_int是ctypes類型，見上表）
sum=add(3,6)
『柒』 Python如何利用多核處理器
GIL 與 Python 線程的糾葛
GIL 是什麼東西？它對我們的 python 程序會產生什麼樣的影響？我們先來看一個問題。運行下面這段 python 程序，CPU 佔用率是多少？
# 請勿在工作中模仿，危險:)def dead_loop(): while True: passdead_loop()
答案是什麼呢，佔用 100％ CPU？那是單核！還得是沒有超線程的古董 CPU。在我的雙核 CPU 上，這個死循環只會吃掉我一個核的工作負荷，也就是只佔用 50％ CPU。那如何能讓它在雙核機器上佔用 100％ 的 CPU 呢？答案很容易想到，用兩個線程就行了，線程不正是並發分享 CPU 運算資源的嗎。可惜答案雖然對了，但做起來可沒那麼簡單。下面的程序在主線程之外又起了一個死循環的線程
import threadingdef dead_loop(): while True: pass# 新起一個死循環線程t = threading.Thread(target=dead_loop)t.start()# 主線程也進入死循環dead_loop()t.join()
按道理它應該能做到佔用兩個核的 CPU 資源，可是實際運行情況卻是沒有什麼改變，還是只佔了 50％ CPU 不到。這又是為什麼呢？難道 python 線程不是操作系統的原生線程？打開 system monitor 一探究竟，這個佔了 50% 的 python 進程確實是有兩個線程在跑。那這兩個死循環的線程為何不能占滿雙核 CPU 資源呢？其實幕後的黑手就是 GIL。
GIL 的迷思：痛並快樂著
GIL 的全稱為Global Interpreter Lock，意即全局解釋器鎖。在 Python 語言的主流實現 CPython 中，GIL 是一個貨真價實的全局線程鎖，在解釋器解釋執行任何 Python 代碼時，都需要先獲得這把鎖才行，在遇到 I/O 操作時會釋放這把鎖。如果是純計算的程序，沒有 I/O 操作，解釋器會每隔 100 次操作就釋放這把鎖，讓別的線程有機會執行（這個次數可以通過sys.setcheckinterval來調整）。所以雖然 CPython 的線程庫直接封裝操作系統的原生線程，但 CPython 進程做為一個整體，同一時間只會有一個獲得了 GIL 的線程在跑，其它的線程都處於等待狀態等著 GIL 的釋放。這也就解釋了我們上面的實驗結果：雖然有兩個死循環的線程，而且有兩個物理 CPU 內核，但因為 GIL 的限制，兩個線程只是做著分時切換，總的 CPU 佔用率還略低於 50％。
看起來 python 很不給力啊。GIL 直接導致 CPython 不能利用物理多核的性能加速運算。那為什麼會有這樣的設計呢？我猜想應該還是歷史遺留問題。多核 CPU 在 1990 年代還屬於類科幻，Guido van Rossum 在創造 python 的時候，也想不到他的語言有一天會被用到很可能 1000＋ 個核的 CPU 上面，一個全局鎖搞定多線程安全在那個時代應該是最簡單經濟的設計了。簡單而又能滿足需求，那就是合適的設計（對設計來說，應該只有合適與否，而沒有好與不好）。怪只怪硬體的發展實在太快了，摩爾定律給軟體業的紅利這么快就要到頭了。短短 20 年不到，代碼工人就不能指望僅僅靠升級 CPU 就能讓老軟體跑的更快了。在多核時代，編程的免費午餐沒有了。如果程序不能用並發擠干每個核的運算性能，那就意謂著會被淘汰。對軟體如此，對語言也是一樣。那 Python 的對策呢？
Python 的應對很簡單，以不變應萬變。在最新的 python 3 中依然有 GIL。之所以不去掉，原因嘛，不外以下幾點：
欲練神功，揮刀自宮：
CPython 的 GIL 本意是用來保護所有全局的解釋器和環境狀態變數的。如果去掉 GIL，就需要多個更細粒度的鎖對解釋器的眾多全局狀態進行保護。或者採用 Lock-Free 演算法。無論哪一種，要做到多線程安全都會比單使用 GIL 一個鎖要難的多。而且改動的對象還是有 20 年歷史的 CPython 代碼樹，更不論有這么多第三方的擴展也在依賴 GIL。對 Python 社區來說，這不異於揮刀自宮，重新來過。
就算自宮，也未必成功：
有位牛人曾經做了一個驗證用的 CPython，將 GIL 去掉，加入了更多的細粒度鎖。但是經過實際的測試，對單線程程序來說，這個版本有很大的性能下降，只有在利用的物理 CPU 超過一定數目後，才會比 GIL 版本的性能好。這也難怪。單線程本來就不需要什麼鎖。單就鎖管理本身來說，鎖 GIL 這個粗粒度的鎖肯定比管理眾多細粒度的鎖要快的多。而現在絕大部分的 python 程序都是單線程的。再者，從需求來說，使用 python 絕不是因為看中它的運算性能。就算能利用多核，它的性能也不可能和 C/C++ 比肩。費了大力氣把 GIL 拿掉，反而讓大部分的程序都變慢了，這不是南轅北轍嗎。
難道 Python 這么優秀的語言真的僅僅因為改動困難和意義不大就放棄多核時代了嗎？其實，不做改動最最重要的原因還在於：不用自宮，也一樣能成功！
- extern"C"{ void DeadLoop() { while (true); }}
- from ctypes import *from threading import Threadlib = cdll.LoadLibrary("libdead_loop.so")t = Thread(target=lib.DeadLoop)t.start()lib.DeadLoop()
- extern"C"{ typedef void Callback(); void Call(Callback* callback) { callback(); }}
- from ctypes import *from threading import Threaddef dead_loop(): while True: passlib = cdll.LoadLibrary("libcall.so")Callback = CFUNCTYPE(None)callback = Callback(dead_loop)t = Thread(target=lib.Call, args=(callback,))t.start()lib.Call(callback)
其它神功
那除了切掉 GIL 外，果然還有方法讓 Python 在多核時代活的滋潤？讓我們回到本文最初的那個問題：如何能讓這個死循環的 Python 腳本在雙核機器上佔用 100％ 的 CPU？其實最簡單的答案應該是：運行兩個 python 死循環的程序！也就是說，用兩個分別占滿一個 CPU 內核的 python 進程來做到。確實，多進程也是利用多個 CPU 的好方法。只是進程間內存地址空間獨立，互相協同通信要比多線程麻煩很多。有感於此，Python 在 2.6 里新引入了multiprocessing這個多進程標准庫，讓多進程的 python 程序編寫簡化到類似多線程的程度，大大減輕了 GIL 帶來的不能利用多核的尷尬。
這還只是一個方法，如果不想用多進程這樣重量級的解決方案，還有個更徹底的方案，放棄 Python，改用 C/C++。當然，你也不用做的這么絕，只需要把關鍵部分用 C/C++ 寫成 Python 擴展，其它部分還是用 Python 來寫，讓 Python 的歸 Python，C 的歸 C。一般計算密集性的程序都會用 C 代碼編寫並通過擴展的方式集成到 Python 腳本里（如 NumPy 模塊）。在擴展里就完全可以用 C 創建原生線程，而且不用鎖 GIL，充分利用 CPU 的計算資源了。不過，寫 Python 擴展總是讓人覺得很復雜。好在 Python 還有另一種與 C 模塊進行互通的機制 : ctypes
利用 ctypes 繞過 GIL
ctypes 與 Python 擴展不同，它可以讓 Python 直接調用任意的 C 動態庫的導出函數。你所要做的只是用 ctypes 寫些 python 代碼即可。最酷的是，ctypes 會在調用 C 函數前釋放 GIL。所以，我們可以通過 ctypes 和 C 動態庫來讓 python 充分利用物理內核的計算能力。讓我們來實際驗證一下，這次我們用 C 寫一個死循環函數
用上面的 C 代碼編譯生成動態庫libdead_loop.so（Windows 上是dead_loop.dll）
，接著就要利用 ctypes 來在 python 里 load 這個動態庫，分別在主線程和新建線程里調用其中的DeadLoop
這回再看看 system monitor，Python 解釋器進程有兩個線程在跑，而且雙核 CPU 全被占滿了，ctypes 確實很給力！需要提醒的是，GIL 是被 ctypes 在調用 C 函數前釋放的。但是 Python 解釋器還是會在執行任意一段 Python 代碼時鎖 GIL 的。如果你使用 Python 的代碼做為 C 函數的 callback，那麼只要 Python 的 callback 方法被執行時，GIL 還是會跳出來的。比如下面的例子：
注意這里與上個例子的不同之處，這次的死循環是發生在 Python 代碼里 (DeadLoop函數) 而 C 代碼只是負責去調用這個 callback 而已。運行這個例子，你會發現 CPU 佔用率還是只有 50％ 不到。GIL 又起作用了。
其實，從上面的例子，我們還能看出 ctypes 的一個應用，那就是用 Python 寫自動化測試用例，通過 ctypes 直接調用 C 模塊的介面來對這個模塊進行黑盒測試，哪怕是有關該模塊 C 介面的多線程安全方面的測試，ctypes 也一樣能做到。
結語
雖然 CPython 的線程庫封裝了操作系統的原生線程，但卻因為 GIL 的存在導致多線程不能利用多個 CPU 內核的計算能力。好在現在 Python 有了易經筋（multiprocessing）, 吸星大法（C 語言擴展機制）和獨孤九劍（ctypes），足以應付多核時代的挑戰，GIL 切還是不切已經不重要了，不是嗎。
『捌』 Python使用Ctypes調用lib，怎麼使用指針類型參數接收輸出參數
本文演示了在python中調用C語言生成的動態庫，返回結構體指針，並進行輸出！
test.c(動態庫源代碼)
// 編譯生成動態庫: gcc -g -fPIC -shared -o libtest.so test.c
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
typedef struct StructPointerTest
{
char name[20];
int age;
}StructPointerTest, *StructPointer;
StructPointer test() // 返回結構體指針
{
StructPointer p = (StructPointer)malloc(sizeof(StructPointerTest));
strcpy(p->name, "Joe");
p->age = 20;
return p;
}
編譯：gcc -g -fPIC -shared -o libtest.so test.c
call.py(python調用C語言生成的動態庫):
#!/bin/env python
# coding=UTF-8
from ctypes import *
#python中結構體定義
class StructPointer(Structure):
_fields_ = [("name", c_char * 20), ("age", c_int)]
if __name__ == "__main__":
lib = cdll.LoadLibrary("./libtest.so")
lib.test.restype = POINTER(StructPointer)
p = lib.test()
print "%s: %d" %(p.contents.name, p.contents.age)
最後運行結果：
[zcm@c_py #112]$make clean
rm -f *.o libtest.so
[zcm@c_py #113]$make
gcc -g -fPIC -shared -o libtest.so test.c
[zcm@c_py #114]$./call.py
Joe: 20
[zcm@c_py #115]$
『玖』 python怎麼導入ctypes
1. 載入Windows系統自帶的dll文件：
#載入cdecl調用約定的dll
msvcrt =cdll.msvcrt
#載入stdcall調用約定的dll
kernel32 =windll.kernel32
2. 載入自己dll文件，假如為addFuncDll，方式如下：
mydll =CDLL("addFuncDll.dll")
或者 mydll = cdll.addFuncDll
如果其中有函數add，計算兩個整數的和，則使用方式如下：
result=mydll.add(4,5)
可以多一步指明add函數的參數類型（也可不指明）：
mydll.add.argtypes= [c_int,c_int]
3. 結構體在python中定義為Structure的子類如下：
class POINT(Structure):
_fields_ = [("x", c_int),
("y",c_int)]
_fields中每一項為元組（成員名稱，類型）
結構體還可以用於其他的結構體：
class RECT(Structure):
_fields_ = [("upperleft",POINT),
("lowerright",POINT)]
『拾』 python用ctypes操作剪切板遇到問題！！
這邊執行沒有問題，版本如下
Python3.5.0(v3.5.0:374f501f4567,Sep132015,02:27:37)[MSCv.190064bit(AMD64)]onwin32
代碼如下
importctypes
defget():
'''從剪切板中獲得字元串'''
h=ctypes.WinDLL('user32.dll')
h.OpenClipboard(0)
aa=h.GetClipboardData(13)
ss=ctypes.c_wchar_p(aa)
h.CloseClipboard()
returnss.value
defset(mystr):
'''把字元串放到剪切板中,成功返回1，失敗返回0'''
u=ctypes.WinDLL('user32.dll')
k=ctypes.WinDLL('kernel32.dll')
s=mystr.encode('utf-16')
s=s[2:]+b' '
ss=ctypes.c_char_p(s)
u.OpenClipboard(0)
u.EmptyClipboard()
k.GlobalAlloc.argtypes=[ctypes.c_uint32,ctypes.c_uint32]
try:
cb=k.GlobalAlloc(0,len(s))
cb=ctypes.c_void_p(cb)
print(type(cb))
ctypes.memmove(cb,ss,len(s))
rr=u.SetClipboardData(13,cb)#13->unicode
finally:
u.CloseClipboard()
ifrr==0:
return0
else:
return1
#-----
set("abcdefg")
程序返回
<class'ctypes.c_void_p'>