110,533
社区成员
发帖
与我相关
我的任务
分享VC->C#，有什么区别，需要做什么调整？
1.一直泡在VC里，转向VC.NET需要掌握什么新内容？
2.另外VC.NET与C#有和关系，有和区别
3.FrameWork为何？
...全文
请发表友善的回复…
发表回复
ilian 2003-01-12
- 打赏
- 举报
另VC.NET中还可以用MFC，也就是说VC.NET有两个重复的库认你使用，呵呵…
ilian 2003-01-12
- 打赏
- 举报
1、你要掌握framework的类库(fcl)和运行机制…
2、C#没有MFC这一块，C#要完成什么任务只能靠fcl，但然是主要也可以平台调用
，接间调用com组件；还一些语法差异，另用fcl做的程序是先编译为的中间言语，
(MSIL)总之好处大于坏处…
3、.net framework 主抱括fcl类库、公共运行库(CLR)它主要起着管理和执行
MIIL的作用，抱括时实编译JIT、垃圾回GC、装入模块、检查模块等组成…
2、C#没有MFC这一块，C#要完成什么任务只能靠fcl，但然是主要也可以平台调用
，接间调用com组件；还一些语法差异，另用fcl做的程序是先编译为的中间言语，
(MSIL)总之好处大于坏处…
3、.net framework 主抱括fcl类库、公共运行库(CLR)它主要起着管理和执行
MIIL的作用，抱括时实编译JIT、垃圾回GC、装入模块、检查模块等组成…
yarshray 2003-01-12
- 打赏
- 举报
1.一直泡在VC里，转向VC.NET需要掌握什么新内容？
MFC7+.NET Framework新内容就多看看MSDN对ATL进行了扩展,然后加入了
.NET Framework.然后VS6里的原有的AppWizard被属性完全取代,但更加方面
就连BS来华访问那时候也说过.这IDE不错.
2.另外VC.NET与C#有和关系，有和区别
关系是如果用VC.NET做中间层,然后用C#来和底层打交道,那是在好不过的了
但C++和C#区别还是很大的,首先,C++的很多语法,看上去很不错,但奇异很大
如多重继承.在C#中就没有,而取而代之的是接口.
3.FrameWork为何？
我想你问错了吧?如果你用MFC怎么会不知道FrameWork是个啥东东咧?
我想你大该是在问.NET FrameWork是何物吧?
和MFC是几乎一个概念级的东西,但和MFC有区别,首先MFC是基于
COM组件技术的,但.NET FrameWork是基于.NET组件.这一点,参考
的资料很多.由于篇幅有限不详述.其次.NET FrameWork可以说
是个RAD快速开发的这样一个FrameWork 所以在C#中是不存在
Document/View/Window 这样的组合的,而是一个完全基于组件
开发的环境.另外,关于事件消息的传递问题,MFC通过宏和建立
一组表,然后使用消息蹦,来传递消息,但C#中使用代理这就很类似
与C/C++中的函数指针.关于这一点可以参考的文章也很多,不详述.
另:说了这么多,不是说VC在推荐你使用那种语言就放弃那种语言.是
希望你能知道,两者间的联系和不同,使用在那种场合还须设计者对两
种环境的把握上.希望两种都学都用.方为上上之策.(完)
*如以上有什么错误尽请指出,本人愿洗耳恭听.
MFC7+.NET Framework新内容就多看看MSDN对ATL进行了扩展,然后加入了
.NET Framework.然后VS6里的原有的AppWizard被属性完全取代,但更加方面
就连BS来华访问那时候也说过.这IDE不错.
2.另外VC.NET与C#有和关系，有和区别
关系是如果用VC.NET做中间层,然后用C#来和底层打交道,那是在好不过的了
但C++和C#区别还是很大的,首先,C++的很多语法,看上去很不错,但奇异很大
如多重继承.在C#中就没有,而取而代之的是接口.
3.FrameWork为何？
我想你问错了吧?如果你用MFC怎么会不知道FrameWork是个啥东东咧?
我想你大该是在问.NET FrameWork是何物吧?
和MFC是几乎一个概念级的东西,但和MFC有区别,首先MFC是基于
COM组件技术的,但.NET FrameWork是基于.NET组件.这一点,参考
的资料很多.由于篇幅有限不详述.其次.NET FrameWork可以说
是个RAD快速开发的这样一个FrameWork 所以在C#中是不存在
Document/View/Window 这样的组合的,而是一个完全基于组件
开发的环境.另外,关于事件消息的传递问题,MFC通过宏和建立
一组表,然后使用消息蹦,来传递消息,但C#中使用代理这就很类似
与C/C++中的函数指针.关于这一点可以参考的文章也很多,不详述.
另:说了这么多,不是说VC在推荐你使用那种语言就放弃那种语言.是
希望你能知道,两者间的联系和不同,使用在那种场合还须设计者对两
种环境的把握上.希望两种都学都用.方为上上之策.(完)
*如以上有什么错误尽请指出,本人愿洗耳恭听.
win32c 2003-01-12
- 打赏
- 举报
微软新任Visual C++架构师Stanley Lippman访谈
Chris Maunder 著 荣耀 译
Stanley Lippman 在C++语言方面和C++社团里有很长的历史背景了。他是C++最早的使用者和实现者之一，曾是Bjarne Stroustrup领导的贝尔实验室基础项目组的一员，做过Walt Disney特色动画公司首席软件工程师，并撰写了象《C++ Primer》这样的大量脍炙人口的专著。
Stanley 最近加入微软，出任Visual C++架构师，我抓住时机做了个随访，以了解他眼中的Visual C++的过去、现在和将来以及他对Visual C++的个人目标。首先也是最重要的是，我要为广大C++开发人员提供一个权威的答案—大多数人都有郁闷已久的疑问： 我们原先掌握的技术在.NET的世界里是否还能派上用场？C++会降级到Win32 开发的次要位置吗？微软会实现持续改进C++兼容性的承诺吗？
记住这一点很重要： Stanely是Visual C++语言架构师，并且他是新任的，因此，象MFC、ATL、WTL等库和Visual Studio这样的工具，都不在Stanley的影响和经验作用范围之内。因此，这次访谈就集中于绝大多数开发人员都关心的问题： Visual C++的将来究竟如何？
首先，我问Stan是什么吸引他愿为微软工作。
Stanely的Unix技术背景深厚，同时兼具多种异质平台开发经历。显然，一些平台要比另外一些易用。谈及.NET，Stanley毫不掩饰对其蕴藏理念的欣赏之情。“框架无疑是令人惊奇、丰富和有意思的。”Stanely曾经有在让即使是线程这样概念简单的东西运作起来都很痛苦的平台上工作的经历，因此，有那么一个容易理解的基础类库，提供诸如容易理解的线程模型之类的功能，并可被你选择的任何一种.NET语言所访问，就极为重要。
对于Visual C++如何适应于.NET整体蓝图，起初Stanley只有有限的想法，但进一步研究后，他惊讶地（同时也是高兴地）意识到，C++非但未被.NET遗弃，实际上更是一等.NET语言！
那么，对于Visual C++的将来你怎么看？并且，作为新任架构师，你的目标是？
对于将来，Stanley非常明晰。“我坚信Visual C++会有更加繁荣的将来！”。Stanley已经会见过Visual C++开发组，并说他（她）们都有无容置疑的激情和活力。Stanely的目标非常简单，“Visual C++将是值得选择的C++实作品”。他的个人目标是让广大C++开发者选择Visual C++并不仅仅是基于工具和平台方面的考虑，而是因为它是C++标准首屈一指的实作品。
关于编译器的兼容性
谈及C++兼容性，Stanley坦言最新发行版（Visual C++ 7.0）还没有正式出炉，但实质性工作早已潜在进行，这就意味着更广泛的兼容性实现指日可待。他将推动这种兼容性的进程，尤其是在模板领域。
尽管Visual C++ 7.0并没有完全实现Stanley乐于看到的所有特性，但他宣称这仍是直到目前为止微软发行的所有版本的C++中兼容性最好的一个版本。它并非百分之百完美，但仍不愧是一个优秀的高度标准兼容的编译器。凡是仍有争议的问题，将会完整描述于署题为“Visual C++标准兼容性问题”的VS.NET文献里。
微软的目标是提供一个“富有竞争力的兼容的”编译器—这就意味着它并非百分之百兼容。ANSI/ISO标准提到的几个特性（如施行于模板类的“export”关键字）将不会予以实现，因为至少在眼下，理论上讲，微软认为他们语意不清。然而，微软正在努力工作以确保Visual C++能够编译诸如Boost、Blitz、Loki等绝大多数流行库，并且完全兼容STL。兼容的重点在于能够编译最流行的库，而不是百分之百的兼容。
微软C++产品经理Nick Hodapp也补充说，尽管高度兼容无疑是一个非常重要的目标，但微软绝不会以牺牲生成的代码质量和强健性为代价来换取极端兼容。尽管如此，最近实验室测试仍表明：在兼容性测试方面，它仍击败了时下几个流行的编译器。
什么时候可以看到新版本？
Stanely大笑起来，他说如果由他来决定的话，他每周都会发布一个升级版。但是，和Visual C++本身一样复杂的诸如质量控制和过程（控制）同样必须要遵守。最新版将于2002年2月左右发行，并预期同年随后对编译器做个升级，但目前尚不能确定是否可能。当然了，他将为早日实现升级而奋战。Nick hodapp也同意这一点，并说极有可能在明年可以升级到VC7。微软正在研究发行专注于兼容性的编译器的最佳机制，以期给明年带来新气象。
很多C++开发人员感觉微软更宠爱象C#这样的新语言而让Visual C++靠边站。
Stanley希望C++将来能比现在在.NET上占有更多的席位。目前，Managed C++最大的好处在于作为一种过渡语言。你可以移植你的本地应用到.NET框架中，或在你的本地应用中使用.NET组件，但这并不是开发完全托管应用的最佳语言选择。
在这个尚未发行的Visual C++.NET（VC7）中，微软专注于互操作能力的特征。在所有托管语言中，VC7具有最好的互操作能力，并且具有在同一个映像中兼具托管代码和非托管代码的能力。他们还专注于生成MSIL的优化技术—VC7是唯一能够产生优化的MSIL的编译器。在将来，微软将集中于ANSI/ISO的一致性的实现 （使托管/非托管代码兼容更多的特性），就象专注于赋予Visual C++和C#同等功能（例如WinForms）一样。Visual C++将被定位于.NET的系统级语言。
模板支持和泛型编程是必需的，并且微软也非常热切地准备实现codeDOM支持，同样还有ASP.NET和WinForms。随着这些特性的加入，Stanley认为Visual C++必将成为.NET框架下极具威力的程序语言选择。即使不支持模板，Stanley仍坚持认为Visual C++是唯一能够提供比C#或VB.NET更多特性的语言。
Stanley庆幸微软从以公司为导向转变为更多地以开发人员为中心。他将推动公司对开发者更加公开化，并乐于看到微软越来越对开发者更加负责。微软以改革和创新而著称，但也可能成为置标准和开发者需求于不顾的冒进分子，Stanley将努力保证微软更多地倾听开发者社团的声音，同时确保更高的标准兼容。
诸如C99规范里的新特征
在谈到关于是否扩展Visual C++以采纳C99规范的新特性时，Stanley声称有关标准本身尚有待商榷。在C和C++开发中的分歧已经越来越受到关注，因为C++已经不再是前者的超集了。微软的目标是实现高度标准兼容(但那是针对C++而不是C)，如果C++标准被升级并加入新特性的话，微软将把它们纳入Visual C++的实现中。
微软会考虑加入的新特性是：
1.已经被使用于代码中并可被其他编译器所编译，或者
2.这些特性已经成为迫切要求并且显而易见开发者需要它们。
微软不会仅仅因为那些特性在标准中提到就实现它们，而会因为对开发者有用而实现之。
启示
在.NET世界里，Visual C++显然有一个充满生机和活力的光明前景。在简单性、趣味性和兼容性方面，Stanley的目标是把这个编译器做成其他编译器可以参照的基准。它应该易用、通用、讨喜，甚至无论何时，开发者一想到C++就会想到它。对C++兼容性的持续改进以及将来对ASP.NET和WinForms的特性支持，将确保Visual C++必将成为.NET平台以及本地开发的极具威力的语言。
在谈到开发人员是否会转向C#而不是Managed C++时，Stanley认为会有更多的人从VB转向C#而不是从C++转向C#。（Visual）C++是更好的、更具通用性的并且是.NET上唯一优化的编译器。
Chris Maunder 著 荣耀 译
Stanley Lippman 在C++语言方面和C++社团里有很长的历史背景了。他是C++最早的使用者和实现者之一，曾是Bjarne Stroustrup领导的贝尔实验室基础项目组的一员，做过Walt Disney特色动画公司首席软件工程师，并撰写了象《C++ Primer》这样的大量脍炙人口的专著。
Stanley 最近加入微软，出任Visual C++架构师，我抓住时机做了个随访，以了解他眼中的Visual C++的过去、现在和将来以及他对Visual C++的个人目标。首先也是最重要的是，我要为广大C++开发人员提供一个权威的答案—大多数人都有郁闷已久的疑问： 我们原先掌握的技术在.NET的世界里是否还能派上用场？C++会降级到Win32 开发的次要位置吗？微软会实现持续改进C++兼容性的承诺吗？
记住这一点很重要： Stanely是Visual C++语言架构师，并且他是新任的，因此，象MFC、ATL、WTL等库和Visual Studio这样的工具，都不在Stanley的影响和经验作用范围之内。因此，这次访谈就集中于绝大多数开发人员都关心的问题： Visual C++的将来究竟如何？
首先，我问Stan是什么吸引他愿为微软工作。
Stanely的Unix技术背景深厚，同时兼具多种异质平台开发经历。显然，一些平台要比另外一些易用。谈及.NET，Stanley毫不掩饰对其蕴藏理念的欣赏之情。“框架无疑是令人惊奇、丰富和有意思的。”Stanely曾经有在让即使是线程这样概念简单的东西运作起来都很痛苦的平台上工作的经历，因此，有那么一个容易理解的基础类库，提供诸如容易理解的线程模型之类的功能，并可被你选择的任何一种.NET语言所访问，就极为重要。
对于Visual C++如何适应于.NET整体蓝图，起初Stanley只有有限的想法，但进一步研究后，他惊讶地（同时也是高兴地）意识到，C++非但未被.NET遗弃，实际上更是一等.NET语言！
那么，对于Visual C++的将来你怎么看？并且，作为新任架构师，你的目标是？
对于将来，Stanley非常明晰。“我坚信Visual C++会有更加繁荣的将来！”。Stanley已经会见过Visual C++开发组，并说他（她）们都有无容置疑的激情和活力。Stanely的目标非常简单，“Visual C++将是值得选择的C++实作品”。他的个人目标是让广大C++开发者选择Visual C++并不仅仅是基于工具和平台方面的考虑，而是因为它是C++标准首屈一指的实作品。
关于编译器的兼容性
谈及C++兼容性，Stanley坦言最新发行版（Visual C++ 7.0）还没有正式出炉，但实质性工作早已潜在进行，这就意味着更广泛的兼容性实现指日可待。他将推动这种兼容性的进程，尤其是在模板领域。
尽管Visual C++ 7.0并没有完全实现Stanley乐于看到的所有特性，但他宣称这仍是直到目前为止微软发行的所有版本的C++中兼容性最好的一个版本。它并非百分之百完美，但仍不愧是一个优秀的高度标准兼容的编译器。凡是仍有争议的问题，将会完整描述于署题为“Visual C++标准兼容性问题”的VS.NET文献里。
微软的目标是提供一个“富有竞争力的兼容的”编译器—这就意味着它并非百分之百兼容。ANSI/ISO标准提到的几个特性（如施行于模板类的“export”关键字）将不会予以实现，因为至少在眼下，理论上讲，微软认为他们语意不清。然而，微软正在努力工作以确保Visual C++能够编译诸如Boost、Blitz、Loki等绝大多数流行库，并且完全兼容STL。兼容的重点在于能够编译最流行的库，而不是百分之百的兼容。
微软C++产品经理Nick Hodapp也补充说，尽管高度兼容无疑是一个非常重要的目标，但微软绝不会以牺牲生成的代码质量和强健性为代价来换取极端兼容。尽管如此，最近实验室测试仍表明：在兼容性测试方面，它仍击败了时下几个流行的编译器。
什么时候可以看到新版本？
Stanely大笑起来，他说如果由他来决定的话，他每周都会发布一个升级版。但是，和Visual C++本身一样复杂的诸如质量控制和过程（控制）同样必须要遵守。最新版将于2002年2月左右发行，并预期同年随后对编译器做个升级，但目前尚不能确定是否可能。当然了，他将为早日实现升级而奋战。Nick hodapp也同意这一点，并说极有可能在明年可以升级到VC7。微软正在研究发行专注于兼容性的编译器的最佳机制，以期给明年带来新气象。
很多C++开发人员感觉微软更宠爱象C#这样的新语言而让Visual C++靠边站。
Stanley希望C++将来能比现在在.NET上占有更多的席位。目前，Managed C++最大的好处在于作为一种过渡语言。你可以移植你的本地应用到.NET框架中，或在你的本地应用中使用.NET组件，但这并不是开发完全托管应用的最佳语言选择。
在这个尚未发行的Visual C++.NET（VC7）中，微软专注于互操作能力的特征。在所有托管语言中，VC7具有最好的互操作能力，并且具有在同一个映像中兼具托管代码和非托管代码的能力。他们还专注于生成MSIL的优化技术—VC7是唯一能够产生优化的MSIL的编译器。在将来，微软将集中于ANSI/ISO的一致性的实现 （使托管/非托管代码兼容更多的特性），就象专注于赋予Visual C++和C#同等功能（例如WinForms）一样。Visual C++将被定位于.NET的系统级语言。
模板支持和泛型编程是必需的，并且微软也非常热切地准备实现codeDOM支持，同样还有ASP.NET和WinForms。随着这些特性的加入，Stanley认为Visual C++必将成为.NET框架下极具威力的程序语言选择。即使不支持模板，Stanley仍坚持认为Visual C++是唯一能够提供比C#或VB.NET更多特性的语言。
Stanley庆幸微软从以公司为导向转变为更多地以开发人员为中心。他将推动公司对开发者更加公开化，并乐于看到微软越来越对开发者更加负责。微软以改革和创新而著称，但也可能成为置标准和开发者需求于不顾的冒进分子，Stanley将努力保证微软更多地倾听开发者社团的声音，同时确保更高的标准兼容。
诸如C99规范里的新特征
在谈到关于是否扩展Visual C++以采纳C99规范的新特性时，Stanley声称有关标准本身尚有待商榷。在C和C++开发中的分歧已经越来越受到关注，因为C++已经不再是前者的超集了。微软的目标是实现高度标准兼容(但那是针对C++而不是C)，如果C++标准被升级并加入新特性的话，微软将把它们纳入Visual C++的实现中。
微软会考虑加入的新特性是：
1.已经被使用于代码中并可被其他编译器所编译，或者
2.这些特性已经成为迫切要求并且显而易见开发者需要它们。
微软不会仅仅因为那些特性在标准中提到就实现它们，而会因为对开发者有用而实现之。
启示
在.NET世界里，Visual C++显然有一个充满生机和活力的光明前景。在简单性、趣味性和兼容性方面，Stanley的目标是把这个编译器做成其他编译器可以参照的基准。它应该易用、通用、讨喜，甚至无论何时，开发者一想到C++就会想到它。对C++兼容性的持续改进以及将来对ASP.NET和WinForms的特性支持，将确保Visual C++必将成为.NET平台以及本地开发的极具威力的语言。
在谈到开发人员是否会转向C#而不是Managed C++时，Stanley认为会有更多的人从VB转向C#而不是从C++转向C#。（Visual）C++是更好的、更具通用性的并且是.NET上唯一优化的编译器。
win32c 2003-01-12
- 打赏
- 举报
http://expert.csdn.net/Expert/topic/1351/1351189.xml?temp=.4064295
didibaba 2003-01-12
- 打赏
- 举报
C#不需要用到麻烦的mfc类，不需要头疼的*.h……
C#基于FrameWork，你可以调用FrameWork封装的类,当然也可以用api.
不过C#的执行通过了虚拟机，执行起来比VC要慢:(
C#基于FrameWork，你可以调用FrameWork封装的类,当然也可以用api.
不过C#的执行通过了虚拟机，执行起来比VC要慢:(
win32c 2003-01-12
- 打赏
- 举报
1新增很多！
2c#是C家族的新成员！
FrameWork
.NET 框架是一种新的计算平台，它简化了在高度分布式 Internet 环境中的应用程序开发。.NET 框架旨在实现下列目标：
提供一个一致的面向对象的编程环境，而无论对象代码是在本地存储和执行，还是在本地执行但在 Internet 上分布，或者是在远程执行的。
提供一个将软件部署和版本控制冲突最小化的代码执行环境。
提供一个保证代码（包括由未知的或不完全受信任的第三方创建的代码）安全执行的代码执行环境。
提供一个可消除脚本环境或解释环境的性能问题的代码执行环境。
使开发人员的经验在面对类型大不相同的应用程序（如基于 Windows 的应用程序和基于 Web 的应用程序）时保持一致。
按照工业标准生成所有通讯，以确保基于 .NET 框架的代码可与任何其他代码集成。
2c#是C家族的新成员！
FrameWork
.NET 框架是一种新的计算平台，它简化了在高度分布式 Internet 环境中的应用程序开发。.NET 框架旨在实现下列目标：
提供一个一致的面向对象的编程环境，而无论对象代码是在本地存储和执行，还是在本地执行但在 Internet 上分布，或者是在远程执行的。
提供一个将软件部署和版本控制冲突最小化的代码执行环境。
提供一个保证代码（包括由未知的或不完全受信任的第三方创建的代码）安全执行的代码执行环境。
提供一个可消除脚本环境或解释环境的性能问题的代码执行环境。
使开发人员的经验在面对类型大不相同的应用程序（如基于 Windows 的应用程序和基于 Web 的应用程序）时保持一致。
按照工业标准生成所有通讯，以确保基于 .NET 框架的代码可与任何其他代码集成。
