非托管的C ++ Win32 API或C＃？

Question

Good afternoon,

I thought about writing an application which I may or may not commercialize, depending on how good the final application is. It is like a personal project, with which I hope to learn many more things about programming, for currently I only know most about C and C#. That's why I thought about starting this project as an unmanaged C++ Win32 application. The problem is that it is most dificult to even show a simple window when compared to C#...

How many people/companies use the Win32 API & C++ in today's business world? How does it perform in comparison with C#?

The application in question may eventually be an IDE for a specific language but whith features like command recognition and spell checking already built in.

Thank you very much.

Answer 1

It seems that when performance is needed people are willing to give up C# for C++. Have a look at this "success" story Lessons from Evernote's flight from .NET .

On our test hardware, Evernote 4 starts five times faster, and uses half the memory of Evernote 3.5.

Evernote chose WTL and Chromium Embedded Framework . Basically they've reused Google's Chrome in their application.

Answer 2

对于您的第一个项目，并且没有C ++和Win32的先前经验，我强烈建议您使用C＃，因为它可以使您更轻松地完成工作，从而在使用过程中获得信心和技能。

Answer 3

I'm a huge fan of C++ under windows, I've been doing it most of my adult life. That said, if you have no experience of C++, and you want to write a windows application, I'd suggest going with the C# route under .NET. Whilst I love native C++, I really disliked C++/CLI, and the horrid ^ suffix for references.

Given this is a personal project, I wouldn't worry too much about whether businesses use C++ or C#, but I will say that it is easier to find a C# developer these days than it is a C++ developer. And no, I am not favouring one language over the other here, it just appears to be the reality (at least in my experience). As for C++/CLI developers? They're kind of thin on the ground :)

You'll definitely be up and running faster with C# than you would with Visual C++/MFC/some-other-gui, but remember there are certain things you may not be able to do in C# (and have to import the native win32 calls via DllImport ), but I doubt you'll come across these fringe cases just yet.

Answer 4

C# is the easy route, and the route most-often pushed by Microsoft. What they don't tell you, though, is that all of their headline products (parts of Visual Studio excepted) are written in C/C++. I'd say, in fact, that most major software packages you are familiar with are written in C/C++.

Answer 5

I'd go with c# too, as it is far more common in a business world (on GUI side at least), than unmanaged c++/win32. You'll also get your desired results faster, especially if you don't know c++.

On the other hand, c++ performs better (if written properly) - so if you are planning some intensive work in your app - maybe c# just won't handle it (but I strongly doubt this is the case).

At last, but not the least - if you are planning for clients, that for some reason do not have and can not get .NET framework (or any other framework, ie Java) - then native code is your only solution.

Answer 6

I have only been using C++ for quite a few years, but I have never had to write any programs which required a User Interface. When I did, I tried to learn to use Qt, but found it to be somewhat of a pain and eventually gave up. I recently just started taking a class on C# .NET and in the first week I have already started developing a pretty advanced application for my companies billing system.

If you were already a seasoned C++ veteran and preferred it over C# .NET, then I would say by all means go for it. In this case however, I would strongly recommend you go with C# .NET for quite a few reasons.

1) The time is takes to do something in C# will probably be at the very least about 10x faster than doing it in C++ regardless of the API you used.

2) The learning curve of C++ on top of already trying to write an application with a UI (which is already very difficult in C++) will make this take an extremely long time.