1. 如果 C++ 链接库的计算很耗时，一定要在 C# 客户端里开一个线程来处理，否则容易造成死机，这和 MFC 之类的原理一样。
2. 为了测试你从 C# 链接 C++ 链接库是否成功，可以用 C# 新建一个命令行工程专门测试，用这种方式来测试更加直接与有效。

最近在用 Boost 库写多线程程序时，需要启动若干个线程，这些线程分别处理不同的事情，线程会获取一个字符串参数，用来标识内容。在编写代码的时候，出现了一个很怪异的现象，例子代码如下：

const int tNum = 4;//并发线程数
vector<boost::thread*> tBox;

for (int i=0; i < tNum; i++ )
{
    char strThread[20];
    sprintf(strThread, "thread%d",i);
    //strThread 字符串是传入的 const char* 类型
    boost::thread* thread_0 = new boost::thread( StreamProcesser,
                                                 param1,
                                                 param2,
                                                 strThread);

    tBox.push_back(thread_0);

    boost::xtime xt;
    boost::xtime_get(&xt, boost::TIME_UTC);
    xt.sec += 2;
    boost::thread::sleep(xt);
}

for (int i=0; i < tNum; i++ )
{
    boost::thread* thread_0 = tBox[i];
    thread_0->join();
    delete thread_0;
}

在线程函数启动参数中，有一个参数是 const char* 类型。如果我在线程中，没有先对 char 字符串拷贝一个副本，则当4个线程都跑起来后，再去读取这个参数，很有可能会读到同一个字符串。

这是因为编译器把 strThread 的地址编码为同一个内存地址造成的，所以，所有的线程读取的都是最后一次设置 strThread 的值。

结论：

1. 传入 char* 后，一定要对 char 字符串拷贝一个副本，否则这个指针指向的内容很有可能被改变；
2. 多用 C++ 的 string，少用 char 或是 char*，用值拷贝的方式比单纯传递一个指针要更安全；
3. 最安全的做法，应该是动态分配一个空间，用来保存传递给线程的参数值，在线程结束后再销毁该值。

同样，如果传入参数是整型或是其它类型的时候，也会有上述类似的问题。拿 Win32 的 CreateThread 函数来说，同样需要保证传入的参数不被修改，例如下面的代码就非常危险：

DWORD WINAPI CloseThreadFun( LPVOID param)
{
    int* pHandle = (int*)param;
    const int handle = *pHandle;

    //打印句柄
    printf("get handle is %d", handle);

    return 0;
}

int _tmain(int argc, _TCHAR* argv[])
{
    const int THREAD_NUM = 4;

    HANDLE* lphandle = new HANDLE[THREAD_NUM];
    for (int j = 0; j < THREAD_NUM; j++)
    {
        HANDLE hthread;
        hthread = CreateThread(NULL, 0, CloseThreadFun, (LPVOID)&j, 0, NULL);
        lphandle[j] = hthread;
    }

    WaitForMultipleObjects(THREAD_NUM, lphandle, TRUE, INFINITE);

    delete [] lphandle;

    return 0;
}

在调用 CloseThreadFun 来启动一个线程后，j 的值很有可能已经被修改掉了：线程启动总是需要时间的，而参数指针指向地址的内容，很有可能在此期间被修改了。比如，上面的代码，运行后，打印的内容如下：

get handle is 3
get handle is 4
get handle is 4
get handle is 4

这就说明了 j 值被重复修改后，会导致线程参数不对的现象。

解决办法：用一个 int 数组把需要传入到各个线程的参数缓存起来，尽量保证地址不一样。

传入线程的参数，应该尽量采用动态分配内存的方式来生成。否则如果采用临时变量，则随着变量生命周期的消逝，该变量的指针，很有可能会变成一个毫无意义的指针（或是被新的值覆盖，或是被成为一个遗留数）。

采用动态分配的变量作为线程启动时的参数，在线程结束后再销毁这个动态分配的变量，则是一个安全法则。

Visual Studio 会自动在源代码里添加

#pragma once

这个指令，在 Linux Gcc 编译器下应该怎么样处理类似的情况呢？

维基百科上有一个权威说法：

http://en.wikipedia.org/wiki/Pragma_once

所以，在编写跨平台的 C++ 代码时，最好使用下面这种方式来获得跨平台的特性：

#pragma once
#ifndef GRANDFATHER_H
#define GRANDFATHER_H

struct foo
{
    int member;
};

#endif /* GRANDFATHER_H */

Windows 下使用 __declspec(dllexport) 来标明一个动态链接库的函数接口，而在 Linux 下，则完全没有这个必要。

这个时候，如果动态链接库代码需要跨平台，应该怎么处理呢？

你可以用如下宏来进行区分：

#ifdef WIN32
#define EXPORT_XX __declspec(dllexport)
#else
#define EXPORT_XX
#endif

