C++,C++/CLI混合编程

   从2001年.net平台开始发布到现在，C++/CLI已经存在了好几年。以前叫mc++,现在改名为C++/CLI，有些人认为C++/CLI是一种新语言，有的只是认为是C++的一个扩展。C++/CLI是完全基于.NET平台之上。C++/CLI的出现给C++项目开发带来了不少的变化。可惜由于.NET平台目前还没有完全覆盖windows的全部操作系统，C++/CLI也只能用于服务器程序的开发。用来编写客户端程序，分发成本实在不低。
 
   光从用途来看C++/CLI是.NET平台和iso c++之间的一个过渡桥梁，一个 ISO c++项目走向.net项目的一个单向桥梁。抛开各种政治上的，信仰上的考虑，.NET平台的确带来了不少吸人眼球的技术。在尝试着开发了几个c#1.1项目之后，由于c#1.1项目开发过于死板。于是一直等待到.NET 2.0发布，.NET平台开始进入成熟时期，我开始尝试着在近期的C++项目中引入.NET技术。.NET2.0以前的版本和.NET 2.0之间差异很大，这样的开发方式最好在vc2005上尝试。vc 2003,vc 2002和vc.net 上都是存在一定缺陷的，而且相互之间的代码也不能完全兼容。

   try-catch-exception,ado.net是羡慕已久的2项.NET技术了。终于可以在项目中尝试一把了。
   
   ISO C++自身也带有try,catch关键字。无论从使用角度还是实际效果方面都没有.NET的try-catch爽。.NET 的try-catch关键字有.NET强力支持，在查找bug和预防程序崩溃方面异常有用。基本上能避免应用程序完全崩溃。

  ado.net和其扩展Microsoft.Practices.EnterpriseLibrary.Data在操作database方面异常的方便。比起C++需要使用各种api或者ado来操作数据库，完全是2个世界的。

  最终完成的项目,99%的代码是ISO C++编写,数据库操作代码和部分try-catch用C++/CLI。C++/CLI的语法以及常用操作符号和ISO C++差异很大，很容易就能分辨出哪些是ISO C++代码，那些C++/CLI代码。在维护上也没有太多问题。不过实际开发过程中，如果不做控制,C++/CLI的代码最终会“蔓延”开来,越来越多。

   最后编译下来，部分ISO C++、C++/CLI代码编译成了.net的中间代码。部分ISO C++代码则还是二进制代码。完全是一个"怪物"应用程序。vc 2005的cl的确有些夸张，这样都能够编译。ISO C++和C++/CLI在某些角度来看是完全两种语言。cl居然能够分辨出来做出不同的编译．
 
  实际运行下来，这样的开发方式完全是可以接受的。数据库操作部分的代码不在有以前使用ado时候那种拖沓、难看的代码了。.NET版本try-catch的引入，使得程序稳定性增强不少。

附一段C++/CLI的操作数据库代码

try
	{
		Database^ db = nullptr;
		String^ sqlCommand = nullptr;
		DbCommand^ dbCommand = nullptr;
		IDataReader^ dataReader = nullptr;

		db = DatabaseFactory::CreateDatabase();

		String ^ temp = nullptr;

		sqlCommand = String::Format("select * from table where ID = {0} and type=1 ",ID);
		dbCommand = db->GetSqlStringCommand(sqlCommand);
		dataReader = db->ExecuteReader(dbCommand);
		if (dataReader->Read())
		{
			temp= (String^)dataReader[0];
		}

	}
	catch(Exception^ ex)
	{
		Console::Write(ex->ToString());
	}

 

个人以为，移植老的cpp程序，不浪费已有的资源，用一下C++/CLI，还是不错的

.NET全新的项目，干吗不用C#呢？


C++本来就够复杂的可以了，C++/CLI搞得更复杂。

一是项目所需。
另外一个C#1.0,C#1.1对于一个用惯C++的技术人员来说，束手束脚的地方实在太多。经常能写出一堆有类似逻辑，但是因为语法上的原因而无法合并的函数。C#2.0则因为引入范型这类概念，就好过很多了。

虽然整个C++体系的确很复杂，不过项目中能够用到的技术并不是很多，对项目本身来说影响并不大。就怕对某项C++技术一知半解，却当作项目核心技术在使用。

我比较奇怪楼主为何强调 try catch 这个方面的问题，在我看来 .net 的异常支持并没有什么比 ISO C++ 强大的地方。能说说么？

C++/CLI支持try catch finally？

#include "stdafx.h"

class A
{
public:
	int a;
	void foo()
	{
		printf("foo %d",a);
	};
};
int _tmain(int argc, _TCHAR* argv[])
{
	try
	{
		A b;
		A *a  = new A;
		a = NULL;
		a->foo();
	}
	catch(...)
	{
		printf("failed");
	}
	return 0;
}

这个例子　输出　＂failed＂

#include "stdafx.h"

using namespace System;
using namespace System::Data;
using namespace System::Data::Common;
using namespace System::Runtime::InteropServices;

class A
{
public:
	int a;
	void foo()
	{
		printf("foo %d",a);
	};
};
int _tmain(int argc, _TCHAR* argv[])
{
	try
	{
		A b;
		A *a  = new A;
		a = NULL;
		a->foo();
	}
	catch(Exception ^ex)
	{
	Console::Write(ex->ToString());
	}
	return 0;
}

这个例子输出


以上２个例子，全部release版本编译.


ps:这个空行真是难看，明明我贴代码的时候没有这么多空行的，奇怪

原来你是在说 .net 里面 exception 的 stack trace 的支持，我想岔了。这个没错，stack trace 没有运行时系统或是虚拟机的支持不怎么好做，ISO C++ 里面没法加的。

虽然在windows上用API可以stack trace，不过够麻烦的。远没有.NET如此方便.

很讨厌C++/CLI。
我们的产品本是基于VC6的，新版本全部用C#重新开发了，
只有一点底层操作库还是用C++写的，供C#调用。

如果是服务器段产品，不妨用下C++/CLI,用C#改写，不知道你们怎么考虑的。就我自己经验来说，最忌讳这种翻版工作了。