[TL]C++处理大型项目的能力开始浮现了？{OT}
up duan
用C++重写的Compiz 0.9.0发布
jinhu wang
多年后，我明白了遇到需要c项目不要说你会c++。
遇到需要c++的项目，你要说你很熟悉c&c++。
Fei Yan
sagasw
根据我对代码粗粗浏览，基本上就是把C++当做“具有类功能的C”来使用，没有什么复杂用法、模板技巧等等。
也称不上什么C++的成功，compiz现在的代码，用C一样可以完成，差别极小。
至于大型项目的成功？它代码量应该只能算中型项目吧。
------------------------------------------
blog: http://sunxiunan.com/
C++, Lua, living in Dalian
http://twitter.com/sagasw
------------------------------------------
up duan
不知道回复的朋友有几个真正下载了compiz的代码稍微看看，然后再发表评论。
根据我对代码粗粗浏览，基本上就是把C++当做“具有类功能的C”来使用，没有什么复杂用法、模板技巧等等。
也称不上什么C++的成功，compiz现在的代码，用C一样可以完成，差别极小。
至于大型项目的成功？它代码量应该只能算中型项目吧。
up duan
不是说用c++重写GCC吧；只是编译时候用g++取代gcc，接受c++代码而已，差别很大的吧。参考这里的Post：以前的ＧＣＣ只接受Ｃ代码，现在可以允许提交用Ｃ＋＋写的代码而已；更多是一种对现实的折中措施。
The goal is a better compiler for users, not a C++ code base for its own sake
我怎么觉得这个Post不是你说的意思呢？完全没有为形势所迫不得不使用C++，而是积极主动的使用C++。
文中提到了要使用构造析构这类典型的C++特征，虽然限制了很多C++的“高级”特征，但是基本原因是为了方式C程序员的误用。yacc生成的编译器理论上是有内存泄漏的，就是因为C没有构造和析构导致的。
他们的目标是一个更好的编译器，是不是可以推论他们认为C++可以让他们作出一个更好的编译器。但是为什么？我觉得是C++表达概念比C清晰导致的。
Guanqun Lu
1. gcc应该从4.0开始就采用手写的parser了吧，还用yacc么？
2. 我查了一下： 这里的 http://www.dazuiniu.com/blog/2010/06/02/gcc-use-cpp-to-develop.html
有几句话总结的还可以：
“他的意思现在不用太着急，没有必要为了改成 C++ 而改，而确实是有需求，
最希望看到的就是利用 C++ 来实现一些高级的，有用的特性，能够确实对 GCC 的用户有显著的帮助，
而并是一股脑的将 VEC_xxx 的类型全部改成 std::vector。”
你的这个问题问的很好，就是为什么他们认为C++会产生一个更好的编译器，至少是直觉上的。
--
Guanqun
up duan
CXX16
On 2010/7/6 16:30, up duan wrote:
http://gcc.gnu.org/wiki/CppConventions�������ܿ���һЩ���������һ�����ͣ�Ϊʲôʹ��C++
2010/7/6 Guanqun Lu <guanqun.lu@gmail.com>
2010/7/6 up duan <fix...@gmail.com>:
>
>
> 2010/7/6 Fei Yan <skyscr...@gmail.com>
>>
>> ����˵��c++��дGCC�ɣ�ֻ�DZ���ʱ����g++ȡ��gcc������c++������ѣ����ܴ�İɡ�
>> ������Post��
>> http://gcc.gnu.org/ml/gcc/2010-05/msg00705.html
>>
>> ��ǰ�ģǣã�ֻ���ܣô��룬���ڿ��������ύ�ãã���д�Ĵ�����ѣ������һ�ֶ���ʵ�����д�ʩ��
>
> The goal is a better compiler for users, not a C++ code base for its own
> sake
>
1. gccӦ�ô�4.0��ʼ�Ͳ�����д��parser�˰ɣ�����yaccô��> ����ô�������Post������˵����˼�أ���ȫû��Ϊ�������Ȳ��ò�ʹ��C++�����ǻ�������ʹ��C++��
>
> �����ᵽ��Ҫʹ�ù�������������͵�C++��������Ȼ�����˺ܶ�C++�ġ��������������ǻ�ԭ����Ϊ�˷�ʽC����Ա�����á�yacc��ɵı��������� �������ڴ�й©�ģ�������ΪCû�й�����������µġ�
>
> ���ǵ�Ŀ����һ����õı��������Dz��ǿ�������������ΪC++��������������һ����õı�����������Ϊʲô���Ҿ�����C++�������C�����µġ�
2. �Ҳ���һ�£� ����� http://www.dazuiniu.com/blog/2010/06/02/gcc-use-cpp-to-develop.html
�м��仰�ܽ�Ļ����ԣ�
�������˼���ڲ���̫�ż���û�б�ҪΪ�˸ij� C++ ��ģ���ȷʵ��������
��ϣ���ľ������� C++ ��ʵ��һЩ���ģ����õ����ԣ��ܹ�ȷʵ�� GCC ���û�������İ���
����һ���ԵĽ� VEC_xxx ������ȫ���ij� std::vector����
�����������ʵĺܺã�����Ϊʲô������ΪC++�����һ����õı�������������ֱ���ϵġ�
--
Guanqun
up duan
其实这个问题应该问为什么LLVM和CLANG要用C++。
Changsheng Jiang
在C编程时, 我最想用的 C++ 特性是模板式的代码生成, 这个可以减少重复代码量. 再一个是析构函数. 这个主要是在资源申请时指定资源释放, 并自动化.
模板在 C 里用宏比较丑陋. 我用过CPP之外的处理程序生成代码.
析构函数的自动化, 实在无法. 一个方法是将资源释放注册到一个栈式的地方, 栈弹出一层, 自动释放此层对应的所有资源.
反而觉得面向对象不是C++吸引C程序员的特性. 觉得面向接口更简单直接, 见过一些Ｃ++代码, 先声明接口 Interface, 再实现 Impl, 实是受强类型的面向对象所累.
不知大家欣赏的C++ - C 的特性是什么?
Changsheng Jiang
Kula
Fei Yan
Guanqun Lu
Fuzhou Chen
的消亡产生了正面作用。:)
没有吵架的意思，呵呵。
2010/7/6 Guanqun Lu <guanq...@gmail.com>:
--
《采莲》·江南
为卿采莲兮涉水，为卿夺旗兮长战。为卿遥望兮辞宫阙，为卿白发兮缓缓歌。
另抄自蒜头的评论：http://www.douban.com/review/1573456/：
且祭一束紫琳秋，为一段落花流水的传说
且饮一杯青花酒，为一场几多擦肩的错过
且焚一卷旖旎念，为一腔抛付虚无的惜怜
且歌一曲罢箜篌，为一刻良辰春宵的寂寞
Kula
Guanqun Lu
2010/7/7 Kula <kula...@gmail.com>:
> 现在已经支持了...童鞋要用发展的眼光来看问题啊
>
> 2010/7/7 Guanqun Lu <guanq...@gmail.com>
--
Guanqun
sagasw
------------------------------------------
blog: http://sunxiunan.com/
C++, Lua, living in Dalian
http://twitter.com/sagasw
------------------------------------------
Kula
correct fault for 16-bit divide on Leopard,
fix 386 signal handler bug.
Kula
Fei Yan
Jeffrey Zhao
Kula
OxFAN
CXX16
而且现阶段go生产的程序运行速度也还是差一些。http://shootout.alioth.debian.org/u32/compare.php?lang=go
话题还是回到C++本身吧。
IMHO，早期gcc还是gnu c compiler时，恐怕没条件用c++写gcc吧；而现在gcc是gnu compiler collection了，人们有选择的可能性了，便开始考虑c++了。
同样可以体现在llvm和clang上，在GCC有C，C++，Fortran, Object-C的基础上，作者还是选择了C++，同样说明了C++有其优点，可以做到抽象性和速度在现实中的平衡。
On 2010/7/7 14:20, OxFAN wrote:
golang 还是个"类C"语言呢
在 2010年7月7日 下午2:00，Kula <kula...@gmail.com>写 道：
我 对任何类python的语言都持有好感. golang哪些地方让我快乐我说不上，毕竟没怎么接触。但c++哪些地方让我不快乐我能说很久很久
2010/7/7 Jeffrey Zhao <je...@live.com>
golang哪些地方让你快乐呢？Jeffrey ZhaoBlog: http://blog.zhaojie.me/Twitter: @jeffz_cn
我 觉得现在已经很有必要跟进golang了。我写过两年c/c++.可能经验尚浅，但是在用c\c++的时候，遇到的一些问题，使我很难接受这两种语言，尤 其是c++.
Linker
其他，我觉得，都还好了。
新语言很难被大众接受，毕竟语言切换的成本太高。
> 2010/7/7 Guanqun Lu <guanq...@gmail.com>
>
>
>
> golang首先一点就不支持windows系统，这个就会对它的大规模流行产生负作用。
>
> 2010/7/7 Kula <kula...@gmail.com>:
>
>
> > 呵呵，20多年过去了，这个时候再来说c++处理大型项目的能力开始浮现，会不会太迟了。
>> 其实花在关注c++上的时间，我们完全可以拿来关注golang.假以时日，等golang成熟了.大批大批的软件又会用golang 重写。
>>
>>
>> 2010/7/7 Changsheng Jiang <jiang...@gmail.com>
>>>
>>> 赞同这句话.
>>>
>>> 在C编程时, 我最想用的 C++ 特性是模板式的代码生成, 这个可以减少重复代码量. 再一个是析构函数.
> 这个主要是在资源申请时指定资源释放,
>>> 并自动化.
>>>
>>> 模板在 C 里用宏比较丑陋. 我用过CPP之外的处理程序生成代码.
>>>
>>> 析构函数的自动化, 实在无法. 一个方法是将资源释放注册到一个栈式的地方, 栈弹出一层, 自动释放此层对应的所有资源.
>>>
>>> 反而觉得面向对象不是C++吸引C程序员的特性. 觉得面向接口更简单直接, 见过一些Ｃ++代码, 先声明接口
> Interface, 再实现
>>> Impl, 实是受强类型的面向对象所累.
>>>
>>> 不知大家欣赏的C++ - C 的特性是什么?
>>>
>>>
> Changsheng Jiang
>>>
>>>
>>> 2010/7/7 up duan <fix...@gmail.com>
>>>>
>>>>
>>>> 2010/7/6 CXX16 <cplus...@gmail.com>
>>>>>
>>>>> 其实这个问题应该问为什么LLVM和CLANG要用C++。
>>>>>
>>>>
>>>>
> 作为一个没有压力的新项目，选择什么语言主要取决于实施者的感觉了。所以LLVM采用C++不太能说明什么问题。但是传统的C项目改为C++就很有说服力
> 了。
>>>
>>
>>
>
>
>
>
>
> --
> Guanqun
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
--
Regards,
Linker Lin
linker...@gmail.com
机械唯物主义 : linjunhalida
莫华枫
dachuan lin
1、对于C来说，代码生成的方式主要是靠宏，其带来的问题就不用说了；
2、C++的创造者发现了宏的问题，其改善的方法，一个是发明了继承，不过这个其实只是擦擦边而已，真正接触到核心的还是模板（template）的引入。
但是，这两者都是在歧路上越走越远。真正的解决之道，一方面如C#引入的，attribute，特性，另一方面，其实就应该光明正大的引入代码生成语言（不错，make configuration就是解决之道，可惜的是没有真正和C完全融合，并形成标准），以及预编译的模板库（或者类型库）。
其实工程界早都已经自觉不自觉的引入了这些技术，比如windows下微软的类型库，以及广泛使用的make等技术，只是都不敢或者没想到把这些完全融合在一起。
在我的理想中，真的希望能够有一种语言，可以完全实现以下的功能：
1、类似C的语法；
2、强类型语言，但是可以静态自动类型推断；
3、代码分两部分：生成阶段语言和运行阶段语言，编译器可以作为库链入代码中；
4、在生成库的时候，带上最完整的类型信息，最后link为exe时可以尽可能优化；
5、预编译模板库；
6、完整的静态接口设计；
7、原生支持并行；
8、原生支持GC；
up duan
严格来说，C和C++用来解决代码生成的技术，其实是走错了方向。
1、对于C来说，代码生成的方式主要是靠宏，其带来的问题就不用说了；
2、C++的创造者发现了宏的问题，其改善的方法，一个是发明了继承，不过这个其实只是擦擦边而已，真正接触到核心的还是模板（template）的引入。
但是，这两者都是在歧路上越走越远。真正的解决之道，一方面如C#引入的，attribute，特性，另一方面，其实就应该光明正大的引入代码生成语言（不错，make configuration就是解决之道，可惜的是没有真正和C完全融合，并形成标准），以及预编译的模板库（或者类型库）。
其实工程界早都已经自觉不自觉的引入了这些技术，比如windows下微软的类型库，以及广泛使用的make等技术，只是都不敢或者没想到把这些完全融合在一起。
在我的理想中，真的希望能够有一种语言，可以完全实现以下的功能：
1、类似C的语法；
2、强类型语言，但是可以静态自动类型推断；
3、代码分两部分：生成阶段语言和运行阶段语言，编译器可以作为库链入代码中；
4、在生成库的时候，带上最完整的类型信息，最后link为exe时可以尽可能优化；
5、预编译模板库；
6、完整的静态接口设计；
7、原生支持并行；
8、原生支持GC；
Milo Yip
不理解"完整的静态接口设计"
在 2010年7月9日下午9:58，dachuan lin <lindach...@gmail.com> 寫道：
> 严格来说，C和C++用来解决代码生成的技术，其实是走错了方向。
> 1、对于C来说，代码生成的方式主要是靠宏，其带来的问题就不用说了；
> 2、C++的创造者发现了宏的问题，其改善的方法，一个是发明了继承，不过这个其实只是擦擦边而已，真正接触到核心的还是模板（template）的引入。
> 但是，这两者都是在歧路上越走越远。真正的解决之道，一方面如C#引入的，attribute，特性，另一方面，其实就应该光明正大的引入代码生成语言（不错，make
> configuration就是解决之道，可惜的是没有真正和C完全融合，并形成标准），以及预编译的模板库（或者类型库）。
> 其实工程界早都已经自觉不自觉的引入了这些技术，比如windows下微软的类型库，以及广泛使用的make等技术，只是都不敢或者没想到把这些完全融合在一起。
> 在我的理想中，真的希望能够有一种语言，可以完全实现以下的功能：
> 1、类似C的语法；
> 2、强类型语言，但是可以静态自动类型推断；
> 3、代码分两部分：生成阶段语言和运行阶段语言，编译器可以作为库链入代码中；
> 4、在生成库的时候，带上最完整的类型信息，最后link为exe时可以尽可能优化；
> 5、预编译模板库；
> 6、完整的静态接口设计；
> 7、原生支持并行；
> 8、原生支持GC；
--
Milo Yip
Twitter @miloyip
http://www.cnblogs.com/miloyip/
http://miloyip.seezone.net/
Jeffrey Zhao
Jeffrey Zhao
Blog: http://blog.zhaojie.me/
Twitter: @jeffz_cn
-----Original Message-----
From: Milo Yip
Sent: Friday, July 09, 2010 11:49 PM
To: pon...@googlegroups.com
Subject: Re: [TL]C++���������Ŀ��������ʼ�����ˣ�{OT}
C# 2.0 �� var �� C++0x �� auto �ɝM���㌦�o�B�Ԅ�����ƌ���Ҫ���N?
�����"����ľ�̬�ӿ����"
�� 2010��7��9������9:58��dachuan lin <lindach...@gmail.com> ������
> �ϸ���˵��C��C++�������������ɵļ�������ʵ���ߴ��˷���
> 1������C��˵��������ɵķ�ʽ��Ҫ�ǿ��꣬�����������Ͳ���˵�ˣ�
> 2��C++�Ĵ����߷����˺�����⣬����Ƶķ�����һ���Ƿ����˼̳У����������ʵֻ�Dz����߶��ѣ�����Ӵ������ĵĻ���ģ�壨template�������롣
> ���ǣ������߶�������·��Խ��ԽԶ������Ľ��֮����һ������C#����ģ�attribute�����ԣ���һ���棬��ʵ��Ӧ�ù��������������������ԣ����?make
> configuration���ǽ��֮������ϧ����û�������C��ȫ�ںϣ����γɱ������Լ�Ԥ�����ģ��⣨�������Ϳ⣩��
> ��ʵ���̽��綼�Ѿ��Ծ����Ծ�����������Щ����������windows��������Ϳ⣬�Լ��㷺ʹ�õ�make�ȼ�����ֻ�Ƕ����һ���û�뵽����Щ��ȫ�ں���һ��
> ���ҵ������У����ϣ���ܹ���һ�����ԣ�������ȫʵ�����µĹ��ܣ�
> 1������C������
> 2��ǿ�������ԣ����ǿ��Ծ�̬�Զ������ƶϣ�
> 3������������֣���ɽ����Ժ����н����ԣ�������������Ϊ����������У�
> 4������ɿ��ʱ�����������������Ϣ�����linkΪexeʱ���Ծ������Ż���
> 5��Ԥ����ģ��⣻
> 6������ľ�̬�ӿ���ƣ�
> 7��ԭ��֧�ֲ��У�
> 8��ԭ��֧��GC��
Yingjie XU
-----Original Message----- From: Milo Yip
Sent: Friday, July 09, 2010 11:49 PM
C# 2.0 的 var 和 C++0x 的 auto 可滿足你對靜態自動類型推導的要求麼?
不理解"完整的静态接口设计"
在 2010年7月9日下午9:58，dachuan lin <lindach...@gmail.com> 寫道：
严格来说，C和C++用来解决代码生成的技术，其实是走错了方向。
1、对于C来说，代码生成的方式主要是靠宏，其带来的问题就不用说了；
2、C++的创造者发现了宏的问题，其改善的方法，一个是发明了继承，不过这个其实只是擦擦边而已，真正接触到核心的还是模板（template）的引入。
但是，这两者都是在歧路上越走越远。真正的解决之道，一方面如C#引入的，attribute，特性，另一方面，其实就应该光明正大的引入代码生成语言（不错，make
configuration就是解决之道，可惜的是没有真正和C完全融合，并形成标准），以及预编译的模板库（或者类型库）。
其实工程界早都已经自觉不自觉的引入了这些技术，比如windows下微软的类型库，以及广泛使用的make等技术，只是都不敢或者没想到把这些完全融合在一起。
在我的理想中，真的希望能够有一种语言，可以完全实现以下的功能：
1、类似C的语法；
2、强类型语言，但是可以静态自动类型推断；
3、代码分两部分：生成阶段语言和运行阶段语言，编译器可以作为库链入代码中；
4、在生成库的时候，带上最完整的类型信息，最后link为exe时可以尽可能优化；
5、预编译模板库；
6、完整的静态接口设计；
7、原生支持并行；
8、原生支持GC；
--
Yingjie XU
Département d'informatique
École Normale Supérieure
45 rue d'Ulm
F-75230 Paris Cedex 05
"If you received this communication by mistake,
please don't forward it to anyone else (it may contain
confidential or privileged information), please erase
all copies of it, including all attachments, and please
let the sender know it went to the wrong person.
Thanks."
Jeffrey Zhao
dachuan lin
2010/7/9 dachuan lin <lindach...@gmail.com>严格来说，C和C++用来解决代码生成的技术，其实是走错了方向。
1、对于C来说，代码生成的方式主要是靠宏，其带来的问题就不用说了；
2、C++的创造者发现了宏的问题，其改善的方法，一个是发明了继承，不过这个其实只是擦擦边而已，真正接触到核心的还是模板（template）的引入。
但是，这两者都是在歧路上越走越远。真正的解决之道，一方面如C#引入的，attribute，特性，另一方面，其实就应该光明正大的引入代码生成语言（不错，make configuration就是解决之道，可惜的是没有真正和C完全融合，并形成标准），以及预编译的模板库（或者类型库）。
其实工程界早都已经自觉不自觉的引入了这些技术，比如windows下微软的类型库，以及广泛使用的make等技术，只是都不敢或者没想到把这些完全融合在一起。不觉得模板是误入歧途。也不觉得Attribute就是真正的解决之道。能给出说明为什么吗？
其实模板只要能够描述代码生成的方式就可以了，而这些完全可以由编译系统来完成。
举个例子 ，比如在类型推断中，常常会有很多的方式来判断类型是原生数据类型呢？还是自定义类型？这些信息，其实编译器都知道，只需要建立一种“编译器语言”，就可以指定如何编译了，
有点类似下面的代码：
[@gen: type TYPE]
int max(TYPE &a1, TYPE &a2)
{
[@gen: if TYPE is NUMBER then ]
return (a1>a2)? a1: a2;
[@gen: elseif TYPE is CLASS && TYPE has @memfun: compare then]
return a1.compare(a2);
[@gen: else]
throw std::exception::member_not_defined;
[@gen: endif]
}
上面的代码中，[@gen]部分表示“生成代码”，其信息可以从编译器对代码的静态分析得到，相当于C中的预编译，但是由于其完全和“运行代码”一体化设计，
所以其功能比简单的代码替换要强得多，可以完成以下功能：
1、自动生成一个代码模板，也就是已经预编译好三段的函数代码；
2、在编译链接时，实际的调用代码中用实际的类型 进行 调用 的时候，编译器会决断其类型是哪一种，从而自动将所需的代码链入；
3、不但可以分辨是否普通数值类型（比如整数、浮点），而且可以分辨是否是一个类，这个类是否含有某个成员，注意这些都是静态的，也就是完全不需要定义是否
是继承或虚函数，因为类的信息在编译的时候都保存起来了。
没错，我知道这个和concept很相近，但是C++中的concept搞得很复杂，我不知道为什么，其实如果换个角度，把concept当作是编译器的指令代码，可以有特权来访问编译的
时候生成的类型完整信息的话，其实现会非常简单。
宏是一个非常好的代码生成技术。当然，C的宏由于自身的一些限制导致不够理想，但是m4明显舒服的多，更别说scheme了。你说的“类型库”就是“预编译的模板库”么？不太清楚你的标的是什么。不过业界早已把make技术用于代码生成了。
同时，如果是模板类型的话，则会包含多重实践的代码；这个有点像delphi的单元+tlb
在我的理想中，真的希望能够有一种语言，可以完全实现以下的功能：
1、类似C的语法；C的语法是如此的不清晰，还是不类似的好一些。
2、强类型语言，但是可以静态自动类型推断；好特性。好难。Haskell和OCaml以及Scala都有这些设施。3、代码分两部分：生成阶段语言和运行阶段语言，编译器可以作为库链入代码中；至少现在的Java和.Net平台都提供了Compiler访问的API。而且编译器作为应用的一部分逻辑上需要虚拟机支撑，否则应用不能部署。而部署虚拟机本身就是一个问题。
为什么要虚拟机呢？比如在windows下生成的程序，自带windows下的compiler和linker，你可以在程序运行中，自动或由用户输入生成一段代码，然后调用附带的compiler编译到内存中，
然后返回函数指针，即可以进行调用。
4、在生成库的时候，带上最完整的类型信息，最后link为exe时可以尽可能优化；LLVM。
5、预编译模板库；……，不是很清楚这是什么意思，你是指C++的模板么？或许是指.NET的Generic？
当然其大小可能很大，但是比源码要快，同时在生成实际代码的时候只链入实际的部分。
6、完整的静态接口设计；这年头，动态接口才是新闻。
7、原生支持并行；
如果是通用目的的并行，现在的Thread和Lock就完全支持了。而且也似乎只有它们才支持通用目的的并行。如果是特定场景下的并行，似乎不应该作为语言的特性存在吧。
8、原生支持GC；
GC似乎仍然达不到通用目的。仍有适用场景。最好是可以通过声明允许或者禁止的。
up duan
dachuan lin
不理解"完整的静态接口设计"
[@gen: type TYPE is CLASS]
interface COMPARE {
int compare( TYPE &a1, TYPE &a2);
}
class COMPLEX
{
int compare ( COMPLEX &a, COMPLEX &b){ ... }
}
[@gen: type TYPE]
int max(TYPE &a1, TYPE &a2)
{
[@gen: if TYPE is NUMBER then ]
return (a1>a2)? a1: a2;
return a1.compare(a2);
[@gen: else]
throw std::exception::member_not_defined;
[@gen: endif]
}
{
COMPLEX a, b;
return max(a, b);
}
可以看到，COMPLEX类完全不需要从COMPARE继承，也不需要任何的虚函数，在编译的时候， 自动会检查是否包含了interface的相关函数或成员，如果是就自动链入
其相对应的函数。要这么做，必须在编译的时候，编译器完全知道所有相关类型的信息。
up duan
宏是一个非常好的代码生成技术。当然，C的宏由于自身的一些限制导致不够理想，但是m4明显舒服的多，更别说scheme了。你说的“类型库”就是“预编译的模板库”么？不太清楚你的标的是什么。不过业界早已把make技术用于代码生成了。类型库指的是你创建的库中所有的类型和函数的完整信息，比如类名，成员变量名称、类型，成员函数名称、参数、返回值、虚实等等。
同时，如果是模板类型的话，则会包含多重实践的代码；这个有点像delphi的单元+tlb
在我的理想中，真的希望能够有一种语言，可以完全实现以下的功能：
1、类似C的语法；C的语法是如此的不清晰，还是不类似的好一些。简洁还是类C的好。当然新语言可以完全不考虑缺省类型自动转换等混淆的部分；
2、强类型语言，但是可以静态自动类型推断；好特性。好难。Haskell和OCaml以及Scala都有这些设施。3、代码分两部分：生成阶段语言和运行阶段语言，编译器可以作为库链入代码中；至少现在的Java和.Net平台都提供了Compiler访问的API。而且编译器作为应用的一部分逻辑上需要虚拟机支撑，否则应用不能部署。而部署虚拟机本身就是一个问题。这个功能我觉得可以实现 嵌入式的脚本编译，脚本相当于是自己的语言。
为什么要虚拟机呢？比如在windows下生成的程序，自带windows下的compiler和linker，你可以在程序运行中，自动或由用户输入生成一段代码，然后调用附带的compiler编译到内存中，
然后返回函数指针，即可以进行调用。
4、在生成库的时候，带上最完整的类型信息，最后link为exe时可以尽可能优化；LLVM。是个好选择。是否可以用于代码生成？5、预编译模板库；……，不是很清楚这是什么意思，你是指C++的模板么？或许是指.NET的Generic？参见上面的例子。其实就是根据不同的生成选项 先 生成不同的代码 集结成库，方便快速进行链接。
当然其大小可能很大，但是比源码要快，同时在生成实际代码的时候只链入实际的部分。
6、完整的静态接口设计；这年头，动态接口才是新闻。这个是和C++和JAVA的接口相比较的，实际上是在编译的时候进行多态，所以完全不需要继承和虚函数。
7、原生支持并行；
如果是通用目的的并行，现在的Thread和Lock就完全支持了。而且也似乎只有它们才支持通用目的的并行。如果是特定场景下的并行，似乎不应该作为语言的特性存在吧。我觉得并行代码应该在底层支持映射到不同平台，同时定义一些原子级的变量、锁和操作
up duan
在 2010年7月9日 下午11:49，Milo Yip <mil...@gmail.com>写道：C# 2.0 的 var 和 C++0x 的 auto 可滿足你對靜態自動類型推導的要求麼?差不多。不理解"完整的静态接口设计"比如下面的代码：
[@gen: type TYPE is CLASS]
interface COMPARE {
int compare( TYPE &a1, TYPE &a2);
}
class COMPLEX
{
int compare ( COMPLEX &a, COMPLEX &b){ ... }[@gen: elseif TYPE is CLASS && TYPE has @interface:COMPARE then]
}
[@gen: type TYPE]
int max(TYPE &a1, TYPE &a2)
{
[@gen: if TYPE is NUMBER then ]
return (a1>a2)? a1: a2;void fun1()
return a1.compare(a2);
[@gen: else]
throw std::exception::member_not_defined;
[@gen: endif]
}
{
COMPLEX a, b;
return max(a, b);
}
可以看到，COMPLEX类完全不需要从COMPARE继承，也不需要任何的虚函数，在编译的时候， 自动会检查是否包含了interface的相关函数或成员，如果是就自动链入
其相对应的函数。要这么做，必须在编译的时候，编译器完全知道所有相关类型的信息。
dachuan lin
dachuan lin
其实类型的信息都在编译器中的数据库里，完全可以使用类似的静态查询的办法来在编译器就能判断是否满足条件，从而可以得到更为准确的错误定位和更清晰的代码，而且也减少了很多的包装层。
没错，“这些代码编译为某种形式（AST？），在调用的时候进行参数化类型的替换。”，这些操作可以集中进行，以后就可以极大的减少编译的时间。
宏是一个非常好的代码生成技术。当然，C的宏由于自身的一些限制导致不够理想，但是m4明显舒服的多，更别说scheme了。你说的“类型库”就是“预编译的模板库”么？不太清楚你的标的是什么。不过业界早已把make技术用于代码生成了。类型库指的是你创建的库中所有的类型和函数的完整信息，比如类名，成员变量名称、类型，成员函数名称、参数、返回值、虚实等等。
同时，如果是模板类型的话，则会包含多重实践的代码；这个有点像delphi的单元+tlb
Java和.NET似乎都满足这个条件。除了你说的模板。
在我的理想中，真的希望能够有一种语言，可以完全实现以下的功能：
1、类似C的语法；C的语法是如此的不清晰，还是不类似的好一些。简洁还是类C的好。当然新语言可以完全不考虑缺省类型自动转换等混淆的部分；
C不仅仅是自动类型转换导致的不清晰。它本身的语法就非常不规整，导致非常不清晰，很多时候需要超越语法规则的元规则才能解决二义性。
2、强类型语言，但是可以静态自动类型推断；好特性。好难。Haskell和OCaml以及Scala都有这些设施。3、代码分两部分：生成阶段语言和运行阶段语言，编译器可以作为库链入代码中；至少现在的Java和.Net平台都提供了Compiler访问的API。而且编译器作为应用的一部分逻辑上需要虚拟机支撑，否则应用不能部署。而部署虚拟机本身就是一个问题。这个功能我觉得可以实现 嵌入式的脚本编译，脚本相当于是自己的语言。
为什么要虚拟机呢？比如在windows下生成的程序，自带windows下的compiler和linker，你可以在程序运行中，自动或由用户输入生成一段代码，然后调用附带的compiler编译到内存中，
然后返回函数指针，即可以进行调用。如果你的程序需要部署到linux下呢？你的compiler和linker还能用么？
4、在生成库的时候，带上最完整的类型信息，最后link为exe时可以尽可能优化；LLVM。是个好选择。是否可以用于代码生成？5、预编译模板库；……，不是很清楚这是什么意思，你是指C++的模板么？或许是指.NET的Generic？参见上面的例子。其实就是根据不同的生成选项 先 生成不同的代码 集结成库，方便快速进行链接。
当然其大小可能很大，但是比源码要快，同时在生成实际代码的时候只链入实际的部分。6、完整的静态接口设计；这年头，动态接口才是新闻。这个是和C++和JAVA的接口相比较的，实际上是在编译的时候进行多态，所以完全不需要继承和虚函数。
看看前面的那个例子max，仔细想想，你就会知道：继承是很多重用的根本。虚函数是一种实现机制，跟继承不可同日而语。编译时就可以确定某些Override的行为具体落实到那个代码片段上，运行时自然就可以直接调用。其实Java在这一点上已经做得非常好了，不过由于Java的优化是JIT的，你或许会觉得还是占用了运行时间，那么Eiffel的完全编译时搞定就能满足你了【完全不用修改现在的连接器】。
7、原生支持并行；
如果是通用目的的并行，现在的Thread和Lock就完全支持了。而且也似乎只有它们才支持通用目的的并行。如果是特定场景下的并行，似乎不应该作为语言的特性存在吧。我觉得并行代码应该在底层支持映射到不同平台，同时定义一些原子级的变量、锁和操作这需要一个比较庞大的运行时，或许叫虚拟机更恰当一点。
up duan
dachuan lin
另外，我这样设计主要是想解决掉例如#if #define 等预编译的情况下的大量问题（比如无法得到类型信息，出错时定位困难，代码丑陋等），直接加入“编译期代码”，既能搞定模板和concept，又能实现条件编译和自动代码生成，何乐而不为呢？
up duan
宏是一个非常好的代码生成技术。当然，C的宏由于自身的一些限制导致不够理想，但是m4明显舒服的多，更别说scheme了。你说的“类型库”就是“预编译的模板库”么？不太清楚你的标的是什么。不过业界早已把make技术用于代码生成了。类型库指的是你创建的库中所有的类型和函数的完整信息，比如类名，成员变量名称、类型，成员函数名称、参数、返回值、虚实等等。
同时，如果是模板类型的话，则会包含多重实践的代码；这个有点像delphi的单元+tlb
Java和.NET似乎都满足这个条件。除了你说的模板。java等问题是，编译好的东西（比如库）包含 太多的信息，并会直接传递到最后的运行程序中。这造成了资源的浪费。我希望的是在生成lib的时候包含充分的信息，但最后link的时候尽可能的去除。
7、原生支持并行；
如果是通用目的的并行，现在的Thread和Lock就完全支持了。而且也似乎只有它们才支持通用目的的并行。如果是特定场景下的并行，似乎不应该作为语言的特性存在吧。我觉得并行代码应该在底层支持映射到不同平台，同时定义一些原子级的变量、锁和操作这需要一个比较庞大的运行时，或许叫虚拟机更恰当一点。编译的时候直接替换也是可以的。比如变量的原子操作，如果你直接编译为window+intel平台，那么 compiler会自动为你生成该变量的一个临界区对象，每次对变量的操作都会自动锁定和解锁；如果编译为某个直接支持内存锁定的平台，那么就直接映射。
dachuan lin
type traits不需要继承，不需要虚函数，不需要是自定义类，原始类型【比如int】也可以用。只是程序员手工把某些信息收集包装起来交给编译器，然后编译器就可以通过类型来进行静态分派了。对于C++来说，traits的成员主要是typedef，ok？
运行时多态的概念很好，但是我总觉得虚函数（以及虚函数表）的实现形式实在是很丑陋。最好的例子就是event（signal）-handler的对应。这个方面用map、hashtable等或维持一个额外的class function address table或许会更好？不知道为什么你会不喜欢虚函数，编译器帮你搞定的间接层，而且不比你自己写性能低。
Fuzhou Chen
> function address table或许会更好？
这这这……莫不是传说中的MFC？
> 运行时多态的概念很好，但是我总觉得虚函数（以及虚函数表）
> 的实现形式实在是很丑陋。
再说虚函数表的***实现形式***，真的那么重要？C++语法上并没有
暴露出虚函数表，我们用C++的时候基本上没什么机会关注虚函数
表是怎么实现的，除非——dachuan你和我一样，必须成天读反汇
编的C++代码。但我那是工作所迫，广大C++爱好者们估计没什么闲
心以看这个为乐吧。
2010/7/9 dachuan lin <lindach...@gmail.com>:
--
《采莲》·江南
为卿采莲兮涉水，为卿夺旗兮长战。为卿遥望兮辞宫阙，为卿白发兮缓缓歌。
另抄自蒜头的评论：http://www.douban.com/review/1573456/：
且祭一束紫琳秋，为一段落花流水的传说
且饮一杯青花酒，为一场几多擦肩的错过
且焚一卷旖旎念，为一腔抛付虚无的惜怜
且歌一曲罢箜篌，为一刻良辰春宵的寂寞
dachuan lin
Fuzhou Chen
顺便也OT一下：其实基于COM的虚函数表还算好，跟GCC的
多继承表比起来，相对算容易理解的。
2010/7/9 dachuan lin <lindach...@gmail.com>:
莫华枫
严格来说，C和C++用来解决代码生成的技术，其实是走错了方向。
1、对于C来说，代码生成的方式主要是靠宏，其带来的问题就不用说了；
2、C++的创造者发现了宏的问题，其改善的方法，一个是发明了继承，不过这个其实只是擦擦边而已，真正接触到核心的还是模板（template）的引入。
但是，这两者都是在歧路上越走越远。真正的解决之道，一方面如C#引入的，attribute，特性，
另一方面，其实就应该光明正大的引入代码生成语言（不错，make configuration就是解决之道，可惜的是没有真正和C完全融合，并形成标准），以及预编译的模板库（或者类型库）。
其实工程界早都已经自觉不自觉的引入了这些技术，比如windows下微软的类型库，以及广泛使用的make等技术，只是都不敢或者没想到把这些完全融合在一起。
在我的理想中，真的希望能够有一种语言，可以完全实现以下的功能：
1、类似C的语法；
2、强类型语言，但是可以静态自动类型推断；
3、代码分两部分：生成阶段语言和运行阶段语言，编译器可以作为库链入代码中；
4、在生成库的时候，带上最完整的类型信息，最后link为exe时可以尽可能优化；
5、预编译模板库；
6、完整的静态接口设计；
7、原生支持并行；
8、原生支持GC；
莫华枫
没错，我知道这个和concept很相近，但是C++中的concept搞得很复杂，我不知道为什么，其实如果换个角度，把concept当作是编译器的指令代码，可以有特权来访问编译的
时候生成的类型完整信息的话，其实现会非常简单。
宏是一个非常好的代码生成技术。当然，C的宏由于自身的一些限制导致不够理想，但是m4明显舒服的多，更别说scheme了。你说的“类型库”就是“预编译的模板库”么？不太清楚你的标的是什么。不过业界早已把make技术用于代码生成了。类型库指的是你创建的库中所有的类型和函数的完整信息，比如类名，成员变量名称、类型，成员函数名称、参数、返回值、虚实等等。
同时，如果是模板类型的话，则会包含多重实践的代码；这个有点像delphi的单元+tlb
在我的理想中，真的希望能够有一种语言，可以完全实现以下的功能：
1、类似C的语法；C的语法是如此的不清晰，还是不类似的好一些。简洁还是类C的好。当然新语言可以完全不考虑缺省类型自动转换等混淆的部分；
2、强类型语言，但是可以静态自动类型推断；好特性。好难。Haskell和OCaml以及Scala都有这些设施。3、代码分两部分：生成阶段语言和运行阶段语言，编译器可以作为库链入代码中；至少现在的Java和.Net平台都提供了Compiler访问的API。而且编译器作为应用的一部分逻辑上需要虚拟机支撑，否则应用不能部署。而部署虚拟机本身就是一个问题。这个功能我觉得可以实现 嵌入式的脚本编译，脚本相当于是自己的语言。
为什么要虚拟机呢？比如在windows下生成的程序，自带windows下的compiler和linker，你可以在程序运行中，自动或由用户输入生成一段代码，然后调用附带的compiler编译到内存中，
然后返回函数指针，即可以进行调用。
4、在生成库的时候，带上最完整的类型信息，最后link为exe时可以尽可能优化；LLVM。是个好选择。是否可以用于代码生成？5、预编译模板库；……，不是很清楚这是什么意思，你是指C++的模板么？或许是指.NET的Generic？参见上面的例子。其实就是根据不同的生成选项 先 生成不同的代码 集结成库，方便快速进行链接。
当然其大小可能很大，但是比源码要快，同时在生成实际代码的时候只链入实际的部分。
6、完整的静态接口设计；这年头，动态接口才是新闻。这个是和C++和JAVA的接口相比较的，实际上是在编译的时候进行多态，所以完全不需要继承和虚函数。
7、原生支持并行；
如果是通用目的的并行，现在的Thread和Lock就完全支持了。而且也似乎只有它们才支持通用目的的并行。如果是特定场景下的并行，似乎不应该作为语言的特性存在吧。我觉得并行代码应该在底层支持映射到不同平台，同时定义一些原子级的变量、锁和操作
8、原生支持GC；
GC似乎仍然达不到通用目的。仍有适用场景。最好是可以通过声明允许或者禁止的。这个确实。可以禁止。
莫华枫
在 2010年7月9日 下午11:49，Milo Yip <mil...@gmail.com>写道：C# 2.0 的 var 和 C++0x 的 auto 可滿足你對靜態自動類型推導的要求麼?差不多。不理解"完整的静态接口设计"比如下面的代码：
[@gen: type TYPE is CLASS]
interface COMPARE {
int compare( TYPE &a1, TYPE &a2);
}
class COMPLEX
{
int compare ( COMPLEX &a, COMPLEX &b){ ... }[@gen: elseif TYPE is CLASS && TYPE has @interface:COMPARE then]
}
[@gen: type TYPE]
int max(TYPE &a1, TYPE &a2)
{
[@gen: if TYPE is NUMBER then ]
return (a1>a2)? a1: a2;void fun1()
return a1.compare(a2);
[@gen: else]
throw std::exception::member_not_defined;
[@gen: endif]
}
{
COMPLEX a, b;
return max(a, b);
}
可以看到，COMPLEX类完全不需要从COMPARE继承，也不需要任何的虚函数，在编译的时候， 自动会检查是否包含了interface的相关函数或成员，如果是就自动链入
其相对应的函数。要这么做，必须在编译的时候，编译器完全知道所有相关类型的信息。
莫华枫
traits好用就没人呼吁concept了。我其实就是想完善一下concept，把它彻底从“运行期代码”提升到“编译器代码”，同时完成绝大部分条件编译的功能而已；type traits不需要继承，不需要虚函数，不需要是自定义类，原始类型【比如int】也可以用。只是程序员手工把某些信息收集包装起来交给编译器，然后编译器就可以通过类型来进行静态分派了。对于C++来说，traits的成员主要是typedef，ok？
dachuan lin
顺便也OT一下：其实基于COM的虚函数表还算好，跟GCC的
多继承表比起来，相对算容易理解的。
我在这里想比较深入的讨论一下关于“模板”和“条件编译”和“concept”等几个问题，基本上算是使用C、C++近十年的一点困惑和总结
1、关于模板，很显然这一开始就是为了解决“代码重用”的问题而来。问题是，C++中的模板和其要替代的“宏”一样，充满了非常大的缺陷，主要问题有几个：
【1】模板和宏一样，不了解参数的类型信息，为了区分使用了很多的匪夷所思的技巧，trait技术就是其中的佼佼者。问题是这对普通程序员带来巨大的学习和使用负担，同时，现有的编译器技术又不能很好的解决问题的定位问题，出错的信息冗长晦涩；
【2】模板并不能完全取代宏，它无法实现“条件编译”，从而无法实现编译时的配置。宏的“条件编译”问题见下面。由于这个原因，模板必须和宏共存；
【3】现有的大部分模板和宏一样，必须提供源码，导致在包含大的模板库的时候，有大量的编译时间耗费在不断的重复劳动中，而且也无法提供“知识产权”的保护。
综上，我个人认为模板技术是很不完备的，为了解决【1】而引入的concept，其问题也很大，放在下面阐述；为了解决【3】，必须提供预编译的模板库；
2、关于“条件编译”，首先我们要看到目前C、C++，不管是linux、windows几乎最后都回到makefile的使用上。当然有朋友会争论makefile并不是C或者C++，但是我们必须要看到这和实际的编程融合得越来越紧密，而且如果把眼光放开，就会发现其实所谓“通用编程，GP“，就是一种“条件编译”，就是“代码生成”，这三者实际上是一体的！
但是现有的makefile中的问题，是其采用了一套类似脚本的语言，其对象只是以文件为单位，粒度太大；以宏技术为主的条件编译，又不知道类型；GP知道类型了，又无法实现文件级别的融合。
3、关于“concept”，基本思想是很好的，但是主要问题是耦合度太高。我们知道编码应该追求的是松耦合，但是concept却强令类型和某concept强绑定。这为类的编写带来了不必要的限制。再以我上面的例子为例：
[@gen: type TYPE is CLASS]
interface COMPARE {
int compare( TYPE &a1, TYPE &a2);
}
class COMPLEX
{
int compare ( COMPLEX &a, COMPLEX &b){ ... }
}
[@gen: type TYPE]
int max(TYPE &a1, TYPE &a2)
{
[@gen: if TYPE is NUMBER then ]
return (a1>a2)? a1: a2;
return a1.compare(a2);
[@gen: else]
throw std::exception::member_not_defined;
[@gen: endif]
}
{
COMPLEX a, b;
return max(a, b); //---（1）
}
上面的代码中我们可以看到COMPLEX不需要从interface COMPARE中继承，它只需要带一个名称是compare的函数即可，（1）行中代码生成的时候，由编译器自动对interface compare和 COMPLEX类中的成员函数进行交叉匹配，如果合适就生成代码，否则指出不匹配错误。这样的代码完全可以自由胶合任意的第三方代码和原始类，达到低度耦合的目的。
莫华枫
顺便也OT一下：其实基于COM的虚函数表还算好，跟GCC的
多继承表比起来，相对算容易理解的。没错，ms不也臭屁的说：COM是更好的C++吗？呵呵
我在这里想比较深入的讨论一下关于“模板”和“条件编译”和“concept”等几个问题，基本上算是使用C、C++近十年的一点困惑和总结
1、关于模板，很显然这一开始就是为了解决“代码重用”的问题而来。问题是，C++中的模板和其要替代的“宏”一样，充满了非常大的缺陷，主要问题有几个：
【1】模板和宏一样，不了解参数的类型信息，为了区分使用了很多的匪夷所思的技巧，trait技术就是其中的佼佼者。问题是这对普通程序员带来巨大的学习和使用负担，同时，现有的编译器技术又不能很好的解决问题的定位问题，出错的信息冗长晦涩；
【2】模板并不能完全取代宏，它无法实现“条件编译”，从而无法实现编译时的配置。宏的“条件编译”问题见下面。由于这个原因，模板必须和宏共存；
【3】现有的大部分模板和宏一样，必须提供源码，导致在包含大的模板库的时候，有大量的编译时间耗费在不断的重复劳动中，而且也无法提供“知识产权”的保护。
综上，我个人认为模板技术是很不完备的，为了解决【1】而引入的concept，其问题也很大，放在下面阐述；为了解决【3】，必须提供预编译的模板库；
2、关于“条件编译”，首先我们要看到目前C、C++，不管是linux、windows几乎最后都回到makefile的使用上。当然有朋友会争论makefile并不是C或者C++，但是我们必须要看到这和实际的编程融合得越来越紧密，而且如果把眼光放开，就会发现其实所谓“通用编程，GP“，就是一种“条件编译”，就是“代码生成”，这三者实际上是一体的！
但是现有的makefile中的问题，是其采用了一套类似脚本的语言，其对象只是以文件为单位，粒度太大；以宏技术为主的条件编译，又不知道类型；GP知道类型了，又无法实现文件级别的融合。
3、关于“concept”，基本思想是很好的，但是主要问题是耦合度太高。我们知道编码应该追求的是松耦合，但是concept却强令类型和某concept强绑定。这为类的编写带来了不必要的限制。再以我上面的例子为例：
[@gen: type TYPE is CLASS]
interface COMPARE {
int compare( TYPE &a1, TYPE &a2);
}
class COMPLEX
{
int compare ( COMPLEX &a, COMPLEX &b){ ... }[@gen: elseif TYPE is CLASS && TYPE has @interface:COMPARE then]
}
[@gen: type TYPE]
int max(TYPE &a1, TYPE &a2)
{
[@gen: if TYPE is NUMBER then ]
return (a1>a2)? a1: a2;int fun1()
return a1.compare(a2);
[@gen: else]
throw std::exception::member_not_defined;
[@gen: endif]
}
{
COMPLEX a, b;
return max(a, b); //---（1）
}
上面的代码中我们可以看到COMPLEX不需要从interface COMPARE中继承，它只需要带一个名称是compare的函数即可，（1）行中代码生成的时候，由编译器自动对interface compare和 COMPLEX类中的成员函数进行交叉匹配，如果合适就生成代码，否则指出不匹配错误。这样的代码完全可以自由胶合任意的第三方代码和原始类，达到低度耦合的目的。
莫华枫
dachuan lin
Fuzhou Chen
> 【1】模板和宏一样，不了解参数的类型信息，为了区分使用了很多的
> 匪夷所思的技巧，trait技术就是其中的佼佼者。问题是这对普通程序员
> 带来巨大的学习和使用负担，同时，现有的编译器技术又不能很好的解
> 决问题的定位问题，出错的信息冗长晦涩；
模板确实不了解参数的类型信息，但我也一样可以说，OOP也不可以。
因为计算机永远不知道所谓的类型究竟是做什么用的。模板提供是类
型推导和分派的手段，正如引入了OOP使得程序员必须考虑类的继承
关系一样，引入了模板就使得程序员必须考虑类型推导，而这个推导的
具体手法就是通过traits。这是为了利用工具必须支付的学习成本，算
不上什么负担，只是我们得选择，看这个学习成本是不是能够被这个工
具带来的便利抵消掉。
而且即便是C++真的如老莫所言引入了concept，我认为这也不是问题的
结束。我相信真的引入了concept的那一天，我们肯定会开始面对新的麻
烦。虽然我们不能据此就从此拒绝引入concept，但这些麻烦绝对不能认
为是concept的缺陷。
> 【2】模板并不能完全取代宏，它无法实现“条件编译”，从而无法实
> 现编译时的配置。宏的“条件编译”问题见下面。由于这个原因，模板必须和宏共存；
这话就不对了。dachuan你前面说模板主要是为了解决代码重用，但条件编译
并不是代码重用的一部分，而是项目管理任务的一部分。所以模板其实没有必
要去解决。事实上现在更多的人都倾向于用编译管理工具（ant、scons、
msbuild）之类的来解决这个问题，而避免在代码中到处安插条件编译——还是
那句老话，这是可读性问题，不是可行性问题。而且根据UNIX的一般原则，我
个人也不喜欢用一个工具解决所有问题。
> 【3】现有的大部分模板和宏一样，必须提供源码，导致在包含大的模板库
> 的时候，有大量的编译时间耗费在不断的重复劳动中，而且也无法提供“知
> 识产权”的保护。
我认为这是实现问题，不是模板这个概念的问题。VC的预编译可以在很大程
度上减轻重复劳动的开销。只是可惜C++标准为了保证和#include兼容，没有
要求定义二进制的模板文件格式。如果能跟Obj-C那样提供一个#import，问题
估计就减轻很多。
至于知识产权保护么，我说一句不客气点的话：无论出于何种目的，任何玩弄
类型的代码，模板也罢，OOP的接口也罢，都不能改变它没有实际功能的本质。
Boost里的很多函数库也证明了，厂商是可以通过混用模板和二进制代码避免
暴露实现的。厂商保护的是真正完成实际任务的代码。如果连模板推导都要保护，
我宁可不再使用这个厂商的产品。
dachuan lin
2010/7/9 dachuan lin <lindach...@gmail.com>:
> 【1】模板和宏一样，不了解参数的类型信息，为了区分使用了很多的
> 匪夷所思的技巧，trait技术就是其中的佼佼者。问题是这对普通程序员
> 带来巨大的学习和使用负担，同时，现有的编译器技术又不能很好的解
> 决问题的定位问题，出错的信息冗长晦涩；
模板确实不了解参数的类型信息，但我也一样可以说，OOP也不可以。
因为计算机永远不知道所谓的类型究竟是做什么用的。模板提供是类
型推导和分派的手段，正如引入了OOP使得程序员必须考虑类的继承
关系一样，引入了模板就使得程序员必须考虑类型推导，而这个推导的
具体手法就是通过traits。这是为了利用工具必须支付的学习成本，算
不上什么负担，只是我们得选择，看这个学习成本是不是能够被这个工
具带来的便利抵消掉。
而且即便是C++真的如老莫所言引入了concept，我认为这也不是问题的
结束。我相信真的引入了concept的那一天，我们肯定会开始面对新的麻
烦。虽然我们不能据此就从此拒绝引入concept，但这些麻烦绝对不能认
为是concept的缺陷。
> 【2】模板并不能完全取代宏，它无法实现“条件编译”，从而无法实
> 现编译时的配置。宏的“条件编译”问题见下面。由于这个原因，模板必须和宏共存；这话就不对了。dachuan你前面说模板主要是为了解决代码重用，但条件编译
并不是代码重用的一部分，而是项目管理任务的一部分。所以模板其实没有必
要去解决。事实上现在更多的人都倾向于用编译管理工具（ant、scons、
msbuild）之类的来解决这个问题，而避免在代码中到处安插条件编译——还是
那句老话，这是可读性问题，不是可行性问题。而且根据UNIX的一般原则，我
个人也不喜欢用一个工具解决所有问题。
不过确实静下心来考虑，确实不太符合UNIX的原则。
> 【3】现有的大部分模板和宏一样，必须提供源码，导致在包含大的模板库
> 的时候，有大量的编译时间耗费在不断的重复劳动中，而且也无法提供“知
> 识产权”的保护。
我认为这是实现问题，不是模板这个概念的问题。VC的预编译可以在很大程
度上减轻重复劳动的开销。只是可惜C++标准为了保证和#include兼容，没有
要求定义二进制的模板文件格式。如果能跟Obj-C那样提供一个#import，问题
估计就减轻很多。
我还是觉得，如果实现太难，那么可能暗示了这个概念有很大的缺陷。
至于知识产权保护么，我说一句不客气点的话：无论出于何种目的，任何玩弄
类型的代码，模板也罢，OOP的接口也罢，都不能改变它没有实际功能的本质。
Boost里的很多函数库也证明了，厂商是可以通过混用模板和二进制代码避免
暴露实现的。厂商保护的是真正完成实际任务的代码。如果连模板推导都要保护，
我宁可不再使用这个厂商的产品。
莫华枫
> 【3】现有的大部分模板和宏一样，必须提供源码，导致在包含大的模板库
> 的时候，有大量的编译时间耗费在不断的重复劳动中，而且也无法提供“知
> 识产权”的保护。
我认为这是实现问题，不是模板这个概念的问题。VC的预编译可以在很大程
度上减轻重复劳动的开销。只是可惜C++标准为了保证和#include兼容，没有
要求定义二进制的模板文件格式。如果能跟Obj-C那样提供一个#import，问题
估计就减轻很多。兄弟，这个问题出现得太久，影响也太大。我感觉标准委员会是不想解决，比如extern template，但是似乎存在很大的问题。
我还是觉得，如果实现太难，那么可能暗示了这个概念有很大的缺陷。
dachuan lin
est
2010/7/7 Guanqun Lu <guanq...@gmail.com>:
> golang首先一点就不支持windows系统，这个就会对它的大规模流行产生负作用。
>
> 2010/7/7 Kula <kula...@gmail.com>:
>> 呵呵，20多年过去了，这个时候再来说c++处理大型项目的能力开始浮现，会不会太迟了。
>> 其实花在关注c++上的时间，我们完全可以拿来关注golang.假以时日，等golang成熟了.大批大批的软件又会用golang 重写。
>>
>>
>> 2010/7/7 Changsheng Jiang <jiang...@gmail.com>
>>>
>>> 赞同这句话.
>>>
>>> 在C编程时, 我最想用的 C++ 特性是模板式的代码生成, 这个可以减少重复代码量. 再一个是析构函数. 这个主要是在资源申请时指定资源释放,
>>> 并自动化.
>>>
>>> 模板在 C 里用宏比较丑陋. 我用过CPP之外的处理程序生成代码.
>>>
>>> 析构函数的自动化, 实在无法. 一个方法是将资源释放注册到一个栈式的地方, 栈弹出一层, 自动释放此层对应的所有资源.
>>>
>>> 反而觉得面向对象不是C++吸引C程序员的特性. 觉得面向接口更简单直接, 见过一些Ｃ++代码, 先声明接口 Interface, 再实现
>>> Impl, 实是受强类型的面向对象所累.
>>>
>>> 不知大家欣赏的C++ - C 的特性是什么?
>>>
>>> Changsheng Jiang
>>>
>>>
>>> 2010/7/7 up duan <fix...@gmail.com>
>>>>
>>>>
>>>> 2010/7/6 CXX16 <cplus...@gmail.com>
>>>>>
>>>>> 其实这个问题应该问为什么LLVM和CLANG要用C++。
>>>>>
>>>>
>>>> 作为一个没有压力的新项目，选择什么语言主要取决于实施者的感觉了。所以LLVM采用C++不太能说明什么问题。但是传统的C项目改为C++就很有说服力了。
>>>
>>
>>
>
>
>
> --
> Guanqun
>
Yongwei Wu
> 在 2010年7月11日 上午4:29，Fuzhou Chen <cppo...@gmail.com>写道：
>> > 【3】现有的大部分模板和宏一样，必须提供源码，导致在包含大的模板库
>> > 的时候，有大量的编译时间耗费在不断的重复劳动中，而且也无法提供“知
>> > 识产权”的保护。
>>
>> 我认为这是实现问题，不是模板这个概念的问题。VC的预编译可以在很大程
>> 度上减轻重复劳动的开销。只是可惜C++标准为了保证和#include兼容，没有
>> 要求定义二进制的模板文件格式。如果能跟Obj-C那样提供一个#import，问题
>> 估计就减轻很多。
#import和#include没有本质区别吧。而且，Objective-C也不支持模板。
> 兄弟，这个问题出现得太久，影响也太大。我感觉标准委员会是不想解决，比
> 如extern template，但是似乎存在很大的问题。我还是觉得，如果实现太
> 难，那么可能暗示了这个概念有很大的缺陷。
是我理解错了，还是大家没听说过export这个关键字？不需要源代码的模板概念
早就被提出来了，但只有Comeau一家实现了。
http://www.comeaucomputing.com/4.0/docs/userman/export.html
由于实现非常复杂，困难度很高，目前没有其他编译器支持，所以实际上没人使
用。这似乎也是唯一一次C++标准委员会把一个还没经过验证的特性加到标准里
（C++-98）。确实，这个概念“听起来很美”。
我听说export将在C++0x中被deprecate。
--
Wu Yongwei
URL: http://wyw.dcweb.cn/
up duan
> 兄弟，这个问题出现得太久，影响也太大。我感觉标准委员会是不想解决，比
> 如extern template，但是似乎存在很大的问题。我还是觉得，如果实现太
> 难，那么可能暗示了这个概念有很大的缺陷。
是我理解错了，还是大家没听说过export这个关键字？不需要源代码的模板概念
早就被提出来了，但只有Comeau一家实现了。
http://www.comeaucomputing.com/4.0/docs/userman/export.html
由于实现非常复杂，困难度很高，目前没有其他编译器支持，所以实际上没人使
用。这似乎也是唯一一次C++标准委员会把一个还没经过验证的特性加到标准里
（C++-98）。确实，这个概念“听起来很美”。
我听说export将在C++0x中被deprecate。
dachuan lin
当初为什么要加入，就是因为实在太重要了。
这个特性废弃太可惜了。
Fuzhou Chen
跟C传统的编译模型是冲突的，所以大部分编译器厂商在实现的
时候应该是遭遇了实际的困难而不愿意支持这个特性。有时候我
也想，如果是Effiel那样支持全局分析的编译器，或许这个问题就
好办很多。
至于Yongwei说的“#import和#include没有区别”，我想我没说明白。
我的意思是如果当初C++的设计过程中能够不那么严格地遵守“和C
共享连接器”这个要求，就可能在编译层面大胆引入一些功能使全
局编译变得可行，那么这个export关键字也许就没有这么难实现。
可惜，历史是不能如果的。
厂商问题么，之前我激动了些，现在想想，俺们说这个确实不合
适，还是搁置吧，别在意，呵呵。
2010/7/11 dachuan lin <lindach...@gmail.com>:
--
Kula
Fuzhou Chen
Jack.Chu
On Jul 9, 9:58 pm, dachuan lin <lindachuan2...@gmail.com> wrote:
> 严格来说，C和C++用来解决代码生成的技术，其实是走错了方向。
> 1、对于C来说，代码生成的方式主要是靠宏，其带来的问题就不用说了；
> 2、C++的创造者发现了宏的问题，其改善的方法，一个是发明了继承，不过这个其实只是擦擦边而已，真正接触到核心的还是模板（template）的引入。
> 但是，这两者都是在歧路上越走越远。真正的解决之道，一方面如C#引入的，attribute，特性，另一方面，其实就应该光明正大的引入代码生成语言（不错，make
> configuration就是解决之道，可惜的是没有真正和C完全融合，并形成标准），以及预编译的模板库（或者类型库）。
> 其实工程界早都已经自觉不自觉的引入了这些技术，比如windows下微软的类型库，以及广泛使用的make等技术，只是都不敢或者没想到把这些完全融合在一起。
> 在我的理想中，真的希望能够有一种语言，可以完全实现以下的功能：
> 1、类似C的语法；
> 2、强类型语言，但是可以静态自动类型推断；
> 3、代码分两部分：生成阶段语言和运行阶段语言，编译器可以作为库链入代码中；
> 4、在生成库的时候，带上最完整的类型信息，最后link为exe时可以尽可能优化；
> 5、预编译模板库；
> 6、完整的静态接口设计；
> 7、原生支持并行；
> 8、原生支持GC；
>
> 在 2010年7月9日 下午2:57，莫华枫 <longshank...@gmail.com>写道：
>
> > C++优点和缺点一样明显。
> > 严格地讲，C++的优点也不是什么特别伟大的东西，只是顺应了一些本质规律，给予更多的选择，而不是拘泥于某种单一的范式。
>
> > C++的缺点则来源广泛，一部分来自C，比如non-lr的语法，隐式的类型转换，资源管理困难，陈旧的编译模型等等。有些来自于过于机巧的设计，比如默认的隐式类型转换构造和操作符，操作符","的重载等等。有些来自于委员会的扯皮，比如ABI问题，逻辑操作的执行次序问题等等。以及添油式的设计，比如GP作为后加入的特性无法同早期OOP特性完美地协调。
>
> > BS创建C++的时候试图利用OOP消除C存在的问题。但是全面兼容C减少了推广的困难，却导致了语法上的混乱。毕竟C是一门独立完备的语言，设计时也没有考虑未来的特性扩展，使得原本non-lr的语法更加复杂，编译时间暴涨，而编译器的开发更加困难。
>
> > OOP的引入当时看起来是对C语言很好的扩充，但现在看来OOP反而引发了很多问题。问题的根源在于OOP并非完善的抽象体系。相反，OOP只能算作一个半熟的解决方案。在C++领域中，OOP有广义和狭义之分。广义上，OOP包括OB、重载和动多态，甚至有人将GP的一些特性算作OOP范畴。狭义上，OOP单指动多态。真正有问题的是狭义OOP，即动多态。
>
> > OB是C++最重要的特性，这是一个完全正面的特性。封装是所有抽象的基础。在此基础上增设的RAII（即自动对象）是C++相对于C最好的补充。RAII允许进入和离开一个scope时执行特定的操作，这是一种极好的资源和状态管理的手段。
> > 继承是依附于封装的特性，但继承存在两重性。作为代码重用机制，很大地提高了开发效率。但另一方面，继承却不恰当地成为OOP的动多态基础。
>
> > OOP（以下OOP仅指动多态）是一种有缺陷的抽象机制，是基于类型和继承的多态。但其中存在根本性的问题。举个例子，计算金额，我们会说把单价*数量。用程序员的语言，就是：一个浮点数*一个整数。这是抽象的说法，说这句话的时候我们没有明确指定单价是什么样的浮点数，是single还是double，什么样的整数，是4字节还是8字节。这是很自然的逻辑。但是在OOP中无法这样描述。我们只能说：一个从float类型上继承的数*一个从integer类型上继承的数。因为在OOP中是通过一种类型来描述一组类型的，两者的联系就是继承。这中间的问题在于，继承是一种很强的耦合关系，依赖于这种关系的抽象体系是侵入的。由于继承关系的存在，接口成为了类型的一部分，一个类型所支持的接口，必须在定义时决定，以后无法扩展。即便一个类型同一个接口完全一致，只要没有继承关系，就不是一家人。形象地说，老虎A，无论多么像老虎B，只要不是老虎B的崽，它就不是老虎。这显然是荒谬的。问题就是我们用一只老虎来指代老虎这个物种。OOP却是这么做的，用一个类型来抽象一组类型。
> > 更糟糕的是，C++引入OOP还带来了意想不到的问题。首当其冲的是对象切割问题：
> > class A
> > {...};
>
> > class B : public A
> > {...};
>
> > B arrayB[10];
> > A pa = arrayB;
> > pa[3]->... //你访问的是什么？
>
> > 很显然，最后那行代码是一个错误的访问。pa[3]是按A计算的偏移，而pa真正指向的是B的数组，两者的偏移可能是不一样的。问题的根本是为了实现动多态，继承类指针可以隐式地转换成基类的指针。而C的数组和指针又是等价的。
> > 从这一点上说，C是不适合引入OOP机制的。C太底层，而OOP又不完备。
>
> > 但另一种抽象机制----GP的引入却是非常恰当的。模板，无论是类模板还是函数模板，提供了一套完全独立于类型的抽象系统，很好地回避了"老虎不是老虎"的问题。而在C++0x中引入未果的concept则是GP机制的一个重要的完善。
> > OOP和GP两种机制分别应对动多态和静多态。看似相互补充，各有分工，但实际上凭空增加了语言的复杂性，难于融合。OOP本身的缺陷加剧了问题的混乱。一种语言只应当有一种抽象体系。对C而言，如果要增加抽象体系，GP比OOP更合适。GP目前只有静多态。但是随着concept的完善，runtime
> > concept也浮出水面，进而促使GP具备动态的抽象能力。这样程序员就不会迷失在两套不同的抽象体系中。
> > GP还有能力消除C语言的某些缺陷。比如，C不能算真正意义上的强类型，因为存在隐式类型转换，容易造成编码的错误。这一点在当年C vs
> > Pascal的论战中是重要的把柄。但如果没有这些转换，又无法获得足够的灵活性。C++对C所作的扩展并未解决这些问题，反而增加了其他更多的问题，特别是依赖于继承的隐式类型转换。而GP的抽象体系却可以在强化C的类型系统的情况下，提供足够的灵活性。这一点在Ada上就有所体现。Ada是先有GP（Ada83），后有OOP（Ada95）。如果Ada能够向runtime
> > GP，而非时髦的OOP发展，或许更有意义。
>
> > --
> > 反者道之动，弱者道之用
> > longshank...@gmail.com
> >http://blog.csdn.net/longshanks/
> > wave开通
Yongwei Wu
现在再搜了一下，翻墙看到了Sutter的三月会议总结：
For context, the only reason we’re even considering this [deprecate,
remove, or leave] is because Edison Design Group (EDG), the only
company to ever implement export, is recommending export be removed or
deprecated. Recall that back in the 1990s the committee originally
voted the feature in over EDG’s objections in the first place, then in
the late 1990s and early 2000s EDG graciously and gallantly went on to
invest enormous effort to implement the feature in order to conform to
the standard, and so the committee was loath to punish them again by
now removing the feature on them. However, given the passage of time,
EDG reports that their experience in the field has been that nearly no
one actually uses the feature, and that it would be right (and okay
with EDG) to deprecate or remove it.
At our previous meeting, the general sentiment was in favor of
deprecation only. However, at this meeting EDG reported that they
would prefer the feature to be removed rather than just deprecated,
because a deprecated feature is still part of the standard and
required for conformance. By removing it from C++0x, it removes the
maintenance burden of being forced to support export indefinitely to
maintain full standards conformance (though of course EDG will
continue to support it as an extension in their compiler front end for
however long seems right based on their own customers’ demand).
The committee agreed, and today voted to remove export entirely from
C++0x. The “export” keyword is still reserved for future use, but has
no defined meaning in the C++0x standard.
上次是考虑要废弃的。而唯一实现了export的公司（Comeau使用的就是EDG的技
术）都出来说赞成删除，于是export就被干掉了。