欧美成人免费观看,亚洲影院免费观看,国产精品vvv

Squirrel — Sun, 21 May 2006 03:41:00 GMT

最�q�看到浪潮的猎鹰服务器管理��Y�Ӟ��其中可以对远�E�服务器的CPU和内存��用率�q�行实时监视�Q�就像�Q务管理器那样�l�制一个报表。我推断他要么是使用SNMP协议从客��h��拿到数据之后在传递给��理器，要么��是使用Windows提供的某些System Performence COM�l��g来抓数据�?br /> 查MSDN�Q�上有一个System Monitor的例子。居然是用VBScript来调一调控刉��?〉管理工�?〉性能-〉系�l�监视器。既然是用HTML嵌VBScript�Q�那转换为应用程序到也方便，��文件后�~�名改�?hta�Q�即以HTML Application方式打开�Q�由MSHTA.exe来解释执行就可以了�?br /> 下面的程序就是从命��o行中获取要监视的计算机IP地址后，启动System Monitor�Q�监视之�?br />

<HTML>
<HEAD>
<HTA:APPLICATION ID="oHTA"
    APPLICATIONNAME="myApp">
   <meta http-equiv="Content-Type" content="text/html; charset=gb2312" >
   HEAD>
    <BODY BGCOLOR="#C0C0C0">
        <SCRIPT LANGUAGE="VBScript">
  Sub Monitor_OnCounterAdded(index)
    Monitor.Counters.Item(1).Width = 8
  End Sub
        SCRIPT>
        <OBJECT CLASSID="clsid:C4D2D8E0-D1DD-11CE-940F-008029004347" ID="Monitor" HEIGHT="80%" WIDTH="100%"
            VIEWASTEXT>
        OBJECT>
        <SCRIPT LANGUAGE="VBScript">

  Sub Window_OnLoad
    On Error Resume Next
    Monitor.ShowValueBar = True
    Monitor.ShowHorizontalGrid = True

    Arg = Trim( oHTA.commandLine )

    IPArgPos = InStr(2, Arg, """", 1)
    IPArg = Trim( right( Arg, len(Arg)-IPArgPos) )

    IPStrings = split( IPArg, " ", -1, 1 )

    for i = 0 to uBound(IPStrings)
    Monitor.Counters.Add( "\\" + IPStrings(i) + "\Processor(_Total)\% Processor Time" )
    Monitor.Counters.Add( "\\" + IPStrings(i) + "\Memory\Available MBytes" )
    Monitor.Counters.Add( "\\" + IPStrings(i) + "PhysicalDisk(_Total)\Avg. Disk Queue Length" )
    Monitor.Counters.Add( "\\" + IPStrings(i) + "\LogicalDisk(_Total)\% Free Space" )
    Monitor.Counters.Add( "\\" + IPStrings(i) + "\Network Interface(*)\Bytes Total/sec" )
    Next

    'Monitor.Counters.Add( "\Process(*)\% Processor Time")
    Monitor.DisplayType=sysmonLineGraph
    Monitor.GraphTitle= "计算机系�l�性能监视"
  End Sub

        SCRIPT>
    BODY>
HTML>

不知道大家有没有使用�q�COM�l��g��这��L��东西嵌到C++�E�序中。如果有的话�Q�不妨发表上来看看�?img src ="http://www.shnenglu.com/Squirrel/aggbug/7458.html" width = "1" height = "1" />

Squirrel 2006-05-21 11:41 发表评论

Windows凭据��理

Squirrel — Sat, 20 May 2006 11:54:00 GMT

题目中的Windows凭据�Q�Credential�Q�其实就是指用户帐户和口令。最�q�项目中存在一台Windows�Q�PC�Q�机�ȝ��理服务器�Q�Server�Q�，�q�之中就设计到服务器��理员权限的问题。需要用户对Windows上存储的用户名和密码�q�行��理�?br /> 在Windows XP和Server 2003 中都已存在了“存储的用户名和密码”。在XP中，通过控制面板中的用户帐户-〉选择用户-〉管理我的网�l�密码。而在Server 2003中，则在控制面板下直接有“存储的用户名和密码”项�?br /> 我们调用一些API�Q�如WTSOpenServer�Q�QueryServiceStatus�Q�NetUserEnum�{�等涉及到RPC的，只要当前用户存储有目标远�E�机的权限合适的凭据�Q�则�q�些API��׃��会因产生ERROR_ACCESS_DENIED而执行失败。因为我�q�不Windows的底层是如何�q�行控制的，比如�Q�是否调用了SSPI�Q�所以，执行�q�些API�Ӟ��我只能向用户要管理员口��o。但又不可能每次都让用户去输入一遍用户名和密码，那么�Q�也��需要保存密码�?br /> 既然保存了密码，��必��考虑删除密码�Q�那么密码管理的问题也就来了。说到密码管理，我在前些�q�看电视的时候，看到介绍一个叫什么“网�l�螃蟹”的�|�站�Q�他��是专门提供个�h密码��理的，当时我就惻I��有�h会去把自��q��密码交给别�h打理吗？�q�好像不大可能。何来也��没听到什么网�l�螃�Ҏ��行的消息�?br /> 现在我的��目中，如果用户有了一台机器（PC�Q�的密码�Q�那么，他就有了N台服务器的管理员权限。这当然是不被允许的了。怎么办？
找了一些API�Q�是Authentication Functions�p�d��的。于是，下面一个小实验代码��是��x��枚�D用户凭据的�?br />

#include <windows.h>
#include <WinCred.h>
int main(){

  DWORD dwCount = 0;
  PCREDENTIAL * pCredArray = NULL ;

  if( CredEnumerate( NULL, 0, &dwCount, &pCredArray ) ){

    for( DWORD dwIndex = 0; dwIndex < dwCount; dwIndex++){
      PCREDENTIAL pCredential = pCredArray[dwIndex];

      cout << "*********************************\r\n";

      cout<<  "Flags: " << pCredential->Flags << "\n"
          <<  "Type:  " <<  pCredential->Type << "\n"
          <<  "Name:  " << pCredential->TargetName << "\n"
          <<  "Persist: "<< pCredential->Persist  <<  "\n"
          <<  "User:  " <<  pCredential->UserName <<  "\n";

      cout << "Data:  \r\n";

      char szHexBuffer[256] = "";
      char szAsciiBuffer[256] = "";
      char szHex[16];
      char szAscii[2];
      DWORD dwByte;

      for (dwByte = 0; dwByte < pCredential->CredentialBlobSize; dwByte++)
      {
        BYTE byte1 = pCredential->CredentialBlob[dwByte];
        sprintf(szHex, "%2.2X ", byte1);
        szAscii[1] = '\0';

        if (byte1 >= 32 && byte1 < 128)
          szAscii[0] = (UCHAR)byte1;
        else
          szAscii[0] = ' ';

        strcat(szHexBuffer, szHex);
        strcat(szAsciiBuffer, szAscii);

        if (dwByte == pCredential->CredentialBlobSize - 1
          || dwByte % 16 == 15)
        {
          printf("%-50s %s\r\n", szHexBuffer, szAsciiBuffer);
          szHexBuffer[0] = '\0';
          szAsciiBuffer[0] = '\0';
        }

      }

      cout << "*********************************\r\n";

    }

    CredFree( pCredArray );
  }
  //system( "rundll32 keymgr.dll,KRShowKeyMgr");
  return 0;
}

好像凭据数据�q�没能打出来�?br />
后来�Q�本着“编�E�的最高境界就是不�~�程”的�_��Q�我惻I��如果直接把Windows的那个“存储的用户名和密码”对话框调出来用用不也可以吗。用ProcessExplorer�Q�找��C��个叫keymgr.dll的东西，嗯，估计对话框就在里面�?br /> 在“运行”中输入“control keymgr.dll”或“rundll32 keymgr.dll,KRShowKeyMgr”，对话框就出来了�?br /> 又省事了�Q?img src ="http://www.shnenglu.com/Squirrel/aggbug/7445.html" width = "1" height = "1" />

Squirrel 2006-05-20 19:54 发表评论

如此��目��理

Squirrel — Fri, 19 May 2006 07:56:00 GMT

�q�几天因��Z��个项目的事情非常郁闷。本来从底层到界面辛辛苦苦地写了两个月的东西�Q�等到第一个版本发布之后，所谓的��目�l�理居然以�ؓ大功告成�Q�说剩下的只是维护�?br /> 作�ؓ一个项目经理，对程序员开发的产品都不了解�Q�也��q��了，你搞好你的进度控�Ӟ��作好与其他部门之间的接口�Q�那也不错。可是这位仁兄还要不时地�q�预技术上面的事情。按照他的写Linux字符命��o界面�E�序的思�\来指挥Windows囑�Ş�E�序的设计。一切都��所谓的“简单”。要知道�Q�简单是对用戯��言的，对程序员来说�Q�简单的设计不能解决所有的问题。不要把Linux下那�U�所谓的��而简单而“强悍”的工具可以解决所有需求的思想来指导针对Windows用户的设计！
更搞�W�的是，当我提出�E�序中有要修改的地方�Q��ƈ询问主要寚w��些方面进行优化时�Q�他居然提出你们的�Q务就是把现在的代码压�?万行以下�Q�现在代码行��Cؓ1�?左右�Q�！其理由是便于��理�Q�！我真是哭�W�不得，我不知道大家是否遇到�q�种样子的项目经理。有�q�样��理软�g开发的吗？�Q�！
更气人的是，当我向他提出修改意见�Q��ƈ��实现一些前期设计因�q�度问题而砍掉的亮点功能�Ӟ��他犹豫了一下，然后��_��你们先学习吧�Q�（所谓的学习不过是个�q�子�Q�就是让你闲着。我来公�总�来就没有什么培训！�Q?br /> 靠，食君之禄�Q�忠君之事。我来公司是做事来的�Q�不是TMD休息�Q�疗养，�{�死来的�Q�是可忍�Q�孰不可忍？�Q?br /> 估计国内的小企业�Q�特别是��Y件企业都一个样�Q�找几个人写点代码，然后��去骗国�Ӟ��骗老百姓的钱，到手之后�Q�就把这几个�E�序员一扔，他才不考虑什么�h力资源的问题呢�?br />骗子�Q?/p>

Squirrel 2006-05-19 15:56 发表评论

�~�程语言发展历程

Squirrel — Tue, 16 May 2006 05:52:00 GMT

Squirrel 2006-05-16 13:52 发表评论

Windows�?ACE中的地址重用

Squirrel — Mon, 15 May 2006 10:51:00 GMT

   在ACE中，�q�个问题好像比较晦�ӆ�?br />
   我所遇到�q�的问题是在ACE_SOCK_Dgram_Bcast的第4个构造参数reuse_addr赋��gؓ1�Q�但很遗憾，在Windows�q�_��上，��是不能使端口重用生效。��用setsockopt来强制服用端口，仍然无效�Q�用ACE_SOCK_Dgram也试�q�了�Q�同��h��效。ACE的代码中如是��_��

// If we are using winsock2 then the SO_REUSEADDR feature is broken
// SO_REUSEADDR=1 behaves like SO_REUSEPORT=1. (SO_REUSEPORT is an
// extension to sockets on some platforms)
// We define SO_REUSEPORT here so that ACE_OS::setsockopt() can still
// allow the user to specify that a socketaddr can *always* be reused.
                                                                               —�?config-win32-common.h"

   在Winsock2中不支持SO_REUSEADDR, 可是我要用的只是端口重用而已�?br />
   不过ACE_SOCK_Dgram_Mcast倒是有效�Q�可惜，不是一个概��c�?br />
   我后来用很不爽的办法才应付过去，用socket函数先创建好SOCKET句柄后，再用ACE_SOCK_Dgram::set_handle讄��。挺郁闷的，不知道有没有好的�Ҏ��能解��x��解释�?br />

Squirrel 2006-05-15 18:51 发表评论

[转蝲]用Boost.Python构徏混合�pȝ��

Squirrel — Mon, 15 May 2006 07:44:00 GMT

Author: David Abrahams

摘要
��?/font>
Boost.Python 设计目标
Hello Boost.Python World
库概�?/font>
从�؜合的思�\思�?Thinking hybrid)
开发历�?/font>
�l�论
引用
脚注

摘要

Boost�Q�Python是一个开源的C++�E�序库，提供�c�M��IDL的接口来把C++�c�d��函数�l�定到Python。借助于C++强大的编译时内省(introspection)能力和最新的元编�E?metaprogramming)技术，它完全用C++来实玎ͼ�而不用引入新的语法。Boost.Python丰富的特性和高��接口使从底层��h��混合�pȝ��的方式设计组件成为可能，从而�ɽE�序员可以轻村֒��q�诏的同时��用C++高效的编译时多态和Python极其方便的运行时多态�?/p>

��?/a>

作�ؓ两门语言�Q�python和C++在很多方面不一栗��C++被编译�ؓ机器码，python被解�?interpreted)执行。Python的动态类�?type)�pȝ��l�常被认为是灉|��性的基础�Q�C++的静态类型是效率的基矟뀂C++有复杂艰��q��~�译时元语言(meta-language)�Q�而在python里，实际上一切都在运行时发生。然而对很多�E�序员来��_��q�些不同恰好意味着Python和C++是彼此的完美补��。Python �E�序里的性能瓉��部分可以用C++来重写，从而最大化速度。强大的C++�E�序库的作者选择Python作�ؓ中间�?middleware)语言�Q�从而获得灵�zȝ��pȝ��集成能力。此外，表面的不同掩盖了二者非常类似的一些地方：

‘C�?家族的控制结�?(if�Q�while�Q�for�?
支持面向对象(object-orientation)�Q�函数式�~�程(functional programming)�Q�泛型编�E?generic programming)(它们都是多范式语�a�(multi-paradigm languages))
认同语法可变�?syntactic variability)在提高代码的可读性和表达力上的重要作用，提供了对操作�W�重载的�q�泛支持
高��概念�Q�如集合(collections)�Q��P代器(iterators)�{?
高�񔞮�装机制(C++: namespaces�Q�Python: modules)支持可重用程序库的设�?
异常处理机制提供了有效的错误��理
被普遍��用的C++习惯用语�Q�如handle/body classes和引用被计数的智能指�?reference-counted smart pointers)对应Python 的引用语�?reference semantics)

考虑到Python丰富的’C'协作API�Q�原则上把C++的类型和函数以类��g��暴露�l�C++的接口暴露给Python是可能的。然而，单是Python提供的这�U�设施对集成C++的支持比较弱。和C++�Q�Python相比�Q�’C'的抽象机刉��常初�U�，而且完全不支持异常处理。’C'扩展模块的作者必��L��动管理引用计敎ͼ��q�不但让人恼火的�ȝ��和单调，�q�极度容易出错。传�l�的扩展模块�Ҏ��产生重复的样板代�?boilerplate code)�Q�从而难于维护，��其是要包装的API很复杂时�?/p>

上述限制��D��了一些包装系�l�的开发。SWIG_ 可能是集成C/C++和Python的包装系�l�中最��行的。一个更�q�的例子�?SIP �Q�它专门设计来提�?Qt 囑�Ş用户界面库的Python接口。SWIG和SIP都引入了它们专有的语�a�来实现语�a�间绑定。这当然有它的好处，但不得不应付三种不同的语�a�(Python�Q�C/C++和接口语�a�)也带来了实际的和心理上的困难�?CXX 软�g包展�C�出它是一个有��的包装�pȝ��。它说明了至��一部䆾Python ‘C�?API可以通过用户友好得多的C++接口来包装和表现。然而，和SWIG和SIP不一��P��CXX不支持把C++�c�d��装成新的Python�c�d��?/p>

Boost.Python 的特性和目标和很多这��L��pȝ��有相当程度的重叠。就是说�Q�Boost.Python试图最大化便利性和灉|��性，而不引入单独的包装语�a�。相反，它在�q�后用静态元�~�程技术管理很多复杂问题，赋予了用户通过高��C++接口来包装C++�c�d��函数的能力，Boost.Python也在如下领域��越了早期的�pȝ��Q?/p>

C++虚函数支持，虚函数可以用Python来覆�?override)
在整个生命周期内对低�U�指针和引用�q�行全面��理的设�?
�Ҏ��扩展(extensions)�l�织成Python packages的支持，通过中心注册�?central registry)来进行语�a�间类型�{�?
安全而便利的�q�接强大的Python序列化引�?pickle)的机�?
C++的lvalue和rvalue的一致的处理规则�Q�这只能来自对Python和C++两者的�c�d��pȝ��的深入理解�?

鼓舞Boost.Python开发的关键发现是，传统扩展开发中的大量样板代码都可以通过C++�~�译时内省来消除。被包装的C++函数的每个参数都必须�Ҏ��参数�c�d��从Python对象里取出来。类似地�Q�函数返回值的�c�d��军_��了返回值如何从C++转换成Python。参数类型和�q�回值类型当焉��是每个函数的�c�d��的一部分�Q�正是从�q�里�Q�Boost.Python推导��Z��大部分需要的信息�?/p>

�q�种�Ҏ��导向�?用户引导的包�?/em> �Q�尽可能的用�U�C++的框架直接从要包装的代码里取得信息，�q�以外的信息��q��h��式提供。大多数引导是自动的�Q�很��需要真正的�q�涉。因为写接口规范和写被暴露的代码的是同一门全功能语言�Q�当需要取得控制时用户有了�I�前强大的能力�?/p>

Boost.Python 设计目标

Boost.Python的首要目标是让用户只用C++�~�译器就能向Python暴露C++�c�d��函数。大体来�Ԍ��允许用户直接从Python操作C++对象�?/p>

然而，有一点很重要�Q�那��是不要 �q�于 按字面翻译所有接口：必须考虑每种语言的惯用语。例如，虽然C++和Python都有�q�代器的概念�Q�表达方式却很不一栗��Boost.Python必须能连接这些不同的接口�?/p>

必须把Python用户和C++接口的微��误用造成的崩溃隔��R��出于同样原因，应该把C++用户和低�U�Python ‘C�?API隔离�Q�容易出错的C接口�Q�比如手动引用计数管理，原始�?raw)PyObject指针�Q�应该用更加健壮�?more-robust)替代物来取代�?/p>

支持��Z��l��g的开发是臛_��重要的，因此被暴露在一个扩展模块里的C++�c�d��应该能够被传递给被暴露在另一个模块中的函敎ͼ�而不丢失重要的信息，比如说C++�l�承关系�?/p>

最后，所有的包装必须�?非��R入的(non-intrusive) �Q�不能修改甚至看不到原始的C++代码。对只能看见它头文�g和二�q�制文�g的第三方�Q�现有的C++库必��L��可包装的�?/p>

Hello Boost.Python World

现在来预览一下Boost.Python�Q��ƈ看看它如何改�q�Python的原始包装功能。下面是我们��x��露的一个函�?

char const* greet(unsigned x)
{
   static char const* const msgs[] = { "hello"�Q?Boost.Python"�Q?world!" };

   if (x > 2)
       throw std::range_error("greet: index out of range");

   return msgs[x];
}

用Python的C API和标准C++来包装这个函敎ͼ�我们需要像�q�样:

extern "C" // 所有Python交互都��用C链接和调用习�?
{
    // 处理参数/�l�果转换和检查的包装�?
    PyObject* greet_wrap(PyObject* args�Q�PyObject * keywords)
    {
         int x;
         if (PyArg_ParseTuple(args�Q?i"�Q?amp;x))    // 取出/���查参�?
         {
             char const* result = greet(x);      // 调用被包装的函数
             return PyString_FromString(result); // �l�果转换成Python
         }
         return 0;                               // 发生了错�?
    }

    // 待包装函数表�Q�函数用�q�个模块来暴�?
    static PyMethodDef methods[] = {
        { "greet"�Q�greet_wrap�Q�METH_VARARGS�Q?return one of 3 parts of a greeting" }
        �Q�{ NULL�Q�NULL�Q?�Q�NULL } // sentinel
    };

    // 模块初始化函�?
    DL_EXPORT init_hello()
    {
        (void) Py_InitModule("hello"�Q�methods); // ��d��成员函数(method)到模�?
    }
}

现在看看我们使用Boost.Python来暴露它时的包装代码:

#include 
using namespace boost::python;
BOOST_PYTHON_MODULE(hello)
{
    def("greet"�Q�greet�Q?return one of 3 parts of a greeting");
}

下面是��用它的代�?

>>> import hello

>>> for x in range(3):
...     print hello.greet(x)
...
hello
Boost.Python
world!

C API版本要冗长的多，此外�Q�一些它没有正确处理的地方值得提到�Q?/p>

原来的函数接受无�W�号整数�Q�Python ‘C�?API仅仅提供了提取有�W�号整数的方式。如果我们试囑֐�hello.greet传递负数Boost.Pyt hon版将抛出Python异常�Q�而Python ‘C�?API版则会��l�像在C++实现中那栯��{换负数到无符��h��(通常包装成某�U�很大的�?�Q�然�?把不正确的�{换结果传�l�被包装函数�?
�q�引起了�W�二个问题：如果函数的参数大�?�Q�C++ greet()被调用时会抛出异常。典型的�Q�如果C++异常跨越C�~�译器生成的代码�?边界传递，会导致崩溃。正如你在第一个版本中看到的，那儿没有C++脚手�?scaffolding)来防止崩溃发生。被Boost.Python包装 �q�的函数自动包含了异常处理层�Q�它把未处理的C++异常��译成相应的Python异常�Q�从而保护了Python用户�?
一个更微妙的限制是�Q�Python ‘C�?API的参数�{换机制只能以一�U�方式取得整数x。如果一个Python long 对象(��L��_�ֺ�整数) ��y可以转换�?fit in)unsigned int而不能�{换成signed long�Q�PyArg_ParseTuple不能对其�q�行转换。同样如果被包装的C++ �c�d��含用户定义的隐式operator unsigned int()转换�Q�它永远不能处理。Boost.Python的动态类型�{换注册表允许用户��L��d�� 转换�Ҏ��?

库概�?/a>

�q�部分简要描�q�C��库的主要�Ҏ��。�ؓ了避免�؜淆，忽略了实现细节�?/p>

暴露�c?Exposing Classes)

C++�c�d��l�构以类似的��z�的接口来暴霌Ӏ�假设有:

struct World
{
    void set(std::string msg) { this->msg = msg; }
    std::string greet() { return msg; }
    std::string msg;
};

下面的代码将在我们的扩展模块里暴露它:

#include 

BOOST_PYTHON_MODULE(hello)
{
    class_("World")
        .def("greet"�Q?amp;World::greet)
        .def("set"�Q?amp;World::set)
    ;
}

��管上述代码有某�U�熟悉的Pythonic的感觉，但语法有时还是有点��o��惑，因�ؓ它看��h��不像��Z��习惯的C++代码。但是，�q�仍然只是标准C++。因为它们灵�zȝ��语法和操作符重蝲�Q�C++和Python都很适于定义特定领域(�?语言( domain-specific (sub)languages) (DSLs)。那��是我们在Boost.Python里所做的。把代码拆开来看:

class_("World")

构造类型class_的未命名对象�Q�把"World"传给它的构造器。这��在扩展模块里创��Z��个叫World的new-style Python�c�，�q�把它和C++�c�d��World在Boost.Python的类型�{换注册表里关联�v来。我们也可以�q�么�?

class_ w("World");

但那样做的话会更�J�琐�Q�因为我们不得不再次命名w以调用它的def()成员函数:

w.def("greet"�Q?amp;World::greet)

原来的例子里表示成员�q�入的点的位�|�没有什么特别的�Q�C++允许��L��的空白符出现在表意符�?token)的�Q一边，把点攑֜�每行的开始允许用�l�一的语法把�q�箋的调用都串�v来，不管我们想串多少都行。另一个允许的串接的事实是class_<>成员函数都返回对*this的引用�?/p>

因此原来的例子等同于:

class_ w("World");
w.def("greet"�Q?amp;World::greet);
w.def("set"�Q?amp;World::set);

能这��h��分Boost.Python�c�d��装层的组成部分有时候是有用的，但本文的剩下部分��一直��用简�z�的语法�?/p>

最后来看包装类被��用的情况:

>>> import hello
>>> planet = hello.World()
>>> planet.set('howdy')
>>> planet.greet()
'howdy'

构造器(Constructors)

因�ؓ我们的World�c�d��是一个简单的struct�Q�它有一个隐式的无参�?no-argument)(nullary)构造器。Boost.Python默认暴露nullary构造器�Q�这��是我们可以像下面这样写的原�?

>>> planet = hello.World()

然而不��哪门语�a��Q�设计得好的�c�d��能都需要构造器参数�Q�以建立他们的不变量(invariants)。在Python里，__init__只是一个特�D�名�U�的成员函数(method)�Q�与�q�不同，C++里的构造器不能像普通成员函数那样处理。特别是我们不能取它的地址: &World::World�q�样会被报错。库提供了一个不同的接口来指定构造器。假设有:

struct World
{
    World(std::string msg); // ��d��的构造器
    ...

我们可以�q�样修改包装代码:

class_("World"�Q�init())
    .def(init())
    ...

当然�Q�C++�c�d��能还有其他的构造器�Q�我们也可以暴露他们�Q�只需要向def()传递更多init<�?gt;的实�?

class ("World"�Q�init())
        .def(init())
        ...

Boost.Python允许被包装的函数�Q�成员函��C��及构造器被重载，以映��C++重蝲�?/p>

数据成员和属�?Properties)

C++中的��M��可公��q��讉K��的数据成员都能轻易的被包装成只读或者只写属�?attributes):

class_("World"�Q�init())
    .def_readonly("msg"�Q?amp;World::msg)
    ...

�q�直接在Python里��?

>>> planet = hello.World('howdy')
>>> planet.msg
'howdy'

�q�不会导致添加属性到World实例__dict__�Q�从而在包装大型数据�l�构时节省大量的内存。实际上�Q�除非从Python昑ּ��d��属性，否则实例__dict__�Ҏ��不会被创建。Python的这�U�能力来源于新的Python 2.2 �c�d��pȝ��Q�尤其是descriptor接口和property�c�d��?/p>

在C++里，可公��q��讉K��的数据成员被认�ؓ是糟�p�设计的表现�Q�因��Z��们破坏了��装(encapsulation)�Q�文体向�?style guides)通常指示代之�?getter" �?"setter"函数。然而在Python里，__getattr__�Q�__setattr__和从2.2开始有的property意味着属性进入只是程序员控制下的��装得更好的语法工具。通过让Python property对用��L��接可用，Boost.Python�q�接了二者的不同惯用语。如果msg是私有的�Q�我们仍然能把它暴露为Python里的属�?

class_("World"�Q�init())
    .add_property("msg"�Q?amp;World::greet�Q?amp;World::set)
    ...

上面的例子映��了��Z��熟悉的Python 2.2+里的property用法:

>>> class World(object):
...     __init__(self�Q�msg):
...         self.__msg = msg
...     def greet(self):
...         return self.__msg
...     def set(self�Q�msg):
...         self.__msg = msg
...     msg = property(greet�Q�set)

操作�W�重�?/a>

能给用户定义�c�d��定义��术操作�W�一直是两门语言的数��D��取得成功一个重要因素。像 Numpy �q�样的��Y件包的成功证明了在扩展模块中暴露操作�W�能产生巨大能量。Boost.Python�l�包装操作符重蝲提供了简�z�的机制。下面是包装Boost的有理数�? rational number library)的代码的片断:

class_ >("rational_int")
  .def(init()) // constructor�Q�e.g. rational_int(3�Q?)
  .def("numerator"�Q?amp;rational::numerator)
  .def("denominator"�Q?amp;rational::denominator)
  .def(-self)        // __neg__ (unary minus)
  .def(self + self)  // __add__ (homogeneous)
  .def(self * self)  // __mul__
  .def(self + int()) // __add__ (heterogenous)
  .def(int() + self) // __radd__

�q�种��法是通过��单的应用"表达式模�?("expression templates") [VELD1995] 来施加的�Q?表达式模�?是一�U�最初�ؓ优化高性能矩阵代数表达式而开发的技术。本质是不立卌��行计��，而重载操作符来构造描�q�计��的�c�d��。在矩阵代数里，当考虑整个表达式的�l�构�Q�而不�?贪婪�?�Ҏ��步操作求值时�Q�经常可以获得戏剧性的优化。Boost.Python用同��L��技术来构徏��Z��包含 self 的表辑ּ�的适当的Python 成员函数对象(method object)�?/p>

�l�承

要在Boost.Python里描�q�C++�l�承关系�Q�可以像下面�q�样把可选的bases<�?gt;参数��d��到class_<�?gt;模板参数表里:

class_ >("Derived")
     ...

�q�样有两个效果：

当class_<�?gt;被创建时�Q�在Boost.Python的注册表里查扑֯�应于Base1和Base2的Python�c�d��对象�Q�然后作为新的Python衍生�c?型对象的基类。因而暴露给Base1和Base2的成员函数自动成��Z��衍生�c�d��的成员。因为注册表是全局的，即��暴露衍生�c�d��的模块和它的��M��基类的模块不同，�l�承同样有效�?
衍生�c�d��基类的C++转换被添加到Boost.Python注册表。因此期待�Q一基类对象(的指针或引用)的被包装C++成员函数可以被包�?了�Q一基类的衍生实例的对象调用。类T的被包装成员函数被视为具有隐式的�W�一个参数T&�Q�那么�ؓ了让衍生对象能调用基�c�L�� 员函敎ͼ��q�些转换是必需的�?

当然从被包装的C++�c�d��例衍生新的Python�c�L��可能的。这是因为Boost.Python使用了new-style class�pȝ��Q�这套系�l�在Python内置�c�d��上工作良好。但有一个重要细节不同： Python内置�c�d��一般在__new__函数里徏立不变量(invariants)�Q�从而衍生类不用在调用它的成员函数前调用基类的__init__:

>>> class L(list):
...      def __init__(self):
...          pass
...
>>> L().reverse()
>>>

因�ؓC++对象构造是一步操�?one-step operation)�Q�直到参数可用C++实例数据才能被构造，在__init__函数�?

>>> class D(SomeBoostPythonClass):
...      def __init__(self):
...          pass
...
>>> D().some_boost_python_method()
Traceback (most recent call last):
  File ""�Q�line 1�Q�in ?
TypeError: bad argument type for built-in operation

发生错误的原因是Boost.Python 在实例D里找不到�c�d��SomeBoostPythonClass的实例数据；D的__init__函数遮盖了基�cȝ��构造函数。可以通过删除D的__init__函数或是让它昑ּ�的调用SomeBoostPythonClass.__init__(�?来纠正错误�?/p>

虚函�?/a>

在Python里从扩展�c�衍生新的类型没太大意思，除非它们在C++里能被多态的使用。换句话��_��当在C++里通过基类指针/引用调用Python成员函数�Ӟ��Python成员函数的实现应该看��h��像是覆盖(override)了C++虚函数的实现。因��改变虚函数的行�ؓ的唯一�Ҏ��是在衍生�c�里覆盖(override)它，用户必须构造一个特�D�的衍生�c�L��分派(dispatch)多态类的虚函数�?

//
// 要包装的接口:
//
class Base
{
 public:
    virtual int f(std::string x) { return 42; }
    virtual ~Base();
};

int calls_f(Base const& b�Q�std::string x) { return b.f(x); }

//
// 包装代码
//

// 分派者类(Dispatcher class)
struct BaseWrap : Base
{
    // 储存指向Python对象的指�?
    BaseWrap(PyObject* self_) : self(self_) {}
    PyObject* self;

    // 当f没有被覆�?override)时的�~�省实现
    int f_default(std::string x) { return this->Base::f(x); }
    // 分派实现
    int f(std::string x) { return call_method(self�Q?f"�Q�x); }
};

...
    def("calls_f"�Q�calls_f);
    class_("Base")
        .def("f"�Q?amp;Base::f�Q?amp;BaseWrap::f_default)
        ;

下面是一些python演示代码:

>>> class Derived(Base):
...     def f(self�Q�s):
...          return len(s)
...
>>> calls_f(Base()�Q?foo')
42
>>> calls_f(Derived()�Q?forty-two')
9

对分�z�者类(Dispatcher class)�Q�要注意:

允许用Python�q�行覆盖(override)的关键因素是call_method调用�Q�它使用了和用来包装C++函数的注册表相同的全局�c�d��转换注册 �?global type conversion registry)�Q�来把参��C��C++转换成Python�Q�把�q�回�c�d��从Python转换成C++
��M��你希望包装的构造器�|�名(signatures)必须有一个的相同的初始PyObject*参数�?
分派者必��M��存这个参��C��便调用call_method时��用�?
当被暴露的函��C��是纯虚函数时�Q�需要f_default成员函数。在�c�d��BaseWrap的对象里�Q�没有其他方式可以调用Base::f�Q�因为它�?覆盖(override)了�?

更深层次的反��即��出�?Deeper Reflection on the Horizon)?

无可否认�Q�重复这�U�公式化的流�E�是冗长乏味的。尤其是��目里有大量多态类的时候。这反映了C++�~�译时内省能力的必然限制:无法枚�D�cȝ��成员来判断哪个是虚函数。不�q�，一个很有希望的��目已经启动�Q�致力于写一个前端程序来从C++头文件自动生成这些分�z�者类(以及其它包装代码)�?/p>

Pyste 是由Bruno da Silva de Oliveira开发的�Q�基�?GCC_XML 构徏。GCC_XML可以生成XML版本的GCC内部�E�序描述。GCC是一�U�高度符�?译注�Q�C++标准)的编译器�Q�从而确保了�Ҏ��复杂的模板代码的正确处理和对底层�c�d��pȝ��的完全访问。和Boost.Python的哲学一��_��Pyste接口描述既不侵入被包装的代码�Q�也不用某种不熟悉的语言来表达，相反�Q�它�?00%的纯Python脚本。如果Pyste成功的话�Q�将标志着我们的很多用户不用再什么都直接用C++包装。它��允许我们选择把一些元�E�序(metaprogram)代码从C++�U�d��到Python。我们期待不久后不仅用户�Q�Boost.Python开发者自�׃��能以混合的思�\来考虑("thinking hybrid")他们自己的代码�?/p>

序列�?Serialization)

序列化是把内存中的对象�{换成可以保存到磁盘上或通过�|�络传送的格式的过�E�。序列化后的对象(最常见的是��单字�W�串)可以被重新取得�ƈ转换回原来的对象。好的序列化�pȝ��能够自动转换整个对象层次(object hierarchies)。Python的标准pickle模块正是�q�样的系�l�。它利用语言强大的运行时内省来序列化几乎是�Q意的用户定义对象。加上一些简单的非��R入限定，�q�种强大的设施可以被扩展成对被包装的C++对象也有效。下面是一个例�?

#include 

struct World
{
    World(std::string a_msg) : msg(a_msg) {}
    std::string greet() const { return msg; }
    std::string msg;
};

#include 
using namespace boost::python;

struct World_picklers : pickle_suite
{
  static tuple
  getinitargs(World const& w) { return make_tuple(w.greet()); }
};

BOOST_PYTHON_MODULE(hello)
{
    class_("World"�Q�init())
        .def("greet"�Q?amp;World::greet)
        .def_pickle(World_picklers())
    ;
}

现在让我们创��Z��个World对象�q�把它放到磁盘上:

>>> import hello
>>> import pickle
>>> a_world = hello.World("howdy")
>>> pickle.dump(a_world�Q�open("my_world"�Q?w"))

在可能不同的计算机的可能不同的操作系�l�的可能不同的脚本中:

>>> import pickle
>>> resurrected_world = pickle.load(open("my_world"�Q?r"))
>>> resurrected_world.greet()
'howdy'

当然也可以用cPickle来获得更快的处理速度�?/p>

Boost.Python的pickle_suite完全支持标准Python文��定义的pickle协议。类似Python里的__getinitargs__函数�Q�pickle_suite的getinitargs()负责创徏参数tuple来重��pickle了的对象。Python pickle协议中的其他元素�Q�__getstate__ 和__setstate__可以通过C++ getstate和setstate函数来可选的提供。C++的静态类型系�l�允许库在编译时��保没有意义的函数组�?例如�Q�没有setstate ��getstate)不会被��用�?/p>

要想序列化更复杂的C++对象需要做比上面的例子�E�微多点的工作。幸�q�的是Object接口(参见下一�?在保持代码便于管理上帮了大忙�?/p>

对象接口(Object interface)

无所不在的PyObject*�Q�手动引用计敎ͼ�需要记住是哪个API调用�q�回�?新的"(自��n拥有�?引用或是"借来�?(原始�?引用�Q�这些可能有�l�验的C语言扩展模块的作者都熟悉。这些约束不仅麻烦，更是错误的主要来源，��其是存在异常的时候�?/p>

Boost.Python提供了一个object�c�，它自动化了引用计数�ƈ提供��L��c�d��的C++对象到Python的�{换。这极大的减��M��未来的扩展模块作者的学习负担�?/p>

从�Q一�c�d��创徏object极度��?

object s("hello�Q�world");   // s ���理一个Python字符�?

object可以和所有其它类型进行模板化的交互，自动的进行到Python的�{换。这一切自然得很容易被忽略不计:

object ten_Os = 10 * s[4]; // -> "oooooooooo"

上面的例子中�Q�在索引和乘法操作被调用前，4�?0被�{换成了Python对象�?/p>

extract�c�L��板可以用来把Python对对象�{换成C++�c�d��:

double x = extract(o);

如果��M��方向的�{换不能执行，��在�q�行时抛��Z��个适当的异常�?/p>

伴随object�c�d��的是一套衍生类型，��可能的映射Python的内�|�类�?list�Q�dict�Q�tuple�{?。这样就能方便的从C++操作�q�些高��c�d��?

dict d;
d["some"] = "thing";
d["lucky_number"] = 13;
list l = d.keys();

�q�看��h��和工作�v来几乎就像是通常的python代码�Q�但它实际上是纯的C++。当然我们能包装接受或返回object实例的函数�?/p>

从�؜合的思�\思�?Thinking hybrid)

因�ؓ�l�合�~�程语言��h��实际的和心理的困难，在进行�Q何实际开发前军_��使用单一的语�a�是普遍现象。对很多应用来说�Q�性能上的考虑军_��了核心算法要用编译语�a�实现。不�q�的是，因�ؓ静态类型系�l�的复杂性，我们��行时性能要付出开发时间大量增长的代�h。经验表明，和开发相应的Python代码比�v来，开发可�l�护的C++代码通常需要更长的旉��和艰隑־�多才能获得的工作�l�验。即使开发者觉得只用一门编译语�a�开发挺好，��Z��用户�Q�他们也�l�常用某�U�类型的特别的脚本层来补充系�l�，哪怕他们永�q�不会得到同��L��好处�?/p>

Boost.Python让我们能 think hybrid 。Python可以用来快速搭建新的应用的原型�Q�在开发能工作的系�l�时�Q�它的易用性和大量的标准库使我们处于领先。需要的话，可以用能工作的代码来扑և�限制速度的热�?rate-limiting hotspots)。�ؓ了最大化性能�Q�这些热点可以用C++来重新实玎ͼ�然后用Boost.Python�l�定来连�q�已有的高��q�程(译注�Q�指Python�E�序)�?/p>

当然�Q�如果一开始就清楚很多��法最后不得不用C++来实玎ͼ��q�种 由顶至下(top-down) 的方法就没那么吸引�h了。幸�q�的是，Boost.Python也允许我们��?由底至上(bottom-up) 的方法。我们非常成功的把这�U�方法用在了一个用于科学应用的工具��p�Y件的开发上。这个工��L��开始主要是一个带Boost.Python�l�定的C++�c�d��Q�接下来有一��段旉��增长主要集中在C++部分�Q�随着工具��变得越来越完整�Q�越来越多新��d��的功能可以用Python来实现�?/p>

上图是实现新的算法时新添加的C++代码和Python代码的估计比率随旉��变化的情��c��我们预计这个比率会辑ֈ�接近70% (Python)。能够主要用Python而不是更困难的静态类型语�a�来解��x��问题�Q�这是我们在Boost.Python上的投入的回报。我们的所有代码都能从Python讉K��Q�这使得更广泛的开发者可以用它来快速开发新的应用�?/p>

开发历�?/a>

Boost.Python的第一版是由Dave Abrahams在Dragon Systems开发的。在那里他非常荣�q�的请到Tim Peters作�ؓ他的"Python之禅"( "The Zen of Python")导师。Dave的工作之一是开发基于Python的自然语�a�处理�pȝ��。因为最�l�要被用于嵌入式��g�Q�系�l�计��密集的内核��L��被假设成要用C++来重写以优化速度和内存需求量(memory footprint) [1] 。这个项目也想用Python��试脚本 [2] 来测试所有的C++代码。当时我们知道的�l�定C++和Python的唯一工具�?SWIG �Q�但那时它处理C++的能力比较弱。要说在那时��对Boost.Python所使用�Ҏ��的可能优��之处有了什么深��L��见，那是骗�h的。Dave对花俏的C++模板技巧的兴趣和娴熟刚好到了能真正做点什么的时候，Boost.Python��那样出��C��Q�因为它满��了需求，因�ؓ它看��h��挺酷�Q�值得一试�?/p>

早期的版本针对的许多基本目标和在�q�篇论文中描�q�的相同。最显著的区别在于早期版本的语法要稍微麻烦一点，�~�Z��Ҏ��作符重蝲�Q�pickling�Q�基于组件的开发的专门支持。后面三个特性很快就被Ullrich Koethe和Ralf Grosse-Kunstleve [3] 加上了。其他热心的贡献�?contributors)也出来�A献了一些改�q�，如对嵌套模块和成员函数的支持�{��?/p>

�?001�q�早期时开发已�l�稳定下来了�Q�很��有新的�Ҏ��添加，然而这时一个烦人的问题暴露出来了：Ralf已经开始在一个��?EDG 前端的编译器的预发布版上��试Boost.Python�Q�这时Boost.Python内核中负责处理Python和C++的类型�{换的机制(mechanism)�~�译��p�|了。结果证明我们一直在利用一个bug�Q�这个bug在所有我们测试过的C++�~�译器实��C��都非常普遍。我们知道随着C++�~�译器很快变得更加标准兼容，库将开始在更多的��^��C��p�|。很不幸�Q�因��套机制是库的功能的中枢，解决问题看�v来非常困难�?/p>

�q�运的是那一�q�的后期�Q�Lawrence Berkeley和后来的Lawrence Livermore National labs�?Boost Consulting �{�订了支持Boost.Python的开发的合同。这样就有了新的��Z��来处理库的基本问题，从而确保将来的发展。重新设计开始于低��c�d��转换架构�Q�内�|�的标准兼容和对��Z��l��g的开发的支持(和不得不昑ּ�的跨��模块边界导入或导出转换的第一版�Ş成对�?。对Python和C++对象的关�p�进行了分析�Q�从而能更直观的处理C++ lvalues和rvalues�?/p>

Python 2.2里出现的强大的新�c�d��pȝ��使得选择是否�l�护对Python 1.5.2的兼�Ҏ��变得容易了�Q�这个丢弃大量精心制作的仅仅用来模拟classic Python�cȝ��代码的机会，好的令�h无法拒绝。另外，Python iterators �?descriptors提供了重要且优雅的工��h��描述�c�M��的C++�l�构。一般化了的对象接口的开发允许我们进一步把C++�E�序员和使用Python C API带来的危险性和语法负担隔离开。大量的其他�Ҏ��在�q�个阶段被加了进来，包括C++异常��译�Q�改�q�的重蝲函数支持�Q�还有最重要的用来处理指针和引用的CallPolicies�?/p>

�?002�q�十月，�W�二版的Boost.Python发布了。那以后的开发集中在改进对C++�q�行时多态和��指针的支持上。特别是Peter Dimov的��y妙的boost::shared_ptr设计使我们能�l��؜和系�l�开发者提供一致的接口�Q�用于跨��语�a�藩篱来回�U�d��对象而不丢失信息�?/p>

刚开始，我们担心Boost.Python v2的复杂性会�ȝ��贡献者，�?Pyste 和几个其他重要特性的贡献(contribution)的出��C�ɘq�些担心昑־�多余了。每天出现在Python C++-sig上的问题和希望得到的改进的积�?backlog)表明了库正在被��用。对我们来说�Q�未来看��h��很光明�?/p>

�l�论

Boost.Python 实现了两�U�功能丰富的优秀的语�a�环境间的无缝协作。因为它利用模板元编�E�技术来对类型和函数�q�行内省�Q�用��h��q�用不着再学�W�三�U�语�a�:接口定义是用��z�而可�l�护的C++写的。同��P��包装�pȝ��不用再解析C++头文件或是描�q�类型系�l�：�~�译器都�l�我们做了�?/p>

计算密集的�Q务适合强大的C++�Q�它一般不可能用纯Python来实现。然而像序列化这��L��工作�Q�可能用Python很简单，用C++��非常困难。假如有从底层开始构建�؜合系�l�的奢侈�Q�我们有新的信心和动力来�q�行设计�?/p>

Squirrel 2006-05-15 15:44 发表评论

Pythonwin VS Eclipse PyDev

Squirrel — Mon, 15 May 2006 07:17:00 GMT
  周末用wxPython + pythonwin写个��应用程序。就Python来说�Q�确实能让�h体会到编�E�的舒畅�Q�但Pythonwin在我机器上面跑得��p��人大失所望了�?br />   同样作�ؓIDE�Q�Pythonwin �?IDLE 有不��o人兴奋的地方�Q�我开始��用Pythonwin也正是由于它的DEBUG环境和别人的推荐。可当我调试�Ӟ��比如�Q�一个程序按两次F5�Q�就出现“Pythonwin.exe 遇到问题需要关闭”，接着��是Runtime Error和内存不能�ؓ诅R��然后必��重启Pythonwin才能用！遇到�q�样的问题，恐怕大多用��L��心理都难以承受�?br />   我后来想起了Eclipse+CDT�Q�那么有Eclipse+PDT么？果然�Q�看到网上有Eclipse+PyDev�?br />   在Eclipse中选择菜单�Q?/font>Help—Software Updates—Find And Install �Q�选择 Search for new features to intall�Q�点 New Remote Site 按钮�Q�输�?http://pydev.sf.net/updates�Q?/font>下蝲�q�安装�?br />   配置旉��要制定Python解释器，选择正确的�\径即可�?br />   然后��可以在Eclipse下开发调试Python�E�序了�?br />

   我也下过BOA�Q�但感觉现在它还有不��缺��P��毕竟才是alpha版。估计等�?.0出来��很��了�?br />   WingIDE 不知道怎么��P��下次��试吧�?/font>

Squirrel 2006-05-15 15:17 发表评论

May it be

Squirrel — Mon, 28 Nov 2005 00:46:00 GMT
May it be an evening star
Shines down upon you
May it be when darkness falls
Your heart will be true
You walk a lonely road
Oh! How far you are from home

Morni? ut�t̔li? (Quenya: Darkness has come)
Believe and you will find your way
Morni? alanti? (Quenya: Darkness has fallen)
A promise lives within you now

May it be the shadow's call
Will fly away
May it be your journey on
To light the day
When the night is overcome
You may rise to find the sun

Morni? ut�t̔li? (Quenya: Darkness has come)
Believe and you will find your way

Morni? alanti? (Quenya: Darkness has fallen)
A promise lives within you now

A promise lives within you now

Squirrel 2005-11-28 08:46 发表评论

欧美成人免费观看,亚洲影院免费观看,国产精品vvv

Windows凭据���理

如此��目���理

�~�程语言发展历程

Windows�?ACE中的地址重用

[转蝲]用Boost.Python构徏混合�pȝ��

Pythonwin VS Eclipse PyDev

May it be

Windows凭据��理

如此��目��理