周星星 阅读(3050) 评论(64)

有关模板的语法很多很杂,无法一一列举,在此仅测试几个简单常用的语法。
以下有关模板的语法分别使用 gcc3.4.2、VC++6.0 和 Intel C++8.0 进行测试,GCC342和ICC都能完全通过测试,VC++6.0有部分通不过测试。

1. 模板类静态成员
template <typename T> struct testClass {
    static int _data;
};
template<> int testClass<char>::_data = 1;
template<> int testClass<long>::_data = 2;
int main( void ) {
    cout << boolalpha << (1==testClass<char>::_data) << endl;
    cout << boolalpha << (2==testClass<long>::_data) << endl;
}

2. 模板类偏特化
template <class I, class O> struct testClass {
    testClass() { cout << "I, O" << endl; }
};
template <class T> struct testClass<T*, T*> {
    testClass() { cout << "T*, T*" << endl; }
};
template <class T> struct testClass<const T*, T*> {
    testClass() { cout << "const T*, T*" << endl; }
};
int main( void ) {
    testClass<int, char> obj1;
    testClass<int*, int*> obj2;
    testClass<const int*, int*> obj3;
}
[注]: VC++6 编译不通过

3. function template partial order
template <class T> struct testClass {
    void swap( testClass<T>& ) { cout << "swap()" << endl; }
};
template <class T> inline void swap( testClass<T>& x, testClass<T>& y ) {
    x.swap( y );
}
int main( void ) {
    testClass<int> obj1;
    testClass<int> obj2;
    swap( obj1, obj2 );
}
[注]: VC++6 编译不通过

4. 类成员函数模板
struct testClass {
    template <class T> void mfun( const T& t ) {
        cout << t << endl;
    }
    template <class T> operator T() {
        return T();
    }
};
int main( void ) {
    testClass obj;
    obj.mfun( 1 );
    int i = obj;
    cout << i << endl;
}
[注]: 对于第二个成员函数模板,VC++6 运行异常

5. 缺省模板参数推导
template <class T> struct test {
    T a;
};
template <class I, class O=test<I> > struct testClass {
    I b;
    O c;
};

6. 非类型模板参数
template <class T, int n> struct testClass {
    T _t;
    testClass() : _t(n) {
    }
};
int main( void ) {
    testClass<int,1> obj1;
    testClass<int,2> obj2;
}

7. 空模板参数
template <class T> struct testClass;
template <class T> bool operator==( const testClass<T>&, const testClass<T>& ) {
    return false;
};
template <class T> struct testClass {
    friend bool operator== <>( const testClass&, const testClass& );
};
[注]: VC++6 编译不通过

8. 模板特化
template <class T> struct testClass {
};
template <> struct testClass<int> {
};

9.
template <template <class T> class X>
    struct Widget{
};
[注]: VC++6 编译不通过

10. [hpho]提供的一个事例
struct Widget1 {
template<typename T>
    T foo(){}
};
template<template<class T>class X>
    struct Widget2{
};
[注]: VC++6 编译不通过

11. 数组作模板实参
template<class T,size_t N>void foo( T (&bar)[N] )
{
    cout << typeid(T).name() << " (&bar)[" << N << "]" << endl;
};
int main()
{
    int a[10];
    foo( a );
    return 0;
}
[注]: VC++6 编译不通过

12. 模板作为模板的参数
template< class T, template<class K> class Y >
void Test( T, Y<T> )
{
}
[注]: VC++6 编译不通过

13.
template<class T> struct foo
{
    foo() {}
    foo( const foo& ) {}
    template<class Q> foo( const foo<Q>& ) {}
};
int main()
{
    foo<int> a;
    foo<int> b(a);
    foo<long> c(a);
}
[注]:
VC++6 编译不通过、ICC没有测试


评论列表
Mick
re: 测试一下 Intel C++8.0 对模板的支持程度
和VC6.0没比较性。要和VC7.1比
netsin
re:
呵呵,VC6只能处理一些最简单的模板.VC6对模板支持的差是出了名的
netsin
re: 和VC6.0没比较性。要和VC7.1比
为什么没有必要?现在用VC6的人多的是,我几个同事都用这个,而没有一个用VC71的
周星星
to Mick:
谢谢您的评论,但我和netsin的观点一致:没人用VC7.1和VC8.0。

VC++6.0的唯一优点是其IDE做得不错,界面科学,速度也很快,而后来的VC++已经没有任何优点了。
七猫
intel of boost
#if defined(_WIN32) || defined(_WIN64)
# define BOOST_INTEL_WIN BOOST_INTEL
#else
# define BOOST_INTEL_LINUX BOOST_INTEL
#endif

