As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Which one should I use in my C++11/CLI program?
Which is the pros and which is the cons of c++11 threading and .net threading?
My program is windows only and is built with .net.
Considering that managed languages usually prefer developer productivity over performance (when in conflict), I'd say that managed threading is likely to be more developer friendly. Also, Garbage Collection is a well-known productivity feature.
Do you have an extreme need for performance and/or control? If not, I recommend managed code and managed threading.
C++11 would be a standard based, platform independent way of going about threading. This is important if you need to work across platforms.
Threading with .Net will typically tie your application with the OS (Windows). This has some advantages such as garbage collection (which is amiss in standard C++). However, note that you will probably need to ship the .Net framework with your application. Issues across versions of the framework are not too uncommon.
If you are asking about managed vs. native, then use managed code C# as much as possible, it's a much nicer developer experience all around. Also, the .NET 4 supports excellent APIs to help with multithreading, see Task Parallel Library (TPL) and the concurrent collections support, for starters.
The general purpose advice is to use managed code as much as possible, then use interop to native only as needed, for problems that don't quite fit the managed solution.
If you are asking about using C# vs. C++/CLI, then use C#. Both are CLI (managed) languages, but C++/CLI is more difficult to work with and is best used for some managed/native boundary scenarios. Also, C++/CLI doesn't support Intellisense (at least for VS2010, maybe now supported in 2012?)
Consider tenure: .NET threading has been around for a long time and is known to work with C++/CLI. C++11 threading is new, and I could totally see problems arising between that and C++/CLI since the /CLI stuff isn't as mainstream and it's likely that few other people are using /CLI and C++11 threading together.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I am trying to make my first desktop app, but I am at my wit's end trying to understand C++/CLI. After several hours of trial and error, it seems to me that it is unrelated with C++( I may be wrong ). I am getting hard time making functions, classes, etc. work, and am unable to understand what is going on. So, I have decided to abandon it for the moment.
Please tell me whether I can make a GUI-enabled desktop app in "pure" C++, using just my Dev C++ compiler. Yes, it might be a better idea to use visual studio, but I want to return to it later. Right now, please tell me whether I can do it in "pure" C++, and if yes, how(i.e., any books, tutorials or some specific learning path).
And yes, the app is just for my learning purpose. So, the issues of cross-platform compatibility, etc. can be safely ignored.
Thanks in advance.
If you're stuck with Windows, some of the more popular choices are:
Microsoft MFC. Not for the faint of heart...
Qt. However, this is also not strictly ISO C++, as it requires a special pre-compilation step. But it comes with a very complete library, is cross platform and widely adopted. The documentation is excellent and the learning curve not very steep.
wxWidgets. Cross-platfrom, popular and standard C++ only. However, relies heavily on the pre-processor and code using it tends to become ugly... (that's my personal opinion...)
GTK+, which is pure C. There is a pretty decent C++ wrapper called gtkmm.
Qt is probably the best C++ GUI framework out there. It does include language extensions that are not 100% C++ but it comes pretty close. There are also tutorials to help you out.
Standard C++ does not come with a gui. There are certain libraries that you could use to create a gui in c++ such as:
Qt
WxWidgets
I hope this helps
Firstly, C++/CLI is not C++, its Microsoft's ".net that looks like C++" language. Ignore it, it was pretty much dead on arrival.
I'm not sure what you mean by "pure ISO C++", if you mean you want to create a GUI app using C++ without any special language features (eg C++/CLI) then you'll be looking at Qt nowadays. Its really rather good and is probably the best C++ GUI system there is today. You can also download the QtCreator IDE that will help you out. (its also all open source and your apps will run on mobile and Linux too!)
If you want something that is Windows-only then you could write old MFC apps (for the desktop) or if you want to be bleeding-edge then write WinRT apps. The native OS GUI features are available in both these systems.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
So it is my understand that using the MFCs, one can created a GUI for a windows application. But is it easier to use use the Qt package instead? Qt is what I'd use for writing an application that runs on linux but for windows I wonder if using the Windows MFCs would be less difficult and time consuming.
Since you say "Qt is what I'd use... on linux" it sounds like you're already familiar with Qt. In that case I'd definitely recommend Qt over MFC. (Hey, that way you can write your application for both platforms!)
If you're already comfortable using Qt, then stick with it - it's cross platform so it will work fine on Windows. Unless you have a specific reason to, there's no point restricting your application to a single platform (and learning a whole new framework) when you are already familiar with a cross platform one.
Additionally, MFC is a lot harder to work with than Qt. Although it was designed to be an Object Oriented layer on top of WinAPI, it wasn't done particularly well IMO and you still need to be comfortable with WinAPI if you want to be proficient with MFC. The out-of-box widgets are fairly dated and limited in their configurable options, and modifying them or designing new ones is not particularly easy. Being an out of date technology, it is also difficult to find resources and/or support online for when you get stuck.
If you do have your heart set on MFC, you may also want to take a look at wxWidgets - it has a similar "feel" to MFC but is more up to date and cross-platform. Personally I prefer Qt.
Qt can be quite heavyweight, both in terms of implementation (lots of DLL dependencies if you link dynamically) and in terms of building (it adds extra steps to your build process). If your application is more suited to something lightweight (but also more basic in it's functionality), take a look at FLTK.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm starting to move from Windows to Linux development. In the process, I need to "forget" all of the familiar Windows APIs (WaitForSingleObject, CreateTimer etc.) and learn a bunch of Linux specific APIs instead.
So, my question is... should I?
I mean, if cross platform libraries like Boost are commonly used in the Linux community, do I really need to learn ahead the Linux-specific APIs?
I'm well aware that it would be a good idea to be at least familiar with the APIs, but... what is most common in the professional industry? Do most Linux-focused software companies use cross platform libraries, or OS specific APIs?
It depends on how complicated things you are going to use/need. For example Linux has SEM_UNDO option for System V semaphore, which is not available, when boost is used. In general, boost portability does not come for free, you will be able to use only common subset of different O/S possibilities. If this is enough for you, go for boost and do not handle (sometimes) obscure low level API. This should not only make your programs more portable (to some extent), but also less error-prone.
As a pure C programmer, I rely on the long-time-successful POSIX standard. This is, for me, the best portable API I have ever used across UNIX-based systems. As #Shi points out in a comment, whether you're developing for embedded or desktop/server computers is important because Boost is quite heavy. I'm also an embedded systems developer and the POSIX standard is also quite portable even for uCLinux (a tiny tiny Linux port for embedded systems).
I think the strength of the POSIX standard resides on its low-level of implementation. It deals with fundamental computer concepts (device I/O, memory management, IPC,...) that unlikely change along the years. We are used to see changes in the way we interact with computers, not in the way computers actually work, and the POSIX standard is powerful due to its maturity on dealing with how computers work. Indeed, I'm in love with those magic functions as fork(), pipe(), read() and write() :-)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
I want to go into native c++ programming after University, but it seems like languages that compile with JIT (like .Net) are overtaking c++. What does the future hold for Native code?
C++ is the seventh programming language I have been professionally paid to program in, and I'm sure won't be the last. My advice is not to think of yourself as a specific language programmer. Even if JIT takes over the world, it has to get down to native machine code eventually, and someone has to write that software.
There are a lot of opportunities to work on natively compiled C++ code. It's especially popular (along with C) in non-PC environments such as embedded and real time environments, and in a lot of situations where there is some level of safety certification required.
Game programming, where performance is usually critical, is another area where C++ is very popular.
It is less popular than it was in traditional 'desktop' applications and web service applications although you can find native code projects in both these areas - especially the former - if you hunt around.
I'm not sure what you mean when you say that you will be "going into native C++ after college". Your career will not be defined by what languages you know, it will be defined by what you can do with those languages.
However, C++ is used widely in many applications. I work in systems and we use C++ for everything. .NET isn't an option in my world, but the guys doing the GIU's next door use it for everything. It comes down to what you want to do with your career. The language you use will come naturally, you are thinking about it backwards.
There will always be a place for C/C++
Any application that needs to be as
fast as possible will be written in
a native language like C/C++
Any application that runs on a device that has limited memory
will
run better in C/C++ since memory
management is more deterministic.
Operating systems will continue to be written in C. That
include
device drivers.
Up until recently one always had the luxury of speeding an application up by using better hardware. Will Moore's law being stretched to the limit, chances are the performance improvements will have to come from software. Chances are that languages that give better performance will come into their own in this regard.
If you go desktop C++ is still the way to go especially if you want to be cross platform.
Java GUI Libraries are way to slow and .NET is not portable (the GUI part).
But C++ is a language beast, the only language where i can understand managers to ask for 5 years experience.
In the server world the VM/JIT has so many advantages that only basic infrastructure is coded native. If this is the industry you want to join learn (infrastructure) or don't learn (applications) C++.
Its also pretty popular in embedded programming where you can't fire up a hundert MB virtual machine.
Since C/C++ is the only fast imperative native programming language left in mainstream you should learn at least the basics.
Yes, of course it is:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
http://langpop.com/
And some of the great features like rvalue-references, variadic templates, uniform initializations, lambdas, unrestricted unions, thread-local storage, extern templates and ... yet keeps C++ to be a good choice for 20 years of the future, until the C++ committee decides to publish another new standard for the other remaining years (like a do...while!) (:
Note that the computers needs native programs to run! Java, .NET, python and ... needs native environment to run on it! so, native programs are the base of softwares.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have a couple c++ utilities that I would like to port over to dot net. I was wondering if there are tools for porting a c++ application to c#?
I imagine that any automated tool would make a mess of any code, so perhaps, I should also be asking if this is a good idea or not?
Sure, it is a lively market. Going from C++ to C# gives you something that might compile cleanly. Making it actually work takes a line-by-line, "oh gawd I'll shoot myself tomorow" effort. YMMV.
Keyboard.
Mouse.
Monitor.
Coffee.
Regular expression search and replace.
This should have been a comment. But I do not have enough credentials to post a comment.
This is not exactly relevant to your question. I thought it will be useful for you.
C++ -> C#: What You Need to Know to Move from C++ to C#
The better question is why would you ever just port working code without gaining added value (ie new features)? The effort will almost cetainly be harder and take longer than you expect. Better, use the many interop capabilities of .Net to call your c++ code from C#. Focus on adding new features in C#, but don't waste your time porting working code.
My company, Semantic Designs has a tool that convert from C++ to C#. It handles the conversion core language constructs from C++ (data/class declarations, executable statements) to C#. The translation tool is based on the DMS Software Reengineering Toolkit.
It needs customization to handle translating exotic constructs (COM calls, your custom APIs, ...) to C#. Any tool you might find will need such customization; no off-the-shelf tool can practically address your complete set of specific circumstances.
How about the C++/CLI compiler, which produces .NET assemblies from C++ code. Eventually you'll want to rework the entry points to accept .NET types (e.g. System::String instead of the classic char *), but you'll get to .NET a lot quicker by not using C#. There are also automated conversions between C++/CLI and C#, but only after the C++ code is .NETified (the aforementioned conversion to System::String, generic<typename T> System::Collections::Generic::List, etc.)