restrict:
restrict只适用于指针，它声明一个指针是唯一初始化访问一个数据对象。
int ar[10];
int* restrict restar=(int *)malloc(10*sizeof(int));
int* par=ar;
for(int n=0; n<10; n++) {
par[n]+=5;
restar[n]+=5;
ar[n]*=2;
par[n]+=3;
restar[n]+=3;
}
restar指针是restrict类型，par指针就不是，因为par即没有初始化也不是唯一访问ar数组的变量。
那么，上面的程序，因为restar是唯一反问数据块的指针，所以编译器可以对它优化为一条语句，
restar[n] += 8; /* ok replacement */
而par就不可以，
par[n] += 8; / * gives wrong answer */
restrict主要修饰函数的指针参数,或者指向由malloc()分配的内存变量。
restrict不仅仅可以被用来加强编译器的优化，还是解决我们代码中存在的隐患，看下面这个例子：
void f (const int* pci, int *pi;); // is *pci immutable?
{
(*pi)+=1; // not necessarily: n is incremented by 1
*pi = (*pci) + 2; // n is incremented by 2
}
int n;
f( &n, &n);
f( &n, &n);如果对两个参数都使用了restrict关键字，那么这里编译时会报错，因为一个地址可以通过两个指针访问了。
但要注意：restrict是C99中新增的关键字，在C89和C++中都不支持，在gcc中可以通过—std=c99来得到对它的支持。
只摘了几个惯用法：
（1）在C++中引用C语言中的函数和变量，在包含C语言头文件（假设为cExample.h）时，需进行下列处理：
extern "C"
{
#include "cExample.h"
}
而在C语言的头文件中，对其外部函数只能指定为extern类型，C语言中不支持extern "C"声明，在.c文件中包含了extern "C"时会出现编译语法错误。
笔者编写的C++引用C函数例子工程中包含的三个文件的源代码如下：
/* c语言头文件：cExample.h */
#ifndef C_EXAMPLE_H
#define C_EXAMPLE_H
extern int add(int x,int y);
#endif
/* c语言实现文件：cExample.c */
#include "cExample.h"
int add( int x, int y )
{
return x + y;
}
// c++实现文件，调用add：cppFile.cpp
extern "C"
{
#include "cExample.h"
}
int main(int argc, char* argv[])
{
add(2,3);
return 0;
}
如果C++调用一个C语言编写的.DLL时，当包括.DLL的头文件或声明接口函数时，应加extern "C" { }。
（2）在C中引用C++语言中的函数和变量时，C++的头文件需添加extern "C"，但是在C语言中不能直接引用声明了extern "C"的该头文件，应该仅将C文件中将C++中定义的extern "C"函数声明为extern类型。
笔者编写的C引用C++函数例子工程中包含的三个文件的源代码如下：
//C++头文件 cppExample.h
#ifndef CPP_EXAMPLE_H
#define CPP_EXAMPLE_H
extern "C" int add( int x, int y );
#endif
//C++实现文件 cppExample.cpp
#include "cppExample.h"
int add( int x, int y )
{
return x + y;
}
/* C实现文件 cFile.c
/* 这样会编译出错：#include "cExample.h" */
extern int add( int x, int y );
int main( int argc, char* argv[] )
{
add( 2, 3 );
return 0;
}
在用“动态反射”方式调用动态链接库的函数时，
eg:
typedef StubBase * (* func)();
func fun = (func)GetProcAddress(dllhandle,LPCSTR("methodName"));
为了让这种动态反射能够成功，最好在dll的实现代码里面使用extern "C"来修饰。如下：
extern "C"
{
__declspec( dllexport ) StubBase * methodName()
{
StubBase * x = new StubBase();
return x;
}
}
这样做能够保证在动态反射函数地址时，编译器编译函数名的方式是一样的，都按照C语言格式编译。
在讨论全局变量之前我们先要明白几个基本的概念：
1. 编译单元(模块)：
在IDE开发工具大行其道的今天，对于编译的一些概念很多人已经不再清楚了，很多程序员最怕的就是处理连接错误(LINK ERROR), 因为它不像编译错误那样可以给出你程序错误的具体位置，你常常对这种错误感到懊恼，但是如果你经常使用gcc，makefile等工具在linux或者嵌 入式下做开发工作的话，那么你可能非常的理解编译与连接的区别！当在VC这样的开发工具上编写完代码，点击编译按钮准备生成exe文件时，VC其实做了两 步工作，第一步，将每个.cpp(.c)和相应.h文件编译成obj文件；第二步，将工程中所有的obj文件进行LINK生成最终的.exe文件，那么错 误就有可能在两个地方产生，一个是编译时的错误，这个主要是语法错误，另一个是连接错误，主要是重复定义变量等。我们所说的编译单元就是指在编译阶段生成的每个obj文件，一个obj文件就是一个编译单元，也就是说一个cpp(.c)和它相应的.h文件共同组成了一个编译单元，一个工程由很多个编译单元组 成，每个obj文件里包含了变量存储的相对地址等 。
2. 声明与定义的区别
函数或变量在声明时，并没有给它实际的物理内存空间，它有时候可以保证你的程序编译通过， 但是当函数或变量定义的时候，它就在内存中有了实际的物理空间，如果你在编译模块中引用的外部变量没有在整个工程中任何一个地方定义的话， 那么即使它在编译时可以通过，在连接时也会报错，因为程序在内存中找不到这个变量！你也可以这样理解， 对同一个变量或函数的声明可以有多次，而定义只能有一次!
3. extern的作用
extern有两个作用，第一个,当它与"C"一起连用时，如: extern "C" void fun(int a, int b); 则告诉编译器在编译fun这个函数名时按着C的规则去翻译相应的函数名而不是C++的， C++的规则在翻译这个函数名时会把fun这个名字变得面目全非，可能是fun@aBc_int_int#%$也可能是别的，这要看编译器的"脾气"了 (不同的编译器采用的方法不一样)，为什么这么做呢，因为C++支持函数的重载啊，在这里不去过多的论述这个问题，如果你有兴趣可以去网上搜索，相信你可以得到满意的解释!
当extern不与"C"在一起修饰变量或函数时，如在头文件中: extern int g_Int; 它的作用就是声明函数或全局变量的作用范围的关键字，其声明的函数和变量可以在本模块或者其他模块中使用，记住它是一个声明不是定义!也就是说B模块(编译单元)要是引用模块(编译单元)A中定义的全局变量或函数时，它只要包含A模块的头文件即可, 在编译阶段，模块B虽然找不到该函数或变量，但它不会报错，它会在连接时从模块A生成的目标代码中找到此函数。
如果你对以上几个概念已经非常明白的话，那么让我们一起来看以下几种全局变量/常量的使用区别:
1. 用extern修饰的全局变量
以上已经说了extern的作用，下面我们来举个例子,如:
在test1.h中有下列声明:
1 #ifndef TEST1H
2 #define TEST1H
3 extern char g_str[]; // 声明全局变量g_str
4 void fun1();
5 #endif
在test1.cpp中
#include "test1.h"
char g_str[] = "123456"; // 定义全局变量g_str
void fun1()
{
cout << g_str << endl;
}
以上是test1模块， 它的编译和连接都可以通过,如果我们还有test2模块也想使用g_str,只需要在原文件中引用就可以了
#include "test1.h"
void fun2()
{
cout << g_str << endl;
}
以上test1和test2可以同时编译连接通过，如果你感兴趣的话可以用ultraEdit打开test1.obj,你可以在里面着"123456"这个字符串,但是你却不能在test2.obj里面找到，这是因为g_str是整个工程的全局变量，在内存中只存在一份, test2.obj这个编译单元不需要再有一份了，不然会在连接时报告重复定义这个错误!
有些人喜欢把全局变量的声明和定义放在一起，这样可以防止忘记了定义，如把上面test1.h改为
extern char g_str[] = "123456"; // 这个时候相当于没有extern
然后把test1.cpp中的g_str的定义去掉,这个时候再编译连接test1和test2两个模块时，会报连接错误，这是因为你把全局变量 g_str的定义放在了头文件之后，test1.cpp这个模块包含了test1.h所以定义了一次g_str,而 test2.cpp也包含了test1.h所以再一次定义了g_str, 这个时候连接器在连接test1和test2时发现两个g_str。如果你非要把g_str的定义放在test1.h中的话，那么就把test2的代码 中#include "test1.h"去掉 换成:
extern char g_str[];
void fun2()
{
cout << g_str << endl;
}
extern不需要include!!!
这个时候编译器就知道g_str是引自于外部的一个编译模块了，不会在本模块中再重复定义一个出来，但是我想说这样做非常糟糕，因为你由于无法在 test2.cpp中使用#include "test1.h", 那么test1.h中声明的其他函数你也无法使用了，除非也用都用extern修饰，这样的话你光声明的函数就要一大串，而且头文件的作用就是要给外部提供接口使用的，所以请记住， 只在头文件中做声明，真理总是这么简单。
2. 用static修饰的全局变量
首先，我要告诉你static与extern是一对“水火不容”的家伙，也就是说extern和static不能同时修饰一个变量；其次，static修饰的全局变量声明与定义同时进行，也就是说当你在头文件中使用static声明了全局变量后，它也同时被定义了；最后，static修饰全局变量的作用域只能是本身的编译单元，也就是说它的“全局”只对本编译单元有效，其他编译单元则看不到它,如:
test1.h:
#ifndef TEST1H
#define TEST1H
static char g_str[] = "123456";
void fun1();
#endif
test1.cpp:
#include "test1.h"
void fun1()
{
cout << g_str << endl;
}
test2.cpp
#include "test1.h"
void fun2()
{
cout << g_str << endl;
}
以上两个编译单元可以连接成功, 当你打开test1.obj时，你可以在它里面找到字符串"123456", 同时你也可以在test2.obj中找到它们，它们之所以可以连接成功而没有报重复定义的错误是因为虽然它们有相同的内容，但是存储的物理地址并不一样， 就像是两个不同变量赋了相同的值一样，而这两个变量分别作用于它们各自的编译单元。
也许你比较较真，自己偷偷的跟踪调试上面的代码,结果你发现两个编译单元（test1, test2）的g_str的内存地址相同，于是你下结论static修饰的变量也可以作用于其他模块，但是我要告诉你，那是你的编译器在欺骗你，大多数编译器都对代码都有优化功能，以达到生成的目标程序更节省内存，执行效率更高，当编译器在连接各个编译单元的时候，它会把相同内容的内存只拷贝一份，比如上面的"123456", 位于两个编译单元中的变量都是同样的内容，那么在连接的时候它在内存中就只会存在一份了， 如果你把上面的代码改成下面的样子，你马上就可以拆穿编译器的谎言:
test1.cpp:
#include "test1.h"
void fun1()
{
g_str[0] = 'a';
cout << g_str << endl;
}
test2.cpp
#include "test1.h"
void fun2()
{
cout << g_str << endl;
}
void main()
{
fun1(); // a23456
fun2(); // 123456
}
这个时候你在跟踪代码时，就会发现两个编译单元中的g_str地址并不相同，因为你在一处修改了它，所以编译器被强行的恢复内存的原貌，在内存中存在了两份拷贝给两个模块中的变量使用。正是因为static有以上的特性，所以一般定义static全局变量时，都把它放在原文件中而不是头文件，这样就不会给其他模块造成不必要的信息污染，同样记住这个原则吧！
3.const修饰的全局常量
const修饰的全局常量用途很广，比如软件中的错误信息字符串都是用全局常量来定义的。const修饰的全局常量具有跟static相同的特性(有条件的，感谢sswv的提醒，const放在只读静态存储区)，即它们只能作用于本编译模块中，但是const可以与extern连用来声明该常量可以作用于其他编译模块中, 如：
extern const char g_str[];
然后在原文件中别忘了定义:
const char g_str[] = "123456";
所以当const单独使用时它就与static相同，（前提是都在描述全局变量，如果在函数内部就不一样）而当与extern一起合作的时候，它的特性就跟extern的一样了！所以对const我没有什么可以过多的描述，我只是想提醒你，const char* g_str = "123456" 与 const char g_str[] = "123465"是不同的， 前面那个const 修饰的是char * 而不是g_str,它的g_str并不是常量，它被看做是一个定义了的全局变量（可以被其他编译单元使用）， 所以如果你像让char *g_str遵守const的全局常量的规则，最好这么定义const char* const g_str="123456"。
转载地址：http://hi.baidu.com/bwandmff/blog/item/56876b30a31d519da9018e9a.html
今天编程练习Linux下的read()和write()函数，无意发现通过gedit输入的文本文件都会多出一个字符，输出原来是换行符“LF”。而通过编程输入的则没有，且gedit能正常显示。在gedit中没有找到相关设置可以去掉这个“LF”。查资料发现好像vim也有这个问题，不知道有没有插件能解决的。
在CSDN上看到一个帖子说“unix 以行为单位”，可能这就是原因吧。
至于解决，实在不习惯就换个编辑器吧。我现在用Geany,可以通过设置去掉“LF”：把“编辑”->“首选项”->“文件”->“保存文件”->“确保文件为有一个新行”勾掉就可以了。
今天想在Ubuntu上用open()实现检测文件是否存在，若存在就read()的功能，代码如下：
int fd=open(temp,O_RDONLY|O_CREAT|O_EXCL,S_IRWXU);
if(-1==fd)
return -2;
ssize_t nbytesRead = read(fd, buffer, count);
close(fd);
结果失败了，错误为“Bad file descriptor”。原因在于O_CREAT和O_RDONLY的矛盾，create的新文件还没写又怎么读呢？create需要写权限。
之所以想到用open()检测文件是否存在，因为在open()的参数描述中：
“O_EXCL 如果O_CREAT 也被设置，此指令会去检查文件是否存在。文件若不存在则建立该文件，否则将导致打开文件错误。此外，若O_CREAT与O_EXCL同时设置，并且欲打开的文件为符号连接，则会打开文件失败。”
我同时指定了O_EXCL和O_CREAT，实际的结果是：open()确实返回了-1(失败),但同时也创建了文件。这不是我想要的效果。
检测文件是否存在，我找到另一个函数替代：access()，只要包含<stdio.h>就可以了。
定义
单件模式是一种用于确保整个应用程序中只有一个类实例且这个实例所占资源在整个应用程序中是共享的程序设计方法（根据实际情况，可能需要几个类实例）。在某些情况下，这种程序设计方法是很有用处的。
单件模式应该使用在什么场合
当需要控制一个类的实例数量且调用者可以从一个公共的众所周知的访问点访问时。
单件模式类的创建
我们分两种方式来讨论一个单件类的创建，一是将一个类的公共构造函数改为私有，另一种方式是保留类的公共构造函数，通过一个静态成员来决定是否要返回一个类实例。
应用
顾名思义，Singleton就是确保一个类只有唯一的一个实例。Singleton主要用于对象的创建，这意味着，如果某个类采用了Singleton模式，则在这个类被创建后，它将有且仅有一个实例可供访问。很多时候我们都会需要Singleton模式，最常见的比如我们希望整个应用程序中只有一个连接数据库的Connection实例；又比如要求一个应用程序中只存在某个用户数据结构的唯一实例。我们都可以通过应用Singleton模式达到目的。
为什么不使用全局对象
一眼看去，Singleton似乎有些像全局对象。但是实际上，并不能用全局对象代替Singleton模式，这是因为：其一，大量使用全局对象会使得程序质量降低，而且有些编程语言例如C#，根本就不支持全局变量。其二，全局对象的方法并不能阻止人们将一个类实例化多次：除了类的全局实例外，开发人员仍然可以通过类的构造函数创建类的多个局部实例。而Singleton模式则通过从根本上控制类的创建，将"保证只有一个实例"这个任务交给了类本身，开发人员不可能再有其它途径得到类的多个实例。这一点是全局对象方法与Singleton模式的根本区别。
Singleton模式的实现要点
- 不直接用类的构造函数，而另外提供一个Public的静态方法来构造类的实例。通常这个方法取名为Instance。Public保证了它的全局可见性，静态方法保证了不会创建出多余的实例。
- 将类的构造函数设为Private，即将构造函数"隐藏"起来，任何企图使用构造函数创建实例的方法都将报错。这样就阻止了开发人员绕过上面的Instance方法直接创建类的实例。
李林老师的例子
头文件:
1 class CLLog
2 {
3 public:
4 static CLLog* GetInstance();
5
6 private:
7 CLLog(const CLLog&);//复制构造函数
8 CLLog& operator=(const CLLog&);//"="操作符
9
10 CLLog();
11 virtual ~CLLog();
12
13 int m_Fd;//记录文件描述符
14 static CLLog *m_pLog;
15 };
实现文件:
1 CLLog* CLLog::m_pLog = 0;//静态成员初始化
2
3 CLLog::CLLog()
4 {
5 m_Fd = open(LOG_FILE_NAME, O_RDWR | O_CREAT | O_APPEND, S_IRUSR);
6 }
7
8 CLLog::~CLLog()
9 {
10 if(m_Fd != -1)
11 close(m_Fd);//析构时关闭文件
12
13 if(m_pLog != 0)
14 delete m_pLog;//释放业务对象占用的资源
15 }
16
17 CLLog* CLLog::GetInstance()
18 {
19 if(m_pLog == 0)
20 {
21 m_pLog = new CLLog;
22 }
23 return m_pLog;
24 }
一点自己的理解，这个类可以分为两部分来看：一部分对外表现出静态(static)特性，负责类的初始化、内部业务对象的创建、释放等管理工作；另一部分就是内部业务对象，它是这个类提供的业务逻辑的实际执行者。