#if (BOOST_INTEL_CXX_VERSION <= 500) && defined(_MSC_VER)
# define BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS
# define BOOST_NO_TEMPLATE_TEMPLATES
#endif

#if (BOOST_INTEL_CXX_VERSION <= 600)

# if defined(_MSC_VER) && (_MSC_VER <= 1300) // added check for <= VC 7 (Peter Dimov)

// Boost libraries assume strong standard conformance unless otherwise
// indicated by a config macro. As configured by Intel, the EDG front-end
// requires certain compiler options be set to achieve that strong conformance.
// Particularly /Qoption,c,--arg_dep_lookup (reported by Kirk Klobe & Thomas Witt)
// and /Zc:wchar_t,forScope. See boost-root/tools/build/intel-win32-tools.jam for
// details as they apply to particular versions of the compiler. When the
// compiler does not predefine a macro indicating if an option has been set,
// this config file simply assumes the option has been set.
// Thus BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP will not be defined, even if
// the compiler option is not enabled.

# define BOOST_NO_SWPRINTF
# endif

// Void returns, 64 bit integrals don't work when emulating VC 6 (Peter Dimov)

# if defined(_MSC_VER) && (_MSC_VER <= 1200)
# define BOOST_NO_VOID_RETURNS
# define BOOST_NO_INTEGRAL_INT64_T
# endif

#endif

#if (BOOST_INTEL_CXX_VERSION <= 710) && defined(_WIN32)
# define BOOST_NO_POINTER_TO_MEMBER_TEMPLATE_PARAMETERS
#endif

// See http://aspn.activestate.com/ASPN/Mail/Message/boost/1614864
#if BOOST_INTEL_CXX_VERSION < 600
# define BOOST_NO_INTRINSIC_WCHAR_T
#else
// We should test the macro _WCHAR_T_DEFINED to check if the compiler
// supports wchar_t natively. *BUT* there is a problem here: the standard
// headers define this macro if they typedef wchar_t. Anyway, we're lucky
// because they define it without a value, while Intel C++ defines it
// to 1. So we can check its value to see if the macro was defined natively
// or not.
// Under UNIX, the situation is exactly the same, but the macro _WCHAR_T
// is used instead.
# if ((_WCHAR_T_DEFINED + 0) == 0) && ((_WCHAR_T + 0) == 0)
# define BOOST_NO_INTRINSIC_WCHAR_T
# endif
#endif

//
// Verify that we have actually got BOOST_NO_INTRINSIC_WCHAR_T
// set correctly, if we don't do this now, we will get errors later
// in type_traits code among other things, getting this correct
// for the Intel compiler is actually remarkably fragile and tricky:
//
#if defined(BOOST_NO_INTRINSIC_WCHAR_T)
#include <cwchar>
template< typename T > struct assert_no_intrinsic_wchar_t;
template<> struct assert_no_intrinsic_wchar_t<wchar_t> { typedef void type; };
// if you see an error here then you need to unset BOOST_NO_INTRINSIC_WCHAR_T
// where it is defined above:
typedef assert_no_intrinsic_wchar_t<unsigned short>::type assert_no_intrinsic_wchar_t_;
#else
template< typename T > struct assert_intrinsic_wchar_t;
template<> struct assert_intrinsic_wchar_t<wchar_t> {};
// if you see an error here then define BOOST_NO_INTRINSIC_WCHAR_T on the command line:
template<> struct assert_intrinsic_wchar_t<unsigned short> {};
#endif


#if (BOOST_INTEL_CXX_VERSION <= 800) || !defined(BOOST_STRICT_CONFIG)
# define BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL
#endif

#if _MSC_VER+0 >= 1000
# if _MSC_VER >= 1200
# define BOOST_HAS_MS_INT64
# endif
# define BOOST_NO_SWPRINTF
#elif defined(_WIN32)
# define BOOST_DISABLE_WIN32
#endif

// I checked version 6.0 build 020312Z, it implements the NRVO.
// Correct this as you find out which version of the compiler
// implemented the NRVO first. (Daniel Frey)
#if (BOOST_INTEL_CXX_VERSION >= 600)
# define BOOST_HAS_NRVO
#endif
bluesky
re: 测试一下 Intel C++8.0 对模板的支持程度
我刚开始也一直反感转到vc7.1.但是其实7.1对标准c++的支持远远强于6.0。我现在的感觉如果大量的借助stl,可以大幅度的提高编写代码的速度。当然如果你不喜欢stl或者程序里边没有必要用stl,那么仍然可以用6.0.
周星星
to bluesky:
vc7.1启动速度太慢,实在没这个耐性,而且安装也复杂多了,需要安装一大堆无用(对我个人而言)的东西。而VC++6不但速度快,而且还是一个绿色软件(^_^),拷贝之后简单设置一下就能用了。

