可冰

将语法作以下修改就好了。

rule<> group, factor, term, expression, integer;

group = * space_p >> '(' >> expression >> * space_p >> ')' >> * space_p;
integer = * space_p >> int_p[Push()] >> * space_p;
factor = integer | group;
term = factor
>> *( (* space_p >> '*' >> factor) [&mul2]
| (* space_p >> '/' >> factor) [&div2] )
;
expression = term
>> *( (* space_p >> '+' >> term) [&add2]
| (* space_p >> '-' >> term) [&sub2] )
;

不错。
不知道naven了解ACE不，感觉有一点类似。不过我觉得更像JAVA。

可以完全用OpenGL来做GUI吗，比如文本输入框、对话框等等，比起MFC来哪个好用一些。我最近要做GUI程序，但又不想学MFC，不知道该用什么好。

任务体系结构
在任务体系结构领域里，有三种主要的技术：
* 单进程单任务（面向进程）：在同一时间里，程序的每一份拷贝都作为一个任务来处理。有时，建立一个新的进程，同时也就建立了一个新的任务（比如： inetd、Sendmail）或者进程可以被重用（如：Apache）。在低负载的时候，这种体系结构一般可以获得较好的性能。在中等负载时，如果进程映像比较小（如：qmail）、应用程序经过执行效率的优化或者应用程序不会创建太多的并发任务，那么还可以勉强应付。在这种情况下，如果总的进程数保持较低的数量（低于中等负载），并且使用了进程缓冲，那么对多处理器系统的利用率将比较高。这种技术存在于所有的操作系统中，不过实现起来Unix比 Windows效率要高得多。（Windows中没有fork()系统调用，并且由于这种方法太慢，所以很少有Windows应用程序采用这种技术。）
* 单线程单任务（多线程）：在完成任务的过程中，程序的每一个拷贝在进程内部都作为了一个独立的线程来执行。在低负载到中等负载的情况下，多进程应用程序的性能都非常的好。对于比较高的负载，性能将会下降，但是还可以接受。然而，当负载非常高的时候，多线程应用程序的性能会急剧下降。在一般情况下，典型的多线程应用程序在处理500到1000个任务并发任务时，其性能还可以容忍。每一个任务使用一个新的线程，这样和一个新的进程比起来，将消耗较少的内存和 CPU资源。因为在极重的多线程负载下，只有那些目前使用非常广泛的 UNIX变种才能够继续保持稳定，所以在源代码开放的项目中，很少使用多线程。
* 单线程多任务（异步方式）：一个程序使用一系列的线程来运行（一般来说，每一个特定的任务都有专门的线程来处理），并且使用所谓的异步（或者叫无阻塞） TCP/IP技术，每一个线程要处理很多的任务。一般来说，由于大部分程序并不要求去处理高负载的情况，并且异步模式的程序设计相对来说比较困难，所以很少会有程序采用这种体系结构。因为可以使用各自独立的线程，所以多处理器系统中，异步程序的可伸缩性要好得多。因为几乎不会因等待CPU而死锁，所以每一个线程基本上都可以长时间地分配到一个CPU（比如：DNS BIND监控程序）。
[引用自chinaunix：http://bbs.chinaunix.net/viewthread.php?tid=56099]

谢谢大家的支持,我会继续下去的。

@Stone Jiang
谢谢你的建议。我觉得“不要拘泥于小节”比较好，我马上就改过来。

纯虚的析构函数可以用来定义抽象类，这样就避免了实例化（正如作者所说的），而且另外一个好处是可以不用再在抽象类中定义另一个纯虚函数（这种情况很常见）来避免实例化。因为抽象类总是没有析构函数的，或者说抽象类的析构函数是无用的、多余的，现在正好变废为宝。

但是这里的纯虚析构函数是可以不用实现的，否则还如何来避免实例化，也更不成其为纯虚函数了啊。

Jamie Zawinski的网站真是牛啊!佩服至极!

系统手册[2-15]
--------------------------------------
RESET
When the nRESET signal goes LOW, ARM920T abandons the executing instruction and then continues to fetch
instructions from incrementing word addresses.
When nRESET goes HIGH again, ARM920T:
1. Overwrites R14_svc and SPSR_svc by copying the current values of the PC and CPSR into them. The value of
the saved PC and SPSR is not defined.
2. Forces M[4:0] to 10011 (Supervisor mode), sets the I and F bits in the CPSR, and clears the CPSR's T bit.
3. Forces the PC to fetch the next instruction from address 0x00.
4. Execution resumes in ARM state.
--------------------------------------
当~nRESET信号(低电平有效)有效时,ARM920T终止当前指令的执行,而连续不断地获取下一字地址处的指令;当~nRESET恢复为高电平时,ARM920T执行下面的操作:
1. 拷贝当前PC和CPSR的值到R14_svc和SPSR_svc中.而保存过的PC和SPSR的值未定义(不确定).
2. M[4:0] <-- 10011,转到Supervisor模式,设置CPSR中的I、F位为1(禁止中断),并对T位清零(进入ARM状态).
3. 设置PC从0x00处获取下一条指令.
4. 在ARM状态下执行指令.

还有一种代码密度更高的写法：
（但不推荐使用，可读性太差了！）
while( *s && *s++ &= 0xDF )
　　　　；
其实对于指针的话还应该加上一条判断：
while( s && *s && *s++ &= 0xDF )
　　　　；

/**************************************/
// 利用字符串数组的结尾都是 \0
void ToUpper(chars[])
{
　　　　int i=0;
　　　　while(s[i++]!='\0' )
　　　　{　　＾＾＾＾＾
/**************************************/
你这个i自加的可不是时候啊

另外，其实只要一条语句就可实现转换的.
while( s[i] != '\0' )
　　s[i++] &= 0xDF; // 11011111B
/*或者*/
while( *s != '\0' )
　　*s++ &= 0xDF;

看来还是知识不过硬啊!

是吗?
我没有在其它编译器下测试,只是看了它的错误说明,我还以为真是这样的呢.
我完了再试一下吧.
谢谢了!

看题好像没有计算重复点吧,如果计算的话上面的图中的交点数可能就不够22个了.
如果要计算的话,我想可以用方程来表示线,计算出每个交点的坐标来.

其实原理很简单,只要知道栈是如何运作的就可以.
栈其实就相当于一个数组,函数的参数都被储存到这个数组中.C方式的参数传递是从后向前的,由于栈顶是大的地址,入栈时栈顶指针减小,所以以这种方式存储参数的话,最后参数在内存中的映象就是想于从前到后的一个数组了.
所以,只要知道第一个元素(即这里的参数)的地址及后面的元素个数和类型,就可以一个一个的把参数取出来.在使用变长参数时一定至少要有一个固定参数就是这个道理.
知道这样的原理的话就可以在程序在通过第一个参数的地址来取得后面的元素了.比如这样一个函数:
void foo( int n, ... );
其中n表示后面的参数的个数.而我在使用时隐式约定后面的参数都是整型的,即int,就可以这样获得后面的参数了:
void* p = &n + 1; //指向后面的第一个参数
while( n-- ) {
int* num = (int*)p;
//use *num
p = (int*)p + 1; //通过类型转换才可以知道1是多少字节.
}
这样就可以不用stdarg.h而使用变长参数了.
其实stdarg.h里面没有什么内容,只是定义了几个宏,有几个还是空的宏.
但最好还是用它里面定义的宏,而且在普通函数中也是完全有理由用它的,并不是只有库函数才可以.

注意是Reserved Byte Stored
在内存中是 68 61 70 70 79

happy

这样的代码的结果是不确定的，并没有规定；就是在不同的编译器下有不同的结果是完全合乎标准的。
况且搞这些玩意没有任何用处，不如多写写代码呢。

请问boost库里有没有XML的解析器,以及对Socket的封装？

这是照书翻译的，呵呵。
我英语不太好，语文也不太好，所以可能会有点乱吧。
大家有兴趣的话一起来帮忙修改一下嘛^-^

count[index^1] = 0; // count[index?0:1] = 0; // count[index==0?1:0] = 0;
//===========================
觉得不如下面这个可读性好或简洁：
count[ ! index ] = 0;

个人意见哈^-^

觉得楼主划分不错。一开始不要分得太细，可以将一楼说的一些参与不太多的类别归到一个子类下面，若有很多人参与，再提上来不迟。
而且我看楼主主要是从技术角度上分的，而一楼朋友是从应用角度上分的，两者怎么样折中一下可能比较好吧。

go here for hints:
　　　　http://www.rickadams.org/adventure/d_hints/index.html

我虽然没有勇气和能力来做这样的事情,但我在学校也是可以做一些改变的.不再用学校的一套来衡量自己的水平,而要看实际的能力,只去努力提升自己的能力.

----------------------------------------
看到王垠的另一篇文章,也一起贴到这边来吧.

<<完全用Linux工作，摈弃Windows>>
http://news.csdn.net/news/newstopic/26/26606.shtml

那你们是怎么过的?可以独立了吗?
我在学校一个感觉就是几乎所有东西都是我自学的,而上课时又必须去,于是去了就睡觉或玩或偶尔也看书.我还没有勇气做这样的事情,因为我的能力还不够,我没有多少经济支撑,家里还等着我毕业工作帮一点忙呢.
我很羡慕你们,能有这样的勇气.因此,我想你们以后的路也不难走吧.

[摘录]Boost源码剖析之:泛型函数指针类boost::function(修订版)
刘未鹏 /文

或许你会对模板参数int(int)感到陌生，其实它是个函数型别——函数g的确切型别就是int(int)，而我们通常所看到的函数指针型别int (*)(int)则是&g的型别。它们的区别与联系在于：当把g作为一个值进行拷贝的时候（例如，按值传参），其类型就会由int(int)退化为int(*)(int)，即从函数类型退化为函数指针类型——因为从语义上说，函数不能被“按值拷贝”，但身为函数指针的地址值则是可以被拷贝的。另一方面，如果g被绑定到引用，则其类型不会退化，仍保持函数类型。
......
请注意，函数类型乃是个极其特殊的类型，在大多数时候它都会退化为函数指针类型，以便满足拷贝语义，只有面对引用绑定的时候，能够维持原来的类型。当然，对于boost::function，总是按值拷贝。

谢谢你的批评.我也正是认识到这个问题后来向大家寻求帮助的.
另外你给我建议很不错的,可以考虑那样的实现.

嗯,确实是.
你说的是对的,模板不能滥用,"模板一般用在批量产生代码、加强类型检查、提高效率、普通代码不好解决问题的时候".以后我会记住的.
其实,我确实可能是有一点追求复杂代码的倾向,写代码时考虑代码最多,而不是具体的运用.在这一点上我是走错路了.
以后一定要改!

我在模板中试了一下,确实用函数类型定义的变量成为了函数指针类型.
定义为: T var;
输出为: var: void (__thiscall Base<void __cdecl(int)>::*)(int)
T : void __cdecl(int)

但是在外部,定义这样的一个类型及变量:
typedef void MethodType (int);
MethodType method;

它们的类型居然是一样的,method在这儿并没有转化为函数指针类型.
输出类型如下:
void __cdecl(int)
void __cdecl(int)

这又是怎么回事?

谢谢提醒.我已经将文件转放在博客园上,现在可以下载了.

void(int)原来是函数类型啊!从来没有见到过这样的类型啊.
你所说的"当把void(int)类型的函数作为一个值来传递时，它自动退化为void(*)(int)指针类型。"应该是指,用它来定义变量的时候,这个变量就成了函数指针类型的了?

这个肯定有用了啊!
还可以,和我以前想的一样,但我还不太了解DLL的用法,所以也就没有实现.而且我总感觉这样做不是很好,但又想不到更好的.现在我就省点力借借光吧,用的时候完善一下就直接用了.
不过,我不知道在LINUX及其它系统上面是不是也有DLL机制的方式来实现同样的功能.

哦,我以前问过这样的问题,不知道看到的是不是我问的.
不管了,反正好好学习就是了.

如何下载你的代码呢?cnblogs上看不到啊

看了这个又稍微理解多一些了,关注中...

不知道我的看法是否正确,还请赐教.

看了你这样子使用模板,真是服了!
我原来不明白你所说的"让编译器根据in/out来推导出函数原型",现在可能明白了:
你是用嵌套的模板,以后使用递归方式,来让编译器在编译时刻生成合适的类.其中最主要的还是If模板类吧,是它可以让编译器递归的分析的.还有In/Out/InOut及其对应的TypeTraits模板类,这样的用法是我从来都没有想到过的.

我从来没有想过这样的用法.
而且,你的模板使用的太好了,很灵活.这个代码我欣赏着很舒服,很喜欢.

也许你进行泛型编程有一段时间了吧,我只是有一点的了解,也没有学过和用过.你的代码我只看得懂,看得舒服,感觉很精妙,但其中的精髓我没法理解,我是万万写不出这样的代码来的.

前篇中所说的那几本书我都没有读过呢,以后有机会一定认真读.
你的这一系列文章我一直在关注中,希望你能坚持下去.我还等着研读你的大作呢

C++的程序员真的不好找工作吗?

想去啊，多么想去啊。可就是去不了啊。希望去过的朋友带点资料回来就很高兴了。

如果我有能力参与的话,我一定会参加的.
我对分布式以及Web Service也是很感兴趣,只是没有相关的知识和经验.
虽然如此,但至少我也会大力支持的!

9: int main()
10: {
0041F540 push ebp
0041F541 mov ebp,esp
0041F543 push 0FFFFFFFFh
0041F545 push offset __ehhandler$_main (45638Bh)
0041F54A mov eax,dword ptr fs:[00000000h]
0041F550 push eax
0041F551 mov dword ptr fs:[0],esp
0041F558 sub esp,17Ch
0041F55E push ebx
0041F55F push esi
0041F560 push edi
0041F561 lea edi,[ebp-188h]
0041F567 mov ecx,5Fh
0041F56C mov eax,0CCCCCCCCh
0041F571 rep stos dword ptr [edi]
　　　　　11: //wifstream wf( "utf8.txt" );
　　　　　12: std::wifstream wf;
0041F573 push 1
0041F575 lea ecx,[wf]
0041F57B call std::basic_ifstream<unsigned short,std::char_traits<unsigned short> >::basic_ifstream<unsigned short,std::char_traits<unsigned short> > (41D285h)
0041F580 mov dword ptr [ebp-4],0

是啊,这里有对esp,edi,ebp等的操作,但我不明白这是什么意思;-( 我还没学32位下的汇编呢.

不懂BOM是什么意思?
在UTF-8中它们没出现过,应该是正确的吧.

我觉得你这种从调用习惯入手进行分析的方式挺不错的,这样用起来会很自然,很方便,而且也容易把握全局.若是从原理方面入手进行代码编写的话,很可能会使最后开发出的代码很难用,也不容易把握好全局的关系.
我一直想实现一个XML的解析器,总是写了一些代码后觉得不合理就再重来,这样会反复好几次.直到现在,还在那放着没有做.我想用你这样的分析方式再尝试一次,看看会怎么样.

哦,我查了一下,局部变量是在栈上的.
是我记错了,动态分配的空间才是从堆上分配.

很不错.看了第一篇时根本看不懂是干什么呢,但这一篇就看得懂了.以这样的方式实现远程调用确实是很简单.
顺便问一下作者,你正在实现这一内容吗?

@ffox:
这样是将对变量的读写操作封装起来以接口的形式提供,它在提供了一定的接口一致性.如果以后要在读写变量的操作内加入其它的操作,那么原有的代码就可以不加任何修改,只改这样的接口就行了.也就是对外部封闭了细节,使编程简单一点.
但我也觉得不能用"一刀切"的方式将所有的成员变量都加以这样的封装,这样无疑会使代码增长(而且可能还有我所不知道的缺点).
所以,可以作如下的总结:
对于要对外部提供应用的变量,最好以接口的形式提供;而如果只是内部用的话,在用途只是用于保存变量的值的话,直接声明为public会好一些.
具体的情况还要加以区别对待,根据实际情况加以应用.

@cpunion
从C＋＋语言的发展方向上，很难看到他们有在语言层面上跨平台的打算。
--------------
确实,但我觉得现在语言层面动态的需求是很大的,尤其是做应用开发的.而C++却是在已经做得不错的效率上下工夫,而且现在又要加入一些保证安全的语言特征.这可不符合大势所趋啊.所以我觉得C++也会往这方面发展的吧.
其实我觉得那些C++的元老对C++的发展起了太大的作用,而他们又是比较保守的,所以导致C++发展缓慢.我觉得现在JAVA的方式不错,通过JCP社区最终决定它的发展方向.
也许也是我错了吧:也许C++并不想走"大众化"的道路,或是那些元老不想让它走.
但我认为使用者才是拥有最终决定权的.

@FrameSniper
"现在？你的意思是以前不是了？"
----------
当然不是了,我的文字不好,没有讲明白,谢谢你指正.

另外,我不认为跨平台只有依靠虚拟机.像cpunion所说,只要系统提供一致的接口就行.但是,如果接口差异不是很大,我想应该可以靠编译器的工作来转换.
我的意思也不是要让生成的可执行文件实现跨平台,而是在一个中间代码的层次实现,而后由编译器针对各系统的不同而生成不同的程序.虽然这也不是完全的跨平台,但在开发者的角度看也差不多了,而且可以通过编译器的实现来将中间代码的编译速度提高,这样也可以实现.NET所谓的即时编译,即第一次运行的时候编译,以后就不用编译了.其实在虚拟机上,也不是可以生成目标操作系统的机器代码吗,但它的效率应该不及C/C++了吧.

确实,在现在的应用中动态性是很重要的,而且也通常会使开发出来的产品有很高的可扩展性.C++对这个的支持确实很少.不过我想如果结合编译器的一些功能与特性,这样的动态性还是可以实现的,而且还有可能实现中间代码级的跨平台性.

其实他这个方式不一定有效,因为C++的类成员的内存布局可以与声明的顺序不一样,而不象C的结构中的成员一样,要完全的一致.所以他这样的实现有赖于编译器的实现,而不能得到语言级的保证.

到现在我天天都在用它收发很多信的,可还是没有发邀请的权限啊.
仍然郁闷的等待中.....