源代码的编码格式，最好统一用 GBK 或是 UTF-8，以避免不同编码器之间转换造成的乱码。

Windows 里 include 一个头文件，你的大小写可以随便写。但是在 Linux 上，你得小心了，clsssa.h 你不能写成

#include "ClassA.h"

因为在 Linux 上，文件及目录名是大小写敏感的。

Windows 处理宽字符集与窄字符集采用的方法，是用宏定义来区分。比如说 TCHAR 在不同的工程下，属于不同的类型。

而在 Linux 下，则需要注意这些问题。为了让你的代码可移植性强。一定要少用 BOOL, TCHAR 这些类型，而要用原生态的 C/C++ 类型，比如说 bool, char 等。

默认情况下，Visual Studio 新建的 Win32 Console 工程，全是类似于这样的。

int _tmain(int argc, _TCHAR* argv[])
{
}

这些代码，移植到 Linux 下面，就需要我们自己做一部分工作。

如果你在 Visual Studio 用的是 Unicode 编码的，则对应的 Linux 代码应该是另外一套。我则是用宏裁剪了两个主函数出来。如果你有什么更好的方法，可以跟我分享。

虽然你的程序可能依赖大量的跨平台库，这些库号称是跨平台的，但是很有可能在不同的平台的表现，会有所不同。例如，log4cxx 在 Linux 和 Windows 下就会有字符集设置的差别。

你在编写跨平台代码的时候，就应该特别小心这些库的细微差别，及时调整。

以上是一些跨平台 C/C++ 代码编写的经验，备忘一下，也希望对大家有用。

首先从官方网站下载开发包，再解压到你喜欢的目录，Java 的东西就是方便呀！

注意，Jetty 还分好几种包，Jetty@eclipse、Jetty@codehaus 是比较常见的，内容应该差不多，应该只是镜像罢了。

Java 开发中使用第三方库的时候，就需要把该库添加到工程里。Jetty 的库文件，全部在解压目录的 lib 目录下，比如说，在我这里就是

D:\eclipse\jetty-hightide-8.0.4.v20111024\lib

目录。在 Eclipse 里新建一个 Java 工程，同时，在工程上点右键，弹出的菜单里，选择”Properties”，打开工程属性对话框，进行如下操作：

在 “Java Build Path” ==> “Libraries” 选项卡里，选择 “Add External JARs” 按钮，然后切换到 Jetty 目录里的 lib 目录，把所有的 jar 包都添加到工程里。

现在，我们可以用最简单的例子来启动一个 Jetty 内嵌网页服务器，但是这个代码，只可以获得一个 404 错误。不过没有关系，这起码可以证明 Jetty Server is Ready！

相比于上面这个 404 错误的例子，相信你会更喜欢下面这个 HelloWorld 例子：

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.ServletException;

import java.io.IOException;

import org.eclipse.jetty.server.Server;
import org.eclipse.jetty.server.Request;
import org.eclipse.jetty.server.handler.AbstractHandler;

public class HelloWorld extends AbstractHandler
{
    public void handle(String target,
                       Request baseRequest,
                       HttpServletRequest request,
                       HttpServletResponse response)
        throws IOException, ServletException
    {
        response.setContentType("text/html;charset=utf-8");
        response.setStatus(HttpServletResponse.SC_OK);
        baseRequest.setHandled(true);
        response.getWriter().println("<h1>Hello World</h1>");
    }

    public static void main(String[] args) throws Exception
    {
        Server server = new Server(8080);
        server.setHandler(new HelloWorld());

        server.start();
        server.join();
    }
}

如果需要在 Java 工程里进行 Embeded Server 开发，也可以把 Jetty 的库目录包含到 CLASSPATH 环境变量里。事实上，只要能找到下面几个文件就可以了：

servlet-api-3.0.jar
jetty-util-8.0.4.v20111024.jar
jetty-8.x.jar

手册上是这样写的，不过最后一个 jetty-8.x.jar 文件，我没有找到。

你可以在一个 org 文件的开头，用下面的设置来关闭这个功能。

#+OPTIONS: ^:nil

如果你需要更方便的设置，可以把上面这个改为

#+OPTIONS: ^:{}

这样，当你写

a_{b}

时，_ 后被 {} 括起来的内容就会被转义，而写 a_b 时，就按普通的方式来显示。

如果你是用 org sites 来写笔记，想让某个 site 的所有 org 文件不转义 _ 字符，则也可以直接在 org sites 配置文件里，配置下面这么一句，一了百了：

(setq org-export-with-sub-superscripts nil)

也可以在 org sites 里设置这个属性，只作用于某一个 site：

:sub-superscript nil

如果需要像上面一样，采用相对智能的 {} 方式，可以设置成

:sub-superscript {}

或是直接用 elisp 来设置全局的属性：

(setq org-export-with-sub-superscripts '{})

这样就会用 {} 来转义了。