:)我对stl一直很依赖的,在我眼中C++只有2.5个优点
a. 析构函数
b. 就是对模板的支持,尤其是实用的模板库STL的出现
c. 更安全的型别检查(算半个优点吧)
在我现在的代码中基本上离不开STL,但没用过boost,不是不喜欢,而是文档太少,我和您一样“英语不好”,呵呵!
周星星
将 hpho 提供的代码放这儿做存根
struct Widget {
template<typename T>
T foo(){}
};

template<template<class T>class X>
struct Widget{
};
晴月浩雪
re: 测试一下 Intel C++8.0 对模板的支持程度
谢谢您的评论,但我和netsin的观点一致:没人用VC7.1和VC8.0。VC++6.0的唯一优点是其IDE做得不错,界面科学,速度也很快,而后来的VC++已经没有任何优点了。
--------------------------------------------------------
对这个观点我认为或许您应该重新考虑下是否恰当。
  VC6的IDE当时也不算独一无二,而界面从VC5时候就已经成型了。VC6成功的主要原因在于优秀的类库(在当时)、丰富的文档、不错的速度和广泛的项目平台适用性。
  VC7.1是个值得考虑换用的IDE。其本身对C++标准的兼容性就是一个很大的优点,STL/Boost/Loki的编译不再是问题。而对原有ATL/MFC库结构的很多改动也足以让人喜悦,更有趣的是属性编程和ATL Server方面,这些都让某些编程工作大大的简化,让项目代码更加整齐优雅。我认为他的改进很多,优点很多,应该属于VC系列最优秀的C++开发平台(注意,我没有评价任何与.NET相关的部分,那些不是考虑是否选择它的理由)
  当然我也得指出,对于关心inline asm和某些硬件通讯等的开发领域,上述这些可贵的好处都不会反映出来。所以,对您所持的观点我表示理解,但观点还是比较片面的。
周星星
to 晴月浩雪:
要谈对C++标准的兼容性,莫过于g++/mingw,VC7.1/8.0还算不了什么,而且其经营方式不同,导致VC++不可能有g++更新速度快,再者g++/mingw是免费的,所以对于学者,或研究者而言,使用g++/mingw是首选(两个原因:对C++标准支持更好,免费获得)。

