C++/CLI有没有兄弟在用？

有一个帖子是发于2005年。四年之前。
请问，现在，C++/CLI有没有兄弟在用？
开发 .NET 应用，C++/CLI不如C#,APS.NET方便，
传统的Windows程序，用MFC就很好。
那么，谁用C++/CLI ? 开发什么呢？

45 个解决方案

#1

好象李建忠老师在用。

#2

基于命令行的程序Linux下用的较多

#3

熟悉C++语言并且要开发.net程序就可以用

#4

顶，我最近再用c++/cli，但是也有和楼主一样的疑问

#5

开发 .NET, C#是最方便和彻头彻尾的CLI语言。
所以，对C++/CLI 的定位很困惑 

#6

那你把现有的代码如何在CLI中使用呢 ,C++/CLI 就是一个交互过程

#7

 c#只能通过调用API和c、c++打交道，c++/Cli可以无缝衔接以往c/c++的技术成果，而且执行效率高

#8

引用 7 楼 xqzl 的回复:

c#只能通过调用API和c、c++打交道，c++/Cli可以无缝衔接以往c/c++的技术成果，而且执行效率高

真的吗？

#9

我也很是纳闷呢?

目前我们是C#做上层,C/C++做底层. 


感觉C++/cli没必要.

#10

C++/CLI的关键意义在于让C/C++程序员融合到.NET平台，战略意义大于应用意义

#11

学习了~~

#12

我最近在用，vc++调用c#的库，
用起来感觉不错。

#13

没什么, 就是 IDE 支持不如 C#, 包括代码编辑器

还有, 编译起来也不如 C# 快

如果用惯了 C#, 的确不适应.

#14

不发表意见

#15

我最近在用，如果你有一大堆C++底层遗留代码，结果上层UI决定用.net的技术，比如wpf，那么就轮到它出场了。native code与managed code交互编程的王者。

#16

用了一段，发现c++/cli是个好东西，不但可以继续用c++编程，调用api什么的也十分方便，还可以使用.net的控件，越用越爽，我觉得c++/cli还是会比较有前途

#17

路过，没遇到过！

#18

晕死，现在看到这帖，是不是意味着一开始，我就不应该选用 C++/CLI 来做我的这个项目，而应该 C#, 虽然两个对我来说都是一种新语言的学习。

#19

有优势，有难度

#20

最主要的就是团队开发了，在开发团队里，只要用CLR编程就不会有语言界限！微软在。net框架下的所有语言都是可以互通的，但前提条件就是它们运行在CLR下面，所以微软从iso/ansi规范中扩展出c++/cli规范，可以和其他任何。net下的开发语言互相交流！
这才是c++/cli的重要之处！否则用iso/ansi编译的程序是不能被其他语言访问的，那样的话.net里的vc就完全和vb、c#、f#、j#分开了，没有整体性了！团队开发就存在太大的障碍了！

#21

在这里只有6楼和10楼说的是对的，其他的回答都不沾边，他们应该看一看ivor horton老先生写的那个系列入门的书，老先生在前言里就介绍了有关于c++/cli的问题，只要再有一点编程经验就完全可以理解为什么微软一定要扩展iso/ansi的c语言的基本规范！

#22

C++/CLI 是我知道最复杂的语言了，但是也是最强大的语言了。建议不学。

#23

引用 18 楼 qinlove 的回复:

晕死，现在看到这帖，是不是意味着一开始，我就不应该选用 C++/CLI 来做我的这个项目，而应该 C#, 虽然两个对我来说都是一种新语言的学习。

如果一开始有得选择，那么你大概是选择错了。

c++/cli更多地是“给出路”的意思，而不是“创新”的意思。

#24

引用 22 楼 healer_kx 的回复:

C++/CLI 是我知道最复杂的语言了，但是也是最强大的语言了。建议不学。

不学完全没有问题！但是谈不上强大，他和其他的语言都差不多，只不过他可以自动管理内存，相对iso/ansi它智能许多，复杂是复杂点，但绝对谈不上最复杂！你有点夸张了！

#25

引用 20 楼 haitao5676 的回复:

这才是c++/cli的重要之处！否则用iso/ansi编译的程序是不能被其他语言访问的，那样的话.net里的vc就完全和vb、c#、f#、……

c#、vb.net、F#程序员也可以直接跟vc、vb、delphi的组件交互的。

#26

引用 25 楼 sp1234 的回复:

引用 20 楼 haitao5676 的回复:
这才是c++/cli的重要之处！否则用iso/ansi编译的程序是不能被其他语言访问的，那样的话.net里的vc就完全和vb、c#、f#、……


c#、vb.net、F#程序员也可以直接跟vc、vb、delphi的组件交互的。

我没说不能交互！而是用c++/cli是可以和其他语言一起编译的，也就是说在团队开发中，c#或vb.net是可以和c++/cli一起共用代码的，而不是组件间的交互！
还不明白！？

#27

引用 25 楼 sp1234 的回复:

引用 20 楼 haitao5676 的回复:
这才是c++/cli的重要之处！否则用iso/ansi编译的程序是不能被其他语言访问的，那样的话.net里的vc就完全和vb、c#、f#、……


c#、vb.net、F#程序员也可以直接跟vc、vb、delphi的组件交互的。

c++/cli中的变量是基本类型的，也就是说我用c++/cli建立的一切函数和变量是可以在c#中直接引用的，你完全可以调用dll或者remoting之类的组件来和c#交互，而直接iso/ansi写出的变量或是函数（类等等）是不可能的（应为他们的类型是不一样的）！

#28

类型取决于编译选项

int i = 0; 

你说这个 i 是 System::Int32 不?

