13518219792
第一步，我先从简单的调用出发，定义了一个简单的函数，该函数仅仅实现一个整数加法求和：
成都创新互联公司坚持“要么做到，要么别承诺”的工作理念，服务领域包括：网站制作、成都网站设计、企业官网、英文网站、手机端网站、网站推广等服务，满足客户于互联网时代的宁波网站设计、移动媒体设计的需求，帮助企业找到有效的互联网解决方案。努力成为您成熟可靠的网络建设合作伙伴！
LIBEXPORT_API int mySum(int a,int b){ return a+b;}
C# 导入定义：
public class RefComm
{
[DllImport("LibEncrypt.dll",
EntryPoint=" mySum ",
CharSet=CharSet.Auto,CallingConvention=CallingConvention.StdCall)]
public static extern int mySum (int a,int b);
}
在C#中调用测试：
int iSum = RefComm.mySum(,);
运行查看结果iSum为5，调用正确。第一步试验完成，说明在C#中能够调用自定义的动态链接库函数。
第二步，我定义了字符串操作的函数（简单起见，还是采用前面的函数名），返回结果为字符串：
LIBEXPORT_API char *mySum(char *a,char *b){sprintf(b,"%s",a); return a;}
C# 导入定义：
public class RefComm
{
[DllImport("LibEncrypt.dll",
EntryPoint=" mySum ",
CharSet=CharSet.Auto,
CallingConvention=CallingConvention.StdCall)]
public static extern string mySum (string a, string b);
}
在C#中调用测试：
string strDest="";
string strTmp= RefComm.mySum("45", strDest);
运行查看结果 strTmp 为"45"，但是strDest为空。我修改动态链接库实现，返回结果为串b：
LIBEXPORT_API char *mySum(char *a,char *b){sprintf(b,"%s",a) return b;}
修改 C# 导入定义，将串b修改为ref方式：
public class RefComm
{
[DllImport("LibEncrypt.dll",
EntryPoint=" mySum ",
CharSet=CharSet.Auto,CallingConvention=CallingConvention.StdCall)]
public static extern string mySum (string a, ref string b);
}
在C#中再调用测试：
string strDest="";
string strTmp= RefComm.mySum("45", ref strDest);
运行查看结果 strTmp 和 strDest 均不对，含不可见字符。再修改 C# 导入定义，将CharSet从Auto修改为Ansi：
public class RefComm
{
[DllImport("LibEncrypt.dll",
EntryPoint=" mySum ",
CharSet=CharSet.Ansi,CallingConvention=CallingConvention.StdCall)]
public static extern string mySum (string a, string b);
}
在C#中再调用测试：
string strDest="";
string strTmp= RefComm. mySum("45", ref strDest);
运行查看结果 strTmp 为"45"，但是串 strDest 没有赋值。第二步实现函数返回串，但是在函数出口参数中没能进行输出。再次修改 C# 导入定义，将串b修改为引用（ref）：
public class RefComm
{
[DllImport("LibEncrypt.dll",
EntryPoint=" mySum ",
CharSet=CharSet.Ansi,CallingConvention=CallingConvention.StdCall)]
public static extern string mySum (string a, ref string b);
}
运行时调用失败，不能继续执行。
第三步，修改动态链接库实现，将b修改为双重指针：
LIBEXPORT_API char *mySum(char *a,char **b){sprintf((*b),"%s",a); return *b;}
C#导入定义：
public class RefComm
{
[DllImport("LibEncrypt.dll",
EntryPoint=" mySum ",
CharSet=CharSet.Ansi,CallingConvention=CallingConvention.StdCall)]
public static extern string mySum (string a, ref string b);
}
在C#中调用测试：
string strDest="";
string strTmp= RefComm. mySum("45", ref strDest);
运行查看结果 strTmp 和 strDest 均为"45"，调用正确。第三步实现了函数出口参数正确输出结果。
第四步，修改动态链接库实现，实现整数参数的输出：
LIBEXPORT_API int mySum(int a,int b,int *c){ *c=a+b; return *c;}
C#导入的定义：
public class RefComm
{
[DllImport("LibEncrypt.dll",
EntryPoint=" mySum ",
CharSet=CharSet.Ansi,CallingConvention=CallingConvention.StdCall)]
public static extern int mySum (int a, int b,ref int c);
}
在C#中调用测试：
int c=0;
int iSum= RefComm. mySum(,, ref c);
运行查看结果iSum 和c均为5，调用正确。
经过以上几个步骤的试验，基本掌握了如何定义动态库函数以及如何在 C# 定义导入，有此基础，很快我实现了变长加密函数在 C# 中的调用，至此目标实现。
三、结论
在 C# 中调用 C++ 编写的动态链接库函数，如果需要出口参数输出，则需要使用指针，对于字符串，则需要使用双重指针，对于 C# 的导入定义，则需要使用引用（ref）定义。
对于函数返回值，C# 导入定义和 C++ 动态库函数声明定义需要保持一致，否则会出现函数调用失败。定义导入时，一定注意 CharSet 和 CallingConvention 参数，否则导致调用失败或结果异常。运行时，动态链接库放在 C# 程序的目录下即可，我这里是一个 C# 的动态链接库，两个动态链接库就在同一个目录下运行。
众所周知，Python 是一门面向对象语言，在 Python 的世界一切皆对象。所以一切变量的本质都是对象的一个指针而已。
Python 运行过程中会不停的创建各种变量，而这些变量是需要存储在内存中的，随着程序的不断运行，变量数量越来越多，所占用的空间势必越来越大，如果对变量所占用的内存空间管理不当的话，那么肯定会出现 out of memory。程序大概率会被异常终止。
因此，对于内存空间的有效合理管理变得尤为重要，那么 Python 是怎么解决这个问题的呢。其实很简单，对不不可能再使用到的内存进行回收即可，像 C 语言中需要程序员手动释放内存就是这个道理。但问题是如何确定哪些内存不再会被使用到呢？这就是我们今天要说的垃圾回收了。
目前垃圾回收比较通用的解决办法有三种，引用计数，标记清除以及分代回收。
引用计数也是一种最直观，最简单的垃圾收集技术。在 Python 中，大多数对象的生命周期都是通过对象的引用计数来管理的。其原理非常简单，我们为每个对象维护一个 ref 的字段用来记录对象被引用的次数，每当对象被创建或者被引用时将该对象的引用次数加一，当对象的引用被销毁时该对象的引用次数减一，当对象的引用次数减到零时说明程序中已经没有任何对象持有该对象的引用，换言之就是在以后的程序运行中不会再次使用到该对象了，那么其所占用的空间也就可以被释放了了。
我们来看看下面的例子。
函数 print_memory_info 用来获取程序占用的内存空间大小，在 foo 函数中创建一个包含一百万个整数的列表。从打印结果我们可以看出，创建完列表之后程序耗用的内存空间上升到了 55 MB。而当函数 foo 调用完毕之后内存消耗又恢复正常。
这是因为我们在函数 foo 中创建的 list 变量是局部变量，其作用域是当前函数内部，一旦函数执行完毕，局部变量的引用会被自动销毁，即其引用次数会变为零，所占用的内存空间也会被回收。
为了验证我们的想法，我们对函数 foo 稍加改造。代码如下：
稍加改造之后，即使 foo 函数调用结束其所消耗的内存也未被释放。
主要是因为我们将函数 foo 内部产生的列表返回并在主程序中接收之后，这样就会导致该列表的引用依然存在，该对象后续仍有可能被使用到，垃圾回收便不会回收该对象。
那么，什么时候对象的引用次数才会增加呢。下面四种情况都会导致对象引用次数加一。
同理，对象引用次数减一的情况也有四种。
引用计数看起来非常简单，实现起来也不复杂，只需要维护一个字段保存对象被引用的次数即可，那么是不是就代表这种算法没有缺点了呢。实则不然，我们知道引用次数为零的对象所占用的内存空间肯定是需要被回收的。那引用次数不为零的对象呢，是不是就一定不能回收呢？
我们来看看下面的例子，只是对函数 foo 进行了改造，其余未做更改。
我们看到，在函数 foo 内部生成了两个列表 list_a 和 list_b，然后将两个列表分别添加到另外一个中。由结果可以看出，即使 foo 函数结束之后其所占用的内存空间依然未被释放。这是因为对于 list_a 和 list_b 来说虽然没有被任何外部对象引用，但因为二者之间交叉引用，以至于每个对象的引用计数都不为零，这也就造成了其所占用的空间永远不会被回收的尴尬局面。这个缺点是致命的。
为了解决交叉引用的问题，Python 引入了标记清除算法和分代回收算法。
显然，可以包含其他对象引用的容器对象都有可能产生交叉引用问题，而标记清除算法就是为了解决交叉引用的问题的。
标记清除算法是一种基于对象可达性分析的回收算法，该算法分为两个步骤，分别是标记和清除。标记阶段，将所有活动对象进行标记，清除阶段将所有未进行标记的对象进行回收即可。那么现在的为问题变为了 GC 是如何判定哪些是活动对象的？
事实上 GC 会从根结点出发，与根结点直接相连或者间接相连的对象我们将其标记为活动对象（该对象可达），之后进行回收阶段，将未标记的对象（不可达对象）进行清除。前面所说的根结点可以是全局变量，也可以是调用栈。
标记清除算法主要用来处理一些容器对象，虽说该方法完全可以做到不误杀不遗漏，但 GC 时必须扫描整个堆内存，即使只有少量的非可达对象需要回收也需要扫描全部对象。这是一种巨大的性能浪费。
由于标记清除算法需要扫描整个堆的所有对象导致其性能有所损耗，而且当可以回收的对象越少时性能损耗越高。因此 Python 引入了分代回收算法，将系统中存活时间不同的对象划分到不同的内存区域，共三代，分别是 0 代，1 代 和 2 代。新生成的对象是 0 代，经过一次垃圾回收之后，还存活的对象将会升级到 1 代，以此类推，2 代中的对象是存活最久的对象。
那么什么时候触发进行垃圾回收算法呢。事实上随着程序的运行会不断的创建新的对象，同时也会因为引用计数为零而销毁大部分对象，Python 会保持对这些对象的跟踪，由于交叉引用的存在，以及程序中使用了长时间存活的对象，这就造成了新生成的对象的数量会大于被回收的对象数量，一旦二者之间的差值达到某个阈值就会启动垃圾回收机制，使用标记清除算法将死亡对象进行清除，同时将存活对象移动到 1 代。 以此类推，当二者的差值再次达到阈值时又触发垃圾回收机制，将存活对象移动到 2 代。
这样通过对不同代的阈值做不同的设置，就可以做到在不同代使用不同的时间间隔进行垃圾回收，以追求性能最大。
事实上，所有的程序都有一个相识的现象，那就是大部分的对象生存周期都是相当短的，只有少量对象生命周期比较长，甚至会常驻内存，从程序开始运行持续到程序结束。而通过分代回收算法，做到了针对不同的区域采取不同的回收频率，节约了大量的计算从而提高 Python 的性能。
除了上面所说的差值达到一定阈值会触发垃圾回收之外，我们还可以显示的调用 gc.collect() 来触发垃圾回收，最后当程序退出时也会进行垃圾回收。
本文介绍了 Python 的垃圾回收机制，垃圾回收是 Python 自带的功能，并不需要程序员去手动管理内存。
其中引用计数法是最简单直接的，但是需要维护一个字段且针对交叉引用无能为力。
标记清除算法主要是为了解决引用计数的交叉引用问题，该算法的缺点就是需要扫描整个堆的所有对象，有点浪费性能。
而分代回收算法的引入则完美解决了标记清除算法需要扫描整个堆对象的性能浪费问题。该算法也是建立在标记清除基础之上的。
最后我们可以通过 gc.collect() 手动触发 GC 的操作。
题外话，如果你看过 JVM 的垃圾回收算法之后会发现 Python 的垃圾回收算法与其是如出一辙的，事实再次证明，程序语言设计时是会相互参考的。
“在Python中，函数本身也是对象”
这一本质。那不妨慢慢来，从最基本的概念开始，讨论一下这个问题：
1. Python中一切皆对象
这恐怕是学习Python最有用的一句话。想必你已经知道Python中的list, tuple, dict等内置数据结构，当你执行：
alist = [1, 2, 3]
时，你就创建了一个列表对象，并且用alist这个变量引用它：
当然你也可以自己定义一个类:
class House(object):
def __init__(self, area, city):
self.area = area
self.city = city
def sell(self, price):
[...] #other code
return price
然后创建一个类的对象：
house = House(200, 'Shanghai')
OK，你立马就在上海有了一套200平米的房子，它有一些属性(area, city)，和一些方法(__init__, self)：
2. 函数是第一类对象
和list, tuple, dict以及用House创建的对象一样，当你定义一个函数时，函数也是对象：
def func(a, b):
return a+b
在全局域，函数对象被函数名引用着，它接收两个参数a和b，计算这两个参数的和作为返回值。
所谓第一类对象，意思是可以用标识符给对象命名，并且对象可以被当作数据处理，例如赋值、作为参数传递给函数，或者作为返回值return 等
因此，你完全可以用其他变量名引用这个函数对象：
add = func
这样，你就可以像调用func(1, 2)一样，通过新的引用调用函数了：
print func(1, 2)
print add(1, 2) #the same as func(1, 2)
或者将函数对象作为参数，传递给另一个函数：
def caller_func(f):
return f(1, 2)
if __name__ == "__main__":
print caller_func(func)
可以看到，
函数对象func作为参数传递给caller_func函数，传参过程类似于一个赋值操作f=func；
于是func函数对象，被caller_func函数作用域中的局部变量f引用，f实际指向了函数func；cc
当执行return f(1, 2)的时候，相当于执行了return func(1, 2)；
因此输出结果为3。
3. 函数对象 vs 函数调用
无论是把函数赋值给新的标识符，还是作为参数传递给新的函数，针对的都是函数对象本身，而不是函数的调用。
用一个更加简单，但从外观上看，更容易产生混淆的例子来说明这个问题。例如定义了下面这个函数：
def func():
return "hello,world"
然后分别执行两次赋值：
ref1 = func #将函数对象赋值给ref1
ref2 = func() #调用函数，将函数的返回值("hello,world"字符串)赋值给ref2
很多初学者会混淆这两种赋值，通过Python内建的type函数，可以查看一下这两次赋值的结果：
In [4]: type(ref1)
Out[4]: function
In [5]: type(ref2)
Out[5]: str
可以看到，ref1引用了函数对象本身，而ref2则引用了函数的返回值。通过内建的callable函数，可以进一步验证ref1是可调用的，而ref2是不可调用的：
In [9]: callable(ref1)
Out[9]: True
In [10]: callable(ref2)
Out[10]: False
传参的效果与之类似。
4. 闭包LEGB法则
所谓闭包，就是将组成函数的语句和这些语句的执行环境打包在一起时，得到的对象
听上去的确有些复杂，还是用一个栗子来帮助理解一下。假设我们在foo.py模块中做了如下定义：
#foo.py
filename = "foo.py"
def call_func(f):
return f() #如前面介绍的，f引用一个函数对象，然后调用它
在另一个func.py模块中，写下了这样的代码：
#func.py
import foo #导入foo.py
filename = "func.py"
def show_filename():
return "filename: %s" % filename
if __name__ == "__main__":
print foo.call_func(show_filename) #注意：实际发生调用的位置，是在foo.call_func函数中
当我们用python func.py命令执行func.py时输出结果为：
chiyu@chiyu-PC:~$ python func.py
filename:func.py
很显然show_filename()函数使用的filename变量的值，是在与它相同环境(func.py模块)中定义的那个。尽管foo.py模块中也定义了同名的filename变量，而且实际调用show_filename的位置也是在foo.py的call_func内部。
而对于嵌套函数，这一机制则会表现的更加明显：闭包将会捕捉内层函数执行所需的整个环境：
#enclosed.py
import foo
def wrapper():
filename = "enclosed.py"
def show_filename():
return "filename: %s" % filename
print foo.call_func(show_filename) #输出：filename: enclosed.py
实际上，每一个函数对象，都有一个指向了该函数定义时所在全局名称空间的__globals__属性：
#show_filename inside wrapper
#show_filename.__globals__
{
'__builtins__': module '__builtin__' (built-in), #内建作用域环境
'__file__': 'enclosed.py',
'wrapper': function wrapper at 0x7f84768b6578, #直接外围环境
'__package__': None,
'__name__': '__main__',
'foo': module 'foo' from '/home/chiyu/foo.pyc', #全局环境
'__doc__': None
}
当代码执行到show_filename中的return "filename: %s" % filename语句时，解析器按照下面的顺序查找filename变量：
Local - 本地函数(show_filename)内部，通过任何方式赋值的，而且没有被global关键字声明为全局变量的filename变量；
Enclosing - 直接外围空间(上层函数wrapper)的本地作用域，查找filename变量(如果有多层嵌套，则由内而外逐层查找，直至最外层的函数)；
Global - 全局空间(模块enclosed.py)，在模块顶层赋值的filename变量；
Builtin - 内置模块(__builtin__)中预定义的变量名中查找filename变量；
在任何一层先找到了符合要求的filename变量，则不再向更外层查找。如果直到Builtin层仍然没有找到符合要求的变量，则抛出NameError异常。这就是变量名解析的：LEGB法则。
总结：
闭包最重要的使用价值在于：封存函数执行的上下文环境；
闭包在其捕捉的执行环境(def语句块所在上下文)中，也遵循LEGB规则逐层查找，直至找到符合要求的变量，或者抛出异常。
5. 装饰器语法糖(syntax sugar)
那么闭包和装饰器又有什么关系呢？
上文提到闭包的重要特性：封存上下文，这一特性可以巧妙的被用于现有函数的包装，从而为现有函数更加功能。而这就是装饰器。
还是举个例子，代码如下：
#alist = [1, 2, 3, ..., 100] -- 1+2+3+...+100 = 5050
def lazy_sum():
return reduce(lambda x, y: x+y, alist)
我们定义了一个函数lazy_sum，作用是对alist中的所有元素求和后返回。alist假设为1到100的整数列表：
alist = range(1, 101)
但是出于某种原因，我并不想马上返回计算结果，而是在之后的某个地方，通过显示的调用输出结果。于是我用一个wrapper函数对其进行包装：
def wrapper():
alist = range(1, 101)
def lazy_sum():
return reduce(lambda x, y: x+y, alist)
return lazy_sum
lazy_sum = wrapper() #wrapper() 返回的是lazy_sum函数对象
if __name__ == "__main__":
lazy_sum() #5050
这是一个典型的Lazy Evaluation的例子。我们知道，一般情况下，局部变量在函数返回时，就会被垃圾回收器回收，而不能再被使用。但是这里的alist却没有，它随着lazy_sum函数对象的返回被一并返回了(这个说法不准确，实际是包含在了lazy_sum的执行环境中，通过__globals__)，从而延长了生命周期。
当在if语句块中调用lazy_sum()的时候，解析器会从上下文中(这里是Enclosing层的wrapper函数的局部作用域中)找到alist列表，计算结果，返回5050。
当你需要动态的给已定义的函数增加功能时，比如：参数检查，类似的原理就变得很有用：
def add(a, b):
return a+b
这是很简单的一个函数：计算a+b的和返回，但我们知道Python是 动态类型+强类型 的语言，你并不能保证用户传入的参数a和b一定是两个整型，他有可能传入了一个整型和一个字符串类型的值：
In [2]: add(1, 2)
Out[2]: 3
In [3]: add(1.2, 3.45)
Out[3]: 4.65
In [4]: add(5, 'hello')
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
/home/chiyu/ipython-input-4-f2f9e8aa5eae in module()
---- 1 add(5, 'hello')
/home/chiyu/ipython-input-1-02b3d3d6caec in add(a, b)
1 def add(a, b):
---- 2 return a+b
TypeError: unsupported operand type(s) for +: 'int' and 'str'
于是，解析器无情的抛出了一个TypeError异常。
动态类型：在运行期间确定变量的类型，python确定一个变量的类型是在你第一次给他赋值的时候；
强类型：有强制的类型定义，你有一个整数，除非显示的类型转换，否则绝不能将它当作一个字符串(例如直接尝试将一个整型和一个字符串做+运算)；
因此，为了更加优雅的使用add函数，我们需要在执行+运算前，对a和b进行参数检查。这时候装饰器就显得非常有用：
import logging
logging.basicConfig(level = logging.INFO)
def add(a, b):
return a + b
def checkParams(fn):
def wrapper(a, b):
if isinstance(a, (int, float)) and isinstance(b, (int, float)): #检查参数a和b是否都为整型或浮点型
return fn(a, b) #是则调用fn(a, b)返回计算结果
#否则通过logging记录错误信息，并友好退出
logging.warning("variable 'a' and 'b' cannot be added")
return
return wrapper #fn引用add，被封存在闭包的执行环境中返回
if __name__ == "__main__":
#将add函数对象传入，fn指向add
#等号左侧的add，指向checkParams的返回值wrapper
add = checkParams(add)
add(3, 'hello') #经过类型检查，不会计算结果，而是记录日志并退出
注意checkParams函数：
首先看参数fn，当我们调用checkParams(add)的时候，它将成为函数对象add的一个本地(Local)引用；
在checkParams内部，我们定义了一个wrapper函数，添加了参数类型检查的功能，然后调用了fn(a, b)，根据LEGB法则，解释器将搜索几个作用域，并最终在(Enclosing层)checkParams函数的本地作用域中找到fn；
注意最后的return wrapper，这将创建一个闭包，fn变量(add函数对象的一个引用)将会封存在闭包的执行环境中，不会随着checkParams的返回而被回收；
当调用add = checkParams(add)时，add指向了新的wrapper对象，它添加了参数检查和记录日志的功能，同时又能够通过封存的fn，继续调用原始的add进行+运算。
因此调用add(3, 'hello')将不会返回计算结果，而是打印出日志：
chiyu@chiyu-PC:~$ python func.py
WARNING:root:variable 'a' and 'b' cannot be added
有人觉得add = checkParams(add)这样的写法未免太过麻烦，于是python提供了一种更优雅的写法，被称为语法糖：
@checkParams
def add(a, b):
return a + b
这只是一种写法上的优化，解释器仍然会将它转化为add = checkParams(add)来执行。
6. 回归问题
def addspam(fn):
def new(*args):
print "spam,spam,spam"
return fn(*args)
return new
@addspam
def useful(a,b):
print a**2+b**2
首先看第二段代码：
@addspam装饰器，相当于执行了useful = addspam(useful)。在这里题主有一个理解误区：传递给addspam的参数，是useful这个函数对象本身，而不是它的一个调用结果；
再回到addspam函数体：
return new 返回一个闭包，fn被封存在闭包的执行环境中，不会随着addspam函数的返回被回收；
而fn此时是useful的一个引用，当执行return fn(*args)时，实际相当于执行了return useful(*args)；
最后附上一张代码执行过程中的引用关系图，希望能帮助你理解：