对于工程上的使用,考虑的东西就很多,比如顺手的IDE、编译速度、编译质量 等等。
顺手的IDE:你也应该承认VC++6.0的编辑界面是最干净的,而后来的VC编译器就有点变态了(个人感觉),比如自动显示/隐藏的属性页,鼠标总是动来动去的,不小心碰到了属性页,那么麻烦来了,得耐心的等待它隐藏起来,这种不时的中断完全打乱了我的思路;固定下来是个好办法,但界面上的垃圾功能太多了,如果固定下来,那么也就看不了几行源代码了。
编译速度:先不谈编译速度,就是VC++7.1的启动速度和反应速度慢得就够吓人的,对于小修改,我用VC++6.0修改、编译、发布完成时估计VC++7.1还像死机一样在那儿启动呐!有次(VC++7.1已经打开工程)我打开工程中的一个文件,竟然耗费了2分钟。中断是软件开发的大忌,因为一旦需要等待,那么程序员就可能去做/思考其他问题了,这种切换是需要耗费大量时间的,所以我看到一个人的论文中写道:“小于2秒钟的工作中断并不会给程序员带来麻烦,即使去骚扰他100次,那么总计也就浪费了他5分钟,但大于5秒钟的工作中断对程序员而言就是大麻烦了,因为他可能利用这段时间去思考其他问题,或是抽支烟,或是在网上冲浪,别期望他会在5秒钟之后回到工作点,即使他回来了,那么先前的思路也就早模糊,需要花费5分钟甚至30分钟去重新整理,还要期待他没有遗忘些什么。”,可见2秒钟和5秒钟的差距是很大的。
编译质量:我想VC++7.1/8.0的编译质量是很高的,但还有比它更高的Intel C++,我更愿意选择Intel C++,因为Intel C++不单有windows平台下的版本,还有Linux平台下的版本,也就是说使用Intel C++可以保证移植效率,而VC++7.1/8.0则不能。
ATL/MFC/属性编程/ATL Server:
MFC:我不用,也极力不推荐其他人使用,要么使用Win APIs,要么使用可移植的、开源的、经过验证的库,比如 stl、boost、gtk、qt、ace 等等。
ATL:如果不是编写COM我觉得ATL根本没什么作用,而COM是什么?我不知道,从来不用,因为它是M$私有的东西,不能保证其他厂商支持它,甚至不能保证明天M$不抛弃它。
属性编程:这是一种小得可以忽略不计的东西,其他理由同上。
ATL Server:假如你说的是DCOM,那么同上,假如你说的NT Service,我更喜欢用win api来编写,这两年我所写的程序都是基于NTService框架,ATL还满足不了我(当然它也可以,但与其改造ATL Server不如直接使用win api)。
所以我的结论是:对于工程应用,在unix/linux上选择g++/Intel C++比较好,在windows上选择 VC++6.0整合Intel C++ 或 mingw 比较好。
晴月浩雪
re: 测试一下 Intel C++8.0 对模板的支持程度
  不使用MFC和相应的衍生和扩展库,编出一个类似VC6或VC7界面的复杂程序会变得异常困难。而VC6当初相对于VB6作GUI应用的一个优势就是作专业风格的界面方便一些。
  COM本身不止是一项技术,对很多人来说更是一种设计思想,他让人们更重视面向接口的设计以及动态的基于事件的反馈模型。而且正式这个M$的技术,养活了国内外不少大大小小的公司,让很多程序员可以在VB、Delphi中使用其他人作好的组件进行二次开发,不用去学习VC或者从头自己开发。这些作用可以从COM在GIS平台、专业开发包、科学计算可视化、DirectX、Office等等无数大型平台软件和引擎的开发中被广泛采用得而得到验证。仅从这点考虑,COM的作用甚至ANSI C++(包括STL)还要大。
  至于属性编程以及MFC/ATL结构的新调整,不研究COM是无法理会它的好处的,我认为他绝对不能被COM开发者所忽略。它让COM与非COM程序基本可以融为一体,具有相似的开发过程、项目组织形式和代码外观。
  ATL Server虽然很好,但毕竟不是热门。它即不是DCOM,也不是NT Service,而且ATL库中本来也基本没有任何对NT Service编写有帮助的模版。ATL Server大概可以看成是一种开发IIS插件的方式,它比大多数其他替代技术方案要更加有效率,而且可以充分借鉴属性编程和ATL库的即有资源。
  原来您主要写NT Servive,那就难怪评价稍微有点狭隘了。其实NT Service是基于OS-API开发的,而且作一套构造NT Service的基于模板风格或类属风格的框架代码本身难度不大,代码量也有限,所以你才不会特别看到新IDE的优点。应该说这个开发领域还是较特别的,在VC众多应用领域中并不占据特别大的份额。我还有一些朋友开发NT Service时仍然用editplus之类的,甚至纯面向过程的进行开发,也相当顺利。可能我这几个类型的开发都研究过一些,对ATL/COM也熟悉些,所以感觉VC7.1的进步很明显。
  Intel C++研究很少,请教一下,它是不是在AMD及嵌入式计算平台上一样有效?
晴月浩雪
re: 测试一下 Intel C++8.0 对模板的支持程度
  VC6的IDE经常会把资源、工程browse等东西弄乱,找代码有时候也因为BUG变得很郁闷。VC7.1下这个问题已经基本解决了。可能您的机器不太好,或者项目组织有问题。我用VC7.1打开23万行的工程也没有遇到停顿的问题。如果您觉得VC7.1的界面凌乱,只要用15秒在起始页中设置一下就可以基本上跟VC6一致了,我觉得两者相似性还是很多的。
京山游侠
g++对模版的支持怎么样?有机会我把星哥的这几行代码考回去测试一番
我用的g++是Linux 13集成的,版本号我不记得了
不知道对标准C++及模板的支持怎样,有机会我把星哥的这几行代码拷回去测试一下
京山游侠
re: 测试一下 Intel C++8.0 对模板的支持程度
把上面的代码稍微改了一下,这样"仿真动态绑定"的用途更加直观

template<class DerivedClass> struct BaseClass { 
    int i;
    BaseClass(){ 
        i = 10;
        DerivedClass::modify_i ();
        cout << i << endl;
    } 
}; 

struct DerivedClass1: public BaseClass<DerivedClass1>{ 
    void modify_i () {
        i ++;
    }
}; 

struct DerivedClass2: public BaseClass<DerivedClass2>{
    void modify_i () {
        i --;
    }
};

