While doing Windows Mobile development, which language should I use? C# or C++ or something else? Why one is better than others?
It depends what you're coding.
Making native calls to the OS are possible via P/Invoke from C#, but extensive use is probably easier via native C++. You'll also require C++ for using some hardware that has not been wrapped by the Compact Framework.
Most hardware (GPS, camera, etc.), is available via CF. If you're working with a Win Mobile 6.x device, you're probably better off with C#. In addition to hardware, Pocket Office's (POOM) object model is also available to C#, so you can integrate with it.
It's worth noting that most references to Windows Phone 7 refer to managed code and the possibility of Silverlight. With Silverlight in the mix, you'll have to code with C#.
Unless your app is high performance or is extremely miserly with memory, use C# or VB.NET.
Scott
It depends on task mainly.
c++ has following pros/cons:
Direct access to resources, faster programs
Can access very deep OS parts, not needed for high level applicaiton
harder to develop and requires to manage resources by developer
C#:
Runs under virtual machine (CLR), that's why is slower
Faster and easier application development
Rich build-in library
There is no right answer for this, becasue there is no one-size-fits-all "better" definition. If you know C++ and have a lot of C++ code assets already, C++ sure looks appealing. If you know c# and not C++, then C# sure looks appealing.
C++ applications load faster, but for many applications, that's not relevent. C# applications can certainly be written faster, but they also don't have determinism. I'd never even attempt a UI in C++ any longer, nor would I think about doing database access in C++. I wouldn't write a driver in C# though, or a shell extension.
Generally speaking, most solutions I've ever delivered were a mix of the two. C# has its strengths. It's fast to write, easier to debug and unit test, hard (though not impossible) to create leaks and for some operations (like data access or XML parsing) it's just easier.
C++ has its strengths too, like speed of execution (though C# can be made to go just as fast for many things), determinism and the ability to plug in to things that want native entry points.
So my answer? You need to know both, and likely write your solutiuon using both. The percentage of each you end up using depends on what your end goal is.
It depends.
At least present a specific use-case. And possibly use SO search? :)
C++ or C# to program mobile barcode device?
Edit:
Apparently others were faster to the draw, and gave more articulated answers. Nevertheless, I still recommend reading the above SO thread.
From my experience it is easier to start with c#, and if the api provided by the compact framework is enough for you then you are ok.
On the other hand if your project is somewhat complex, or if you want to do something that is not in the compact framework you may end needing to create a helper .dll in c++. Even in this case you maybe good doing your main program in c#, and programming helpers dll in c++.
If you go directly to program in c++ you may benefit from the fact that you have a raw performance better than c#, which is good if you are doing a game.
But you will also suffer more from the limitation of windows mobile OS. Like a maximum of 32MB per process, or that all .dll share the same address space.
So in the end it really depends on what are planning to do and the experience you have.
Related
I have just finished my first real commercial application written in C++ / MFC.
The application consisted of agent installed on users workstations which in turn was controlled from a GUI Application on an administrators workstation. I choose C++ / MFC for these reasons.
Because I didn't know C#
Because I was not sure how long it would take for me to become as productive in a new lanuage
Because I did not want the hassle of installing the .NET runtime on workstations some of which might be W2K.
Now I am thinking of my second application which will again consist of an agent & a GUI Application. I am happy to continue on the same track with the agent for the reasons above but the GUI application will be much more complicated then the first. The first GUI app took a very long time to develop, was torturous and looked out of date even though it was freshly made.
Should I just bite the bullet with .net c# or look into something like QT.
TIA.
If you want really fast results, use .NET WinForms. Nothing beats the speed of putting together a GUI app and filling it with life, except maybe Delphi. The C# language and the .NET Base Class Library will also give you a huge productivity gain, even over the already great Qt framework. If you stick to the basic Windows Forms controls, it will even run on Mono.
WPF is even more productive once you're used to it, but getting used to it takes way more time than for Windows Forms.
.NET C# is a very good choice for GUI applications more generally. It's simple, to-the-point and there are vast resources on the internet.
The only thing against it I can think of, is platform compatibility, but if you're limiting yourself to C++/MFC, that shouldn't be a concern to you.
Even if you want to go platform-independent some time later, you can make a separate Gtk in .NET on Linux (Mono, the open-source .NET framework). Heck, there's even a Cocoa (Mac OS X) binding, I just don't know how mature it is. Furthermore Windows Forms is largely supported in Mono already... it really surprised me how mature it is when I was trying it out, although my primary experience with C# is on Windows.
For GUI application, you won't regret using C#. Even if you want to go cross-platform, and certainly not if you intend to only target Windows clients.
C# will almost definitely make you more productive!
Delphi. Produces stand-alone Windows executables which will work fine on Win2K (best OS Microsoft ever produced - this post is being written on it). Only disadvantage is Object Pascal, but if you know C++ it's very easy to pick up - and its was designed buy the guy who designed C#. The IDE is several orders of magnitude more productive than MFC with VS.
I've done them all - a monkey can use C#, it's all drag and drop interfacing and public accessors. I wouldn't wish using MFC upon my worst enemy, and QT just wasn't as intuitive as C# for me. It's also really easy to make C# look nice. Difficult things like changing colors and flashing controls are trivial in C#. It also has built in styles to use. I use it professionally daily. The only time I use C++ is if I'm programming a server where every microsecond counts.
The first question would be exactly what caused the difficulty in developing the GUI with MFC. Was it inherent to MFC, or what it because you were learning something new, and didn't really know what you were doing? To put it slightly differently, if you had to do it again today, how would the difficulty compare?
Make no mistake about it -- MFC is an old design with far more than its share of problems, shortcoming and design flaws. .NET is a lot newer, but has far more than its share of problems, shortcoming and design flaws as well.
Along with that, .NET is just plain huge. It's reasonably well organized, which helps, but it still takes quite a while to digest the sheer volume of information necessary to use it well. Likewise, while C# (for the most obvious example) is a perfectly decent language, learning to use it well isn't an overnight task either. This is probably a smaller issue though: C# doesn't really have many new concepts compared to C++. Just for example, a competent C++ programmer can easily read C# almost immediately, and while he may not use it optimally, can also write bits of C# immediately as well.
on which platform will your second app run on?
if it's XP and up i'll suggest C# / WinForms / GDI.
C# isn't that hard to adapt to, and there are literally a ton of examples online, and great books (the Head First one caught my eye as you can code a nethack clone and other fun projects). I've had to transition from C++ to C# myself, and it wasn't that rough at all (in fact it seemed like a pretty easy transition), and allowed me to rapidly prototype.
Good luck!
Which areas of programming are each language best suited for?
I like both C++ and C# but i prefer to use C# because of .NET.
My question is when will you use C++ and when do you use C#?
So if you make a financial application for a company you will use C#? ( It's easy to design a form and connect to a database without downloading 3rd party libraries, and if you make advanced algorithms you would use C++ for it's speed?
This is my idea. I just watched video's # http://www.academicearth.org, and it seems that universities prefer to use C++ for Machine Learning for example.
What do you guys think of it? and what is the industry view on this.
Trying to compare the two isn't really fair -- C++ is usually used nowadays when you have the need for low-level, or portable, high performance code. You rarely find it used to implement business logic for enterprise systems, though about 10 years ago you did. You certainly wouldn't want to start out development with an enterprise system with C++ today unless you had a really, really good reason to.
But in academia, C and C++ have been used for many years, so it's probably not surprising that there is a large base of C++ code there for things like Machine Learning. C++ can often be faster than C# when it's optimized properly. It can run with less memory, on more platforms, and with fewer dependencies on large frameworks than C# can.
C#, however, is a lot more forgiving with its memory model, and typically has access to Microsoft or Mono's very large, comprehensive framework which allows developers to do a lot of stuff with minimal development effort, time, and cost. If you're working on the Microsoft platform, it is arguably the standard language nowadays.
Always use C# for business solutions. It's a more evolved language.
I worked for a company that does real-time authentication for PPV (like if you buy WWE or boxing on cable). They have huge volume right before the event. The team that worked on that part insisted that it had to be written in C++ for speed.
After a year of debating, we finally wrote a prototype replacement in C#. It turned out that the replacement was twice as fast.
There are VERY few problem domains where you need any of the optimizations you can do in C++ that are unavailable in C#, but C# code is much less error prone.
Often we will use C# for front-end UI development, and C++ for server-side. One of the main reasons is portability/speed. People tell me mono for C# on linux/OSX is fast and stable, but from what I have seen that is not the case. YMMV.
The one feature I like in C++ is the low-level access to memory and the control over memory-layout of structures. If you interface with even lower level APIs such as OpenGL, you usually interact with arrays of basic datatypes, such as floats. In C++, you can cast a void* texture to user defined types such as Image2D<PixelWithAlphaChannel<float, 4> > and use a fully object oriented interface for this otherwise unstructured dump of unspecified data.
If you cannot afford to keep multiple copies of low-level API data, C++ is the way to keep your code clean. However, you trade a lot of developer time for this. While in theory C++ allows for faster code (or at least the same speed, you could implement .NET in C++, but not vice versa), having tools such as Resharper and dotTrace can enable developers to improve the performance faster. So in practice, I'd opt for C# for both financial applications AND performance critical algorithms, IF they are not constrained by low-level APIs.
From a commercial and support perspective, C# is still a one platform wonder. If you're not targetting the .NET runtime then it's not usually a realistic choice to use C#.
C++ is supported by a huge array of platforms, from embedded OS's to super-computers.
If you're targetting .NET, then C# is probably a more suitable language, there isn't really a good binding for C++, C++/CLI is more like a different or extended language in any case.
If there is a genuine choice, then the most overriding consideration should be the expertise available. Getting a bunch of C++ experts to develop in C# is a poor use of skills; writing a system in C++ with no C++ experts will probably result in a mess.
How is winforms programming in visual c++/c# different from windows programming in visual c++(MFC).
Also I want to know whether C# is strong enough to do Windows programming as in other than forms.
I'm not sure if anyone can give one single answer to this question, I can just try to point out a few of the many differences:
C# and C++ are quite different: Memory management, package structure, class layout, events/delegates, generics/templates... Even writing non-GUI apps is completely different in C++ and C#. Many of the features of the C# language are very helpful if not even designed for GUI development.
Winforms has a very good visual designer support if compared to MFC. For 95% of all apps, you'll be a lot more productive using winforms. This is especially true for custom controls (either your own or third party)
MFC on the other side provides more framework support (document/view structure etc.).
For some applications, MFC apps may seem more responsive. In most of these cases, a winform application can be optimized to have the same performance, but this is above the average winforms developer level (which is generally lower than the knowledge level of MFC programmers).
MFC encapsulates the WIN32 API more directly than Winforms do. There are cases where you need to access the WIN32 API even from winforms directly. Then it is not always clear (and not well documented), how to do this. Again, a typical winforms programmer has less knowledge of the WIN32 API than a MFC programmer, so in these cases he will run into troubles more likely.
I think winforms is well supported and you can solve pratically all GUI/NON-GUI tasks. For most tasks, it will be easier to write a C# program.
I'm sure, there are much more arguments pro/contra, I just noted the few that came into my mind...
There are a few notable differences:
You'll eventually be more productive as it is much easier to do (.net)
The language helps you from making a lot of common mistakes (null pointers, overflows, leaks)
The framework is a lot (and really I mean a lot) more clean than MFC
In essence you can do almost anything. The least common 0.01% of things you need to do through direct win32 DLL invokes (or use a wrapper or library someone else made)
As a professional, I have to admit that I prefer to use Delphi instead of C++ for any WIN32/Desktop development. If you're going to build GUI applications that are client applications or stand-alone applications then you might find that Delphi (and C++Builder) has far more visual components than .NET, at this moment. That's because .NET is still more popular for web development and service applications.
Doesn't mean that Delphi (or C++) is more powerful than .NET, since .NET is gaining quickly on the GUI application level. WPF/Silverlight is going to promise a lot of new possibilities for developers.
Another reason why many people are still using Delphi/C++ for WIN32 is because they still have lots of legacy code. And some of this code has already been working for over a decade and only needs additional maintenance. Rewriting those projects in C#/.NET would be way too expensive. People are considering this but existing code has proven itself already. New code will introduce new bugs.
With C# you're not going to do Windows development. You're doing .NET development and some parts of .NET will allow you to use the Windows functionality. However, a major part of the .NET classes are actually wrappers around the Windows API, making it easier to use those functions. But not everything is already implemented in .NET, so there's still a lot of work that needs to be done.
The danger of .NET development is what I like to call, the ".NET Hell". When .NET was introduced, people said it was going to end the DLL Hell that was bothering every C++ developer on Windows. Well, It did end the DLL Hell, only to replace it with the .NET Hell, where multiple versions of the same assembly are still able to cause lots of problems. So, in that regard, nothing much has changed. You're still depending on a certain runtime version of a specific library (especially with third-party libraries) so there's no real gain here.
Still, I really like .NET development, most of all because more and more applications are run as a service (SAAS) instead of the old-fashioned desktop application. Basically, you'd only need a web browser to use those applications, thus becoming less dependent on certain hardware requirements. Here lies the real strength of .NET development.
I learned windows programming using Visual C++, and the Win32 API. Nowadays, it seems most apps are being developed in .NET using C#. I understand that most of the time there isn't much performance difference between native code and managed code. So I'm wondering, if I were to start writing a new desktop app today, is there any reason (other than the fact that I'm more familiar with C++), that I might want to write it in non-managed C++ instead of .NET? Are there still some advantages to using C++ and native code? Or has that method been more-or-less replaced with .NET on the Windows platform?
Of course I know that people who are writing low-level device drivers and similar programs wouldn't do it in .NET. I'm asking with reference to typical client-facing apps that don't make direct hardware calls.
IMO the most important one for small downloadable applications is that native code does not need the .NET runtime. While broadband becomes more and more common not nearly everybody has it yet.
Some people may be disappointed to see that your 2 MB application actually requires another 20MB of framework download and a bothersome installation process to run. If they are not sure whether or not they really need your application in the first place, they might just delete it before even giving it a try and turn to a competing product.
Performance (certain situations, such as graphics)
Memory footprint (as Mancuso said)
Use of existing libraries
No need for a runtime
Finer control
To list a few.
However, you may also want to look at the question from the opposite angle to fairly evaluate which language to use.
Additionally, you could use C++/CLI to incorporate both native and .net code.
If your application needs to be able to run without an installation (i.e. if you can't or shouldn't do something like install the .NET framework), you can't count on .NET being on a windows machine (pre-Vista). Lots of utility applications can fall in this category.
I would recommend to write every desktop application in managed code. .NET/C# is a great platform to do so.
My reasons:
Performance penalty is negligible. Google for benchmarks if you don't take my word. What matters more is the code itself. You can write O(n^m) algorithms in C++ or .NET/C#. JIT engines are very mature these days.
Unmanaged C++ has major drawbacks when it comes to unit testing, mocking and refactoring. It's very cumbersome and inflexible. Reflection allows managed code to make such things very convenient.
Deployment is a small issue. However, creating a setup which checks for the necessary .NET preconditions and installs them automatically is a no-brainer.
Compilation is quicker, no linker! It even happens in the background when you edit the code.
.NET library support is way better and cleaner than STL, MFC and boost.
No header files and macros. They are just error prone.
Security! Good bye buffer overflows, bad pointers, uninitialized variables...
Exceptions. Clear exception hierarchy in .NET. C++ exceptions are messed up.
Memory footprint. But unless you're developing for a severely handicapped machine memory-wise, it really shouldn't be an issue for most applications.
If you can afford the dependency on the stack, go for .NET
Modern, elegant, powerful and as a result much quicker to develop for.
But realize that you chain your app to it - to the language and the framework, if you forsee a future where you may want to escape this, then better think twice.
Win32 is old and clunky, but it works on virtually any Windows version without extra dependencies, and your code can be in plain, portable, C/C++.
+1 for not having to require a .NET package/install on the target machine(s). This is still a big issue.
When all machines have mono or NET it won't be such a big deal.
Two things that I can think of.
Protection of intellectual property. It's infinitely harder for someone to reverse engineer an Unmanaged C++ app. Managed .Net or Java apps can be easily de-compiled this is not the case with Unmanaged C++.
Speed. C++ is closer to hardware and has a smaller memory footprint as the other comment mentioned. This is why most video games continue to be written in C++ and inline assembly.
.Net programs also have a support lifetime, where native do not really. Native will run for many years across different OS's without requiring updates.
.Net programs can be hosed by bad .Net configuration, native just keeps on running and is hardly effected by OS updates.
.Net programs startup slow and feel sluggish, native starts quick and runs quick.
.Net has to be coded for lowest common denominator (most distributed framework version), Native compiles all code into application - so use what you want.
Use Delphi for Native, not C++. .Net is partially based on Delphi RAD and Java backend.
So, following a tutorial I found on MSDN I've created what you might call an "engine" using DirectX and C#. I haven't seen a lot of this sort of thing (Personally, that is) done in C# and the majority seem to favour C/C++ so I'm curious as to whether using C# will come back to bite me, or whether I should just go ahead?
The reason I ask is that the tutorial stopped rather suddenly and so there's a basis of something but it's small enough to be ported without much hassle. I like C# myself, but I don't know whether there's something everyone else knows that I don't.
Well Peter, the main reason is C++ is platform agnostic, while C# isn't in the true sense, despite Mono (I don't think you can run Mono C# on most cellphones, the Nintendo DS or the Playstation3, for example).
Anyways most of these engines support DirectX and OpenGL, and/or software renderers, thus they are engineered from the ground up to be agnostic. But as with any agnostic system, this requires a lot of effort, and resources.
Now from what you say, your engine is C# + DirectX, meaning your engine right now may run on PC, Xbox, Zune, and some Window's powered cell-phones. This isn't a bad range of platforms to be honest. So if your happy with this degree of freedom, and you prefer C# over C++ than you might as well stick with what you have, and spend the time improving your engine. However if you want to run your engine on anything not Microsoft, you'll need to make the jump to C/C++ sometime.
For an idea of what I'm talking about my team's engine supports Xbox,PS3,Wii,PSP,PC, and possibly other platforms as-well if we spend the effort, however we have 15 full-time engineers working on it, so... you see it's a big cost. Now if you want something like this for a free project, and you know C++ you may try any of the many open source engines out there such as Ogre or Irrlicht.
I suggest staying with what you are familiar with. Use of C or C++ should only be considered in your situation if you intend to do some lower level functionality, like implement your own image processing or create custom filters or transforms (depending on what you are using directx for).
Graphic applications can have computationally intensive aspects. Most of these have been addressed in the DirectX api- which is just as fast if you use it from C++ or from C#.
Where you would consider lower level language: If you are creating some image processing which could perform quicker natively- this only applies if it is not offered by the directx api, such as creating some custom encoders/decoders. In this case you could create the custom component in another language- and then load it in your C# application separately. If you are- look into using C++ Intrinsics, which allow you to program for your CPU, and also take a look at GPGPU API's like CUDA.
As a hobbyist game developer I greatly prefer C# (with a 3rd-party library call SlimDX) over C++. Yes, a game written in well-optimized C++ will probably run better than the same game written in well-optimized C#. But the time I save by using C# (I'm guessing very roughly 30-40%) can be used to optimize my algorithms such that a C# game will actually run faster than had I written it in C++ in the same amount of time.
As pointed out above, there's also the cross-platform compatibility issues because for most practical purposes a C# game will only run on Microsoft platforms.
Another issue to consider is that if you write your application in C# then it will require the .Net Framework to be installed on the computers it runs on. This can make distributing your application cleanly somewhat more of a hassle, though this is by no means an insurmountable obstacle.
There are a few studios using c# for games.
You can also have a look at XNA, there is also a port of quake3 engine flying around the internet ported to c#.
So it should be ok.
If you feel more comfortable in C# and there are no performance issues forcing to switch to a language closer to the CPU, then I see no need to change.
However, depending on what you plan to do in the future and how far this engine should be taken, that might change dramatically and C# might turn out to be the wrong choice. But this only time can tell, unfortunately. The right educated guess requires much more detail about the current implementation and about your future plans.