昨天下午安装上了Doxygen和Graphviz，并花了一晚上时间看了看文档，基本学会使用。用Doxygen结合Graphviz生成的文档比较清晰，带有类和函数的关系图。

    现将Doxygen在VS.NET 2005 下的配置过程记录如下：

假设Doxygen安装在c:\program files\doxygen\
     Graphviz安装在c:\Program Files\Graphviz\

在VS.NET 2005“工具”菜单下添加外部工具“Doxygen文档自动生成“，参数如下:
    命令:       c:\program files\doxygen\bin\doxygen.exe （即Doxygen的安装目录）
    命令参数：$(ProjectDir)Doxyfile （注意$(ProjectDir)和Doxyfile之间没有斜线\）
    初始目录: $(ProjectDir)
    选中"使用输出窗口"，使doxygen的输出在VS.NET的输出窗中显示。

对于每个VS工程(Project)
    使用向导doxywizard.exe生成配置文件Doxyfile 
    在向导中将Destination Directory设置成 .\Doc [可选]
    将Doxyfile文件拷贝到对应的工程目录下($(projectdir))
    如果要生成图形化的文档，请设置配置文件中的
        HAVE_DOT = YES
        DOT_PATH = "c:\Program Files\Graphviz\bin"
    如果需要更详细的配置可编辑Doxyfile文件

    点击VS.NET 2005“工具”菜单下的“Doxygen文档自动生成“，就在项目的\Doc目录下生成图文并貌的文档了。是不是很有成就感？

参考：
    10 Minutes to document your code

DOC++和Doxygen是两个类似于JavaDoc的文档生成工具。

DOC++

DOC++ is a documentation system for C, C++, IDL and Java generating both TeX output for high quality hardcopies and HTML output for sophisticated online browsing of your documentation. The documentation is extracted directly from the C/C++/IDL header/source files or Java class files.

Here is a short list of highlights:

hierarchically structured documentation
automatic class graph generation (as Java applets for HTML)
cross references
high end formatting support including typesetting of equations

It is known to work on Linux, Solaris, AIX, HP/UX, IRIX, OSF, Unixware, FreeBSD and BeOS, but should work without any modifications on other UNIXes too, because it uses "autoconf"/"automake" configuration scripts, which ensure a high portability degree. It also works on Windows 95, 98, 2000, XP and NT.

链接： 
http://docpp.sourceforge.net/

Doxyen

Doxygen is a documentation system for C++, C, Java, Objective-C, Python, IDL (Corba and Microsoft flavors), Fortran, VHDL, PHP, C#, and to some extend D.

It can help you in three ways:

1. It can generate an on-line documentation browser (in HTML) and/or an off-line reference manual (in ) from a set of documented source files. There is also support for generating output in RTF (MS-Word), PostScript, hyperlinked PDF, compressed HTML, and Unix man pages. The documentation is extracted directly from the sources, which makes it much easier to keep the documentation consistent with the source code. 
2. You can configure doxygen to extract the code structure from undocumented source files. This is very useful to quickly find your way in large source distributions. You can also visualize the relations between the various elements by means of include dependency graphs, inheritance diagrams, and collaboration diagrams, which are all generated automatically. 
3. You can even `abuse' doxygen for creating normal documentation.

Doxygen is developed under Linux and Mac OS X, but is set-up to be highly portable. As a result, it runs on most other Unix flavors as well. Furthermore, executables for Windows are available.

链接： 
    http://www.doxygen.org/
    http://www.stack.nl/~dimitri/doxygen/

    Unicode（统一码、万国码、单一码）是一种在计算机上使用的字符编码。它为每种语言中的每个字符设定了统一并且唯一的二进制编码，以满足跨语言、跨平台进行文本转换、处理的要求。
    Unicode编码系统可分为编码方式和实现方式两个层次：

编码方式
    Unicode的编码方式与ISO 10646的通用字元集(亦称通用字符集，Universal Character Set，UCS）概念相对应。目前的用于实用的Unicode版本对应于UCS-2，使用16位的编码空间。也就是每个字符占用2个字节。这样理论上一共最多可以表示65,536(2的16次方)个字符。基本满足各种语言的使用。实际上目前版本的Unicode尚未填充满这16位编码，保留了大量空间作为特殊使用或将来扩展。
    上述16位Unicode字符构成基本多文种平面（Basic Multilingual Plane, 简称 BMP）。最新（但未实际广泛使用）的Unicode版本定义了16个辅助平面，两者合起来至少需要占据21位的编码空间，比3字节略少。但事实上辅助平面字符仍然占用4字节编码空间，与UCS-4保持一致。未来版本会扩充到ISO 10646-1实现级别3，即涵盖 UCS-4的所有字符。UCS-4是一个更大的尚未填充完全的31位字符集，加上恒为0的首位，共需占据32位，即4字节。理论上最多能表示 2,147,483,648(2的31次方)个字符，完全可以涵盖一切语言所用的符号。
    BMP字符的Unicode编码表示为U+hhhh，其中每个h代表一个十六进制数位。与UCS-2编码完全相同，对应的4字节UCS-4编码后两个字节一致，前两个字节的所有位均为0。

实现方式
    Unicode的实现方式不同于编码方式。一个字符的Unicode编码是确定的。但是在实际传输过程中，由于不同系统平台的设计不一定一致，以及出于节省空间的目的，对Unicode编码的实现方式有所不同。Unicode的实现方式称为Unicode转换格式（Unicode Translation Format，简称为UTF）。
    例如，如果一个仅包含基本7位ASCII字符的Unicode文件，如果每个字符都使用2字节的原Unicode编码传输，其第一字节的8位始终为0。这就造成了比较大的浪费。对于这种情况，可以使用UTF-8编码，这是一种变长编码，它将基本7位ASCII字符仍用7位编码表示，占用一个字节（首位补0）。而遇到与其他Unicode字符混合的情况，将按一定算法转换，每个字符使用1-3个字节编码，并利用首位为0或1进行识别。这样对以7位ASCII字符为主的西文文档就大大节省了编码长度。类似的，对未来会出现的需要4个字节的辅助平面字符和其他UCS-4扩充字符，2字节编码的UTF-16也需要通过一定的算法进行转换。
    再如，如果直接使用与Unicode编码一致（仅限于 BMP 字符）的UTF-16编码，由于每个址都不相同，Macintosh机和PC机上对字节顺序的理解是不一致的。这时同一字节流可能会被解释为不同内容，如编码为U+594E的字符“奎”同编码为U+4E59的“乙”就可能发生混淆。于是在 UTF-16 编码实现方式中使用了大尾序（big-endian）、小尾序（little-endian）的概念，以及BOM（Byte Order Mark）解决方案。
    此外Unicode的实现方式还包括 UTF-7、Punycode、CESU-8、SCSU、UTF-32等，这些实现方式有些仅在一定的国家和地区使用，有些则属于未来的规划方式。目前通用的实现方式是 UTF-16小尾序（BOM）、UTF-16大尾序（BOM）和 UTF-8。在微软公司Windows XP操作系统附带的记事本中，“另存为”对话框可以选择的四种编码方式除去非Unicode编码的 ANSI 外，其余三种“Unicode”、“Unicode big endian”和“UTF-8”即分别对应这三种实现方式。
    目前辅助平面的工作主要集中在第二和第三平面的中日韩统一表意文字中，因此包括GBK、GB18030、Big5等简体中文、正体中文、日文、韩语以及越南字喃的各种编码与Unicode的协调性被重点关注。考虑到Unicode最终要涵盖所有的字符，从某种意义而言，这些编码方式也可视作Unicode的出现于其之前的既成事实的实现方式，如同ASCII及其扩展Latin-1一样，后两者的字符在16位Unicode编码空间中的编码第一字节各位全为0，第二字节编码与原编码完全一致。但上述东亚语言编码与 Unicode 编码的对应关系要复杂得多。

参考：
百度百科--UNICODE

    C语言原本是在英文环境中设计的，主要的字符集是7位的ASCII码，8位的byte（字节）是最常见的字符编码单位。但是国际化软件必须能够表示不同的字符，而这些字符数量庞大，无法使用一个字节编码。
    C95标准化了两种表示大型字符集的方法：宽字符（wide character，该字符集内每个字符使用相同的位长）以及多字节字符（multibyte character，每个字符可以是一到多个字节不等，而某个字节序列的字符值由字符串或流（stream）所在的环境背景决定）。
    自从1994年的增补之后，C语言不只提供char类型，还提供wchar_t类型（宽字符），此类型定义在stddef.h 头文件中。wchar_t指定的宽字节类型足以表示某个实现版本扩展字符集的任何元素。
    在多字节字符集中，每个字符的编码宽度都不等，可以是一个字节，也可以是多个字节。源代码字符集和运行字符集都可能包含多字节字符。多字节字符可以被用于字符的常量、字符串字面值（string literal）、标识符（identifier）、注释（comment），以及头文件。
    C语言本身并没有定义或指定任何编码集合，或任何字符集（基本源代码字符集和基本运行字符集除外），而是由其实现指定如何编码宽字符，以及要支持什么类型的多字节字符编码机制。
    虽然C标准没有支持Unicode字符集，但是许多实现版本使用Unicode转换格式UTF-16和UTF-32（参考http://www.unicode.org）来处理宽字符。如果遵循Unicode标准，wchar_t类型至少是16或32位长，而wchar_t类型的一个值就代表一个Unicode字符。
    UTF-8是一个由Unicode Consortium（万国码联盟）定义的实现，可以表示Unicode字符集的所有字符。UTF-8字符所使用的空间大小从一个字节到四个字节都有可能。
    多字节字符和宽字符（也就是wchar_t）的主要差异在于宽字符占用的字节数目都一样，而多字节字符的字节数目不等，这样的表示方式使得多字节字符串比宽字符串更难处理。比方说，即使字符'A'可以用一个字节来表示，但是要在多字节的字符串中找到此字符，就不能使用简单的字节比对，因为即使在某个位置找到相符合的字节，此字节也不见得是一个字符，它可能是另一个不同字符的一部分。然而，多字节字符相当适合用来将文字存储成文件。
    C提供了一些标准函数，可以将多字节字符转换为wchar_t，或将宽字符转换为多字节字符。比方说，如果C 编译器使用Unicode 标准的UTF-16 和UTF-8，那么下面调用wctomb()函数就可以获得字符的多字节表示方式（注：wctomb = wide character to multibyte）。

参考：
[1] C in a Nutshell, Peter Prinz, Tony Crawford
[2] A Reference Manual, 5ed, Samuel P. Harbison III, Guy L. Steele Jr.

    如题。

    最近想写个算法并评估一下运行效率，打算用标准C来实现。

    其实从程序设计的角度来看，还是用C++更方便一些。但是C++提供的各种高级功能，如封装、继承、多态等面向对象技术，隐藏了许多底层的细节，不利于对于算法本身的优劣做评估。偶以为用C语言来评估算法是最简单和直接的。

    但我发现好久没用纯C写程序了，还真有些生疏了。从去年做项目开始，就一直用C++写程序，现在又用C#写程序。它们的抽像级别越来越高，IDE环境做得也越来越友好，编译出错输出的信息也越来越清晰。今天用C语言写了一个小程序，在VS2005下编译竟然出错，提示 ，我看着这么几行的小程序就傻了眼，怎么也找不出哪个地方错了。无耐之下我把编译器改为C++编译模式，发现一切正常，连个警告都没有。后来我仔细想了想才知道错在哪里，原来是有个变量定义的位置不对。C语言强制变量在函数或语句块的一开始就定义，而C++F却允许随用随定义，所以才出现C编译器编译出错而C++编译器却能编译通过的情况。

    重新审视C语言，拿出买来已久的 C A Reference Manual 翻了翻，发现C++和C还是有不少不一致的地方的。看来我又得好好地用用C语言了。以后写C程序尽量能同时符合C和C++标准，既所谓的Clean C程序。

    最近在研究共享存储模型下的并行程序设计，找了一些书籍和相关资料来看，重点看了OpenMp官方标准2.5版。

    OpenMP是共享存储模型下并行程序设计这一领域最为流行的一个标准，它是一个跨平台、跨编译器、高可移植性的方案，而且现在已被大多数主流厂商所支持并实现。

    OpenMp规范包括三个方面：编译器制导语句(Compiler Directives)、运行库(Runtime Library Routions)、环境变量(Environment)。OpenMP依赖用户指定编译器和运行时系统的操作以实现程序的并行运行。OpenMP兼容的实现不要求对依赖性、冲突、死锁、竞争和程序不确定性导致的问题进行检测。用户必须自己保证应用程序的正确性。

    OpenMP API采用分支-合并(fork-join)模型来实现并行执行。OpenMP程序执行时的初始线程是串行执行的。当一个线程遇到一个并行结构(parallel construct)时，这个线程将创建一个包含自身在内的线程组(team)，并且自己变成这个线程组的主线程(master thread)。这个新的线程组中的所有线程执行这个并行结构中的代码。在这个并行结构的最后隐含有一个屏障(barrier)。只有主线程才能执行并行结构以后的代码。一个程序中可以指定任意数目的并行结构，并且允许嵌套。

    OpenMP提供一个松一致性(relaxed-consistency)，共享内存(shared-memory)的模型。所有的OpenMP线程可以检索或存储主存中的变量。另外，每个线程允许有自己对主存的临时视图(temporary view)。临时视图并不是OpenMP内存模型所必须的，但这个概念可以表示多种实际中可能介入在线程与主存之间的结构，例如寄存器、缓存或者其它的局部存储器等。临时视图允许线程缓存变量而不必每次都访问主存。

    parallel制导语句可以决定相关并行结构中变量的可访问性，变量可以是共享的(shared)和私有的(private)。并行结构中访问的共享变量和并行结构外的原始的共享变量是同一个版本。而对于私有变量，每个参予该并行结构的线程(除了该线程组的主线程)都将在主存中复制一个该变量的副本。对于私有变量的访问，都是对当前线程中该变量的私有版本进行访问。   

    内存模型之所以具有松一致性是因为于每个线程的临时视图并不总是与主存一致。如果多个线程在没有同步机制的情况下修改和检索同一个变量，则产生的结果是未知的。OpenMP的刷新操作(flush opteration)强制临时视图与主存保持一制性。

    新学期又开始了，我在这个学期的打算很多，希望都能一步一步地去实施。文章要写，要学的东西还很多。下个学期就要找工作了，所以要多多做些准备。

    当然，身体更要锻炼好。这不昨天刚在黑俊马办了一张健身卡，准备重操旧业呢。不过以后去健身房一定要掌握好时间，每次要速战速决，不能拖泥带水，做到用最少的时间起到最好的效果。

    给自己加油！！！