int main(){ 
  DerivedClass1 obj; 
  DerivedClass2 obj2;
  return 0; 


周星星
to 京山游侠:
谢谢您的指正,文章现已修改;
对于您给出的代码,我在vc++6.0中编译不过,我觉得 DerivedClass1 既然是 BaseClass<DerivedClass1> 的派生类,那么就不能直接调用 DerivedClass::modify_i () ,除非它们的派生关系反过来。
京山游侠
re: 测试一下 Intel C++8.0 对模板的支持程度
上面的代码是有点问题,我昨天是在网吧信手写的,所以有很多错误。最明显的一点就是modify_i前面掉了一个static,昨天回去后我修改了好几次才在VC6中编译通过,在g++ 3.2.3中也通过了。

星哥的几个测试代码g++都能通过,呵呵,我对g++越来越满意了。可惜的是没有集成开发环境

把派生类当模版参数传入基类是没有问题的,ATL中有大量的这种用法,在我翻译的文章《ATL中的窗口类》中你可以看到,在第三十一期(呵呵,顺便打个广告)

shoryuken
re: 测试一下 Intel C++8.0 对模板的支持程度
星星可否介绍一下打造免安装vc6的方法?谢谢
zhtuan
re: 测试一下 Intel C++8.0 对模板的支持程度
大家有人在vc6.0下,编译boost通过的吗??
listlike
re: 测试一下 Intel C++8.0 对模板的支持程度
对g++的测试结果:
    以上的测试在gcc3.41 和 gcc4.00上测试的结果,由于gcc从3.4开始加强了对c++标准的支持,以前的g++支持的因该更差:
    第1,4的测试编译没有通过。
    其中第4个测试
    可以改成:
int main( void ) {
int a=1;
     testClass obj;
     obj.mfun(a);
     int i = obj;
     cout << i << endl;
}
 或者改成:
  template <class T> void mfun( const T& t ) {
        cout << t << endl;
    }
就可以通过测试。
will
re: 测试一下 Intel C++8.0 对模板的支持程度
devcpp不是用g++的吗,怎么可以编译通过1,4啊,要怎么设置呢??
listlike
re: 测试一下 Intel C++8.0 对模板的支持程度
devcpp 默认使用的是mingw,在mingw下1,4的测试是可以通过的。我的测试环境是cygwin+g++4.0 /g++3.4.1。
listlike
re: 测试一下 Intel C++8.0 对模板的支持程度
不好意思,我把第1个的测试写错,把template<> int testClass<char>::_data = 1;写成了int testClass<char>::_data,在g++4.0没有通过,居然在mingw下编译通过了晕死了。。。。还有其实gcc并不是对标准支持的最好的c++编译器,现在应该是vc8支持的比较好,其实大家只要看一下boost库对于编译器的支持列表,就可以看的比较明白了。
周星星
to listlike:
我在 mingw3.4.2 中没有编译通过呀。
这个Bug其实是VC++6.0的。
listlike
re: 测试一下 Intel C++8.0 对模板的支持程度
 哦,我测试用的mingw是3.1.0,对于测试1,不论写成什么样子,都可以通过,换成3.2.0后int testClass<char>::_data就过不去了。我始终弄不明白mingw和gcc各个版本之间的关系,不过通过这次测试3.1.0因该相当于gcc3.3的版本,mingw3.2.0相当与gcc3.4.1吧。mingw比gcc还是慢半拍啊。
猛犸
re: 测试一下 Intel C++8.0 对模板的支持程度
偶然看到此文,愿意说几句自己的看法。

我仅关注标准C++,如果用到M$的东西也尽量以标准C++做层包装。因此,对MFC、ATL、ATL Server都不了解,不在我讨论的范围内。

我特别同意 晴月浩雪 的观点。楼主不用VC7.1的原因我感觉都不是确切,或说不能构成放弃VC7.1的原因。

在VC7.1起始页选用VC6风格,之后界面基本与VC6相同。重要的是,VC7.1对模板、STL的支持日臻完美了——编译基于STL的代码再也没有那么多莫名其妙的警告;编译基于Loki(并非VC6、VC7的Loki移植版)的代码顺利通过。

VC7.1打开一个Solution的时间的确长点(打开一个几十个文件的Solution需要二三十秒,迅驰二代1.8G,1G内存的ThinkPad R51),配置高一些的机器也不是问题。另外,在装VS.net2003时可以只装自己有用的东西,比VC6复杂不到哪儿去。

我目前在Windows上的C++开发环境是有两种:一为VC7.1;另一系列为 eclipse/CDT/MinGW-3.1.0-1加Cygwin的sed(Makefile里有时用到)。其他C++编译器如Intel C++、Dev-CPP还没有接触过。

这两套开发环境已经能满足我目前开发C++程序的需要,可以编写Windows、Linux都跑得起来的代码,可以尝试template及Loki的深度应用。boost一直没接触,我想在这两个环境下应该都不是问题。

我说这些是为了和大家交换好的经验,没有争论哪个IDE更好的意思。
Some side, Don't
re: 测试一下 Intel C++8.0 对模板的支持程度
MFC是可以移植的,开源(?不属于开源概念,但是所有源代码都是公开)的一个Windows上的C++库,也是目前为止Windows上UI开发最常用的库。
你个无聊偏执狂
re: 测试一下 Intel C++8.0 对模板的支持程度
周星星同学只是一个带有反微软,或者反霸权的偏执狂而已,故意拿一个工具的短处和另一个的长处比,莫名其妙,神经有病
周星星
to 楼上的:
你说我反微软,我从来不这么认为,我也没空去反对哪个公司,不但没空,而且也没这个资格,井水不犯河水,管俺鸟事?
说我反霸权,细想想好象我也没这嗜好,只要是正确的,霸道一点又如何?
说实话,我不知道你想说什么,有理说理,你说的“故意拿一个工具的短处和另一个的长处比”这个屁话中,这“一个工具”指的是谁呀?这“另一个”又是谁呀?这“短处”是什么?这“长处”有是什么?下次说清楚点,不要像个娘儿们,支支吾吾,说话不清楚。
算了,我也不细问了,那你只要告诉我,为什么不能拿两个工具互相比较长短?我比较几个主流的C++编译器对模板的支持程度的做法错在哪里?如果不比较,你知道米饭香,大便臭呀?如果你拿大便塞你嘴巴里当饭吃的话,我就承认不应该比较几个主流的C++编译器对模板的支持程度,我就把这篇文章删除了。你这个傻鸟还好意思说其他人“莫名其妙,神经有病”,我看你就是从汤山溜出来的。
我爱周星星
re: 测试一下 Intel C++8.0 对模板的支持程度
说实话,我很欣赏周星星。国内的技术论坛,充斥了太多的无知、狂妄、傲慢之徒。你提出一个问题来讨论,总有那么一帮傻B站着说话不腰疼,批这批那的。我自己也有技术BLOG,但我现在发BLOG时已经不允许有评论回复了,所以我很欣赏周星星,尽管有那么多他妈的混蛋在这里说着这么多跟技术问题本身不相干的屁话,周星星还是能够一一驳斥和回复,我觉得非常难得。现在的我,是这样想的:去他妈的讨论吧,老子不跟你们这些弱智讨论了,老子就他妈的写给自己看的,看不看随你,关俺鸟事!操!
周星星
to 我爱周星星:
同感呀,经常面对 一尘不变的、弱智到可恨的、理由都给不出一个的 的攻击,我感觉到有点累,很多时候也想一删了之。
有时候我也奇怪,是这些人因为本身智商低,看出谁对谁错?还是明明自己知道,但就是不允许其它人说出来? 如果是后者,那就可恶了。
刘未鹏
re: 测试一下 Intel C++8.0 对模板的支持程度
星星,为什么不用VC 2005 Express(VC 8.0),现在到了Beta2版,除了一些无关紧要的小bug外,其IDE的功能对于C++研习者来说实在是太棒了,我最看重的就是一个重大突破,VC8.0之前的IDE的智能感知都没法解析宏,而VC8.0的则可以现场解析宏,换句话说,它自身就是一个just-in-time的预处理器,这一优点在我阅读BOOST的时候给予了莫大的帮助。说实话我到目前为止还没有用到过比VC8.0更好的IDE。

VC8.0的编译器对C++标准的支持也是相当高,呵呵,仅次于comeau。
周星星
to 刘未鹏:
谢谢,但我没钱买vc2005(你不是不让用盗版嘛,而公司.net部门用VS2002,它们没法换新版本了,因为它们的代码以及第三方的控件在VS2003中跑不起来,甚至win2ksp4都不能打 ^_^看.net的兼容性有多好?!),何况它还只是beta版(如果出了问题我负担不起呀。)
更主要的是,我现在(将来更是)不用MFC,不用ATL,只用纯C/C++语法和C/C++标准库(稳定无BUG是主要目的,其次是要保证能移植到Linux上),所以安装庞大的VC2005.net有点浪费机器资源。
不过它能够现场解析宏确实是一个大亮点,如果有机器空余的话,安装一个瞧瞧。
周星星

VC 2005 Express(VC 8.0) 是免费下载的,不过很庞大,要3G空间。
刘未鹏
re: 测试一下 Intel C++8.0 对模板的支持程度
to 星星:
误会了,我说的就是VC 2005 Express(8.0),不是Widbey,Widbey还没出呢:)
另外,我安装了VC 2005 Express好像只耗了200M嘛:)怎么会有3G呢?你只装VC 2005 Express就是了嘛。另外,如你所愿,VC 2005 Express不带MFC,不带ATL,甚至连Platform SDK都不带,再加上它对C++标准的极好支持,实在是得心应手的好工具哦。
我并不是推荐你用它来做公司开发,而是私下用来研习C++而已:)
此外,可以考虑使用VC 2005 Express+ STLport 的搭配,强强联合:)说实话,P.J.Plauger写的STL代码实在看起来头疼:)
周星星
to 刘未鹏:
谢谢,下次我试试。
随便问一下,安装VC 2005 Express(8.0)时必须安装.net framework吗?
abc
re: 测试一下 Intel C++8.0 对模板的支持程度
visual studio .net 2003也就是VC7吧?它的IDE就能智能解析宏啊。
abc
re: 测试一下 Intel C++8.0 对模板的支持程度
绝大多数程序员需要的是一个良好的IDE,使用方便的编辑器,功能强大的调试器,完整的帮助,速度快,非常稳定,BUG很少的编译器和连接器.vs在这些方面无疑是做的最好的。

