64,654
社区成员
发帖
与我相关
我的任务
分享C++/CLI & VC2005讨论
刚下了个C++/CLI草案1.14及Apress.Pro.Visual.C++.CLI.and.the.dot.NET.2.0.Platform.Dec.2005,翻了几页,
总觉得C++/CLI非常怪异,实在是别扭得很,本人用C++已有数年,实在看不到C++/CLI的前景,很迷茫,请各位大侠发表一下对VC2005及C++/CLI的看法!
总觉得C++/CLI非常怪异,实在是别扭得很,本人用C++已有数年,实在看不到C++/CLI的前景,很迷茫,请各位大侠发表一下对VC2005及C++/CLI的看法!
...全文
请发表友善的回复…
发表回复
htqx 2006-12-10
- 打赏
- 举报
c++ /CLI 的优势：
1。可以无视 mfc
2. 可以使用.net庞大的类库
3。可以使用 c++
感觉结合的比较好的。
1。可以无视 mfc
2. 可以使用.net庞大的类库
3。可以使用 c++
感觉结合的比较好的。
zhan_yonghua 2006-12-10
- 打赏
- 举报
GO ON
sandrowjw 2006-12-03
- 打赏
- 举报
ASP.Net程序需要配一个Web.config文件。
至于C++/CLI，我从来不指望用户会去装.Net Framework……
至于C++/CLI，我从来不指望用户会去装.Net Framework……
axx1611 2006-12-03
- 打赏
- 举报
我通常使用C++/CLI都是在和C#接口的地方
如LSSS所说 C#和原生C++代码交互存在许多困难，这种地方当然首选C++/CLI，事实上我也是这么做的。不过不赞成整个项目都采用C++/CLR去写，那样会累死你的，你会发现使用C#的开发效率能比起高出好几倍。
所以C++/CLR绝对1不能替代C#，2不能替代原生C++，甚至在很多场合，它就只适合做C#(CLR)-原生C++的桥梁，所占代码量不需要超过整个工程的1/10。
如LSSS所说 C#和原生C++代码交互存在许多困难，这种地方当然首选C++/CLI，事实上我也是这么做的。不过不赞成整个项目都采用C++/CLR去写，那样会累死你的，你会发现使用C#的开发效率能比起高出好几倍。
所以C++/CLR绝对1不能替代C#，2不能替代原生C++，甚至在很多场合，它就只适合做C#(CLR)-原生C++的桥梁，所占代码量不需要超过整个工程的1/10。
zhan_yonghua 2006-12-03
- 打赏
- 举报
Mephisto_76((望美人如梦)) 说得不错,赞一个
solar 2006-12-03
- 打赏
- 举报
gz
Mephisto_76 2006-12-03
- 打赏
- 举报
前几天没事用了一下，感觉主要可以完成新老代码的无缝结合。
有人说在.Net下不如用C#，但是C#在调用Win32或者C++写的代码（DLL、Lib）的功能有时候是很烦琐的，不信的话搞一个复杂的平台调用来看看。而C++/CLI在这方面当然不让是首选，你可以将绝大部分功能用C++实现（当然更有可能是已经用C++实现好了），然后创建一个CLR DLL 项目，包括原来的头文件、lib库、DLL，选/clr编译选项就可以轻松的搞定了，而且这个CLR DLL可以供其它语言如C#使用。而C#只能有两个选择，要么是COM包装，要么是平台调用。这两个无论从效率和优雅程度上来说，肯定不及前者。
还有人说不能跨平台了，或者是必须依赖.Net Framework了。这确实是事实，但事已至此，已非我们个人能决定了。既然微软和SUN、IBM还有其它寡头已经决定将这一场战争放在.NET和Java平台进行了，我们只能顺应潮流（我指的是应用程序，工具和基础软件不在此列）。
至于有人说不如用C#，这个我也有看法。我用C#多年，十分喜欢其语法清爽简洁，但对其一些缺点也有抱怨（比如资源的释放不够自然，要用using等等，平台调用的烦琐等等）。C++/CLI相比而言，在这些方面以及IL语言的映射方面，稍微优越。如ref class,value class,以及析构函数超出对象范围自动调用Dispose方法等，以及引用类型模拟栈语意等都是不错的。能够在CLI中定义Native对象的指针（但不能引用Native对象和内置类型），在Native类中可以用gcroot类包装CLI类型作为成员等等，这些与既有代码的交互能力都要强于C#和.Net平台上的其它语言。
但是C++/CLI也有令我不满意的地方，就是其语法十分累赘。每次要引用CLI类型时都要加上一个“^”尾巴，还有一些较容易混淆的地方。但是当我看了微软的官方说明（不知道是Herb Sutter还是Lippman执笔的），我觉得其良苦用心还是值得尊敬。
如果你决意不将自己升级到.Net，又或者你无意在Windows上进行开发，那么你完全没有必要使用C++/CLI。但是如果你希望在你的.Net程序中使用既有的代码，又或者将你的C++代码迁移到.Net平台，那么我认为C++/CLI是一个可选的桥梁。通过尽可能将C++/CLI局限在局部的地方，你将尽可能得保持你的代码的可移植性。
有人说在.Net下不如用C#，但是C#在调用Win32或者C++写的代码（DLL、Lib）的功能有时候是很烦琐的，不信的话搞一个复杂的平台调用来看看。而C++/CLI在这方面当然不让是首选，你可以将绝大部分功能用C++实现（当然更有可能是已经用C++实现好了），然后创建一个CLR DLL 项目，包括原来的头文件、lib库、DLL，选/clr编译选项就可以轻松的搞定了，而且这个CLR DLL可以供其它语言如C#使用。而C#只能有两个选择，要么是COM包装，要么是平台调用。这两个无论从效率和优雅程度上来说，肯定不及前者。
还有人说不能跨平台了，或者是必须依赖.Net Framework了。这确实是事实，但事已至此，已非我们个人能决定了。既然微软和SUN、IBM还有其它寡头已经决定将这一场战争放在.NET和Java平台进行了，我们只能顺应潮流（我指的是应用程序，工具和基础软件不在此列）。
至于有人说不如用C#，这个我也有看法。我用C#多年，十分喜欢其语法清爽简洁，但对其一些缺点也有抱怨（比如资源的释放不够自然，要用using等等，平台调用的烦琐等等）。C++/CLI相比而言，在这些方面以及IL语言的映射方面，稍微优越。如ref class,value class,以及析构函数超出对象范围自动调用Dispose方法等，以及引用类型模拟栈语意等都是不错的。能够在CLI中定义Native对象的指针（但不能引用Native对象和内置类型），在Native类中可以用gcroot类包装CLI类型作为成员等等，这些与既有代码的交互能力都要强于C#和.Net平台上的其它语言。
但是C++/CLI也有令我不满意的地方，就是其语法十分累赘。每次要引用CLI类型时都要加上一个“^”尾巴，还有一些较容易混淆的地方。但是当我看了微软的官方说明（不知道是Herb Sutter还是Lippman执笔的），我觉得其良苦用心还是值得尊敬。
如果你决意不将自己升级到.Net，又或者你无意在Windows上进行开发，那么你完全没有必要使用C++/CLI。但是如果你希望在你的.Net程序中使用既有的代码，又或者将你的C++代码迁移到.Net平台，那么我认为C++/CLI是一个可选的桥梁。通过尽可能将C++/CLI局限在局部的地方，你将尽可能得保持你的代码的可移植性。
zhan_yonghua 2006-12-02
- 打赏
- 举报
米人啊,最近在用VC2005写一个ATL SERVER WEB服务的WEB SERVICE,但调试时老是报错,说无法启动WEB服务....请验证WEB.COFIG配置正确之类~~~有没谁遇过此情况?
zhan_yonghua 2006-12-01
- 打赏
- 举报
来UP...
zhan_yonghua 2006-11-29
- 打赏
- 举报
继续UP,兄弟请继续
syy6 2006-11-29
- 打赏
- 举报
C++/CLI总体是感觉怪怪的，而且很复杂。
还是托管用C#好些。
还是托管用C#好些。
zhan_yonghua 2006-11-29
- 打赏
- 举报
迷茫...
shanlu9 2006-11-29
- 打赏
- 举报
看来ＶＣ＋＋的前途有点不大明朗，迷茫。。。
axx1611 2006-11-28
- 打赏
- 举报
CLI不是C++的出路，楼主不用费心了。
zhan_yonghua 2006-11-28
- 打赏
- 举报
我来UP,大家接着讨论,看来C++/CLI与MANAGED C++一样,是个失败的东西!唉...
zhan_yonghua 2006-11-27
- 打赏
- 举报
一年前我就打算学习C++/CLI,当时的资料极少,感觉微软VC8还是做得不够成功!
象我们这些习惯于底层编码的程序员,VC6之后该用什么接班呢,总不至于叫我们去用C#吧
象我们这些习惯于底层编码的程序员,VC6之后该用什么接班呢,总不至于叫我们去用C#吧
axx1611 2006-11-27
- 打赏
- 举报
CLI的强大是毋庸置疑的，当然我没有否认MFC的强大，但毕竟也写了几年的MFC了，接触CLI还不到半年，两者的差距是明显的
xiaonian_3654 2006-11-27
- 打赏
- 举报
CLI是拿来用的，又不是拿来背的，干吗搞得自己那么痛苦
我只是想说对于windows程序员来说，是一个不错的选择，尤其是做UI，效率高出MFC很多，不弱于DELPHI，而且更强大。
不过个人也比较BS这个东西，离了win32就啥都不啥了
而且托管系统高度排外，混编很麻烦。
========================================================
我没说背CLI啊，MFC虽然工作经验2年多，不过基本上很熟了，大大小小的问题都能搞定，
我没事学那个干什么啊，能有什么强大不强大的阿，
我只是想说对于windows程序员来说，是一个不错的选择，尤其是做UI，效率高出MFC很多，不弱于DELPHI，而且更强大。
不过个人也比较BS这个东西，离了win32就啥都不啥了
而且托管系统高度排外，混编很麻烦。
========================================================
我没说背CLI啊，MFC虽然工作经验2年多，不过基本上很熟了，大大小小的问题都能搞定，
我没事学那个干什么啊，能有什么强大不强大的阿，
axx1611 2006-11-27
- 打赏
- 举报
CLI是拿来用的，又不是拿来背的，干吗搞得自己那么痛苦
我只是想说对于windows程序员来说，是一个不错的选择，尤其是做UI，效率高出MFC很多，不弱于DELPHI，而且更强大。
不过个人也比较BS这个东西，离了win32就啥都不啥了
而且托管系统高度排外，混编很麻烦。
我只是想说对于windows程序员来说，是一个不错的选择，尤其是做UI，效率高出MFC很多，不弱于DELPHI，而且更强大。
不过个人也比较BS这个东西，离了win32就啥都不啥了
而且托管系统高度排外，混编很麻烦。
itoaer 2006-11-27
- 打赏
- 举报
有了C#，为什么还要CLI，没有看到有多少人在用这个东西
加载更多回复（14）
