C ++ / CLI是否获得了任何牵引力？ [英] Is C++/CLI gaining any traction???
问题描述
我一直在寻找新的IT职位，到目前为止，与Windows平台相关的大部分工作都是C＃/ .Net，还有一些vb.net
经常请求。甚至许多C ++ / MFC / ATL职位都是那些公司希望将其迁移到C＃和.Net的公司。我没有看到一个职位要求C ++ / CLI，更不用说任何听说过这个职位的b $ b $招聘人员了！
我可以理解那些希望创建新应用程序的公司
希望从C＃开始，因为它是新的时尚语言和专为.net制作的一个
，但是我会想那些想要移植他们的C ++ / Win32 / MFC / ATL的人，会看到新的和改进的b / b $ C $ / CLI来迁移那些有意义的部分整合.net。
相反，我主要在Windows上看到以下类型的职位：/ b
到C ++：
1）新的应用程序请求C＃/。Net，而某些vb.net只需要
2）将所有原生C ++应用程序移植到C＃/ .Net
3）坚持使用原生C ++，完全没有.Net
就像我提到的，我可以理解1）因为如果你要创建新的
..Net的东西，不妨使用构建的语言特别是它。
3）我可以理解，因为如果你已经有本地的东西，那么
适合你，特别是如果它的应用程序具有性能和/>
可移植性，没有理由去.net。
2）但是，我认为是疯了！看起来有些公司已经将.b $ b买入了.net炒作，并认为他们需要将他们原生的C ++应用程序完全转换为C＃。可悲的是，他们似乎并不知道他们可以使用C ++ / CLI来扩展和保留他们现有的原生C ++代码。 C ++ / CLI是这种
类型迁移的完美候选者，但似乎没有人意识到它！
我只能总结一些事情：1）C ++ / CLI来得太晚了。这应该是第一种出来的语言，而不是可怕的管理C ++的b
。 2）微软在营销方面做得很惨淡。
C ++ / CLI。 3）我的感觉是，硬核C ++编程商店可能不会关心.Net，而且，我认为对.Net扩展语言有一些很强的b $ b抵抗力C ++。只需阅读一些
新闻组，如comp.lang.c ++或comp.lang.c ++。主持。
很遗憾看到这一点，鉴于所有投入到C ++ / CLI，以及
因为我最喜欢的两位C ++作者，即Stan Lippman和
Herb Sutter，为此投入了大量的工作但是看起来市场似乎不知道，甚至可能对它不感兴趣。
但我认为C ++ / CLI可能会消失，或构成一个非常小的利基。我认为最好的办法就是坚持使用C＃/。Net（或vb.net），如果现在和将来你将要做Windows，并且将来，以及对于原生C ++，
如果你在Windows平台上工作作为维护程序员，那么可以转移到Unix / Linux环境中，其中大部分是新的和切割的/>
涉及C ++的边缘内容，以及C正在进行。
-Don Kim
Don，
我同意你对CLI / C＃的看法。我不认为CLI是获得任何动力的
。甚至MC ++也没有获得任何动力。当.Net首次发布时，如果CLI被释放，它可能会有不同的价值。但是我确实怀疑它。
但在我看来，主要因素是使用
MFC / ATL开发的应用程序/ Win32通常没有任何需要管理。没有
令人信服的理由这样做。它真的不会给你带来任何其他可能的头痛（更多QA）和可能的性能问题。对于用C ++编写的现有商业非托管应用程序，它是一个主要的b
步骤。在我看来，管理土地中的C ++有点不自然。很难看到Herb Sutter要求输入修改C ++到现在
托管表单（CLI）（在Redmond也是如此）。
就C＃与CLI而言，C＃的胜利主要是因为它的简单性（与C ++相比）并且与CLI相比销售得非常好。
--------
Ajay Kalra
aj *******@yahoo.com
>我只能总结一些事情：1）C ++ / CLI来得太晚了。这应该是，而不是可怕的管理C ++。 2）微软在营销C ++ / CLI方面做得很惨淡。
3）我的感觉是，硬核C ++编程商店对.Net的关注度较低，而且我认为还有一些阻力关于一个.Net的扩展语言。只需阅读一些新闻组，例如
comp.lang.c ++或comp.lang.c ++。moderated。
考虑到投入C ++ / CLI的所有投资，我很难过。以及我最喜欢的两位C ++作者，即Stan Lippman和Herb
Sutter，为此付出了很多努力，但似乎市场对此一无所知，也许甚至抵制它。
C ++ / CLI要好得多......但如果他们单独留下语法
，我会更喜欢。而不是所有这些参考东西和^指针，他们应该有
只是说
托管类MyClass
{
... 。
public：
void DoSomething（int * myInt）// *通过引用传递
{
。 ..
}
unmanaged int DoSomethingElse（）''
{
}
}
和一些.NET特定的东西在标准中无法表达
C ++ ......但在大多数情况下，我认为C ++ / CLI语法是quircky虽然比b ++更优惠
。
我使用C ++ / CLI（有时）代替C＃因为（某些）类型的
$ b我创建的$ b项目在使用
C ++ / CLI编译器而不是C＃时看到显着的性能提升，因为C ++ / CLI编译器将在编译期间优化
代码而不是离开JIT''er的一切都像C＃
那样。这导致.NET应用程序的性能显着提高，这是我使用C ++ / CLI的东西。通常我会使用C＃。
这就是说，我注意到C ++ / CLI也在慢慢吸收，但所有的东西都是.NET
2.0似乎慢不知道为什么。也许是因为敬畏因素
新的2.0功能的
在两年前第一次开始讨论它时就已经消失了。现在它出局并没什么大不了的。我预测相同的
..NET 3.0。
谢谢，
Shawn
< BLOCKQUOTE>>但在我看来，主要因素是使用
MFC / ATL / Win32开发的应用程序通常不需要管理。
完全正确。 GC已经存在了几十年。这不是新的。 MS给出了他们创造全新技术的
印象 - 他们没有。
它解决了一组问题并介绍了其他人
有一些可能受益的应用程序，而非所有应用程序很多
会慢很多 - 很多。
对我来说，整个.NET都是政治性的。这不是预付款。
它旨在接管并杀死Java。
没有令人信服的理由这样做。
确切地说
除了可能的头痛（更多QA）
以及可能的表现>问题之外，它真的不会给你买任何东西。
完全正确。浪费时间。我可以看到MS福音传教士跳舞，写作
白皮书，文章，书籍，以及
公司的牧师和程序员编写新应用程序，将旧应用程序重写为.NET应用程序。
为了什么？他们不会更快。有些会慢很多。
Win32没有什么特别的错误。
鉴于10年，MS将放弃它。
它是不过是最新的程序员时尚。
任何经理都在阅读 - 避免它。只考虑它是否提供了一些你需要的简单的功能，使用Win32 API编写代码并不容易。
我们公司有MFC7应用程序和Win32 DLL 。他们都不需要写作
作为.NET应用程序。
没有任何好处。
对于现有的商业非托管应用程序写的在C ++中，它是一个重要的步骤。在我看来，管理土地中的C ++有点不自然。很难看到Herb Sutter要求输入修改C ++到现在的管理形式（CLI）（在Redmond也是如此）。
他做得很好。
托管C ++的第一个版本非常笨重。
当前版本很多更好。
即使这样，我也不是enam
就C＃与CLI而言，C＃获胜主要是因为它的易用性（与C ++相比）与CLI相比，它的销售情况非常好。
不确定。
现在有很多相同语法语言的方言 - C ++，
C ++ / CLI，C＃，Java，D
它在单个/多个继承，模板，
垃圾收集上占据不同的位置。
我个人认为从长远来看C＃会输。它只有.NET和
Windows。
C ++可用于多个平台，它不需要图形和
有很多聪明的人继续以ISO标准的
条款投入其开发。
Java仍然存在但它已经失去了它的方式。
D值得一看。
Stephen Howe
I''ve been looking for a new IT position, and so far, the majority of
work with respect to the Windows platform is C#/.Net, with some vb.net
requests every so often. Even many of the C++/MFC/ATL position are ones
in which the companies are looking to migrate this to C# and .Net. I
have NOT even seen one position requesting C++/CLI, let alone any
recruiters who have even heard of it!
I can understand those companies looking to create new applications
looking to start with C#, since it is the new trendy language and one
made specifically for .net, but I would think those looking to migrate
their C++/Win32/MFC/ATL stuff, would be looking at the new and improved
C++/CLI to migrate those portions which make sense to integrate .net.
Instead, I''ve mostly seen the following types of positions with respect
to C++ on Windows:
1) New apps with C#/.Net requested, and some vb.net only
2) Port all native C++ apps to C#/.Net
3) Stick with native C++, with no .Net at all
Like I mentioned, I can understand 1) since if your going to create new
..Net stuff, might as well use the language built specifically for it.
3) I can understand, since if you have native stuff already that is
working well for you, and especially if its apps with performance and
portability in mind, there is no reason to go .net.
2) though, is what I think is nuts! Looks like some companies have
bought into the .net hype, and are under the notion that they need to
convert their native C++ apps completely to a C# one. Sadly, they don''t
seem to know that they can use C++/CLI to extend and preserve their
existing native C++ code. C++/CLI is the perfect candidate for this
type of migration, yet no one seems to be aware of it!
I can only conclude a few things: 1) C++/CLI came too late. This should
have been the first language to come out, instead of the horrendous
managed C++. 2) Microsoft has done a lackluster job of marketing
C++/CLI. 3) My feeling is that the hardcore C++ programming shop could
care less about .Net, and furthermore, I think there is quite some
resistance about a .Net extended language of C++. Just read some of the
newsgroups like comp.lang.c++ or comp.lang.c++.moderated.
Its sad to see this, given all the investment put into C++/CLI, as well
as the fact that two of my favorite C++ authors, namely Stan Lippman and
Herb Sutter, put a lot of work into this, yet it seems the marketplace
is ignorant of, and maybe even resistent to it.
But I think C++/CLI may wither away, or comprise a very small niche. I
think the best thing to do is either stick with C#/.Net (or vb.net) if
your going to do Windows now and in the future, and for native C++,
either work as a maintence programmer if your on the Windows platform,
or move to a Unix/Linux environment where most of the new and cutting
edge stuff involving C++, as well as C is going on.
-Don Kim
Don,
I am in agreement with you regarding CLI/C#. I dont think CLI is
gaining any momentum. Even MC++ did not gain any momentum. It may have
been different had CLI been released when .Net as first released. But I
really doubt it.
But in my view, the main factor is that applications developed using
MFC/ATL/Win32 typically do not have any need to go managed. There is no
compelling reason to do so. It really does not buy you anything other
than possible headaches(more QA) and possibly performance issues. For a
existing commercial unmanaged application written in C++, its a major
step. In my view, C++ in managed land is kind of not natural. It was
hard to see Herb Sutter asking for input to modify C++ to its present
managed form(CLI) (that too in Redmond).
As far as C# vs CLI is concerned, C# wins mainly because of its
ease(compared to C++) and was marketed very well compared to CLI.
--------
Ajay Kalra
aj*******@yahoo.com
> I can only conclude a few things: 1) C++/CLI came too late. This shouldhave been the first language to come out, instead of the horrendous
managed C++. 2) Microsoft has done a lackluster job of marketing C++/CLI.
3) My feeling is that the hardcore C++ programming shop could care less
about .Net, and furthermore, I think there is quite some resistance about
a .Net extended language of C++. Just read some of the newsgroups like
comp.lang.c++ or comp.lang.c++.moderated.
Its sad to see this, given all the investment put into C++/CLI, as well as
the fact that two of my favorite C++ authors, namely Stan Lippman and Herb
Sutter, put a lot of work into this, yet it seems the marketplace is
ignorant of, and maybe even resistent to it.
C++/CLI is much better... but I would have preferred if they left the syntax
alone. Instead of all this "ref" stuff and "^" pointers, they should have
just said
managed class MyClass
{
....
public:
void DoSomething(int *myInt) // * pass by reference
{
...
}
unmanaged int DoSomethingElse()''
{
}
}
and perhaps a few .NET specific things that aren''t expressible in standard
C++... but for the most part, I think the C++/CLI syntax is "quircky" though
better than MC++.
I use C++/CLI (sometimes) instead of C# because (some of) the types of
project I create see significant performance increases when using the
C++/CLI compiler instead of C# because the C++/CLI compiler will optimize
code during compile time instead of leaving everything to the JIT''er as C#
does. This results in drastically better performance .NET applications for
the things I use C++/CLI for. Usually I use C#, though.
That said, I''m noticing C++/CLI making slow uptake also, but all things .NET
2.0 seem to be slow. Don''t know why. Perhaps its because the "awe" factor
of the new 2.0 features wore off two years ago when they first starting
talking about it. Now its out and its no big deal. I predict the same for
..NET 3.0.
Thanks,
Shawn
> But in my view, the main factor is that applications developed usingMFC/ATL/Win32 typically do not have any need to go managed.
Exactly. GC has been around for many decades. It is not new. MS gives the
impression they have created brand new technology - they have not.
It solves one set of problems and introduces others
There are some applications that might benefit, not all applications. Many
will be slower - by a lot.
To me, the whole of .NET is political. It is not an advance.
It is designed to take on and kill Java.
There is no compelling reason to do so.
Exactly
It really does not buy you anything other than possible headaches(more QA) and possibly performance >issues.
Exactly. Waste of time. I can see MS evangelists dancing, writing
whitepapers, articles, books all to herd managers and programmers in
companies to write new apps, rewrite old apps as .NET applications.
And for what? They won''t be any faster. Some will be a lot slower.
There is nothing particularly wrong with Win32.
Given 10 years, MS will abandon it.
It is no more than the latest programmer fashion.
Any manager reading this - avoid it. Only consider if it provides some easy
functionality you need that is not easy to code using Win32 APIs.
We have MFC7 apps and Win32 DLLs in our company. None of them need writing
as a .NET app.
No benefit whatsover.
For a
existing commercial unmanaged application written in C++, its a major
step. In my view, C++ in managed land is kind of not natural. It was
hard to see Herb Sutter asking for input to modify C++ to its present
managed form(CLI) (that too in Redmond).
He has done a good job.
The first version of managed C++ was appalingly clunky.
The current version is much better.
Even so, I am not enam
As far as C# vs CLI is concerned, C# wins mainly because of its
ease(compared to C++) and was marketed very well compared to CLI.
Not sure about that.
Right now there are many dialects of the same syntactic langauge - C++,
C++/CLI, C#, Java, D
which take various positions on single/multiple inheritance,templates,
garbage collection.
I personally think that in the long run C# will lose. It is only .NET and
Windows.
C++ is available for multiple platform, it does not require graphics and
there are many bright people continually inputing into its development in
terms of a ISO standard.
Java will still be around but it has lost its way somewhat.
D is one to watch.
Stephen Howe
这篇关于C ++ / CLI是否获得了任何牵引力？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