而不是一个对某些语法的奇技淫巧支持的很好的编译器.这对大多数程序员根本是毫无意义的。

实际上多数程序员和组织在工作中都是倾向于采取比较保守但是稳妥的策略去解决问题的,语言的使用也是这样。
abc
re: 测试一下 Intel C++8.0 对模板的支持程度
比如正则表达式的解析,Boost::regex,greta,PCRE这三个库应该是C++程序员比较主要的选择。

Boost的写法用了一些模板的高级特性,而greta则是使用了模板的基本特性,而pcre跟本就是一些c function.

boost::regex和greta,PCRE比,在效率,编译后代码的大小方面根本没有什么优势,甚至可以说反而有点劣势。虽然写的很漂亮,功能也很强大,但是在实际应用中,大多数程序员和组织反而愿意选用后两种。

你Boost::regex又没有给我带来象效率,更小的代码这些对产品品质真正有帮助的东西,就是写的很漂亮,写的很cool有什么用呢?反而到是模板高级特性大量的使用,造成了对大多数程序员来说维护,理解和使用的不方便和困难。

上面就是一个例子,不知道楼主工作了几年,在没在一些行业领导的公司工作过,感觉楼主已经走入了一个有点偏执的误区了。
eyye
re: 测试一下 Intel C++8.0 对模板的支持程度
      我想请问一下周星星及大家,gcc(mingw)能不能整合进vc6-IDE?
      如果能,请指点。
