有没有理由再使用VC ++了？ [英] Is There Any Reason to Even Use VC++ Anymore?

问题描述

除了遗留或非.NET应用程序之外，还有什么理由使用VC ++

了吗？对于.NET应用程序来说，似乎没有理由选择C ++而不是C＃，因为C＃开发速度更快（即没有头文件，

对象更容易创建和使用，C＃语言是.NET的原生语言。


我确定这个问题会激起一些情绪:-)


-

Greg McPherran
www.McPherran.com

解决方案

这里有一些争论：

http://blogs.msdn.com/texblog/archiv...21/495404 .aspx


特德。


" Greg" < [e-mail]>在消息中写道

新闻：B6 ********************************** @ microsof t.com ...

除了遗留或非.NET应用程序之外，还有什么理由使用
VC ++
了吗？似乎对于.NET应用程序，没有理由选择C ++而不是C＃，因为C＃开发速度更快（即没有头文件，
对象更容易创建和使用，C＃语言原生于.NET）

我相信这个问题会激起一些情绪:-)

-
Greg McPherran www.McPherran.com

查看我的文章：

[理性尝试将C ++ / CLI证实为一流的CLI语言]

URL http://www.codeproject.com/managedcpp/whycppcli.asp


-

问候，

Nish [VC ++ MVP]

" Greg" < [e-mail]>在消息中写道

新闻：B6 ********************************** @ microsof t.com ...

除了遗留或非.NET应用程序之外，还有什么理由使用
VC ++
了吗？似乎对于.NET应用程序，没有理由选择C ++而不是C＃，因为C＃开发速度更快（即没有头文件，
对象更容易创建和使用，C＃语言原生于.NET）

我相信这个问题会激起一些情绪:-)

-
Greg McPherran www.McPherran.com

感谢您的回复。


这是我的评估：


对于RAD GUI密集型前端也可以发布到网上：C＃


仅适用于Windows的GUI密集型应用程序：

C＃除非交付大小很重要（例如下载）和你不想要

要求cutomer拥有.NET，然后是C ++和原生的。


对于仅限Windows的应用程序，其中GUI不是主要的piece：

如果性能和/或交付规模至关重要，那么C ++当地人。只有使用

..NET，如果它具有MFC / ATL等不具备的关键功能。

我们有一个频谱：


-------------------------------------

Web

-------------------------------------

Windows GUI / DB应用程序

----------------------------------- -

Windows编号紧缩应用

Windows直接图形游戏

---------------- ---------------------

快速ATL浏览器对象

--------- ----------------------------

司机

----- --------------------------------


频谱的每个区域都有映射到它的语言/技术。

问题是中间存在灰色区域:-) C＃通常是可取的

用于Web和GUI密集型Windows专用应用程序。对于许多仅限Windows的应用程序，C ++ native仍然通常是
。我不认为这仅仅是因为我们有MFC和ATL已经过时的
..NET。每个人都有自己的位置。


C＃可能会开始淹没到现在被C ++覆盖的区域，而C ++可能会开始drill
向上钻取到Web和.NET（就像它在VS 2005中已有的那样）。


我认为管理这一切的一种聪明方法是将GUI前端与
$隔离开来。 b $ b您的核心应用程序在您的架构中运行。这样，.NET vs native

决定可以独立地为这些架构区域做出决定。对于

示例，可以将应用程序的GUI演变为.NET，并将应用程序处理为

native。或者相同的应用程序甚至可能采取两种形式（没有双关语:-)）一个

带有.NET前端，另一个带有MFC前端。两者都可以支持

具有适当的架构，每种口味都有它自己的优势。

我们不再在堪萨斯州托托:-)选择你的你正在努力的工具

要完成什么，什么能让你最快到达目的地。它不是 - 或者，它是

以上所有:-)


-

Greg McPherran
www.McPherran.com

Except for legacy or non-.NET applications, is there any reason to use VC++
anymore? It seems that for .NET applications, there would be no reason to
choose C++ over C# since C# is faster to develop with (i.e. no header files,
objects are easier to create and use, C# language is native to .NET)

I''m sure this question will stir some emotions :-)

--
Greg McPherran
www.McPherran.com

解决方案

Here''s some arguments pro-con:

http://blogs.msdn.com/texblog/archiv...21/495404.aspx

Ted.

"Greg" <[e-mail]> wrote in message
news:B6**********************************@microsof t.com...

Except for legacy or non-.NET applications, is there any reason to use
VC++
anymore? It seems that for .NET applications, there would be no reason to
choose C++ over C# since C# is faster to develop with (i.e. no header
files,
objects are easier to create and use, C# language is native to .NET)

I''m sure this question will stir some emotions :-)

--
Greg McPherran
www.McPherran.com

See my article :

[A rational attempt to substantiate C++/CLI as a first class CLI language]
URL http://www.codeproject.com/managedcpp/whycppcli.asp

--
Regards,
Nish [VC++ MVP]
"Greg" <[e-mail]> wrote in message
news:B6**********************************@microsof t.com...

Except for legacy or non-.NET applications, is there any reason to use
VC++
anymore? It seems that for .NET applications, there would be no reason to
choose C++ over C# since C# is faster to develop with (i.e. no header
files,
objects are easier to create and use, C# language is native to .NET)

I''m sure this question will stir some emotions :-)

--
Greg McPherran
www.McPherran.com

Thank you both for your responses.

Here''s my assessment:

For RAD GUI-intensive front ends that may also be published to web: C#

For Windows-only GUI-intensive apps:
C# unless delivery size is critical (e.g. download) and you don''t want to
require cutomer to have .NET then C++ and native only.

For Windows-only apps where the GUI is not the major piece:
If performance and/or delivery size is critical then C++ native. Only use
..NET if it has critical features that are not available in MFC/ATL etc.
We have a spectrum:

-------------------------------------
Web
-------------------------------------
Windows GUI/DB apps
-------------------------------------
Windows number crunch apps
Windows direct graphics games
-------------------------------------
Fast ATL browser objects
-------------------------------------
Driver
-------------------------------------

Each area of the spectrum has languages/technologies that map to it. The
problem is that there are grey areas in between :-) C# is generally advisable
for web and GUI intensive Windows-only apps. C++ native is still generally
advisable for many Windows-only apps. I don''t think that just because we have
..NET that MFC and ATL are antiquated. Each has its own place.

C# may begin to drill drown to areas now covered by C++ and C++ may begin to
"drill up" to the web and .NET (as it already has in VS 2005).

I think a smart way to manage all this is to isolate the GUI front end from
your core app crunching in your architecture. This way, the .NET vs native
decision can be made independently for these architectural areas. For
example, one could evolve an app''s GUI to .NET and leave the app crunching in
native. Or the same app may even take two forms (no pun intended :-) ) one
with a .NET front end and one with an MFC front end. Both could be supported
with a proper architecture and each flavor could have it''s own advantages.
We''re not in Kansas anymore Toto :-) Pick your tool for what you''re trying
to accomplish and what will get you there fastest. It''s not either-or, it''s
all of the above :-)

--
Greg McPherran
www.McPherran.com

这篇关于有没有理由再使用VC ++了？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！