实现支持 c++/cli 的编译器的工作量不小

#29

引用 28 楼 dobzhansky 的回复:

类型取决于编译选项

int i = 0; 

你说这个 i 是 System::Int32 不?

实现支持 c++/cli 的编译器的工作量不小

i是不是System::Int32都要讨论，谁能告诉我这个语言不复杂?

#30

刚在写一个 wrapper


char* getPchar(System::String^ ms)
{
  if (System::String::IsNullOrEmpty(ms))
    return NULL;

  char* buffer = NULL;
  pin_ptr<const wchar_t> wchar = PtrToStringChars(ms);
  size_t size = wcstombs(NULL, wchar, 0);
  buffer = (char*)malloc(size*sizeof(char)+1);
  size = wcstombs(buffer, wchar, size);
  buffer[size]='\0';
  return buffer;
}

void freePchar(char* s)
{
  if (s)
    free(s);
}

#31

引用 28 楼 dobzhansky 的回复:

类型取决于编译选项

int i = 0; 

你说这个 i 是 System::Int32 不?

实现支持 c++/cli 的编译器的工作量不小

这个i再返回值时c++/cli将自动返回System::Int32，在编译之前就会完成！

#32

引用 31 楼 haitao5676 的回复:

引用 28 楼 dobzhansky 的回复:

类型取决于编译选项

int i = 0;

你说这个 i 是 System::Int32 不?

实现支持 c++/cli 的编译器的工作量不小

这个i再返回值时c++/cli将自动返回System::Int32，在编译之前就会完成！

不考虑 形如这样的编译选项,
cl hello.cpp
cl /clr hello.cpp
cl /clr:mixed hello.cpp
cl /clr:safe hello.cpp

以及变量的上下文?

#33

引用 32 楼 dobzhansky 的回复:

引用 31 楼 haitao5676 的回复:

引用 28 楼 dobzhansky 的回复:

类型取决于编译选项

int i = 0;

你说这个 i 是 System::Int32 不?

实现支持 c++/cli 的编译器的工作量不小

这个i再返回值时c++/cli将自动返回System::Int32，在编译之前就会完成！


不考虑 形如这样的编译选……

根本不用编译，因为c++/cli在定义时允许你写成int i(0);也可以直接写成值类型System::Int32，不过运算时只以System::Int32来运算，怎样写是你的*！

#34

使用COM吧，把非托管的代码使用COM封装，然后直接可以在.Net环境下调用了.有点C++基础然后看看ATL和COM基础就可以动手做啦！

#35

其他方法么？DllImportAttribute，VC++.Net

#36

感觉封装成COM组件没有封装成程序集用着舒服，safearray之类的东西操作起来就很麻烦。

#37

我再用，c++/cli保持的是c++的流程和风格也就是c++的语言特性。同时兼容最新的.net技术，操作简单。它是事件驱动容易理解上手。mfc是消息驱动没有事件理解快速。它也就是c++语言同时兼顾.net新特性。它的效率并不慢，因为它是c++。有c++的一切特性，有.net的垃圾回收器，不会有标准c++的内存泄漏问题。c++与c#的区别可以在网上查找。.net与标准c++的区别优势你也可以查找。它对解决了一些问题，综合了一些优势。是融合体。你是c#程序员，但是遇到要解决一些底层问题。用它可以与c#一样写但是是c++可以解决底层问题。同时没有标准c++麻烦。其他自己在网上搜索。

#38

引用 35 楼 shuaid 的回复:

其他方法么？DllImportAttribute，VC++.Net

     要知道.Net中的好多底层东西都是用COM或COM+ Service实现的，包括数据库访问和Web 服务等，包括微软的操作系统和其他产品对COM的依赖是比较强滴。有的时候不要只求方便或用着舒服，要求效率！

#39

引用 35 楼 shuaid 的回复:

其他方法么？DllImportAttribute，VC++.Net

要知道.Net中的好多底层东西都是用COM或COM+ Service实现的，包括数据库访问和Web 服务等，包括微软的操作系统和其他产品对COM的依赖是比较强滴。有的时候不要只求方便或用着舒服，要求效率！

#40

封装成COM效率不一定高啊，c#与c++使用的是自动化接口进行通信。用c++/cli封装成程序集，效率可能更高一些。

#41

引用 40 楼 chd_wu 的回复:

封装成COM效率不一定高啊，c#与c++使用的是自动化接口进行通信。用c++/cli封装成程序集，效率可能更高一些。

cli的本质是什么，他只不过是一种中间代码，需要被解释执行。而COM是建立在二进制标准上，也就是说执行效率上COM可能要比Cli的速度要快一些，效率问题最多可能是COM与.Net通信时可能出现，不过COM有自己的运行单元，其速度远远要比你用.Net写的东西要快。这个你可以试验一下。
根据很多人.Net只适合编写上层应用，比如用WinForm界面等，写底层的东西还是离不开C or C++。

#42

引用 41 楼 shuaid 的回复:

引用 40 楼 chd_wu 的回复:
封装成COM效率不一定高啊，c#与c++使用的是自动化接口进行通信。用c++/cli封装成程序集，效率可能更高一些。

cli的本质是什么，他只不过是一种中间代码，需要被解释执行。而COM是建立在二进制标准上，也就是说执行效率上COM可能要比Cli的速度要快一些，效率问题最多可能是COM与.Net通信时可能出现，不过COM有自己的运行单元，其速度远远……

如果你跟踪Com调用的Invoke代码也许就不这么认为了。

#43

VC++.NET好象用的不多,几乎都是用VC++.NET的VC++部分没人用.NET部分.

#44

c++/cli是好东西，好好学习

#45

与时俱进，多么想成为你们这样的高手