周星星
to eyye:
嘿嘿,难度太大了,但如果真的有人完成这个工作,一定很有意思。
疯子阿虹
re: 测试一下 Intel C++8.0 对模板的支持程度
好长的一篇文章啊,我看了一点,但是我想说两句。
VC7.1完善了很多C++语法的支持。

不过搂主说:

# to Mick: 2005-01-27 03:14 周星星 
谢谢您的评论,但我和netsin的观点一致:没人用VC7.1和VC8.0。 

VC++6.0的唯一优点是其IDE做得不错,界面科学,速度也很快,而后来的VC++已经没有任何优点了。 


这个简直是大错特错,你这不是在抗拒时代的发展吗?
拒绝新事物是人类的本性。
可是必须要适应新事物才能跟上脚步。

前两年,我刚听到python,嗤之以鼻,可是近来我的想法却大有改变。看着那么多人大肆谈论python。我才发现我已经落伍了。

疯子阿虹
re: 测试一下 Intel C++8.0 对模板的支持程度
这位老兄说的更有意思:
--------------------------------------
我自己也有技术BLOG,但我现在发BLOG时已经不允许有评论回复了,所以我很欣赏周星星,尽管有那么多他妈的混蛋在这里说着这么多跟技术问题本身不相干的屁话,周星星还是能够一一驳斥和回复,我觉得非常难得。现在的我,是这样想的:去他妈的讨论吧,老子不跟你们这些弱智讨论了,老子就他妈的写给自己看的,看不看随你,关俺鸟事!操! 
--------------------------------------

技术本来就是讨论的,尤其对于我们来说,并不是国际权威人士,怎么可能保证自己的观点都是正确的???

