Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm a C# programmer for a few months, and lately I've been considering learning C++.
So my question is, is there anything C++ can do that C# can't do?
I know about the manual memory management in C++, but as long as I don't program operating systems or extremely heavy memory applications, I shouldn't worry about that too much (becuase I heard .NET handles automatic memory management very well).
But, can I program in C# everything that I can in C#? I also mean things like DLL injection, Registry Editing, Drivers and things like that.
Is C# considered as powerful as C++? If not, what can't C# do that C++ can?
C# and C++ are languages. It's somewhat elusive to define what a language "can" and "can't" do. One example of a thing that C++ can do and C# can't, is free the memory of an heap allocated object at will, without freeing other unused objects as well. But it's a thing that won't matter most of the time. (You can use Marshal.AllocHGlobal and Marshal.FreeHGlobal to allocate and deallocate memory like in C.)
The main reason why C++ can be used to write things like Windows drivers is because this is what Windows supports and facilitates. If one day Microsoft decided to support only C# and ditch C++, we'd be here saying that C# can do something that C++ can't (even if the languages magically remained as they are now, by then). Most likely it won't, and rightly so, because C++ is better fit for systems programming than C#. But hopefully you get the point.
Essentially, it's not a matter of the languages themselves, but their implementations, their tools and the world around them. For example, you can easily write an operating system in C#. Why? Because there's a proper tool for it. You can also write for embedded systems with non-real-time requirements. It has nothing to do with the language, again, it's because there's a tool for it.
That being said, do learn C++. Regardless of how it compares with other languages, it's absolutely useful.
C# is a slightly higher level language that C++. Its requirement of a managed runtime environment means that you wont be able to write an operating system, or even a device driver, in it. This sort of area is typically known as systems programming
However, there is a Microsoft research project currently underway into creating a systems program version of C#. It's headed up by Joe Duffy, the Windows threading guru, and if the rumors on the web are to be believed it will be called M#. Joe has posted some information about his progress on his blog.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I have a few .NET portable libraries written in C# which I need to port to Qt (C++). Since many of the classes don't really depend on .NET framework classes to a large extent, I thought it would be good strategy to use a tool to convert the C# code to Managed C++ first and then use that as the base for the porting it for use in Qt rather than rewriting the whole thing in C++
Are there any free tools to convert C# code or decompile a built assembly to Managed C++?
Since many of the classes don't really depend on .NET framework classes to a large extent, I thought it would be good strategy to use a tool to convert the C# code to Managed C++ first and then use that as the base for the porting it for use in Qt rather than rewriting the whole thing in C++
This is an error in reasoning. Managed C++ is not C++. Just because they're syntactically similar does not make the process of moving code across easier, on the contrary, you're making things unnecessarily harder for yourself.
The first thing that comes to mind is memory management. Your Managed C++ project will use GC object references (the ^ type) which cannot be easily converted to C++ memory-management semantics, nor is this something that can be done automatically unless you have your own Garbage Collection library you're prepared to weave into your existing program.
There is more to .NET than the framework classes, but consider the runtime environment. I've already touched on the GC, but what about Exceptions? Threading? The ABI? And so on.
You're better off rewriting it in pure idiomatic C++ rather than creating a mess that tries to straddle the CLR and pretend-C++.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm currently having some analysis paralysis in deciding which is better for me between C++ using the Qt framework, or C# using the .NET framework for developing a small to medium sided project I currently designing.
I have a little experience in both languages, slightly more in C++ however would probably still be considered a novice.
All the information I have read has been relativity outdated (being at least a couple of years old) and was wondering if there have been any updates that would swing the advantage one way or another, or if it really is just a matter of preference.
QT seems to support my particular requirements needs slightly better however the additional difficulty of working in C++ may offset taking me back to square 1.
My requirements are fairly simple, I will need rich text support, database connections, the ability to export to various file types and have a fairly dynamic GUI.
Anyone have any personally experiences or recommendations they wish to share?
I recommend to use Qt because:
It's cross-platform and covers wide range of operating systems (including mobile)
Writing in C++ gives you the opportunity to use libraries
like the STL, Boost, etc;
Using C++ gives you the benefit of running your app at high speed
It is opensource and has a fast speed in getting better
It has the a nice GUI designer and a very capable IDE (Qt Creator)
The API design is excellent and easy to use
It has a great documentation which is easy to read
It has the Qt translation system which enables you to have a multilingual app
The GUI layout system where the widgets resize themselves according to a layout makes everything much easier
The QML gives you the power to create fantastic GUI with great graphics and animations
It has great support for networking and connectivity(socket, SSL, www, IPC, ...)
It has QTestLib for testing the code
It has many language binding if you don't want to use C++
You can learn Qt easily if you know C++
All requirements you have given are completely feasible and easy to do in Qt
It doesn't require any VM for deployment but .NET needs that.
Your application will be cross platform
Creating custom UI is very much possible in Qt. You can create almost any kind of UI in Qt.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I guess what I'm asking is running my application under Mono going to be notably bad for performance? Note that the application is not meant to do or require anything other than access to a local relational database (probably MySQL).
Edit: The application is meant to do in-memory work with data queried from the database. The database itself should not be a bottleneck.
Also, the 'work' will be multi-threaded and (must be anticipated to be) as much "parallel" as "serial", if that makes sense...
Edit 2: Profiling hasn't yet been done as the product is only now coming out of a long planning phase to begin development, but the plan was made with anticipation of likely use making this mostly memory-intensive by design (so as to eventually allow the database itself to be made to do as much work as possible, ideally). However, cases of "serial" work (i.e. number crunching) must be expected to occur by design, but my goal is to eliminate these cases as much as possible.
Edit 3: By number crunching, I mean literally any math formula serialized into the database and called into use for representing some kind of abstract data. Most of my (eventual) work will be to minimize this, however.
Your question indicates that you assume that Mono is some kind of .NET emulation, like wine is a Win32 emulation. This is not the case.
Mono is a native implementation of the .NET framework, so there is no reason why it should be fundamentally and/or generally slower than the implementation of the .NET framework on Windows.
It is a bad idea. I ported my application to mono and it doesn't work well:
1. Mono is not stable when it comes to threads (try to load many threads and see how it goes down)
2. Mono does not behave as expected with Forms
3. You are building CPU intensive app and Mono is very slow (as well as .NET) so use cpp, Python or something else.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
So we have this Image processing course at the university and we'll be using OpenCV extensively. Problem is, OpenCV uses C++ but I'm much more fluent in C# than C++. I know that there are wrappers for OpenCV (OpenCVDotNet, SharperCV, EmguCV,...) But I don't know which to choose.
My questions are :
Which one wraps most/all of OpenCV functionality ?
Are they even worth using ? (May not be updated often, lack functionality or speed,...)
Or should I be better off brushing my C++ skills?
Note : I know that my question is a possible duplicate of this one but it's old (from 2008) and things may have changed.
I have not used EmguCV, but I have used OpenCV for a while now.
From SharperCV's website:
The Emgu CV.Net wrapper is our current recommendation if you want to use OpenCV.
And, OpenCVDotNet looks more like an academic sandbox, so if it were me, I would use EmguCV for any of my research projects that involved C#. Mainly because it is being actively maintained, and it has the most features of the available wrappers today.
I had tried EmguCV. The range of functionalities it supports is fine. But if your project is something in which the speed is an issue, then it would be better to brush up your C++ skills.
I do not know much about other wrappers. I was in your same position once. I worked in emgucv during my academics and had to shift to c++ in my profession.
Believe me, you wont find it too difficult to move onto C++.
As an update, I can corroborate the answers previously given.
I have used both OpenCV with C++ and the EMGU Wrapper for both research and work and I agree partially with most people.
EMGU CV can be easy to learn and your code will be much easier to understand, it will require less lines of code and there is a decent range of functions you can call. But it is not complete.
Many functions will not provide all the originally intended functionality that you will find with OpenCV 3.0 e.g. FindNonZero() does not work exactly the same as the function that is wrapping and SetValue() gave me a hard time throwing runtime errors difficult to debug.
On the other hand, OpenCV provides great support compared to any other Wrapper you might find online and you will be working with the most up-to-date libraries. OpenCV 3.1 is a great release and I found no problems running it on Xcode or Visual Studio.
Therefore, I would recommend anyone wanting to immerse themselves into Computer Vision and Image Processing to go straight for OpenCV C++. If you just want to work on less complex problems you can opt for EMGU (I cannot recommend others as I am not familiar).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I got my hands on some well documented C++ code that's about 1KLOC. It would take me a significant amount of time to port this line by line and debug the results, so I'm wondering if there are tools or ways to do it faster, and I have questions in case I have to do it fully manually.
Specific questions:
Does C# also support overriding operators like * and +?
What to do with the C++ memory management code like alloc() and free()?
How to identify functions used from <stdio.h>, <conio.h> and <math.h>?
How to find replacements to such system functions?
Does C# have any special/open source libraries that provide such functions?
No graphics libraries have been used, its purely command line based.
You might want to try this tool and see if that works out for you. There is a demo where you translate up to a 100 lines of code at a time:
http://tangiblesoftwaresolutions.com/Product_Details/CPlusPlus_to_CSharp_Converter_Details.html
Try it out and let us know. But it would prolly be more beneficial to port this yourself in c# so you can get a handle of the features that c# comes with.
You will need to do it manually, and 1KLOC isn't much.
However, you will need to learn C#.
To answer your questions:
Yes
Depending on what you're doing, probably List<T>
I don't know what you're asking
Look in the .Net Framework class library on MSDN
Yes
1 - C# also support operator overloading see : http://msdn.microsoft.com/en-us/library/aa288467(VS.71).aspx (it looks very much to c++ operator overriding)
2 - C# is garbage collected so you only need "new" instead of alloc. free is done by the garbage collector
3 - I have no idea , but when porting code you would have to find in standard c# library the equivalents
4 - In MSDN there is a lot of information.
5 - ( http://code2code.net/ ) ??? but better to do it at hand
More information on coding standards : http://msdn.microsoft.com/en-us/library/xzf533w0.aspx
ie naming: http://msdn.microsoft.com/en-us/library/x2dbyw72.aspx