我们需要回复是我们需要交流,我们需要通过我们的智力来判断有用的和无用的,取之精华。你这种做法,和大清国的闭关自守有什么分别呢?

周星星
to 疯子阿虹:
您觉得版本号的提高就是“时代的发展”?
“VC7.1完善了很多C++语法的支持。” --- 我不知道您想说什么,如果您觉得因为VC7比VC6对C++语法支持更好就应该使用它的话,我们是不是忘了还有对C++支持最好的GCC?
另外您从何处觉得我“拒绝新事物”?只是问问而已(好奇心),我既不拒绝新事物,也不不拒绝新事物,我从来不因为事物的新或旧而接受或拒绝。我只是不喜欢VC++.net的界面设计,一个非专业人员的设计,当然你可以有不同的观点。

对于您的第二段,我想替那位仁兄回答你:
“技术本来就是讨论的” --- 是,但要讨论“技术”,而不是无知的谩骂。我的Blog建在VCKBASE上,VCKBASE是我见过文明而自由(文明我见多了,只要斑竹不停的删贴子就行;自由我见多了,无非就是任意谩骂)的唯一地方,估计那位仁兄就没有这么好运,整天面对无聊的谩骂和无知的驳斥,当然很累,我深有同感,很多贴子我不想回,包括您这一篇,其实我犹豫了很久。
“怎么可能保证自己的观点都是正确的” --- 同上,是不能保证,但谩骂和没有深思过的驳斥于事又有何益?
“我们需要通过我们的智力来判断有用的和无用的,取之精华” --- 您没有错,这只是一个认识程度的问题,对于一包黄沙,您想沙里淘金,而那位仁兄想做更有意义的事,沙里肯定有黄金,一个觉得值得淘一下,一个觉得淘出来的黄金还抵不上浪费的时光。而我虽然在淘着沙子,但已经心意阑珊,滋生悔意。

说点轻松的吧,您给我了一些批评,虽然我并不接受,但我仍心存感激,能够看得出您的善意。我想有所回报,就“前两年,我刚听到python,嗤之以鼻,可是近来我的想法却大有改变。看着那么多人大肆谈论python。我才发现我已经落伍了。”这段话,也给你一些建议:
您为什么在“刚”听到python时,就对它嗤之以鼻?您还没有了解它呀,如何匆匆下结论;您为什么看到那么多人大肆谈论python时,感到自己已经落伍了?那毕竟是别人的事呀!从这里看来:
a。工具(比如“python”)成了您的主人,而您却成了它的消耗品。
b。您在刻意的追赶时髦,我觉得时髦可以被创造,却不可以被追赶上。就比如这个python,当您对其“嗤之以鼻”的时候,它并不时髦,当您“看着那么多人大肆谈论python”时,你“已经落伍了”,即使当您全力追赶,我猜测,如果您能追赶得上的话,python一定早已不再时髦。
评论有所不对的地方,请见谅,我只是想轻松一下而已。
songyuling
re: 测试一下 Intel C++8.0 对模板的支持程度
希望以后类似的讨论多一些,大家都是从技术的角度真诚的去讨论工具,不要出现无故的漫骂。谢谢周星星,谢谢清月浩雪还有那些怀着真诚的心去讨论技术的人。
我本来是很郁闷的,花了几年的时间把MFC 的东西搞清楚些,Microsoft 马上要放弃了。上来看了这些人的讨论,对各个工具也有了一些新的认识,心里还是非常感动。
zz3
re: 测试一下 Intel C++8.0 对模板的支持程度
我用borland c/c++,支持c++标准比vc6要好些。.net 的vs2003没用,我的机器不够。
冯唐
re: 测试一下 Intel C++8.0 对模板的支持程度
那个用着顺手,就用那个。
只要用着顺手就是对自己最合适的
Leonlux
re: 测试一下 Intel C++8.0 对模板的支持程度
问一下星星,文章里面很多模板的技巧或者用法是很罕见的,一般在哪里(或者什么书)可以找到这些相关的知识?
周星星
re Leonlux:
我也不知道,有一部分是从《STL源码剖析》中抄来的,另一部分是平时从别处看到的。推荐你看看《C++设计新思维》,里面模板的各种用法很多。
leonlux
re: 测试一下 Intel C++8.0 对模板的支持程度
谢谢星星。
低调的人
re: 测试一下 Intel C++8.0 对模板的支持程度
可能我们暂时还没有能力来评论一样东西好与坏,在完全搞懂它之前。完全搞懂它要等到,,,,时侯。低调的人永远也不完全懂。
1 2 下一页共2页  到第

发表评论
切换编辑模式