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 want to have working experience in c++ application programming. I am in dilemma to choose game programming or standalone programming. please suggest me which framework/API is beneficial for me to learn.
Qt mobile / QT gui programming , any other APIs ,
what about learning MFC instead of QT,
are there any other gui framework than qt
On the first part of the question: I suggest you try some lightweight programming in both directions.
Now on the part of what framework to use. If you truly decide on game coding only you would probably need to go with specialized framework/engine for game development. Still, Qt will let you do some game development so you can try it for game and standalone programing before you make up your mind.
Regarding the frameworks you suggested. MFC is not popular as before and probably will not be much supported by microsoft in the future. Qt and wxWidgets are popular frameworks that will allow you to do cross platform apps. I recommend Qt because it makes coding much easier, wxWidgets becomes more useful if you are really interested in making native apps for the major platforms.
There are a variety, with different benefits and limitations. MFC is pretty much just Windows, whereas QT is cross platform, and (IMO) much more in demand in the current job market (which until recently I was searching very tenaciously!) Another popular option might be WPF, which is Windows specifc.
Short answer: do QT until 'the next big thing (tm)' comes along.
I can't give you opinions here. To gain experience, start programming in whichever framework fulfills your requirements.
Qt is good enough, and there is wxWidgets as an option. These two are cross platform unlike MFC.
As for choosing between game programming or GUI programming, you can do both, one after another.
Hope this helps!
MFC is windows and if you are mainly targetting windows, WPF is the new Micorsoft desktop GUI standard. Having said this, most games do everything in a 3D API-native (OpenGL/Direct3D) manner, and the main platform-specific parts is the windowing and user input.
There also comes a tradeoff between using an existing User Interface library compared to rolling your own. You will find it quite hard to deeply integrate Qt or WPF widgets into your game as first class citizens, and may need to jump through some hoops to do certain custom behaviours. Doing it manually from scratch comes with the benefit of really learning what is going on and being able to do exactly what you want to do; but the cost of this is you arent leveraging an existing complete library.
My personal advice is to take some time to learn either Qt or WPF (Qt if you care about multiplatform, a lot of projects use Qt, but WPF is pickup up momentum, especially due to Windows 8) just to get an idea of what a UI API looks like from the client side. Also learn the basics of a graphics API (OpenGL or Direct3D). Then you will be in a much better position to make your decision. Ultimately I would recommend creating a non-game UI program, and a seperate game program. This will give you a much better idea.
In the context of a game, you can leverage Qt/WPF/etc in the area of tools and editors. But generally realtime in-game UIs use a tightly integrated 3D accelerated UI library. One such library is Scaleform (commercial, flash-based), and another is CEGUI (LGPL/MIT).
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 10 years ago.
I know there is a lot of Qt vs MFC questions, but I'll try to be very specific.
We have a big (10 years of development) C++ MFC application for niche industry. It's supposed to stay Windows-only and English-only forever. But we need to add a bunch of new designer-drawn GUIs and GUI controls (dialogs, buttons, custom lists, ...).
We can hire 1 or 2 new GUI developers to build these new interfaces, so we can afford to choose different technology than MFC.
Qt seems most promising and suitable to run side-by-side with MFC (oh, no, we are not reduilding the app from scratch).
It seems that most cited Qt advantages are irrelevant: cross-platform development, easy internationalization, opensource, non-GUI libraries (we don't need networking and have most of other features already implemented).
But Qt is also famous for its good OO design and they've introduced QtQuick recently. I'd like to give it a chance, so the questions are
In a commercial Windows-only project, what are substantional advantages of moving to MFC+Qt from of pure MFC, which is worth the trouble of learning Qt, integrating it in our build/deploy process and maybe paying for a commercial license?
In particular, will it speed-up the development if we build new GUIs in Qt and incorporate them in the app via QWinWidget?
Probably not.
If the gui and business logic are nicely separated then it might make sense to move the gui gradually to Qt or implement new parts in Qt - but we both know the gui/logic will be a horrible mixed together mess
If you are doing a rewrite (which is what the Qt will end up as) then if it's a regular business type app then using C#/.net is probably easier.
If performance is critical and you have a lot of domain knowledge tied up in well defined well separated c++ libs then a Qt front end would be worthwhile
Not basically answer to a question, but might be helpful as weel. I think another way to do GUI with newer tools is to use ActiveX and COM. I believe you can easily use ActiveX components in your MFC applications. Also there are many ways to create such controls. I was using Delphi to do controls that were successfully used in .NET WinForms applications, but as far as I know such controls can be created in .NET environment with little effort.
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 11 years ago.
I was going through the Hilo tutorial series Developing C++ Applications for Windows 7; seemed pretty interesting.
What modern books that go into details of developing C++ based applications for Windows 7? It should show how to take advantage of Windows 7 features and based on "modern" C++ (templates, Unicode, etc.). Not looking for old school Petzold or MFC type books (sorry). Also should feature native code development (i.e. no Qt-/wx-type 3rd party libraries). The 3rd party libraries seems to be at least a generation behind and don't seem to leverage the latests features (ex. Ribbon, Animation etc.).
I'd recommend that you ensure you're familiar with the theory in winprog.org/tutorial, then Ivor Horton's book (below), and then finally check out the WTL library.
The examples on the ribbon code in the Hilo articles use the windows API, which relies on COM objects to create the ribbon. ATL constructs like the CComPtr manage the lifetime of the ribbon objects and interfaces.
Because of this, I'd recommend that you ensure that you understand the basics of writing COM client code - e.g. You should understand CoCreateInstance, QueryInterface and smart pointers. ATL Internals (search on Amazon) is the essential reference on COM, but it is heavy going.
WTL wraps the detail of creating the ribbon and accessing it, but WTL was made for COM programmers looking for a windowing API, so it's not an easy API to begin with if you don't have experience of COM programming with ATL.
WTL supports the latest windows features, like ribbons etc. Don't expect any books on the subject though, there aren't any. M$ open sourced WTL some years ago, so the code is available to read, so you can figure out how everything works by reading the code. It's quite advanced though, you may want to look at it after you've had a look at the alternatives first.
Google uses WTL for the UI for Chrome.
I suspect you should Start with Ivor Horton's beginning Visual C++ 2010, it'll be a good all round introduction.
If you're looking for a great programming book for windows though, you can't do better than windows via c/c++ by Jeff richter - by far the best windows coding book I've ever bought.
If you are interested in WTL, then look at Michael dunn's series wtl for mfc programmers on code project.
Finally, there is no one book that hand hold the would be c++ GUI developer through all this, and that's a big gap in the market. I've often wondered why no one has picked up on this, given the popularity of c++
I still think that Stroustrup's The C++ programming language is a required read (cover to cover) for every C++ programmer. Then, add the Essential C++/STL series by Scott Meyers for some additional tips and advice.
I don't know if it's still 'modern', but Modern C++ Design is a great resource on templates and generic algorithms.
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.
While I have played with parts of Qt in the past I am thinking of putting some real effort into learning it but also wondering what the potential monetary payback might be down the road. So I have some general questions about Qt's future.
What is Qt's place in the job market? Are there many, or do you sense a growing number of installations using it? What are its main competitors?
What kind of enterprise niches does Qt satisfy? Are more corporate applications trying to be cross-platform these days or do most of those efforts go the Java, etc., route?
Since being bought by Nokia I assume Qt has a viable future on mobile devices. Has this in fact been working out? Is Qt pretty much limited to Nokia offerings or does it have a place on Android devices, etc.?
Please feel free to comment on any aspect of Qt's future that I may have missed.
Don't have a real answer for you, but I recently saw this diagram for job trends with various C++ libraries.
They have been around since 1995, and recently some feared that Nokia would buy them to stifle the competition in favour of Symbian. Now that seems definitely out of the way by the way Qt will soon support Symbian and Maemo 5. Seeing the effort they spend in R&D and what their framework already provides on so many platforms, I wouldn't worry about their future.
As an open-source platform, I would venture Android devices are more of a competitor, rather than a possible platform, but it's just a wild guess ;-) There are some fierce debates out there on the subject.
Another real competitor would be .NET, both offer more than just IDE building tools and deal with workstations and the embedded world.
Clifford's advice about not sticking with only one framework is very wise IMHO. Another argument to start with Qt beside the advantage of covering more platforms is that it uses the C++ language, which is more demanding than C#. Starting with that will give you good programming habits, and it will be much easier to investigate something else later, be that a C# or a Java-based framework: you'll have a better idea of what lies behind the scenes of memory management (if that is not already the case, that is), and your code will be potentially more efficient.
I started using Qt in 2007. I liked it a lot, but the price meant that I couldn't use it as much as I would have wanted to.
The Nokia acquisition has been a good thing so far: (ex)Trolltech have completely opened up their development process. You have access to their VCS and bug tracker, you can contribute code, test development snapshots, open and track issues and so on. They value input from the community.
The framework is high quality and very popular in the open source world (KDE comes to mind). LGPL licensing has resulted in a bigger adoption with commercial software developers. This year's DevDays has seen a record attendance.
What is Qt's place in the job market?
I'm not based in the US so I don't know what the situation is over there. Most C++ jobs are MFC in my area. I know of a few places that use Qt.
Are there many, or do you sense a growing number of installations using it?
I've definitely seen more interest in newsgroups/forums/online communities.
What are its main competitors?
.NET on Windows, Cocoa on Mac and GTK+ on Linux. When it comes to C++ only wxWidgets, MFC or WTL could be considered as alternatives, although I would argue that Qt is in a different league from them.
Is Qt pretty much limited to Nokia offerings or does it have a place on Android devices, etc.?
Qt is also available on WinMo/CE and Linux devices. Symbian is not Nokia-only any more.
I don't think that we'll see an official Android or iPhone port. Right now they're working full steam on S60 and Maemo support.
Qt is one amongst a number for GUI frameworks and libraries, such as wxWidgets, Windows Forms, MFC, GTK+, VCL and many others. I suggest that the choice of framework is seldom a critical business decision, the choice is most often determined by such things as platform, functionality required, existing developer experience, and development tool support.
A general working knowledge of GUI frameworks is probably far more useful since it would make your skills more portable. Specialising in a single technology seldom pays in this business, flexibility and an ability to acquire new and relevant skills quickly is.
However Qt is the basis of the KDE environment, so for any Linux development targeting KDE, Qt would be a useful skill.
I know for a fact that this company's products are Qt based to provide cross-platform portability.
I've been doing contract work using the Qt framework for about two years now, for entertainment software. Here's what I have found:
It's a great toolset for developing
cross-platform applications. Easy,
fast, powerful, advanced. I never
feel constrained using it. Since it's developed in C++ you can easily embed any
number of C and C++ libraries out
there and quickly delve into the native system
APIs when you have to. If it has a niche I would say it's performance critical GUI applications, dealing with 2D/3D graphics...etc. I personally have not seen an enterprise-level company which uses Qt.
I live in the South-Eastern US
(Atlanta) - I rarely see any job
offers around here, mostly .NET or Java. The job offers I
see tend to be on the West Coast, or
overseas. However, I do see more
than I used to, probably due to Nokia's involvement.
I do feel it is growing in
popularity instead of shrinking. I
see things like QtCreator and the
like as good indications of this.
I'm doing embedded development and see Qt increasing market share with innovative ideas. Stopping QtExtended worried me for some time, but now I'm convinced QT in embedded is growing rapidly.
Not only in mobile/smart phones, but automotive as well.
Wanting your App cross-platform for Symbian AND Maemo AND WinCE AND Linux (AND all Desktop) platforms, I don't see a competing Toolkit.
Yet I have no seen a company hiring that skill, but everythin under LGPL and developments like Qt Mobility are quite new.
Qt is not available on Android, link: http://sourceforge.net/p/necessitas/home/necessitas/
And it will be made available to more platforms with project Lighthouse.
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 been wanting to give game programming ago for a long while and never got round to it, and i have finally decided to give it ago. I have decided to try and create a simple to 2D platform game. I have had a quick play with XNA and I do like it. What i am looking for tho is a comparison between XNA, directx, OpenGL. mainly the strengths and weakness between them. I have been a .net developer for the last 4 years and that's were my knowledge mainly is.
If you want to do Direct X, say hello to Win32 and COM as your new best buddies. You'll be spending lots of time early on learning ins and outs of the win32 API. DirectX with Win32 provides you all the features needed for sound, game input, and graphics display. You'll also be writing in C or C++, and you'll get to learn all about memory management and the C mindset - not something you should consider giving up lightly. Learning and using C as a language for a major project can be very illuminating, and make you thankful for modern programming language features and design elements. You aren't actually forced to use C or C++ for development here; there are various .NET wrappers and other language wrappers for Direct X, but if you've got .NET experience, you might as well use the framework made for .NET: XNA.
XNA is a much newer, .NET based set of tools. It provides many of the same features that straight use of Win32 and DirectX does (sound, input, etc) but natively on a managed platform. For most games (especially one when just starting out) you can get great framerates with an XNA game (even though a native app can give you more), and is very good for learning the ins and outs of game development -- you can't really go wrong. Most of the fundamental data structures you'll need (quad/oct trees, Model-view-controller architecture, handling of events, structure of your program) you will still need to learn and implement yourself, and doing it in .NET will most certainly be easier than in C and C++. As a nice side bonus, if you have an Xbox 360, XNA community games can, with some work, be released through Xbox Live marketplace. Basically, as a .NET developer, you would probably feel most comfortable here.
OpenGL is a cross-platoform library for drawing polygons. It has a different framework and API from Direct X, and does not provide any any OS interaction tools. There's packages that let you program in OGL in many different languages. However, as others have said, this will probably be just as much work as writing with Win32 and DirectX. For other features besides graphics (keyboard, mouse, joystick, audio) you could consider using a framework like SDL some of the missing DirectX features. There's a pretty decent community surrounding the library that can give you pointers and tips if you go this route.
More thoughts on this can be found in an almost identical article, here: Suggested Gaming Platform to Learn direct-x, C Open GL, or XNA.
XNA is going to be the easiest/quickest way to get a game up and running for the 360 or Windows platforms. It will allow you to continue developing in a way that you are already familiar (C#.NET) and it will provide you with a sizable framework that will take care of the commonly used stuff automatically. With this ease comes some limitations though, as you will be limited to only the aforementioned platforms and due to it being a large framework there will be a lot of overhead that will go largely unused causing performance hits, however with a simple 2D platformer, this probably isn't going to be an issue.
DirectX is going to limit you in platform as well, and is going to be a lot more complicated to learn and develop in. Also you will most likely be programming in C or C++ here. The advantages will be in performance, since you are handling everything you will be in control of everything and able to optimize everything for what you need. I would think that for a first game, you're going to be much better off starting with XNA and moving to DirectX after you've "outgrown" XNA. Especially with the goal of creating a simple 2D platformer.
OpenGL will allow your game to run on most platforms but will be as complicated (if not moreso) as DirectX (although I should mention there are graphic engines for OpenGL which are pretty simple to use like OGRE. You'll also be developing in C/C++ for OpenGL. Again I would think XNA would be the better choice until you feel you're ready for the next step.
If your experience has been mostly with .NET as you say, XNA would have the shortest barrier to entry although you won't get quite as good of performance as you can with other options. As you say that you're planning on making a 2D platformer, however (assuming that the implication here is "non-hardware intensive"), then XNA would be more than sufficient and probably the most suitable choice for your project.
DirectX doesn't mean you have to use native code, there's several managed wrappers out there. The performance loss is somewhere in the range of 1-3% of native DirectX, but considering you will save hours and hours of dev time and likely will never need that last 2% anyway, managed is the way to go.
See this example: SlimDX - a fully managed wrapper for DirectX in C#
One option is to write your engine in .NET but implement the renderer with C++/CLI. I'm doing this for one of my projects. XNA, OpenGL and DX are all too low-level for what I want. I don't want to write a renderer, I want to use an existing one. The Ogre3D wrapper, Mogre, appears to be a complete mess (not sure if it's the design of Mogre, Ogre3D or both), and most other wrappers are hopelessly out of date. Instead I'm implementing the renderer using C++/CLI and Irrlicht, which seems to be faster and more well designed than Ogre3D.
You may consider doing something like this.
I started out using DirectX but have now moved on to XNA, mainly because I want to be able to focus more on the actual gameplay and less on the technology behind the game. Sure, you'll still have to do some engine coding, but it helps out alot to have a framework that supplies ready made functions specifically made for game programming.
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.
Will learning C++ help me build native applications with good speed? Will it help me as a programmer, and what are the other benefits?
The reason why I want to learn C++ is because I'm disappointed with the UI performances of applications built on top of JVM and .NET. They feel slow, and start slow too. Of course, a really bad programmer can create a slower and sluggish application using C++ too, but I'm not considering that case.
One of my favorite Windows utility application is Launchy. And in the Readme.pdf file, the author of the program wrote this:
0.6 This is the first C++ release. As I became frustrated with C#’s large
.NET framework requirements and users
lack of desire to install it, I
decided to switch back to the faster
language.
I totally agree with the author of Launchy about the .NET framework requirement or even a JRE requirement for desktop applications. Let alone the specific version of them. And some of the best and my favorite desktop applications don't need .NET or Java to run. They just run after installing. Are they mostly built using C++? Is C++ the only option for good and fast GUI based applications?
And, I'm also very interested in hearing the other benefits of learning C++.
yep, C++ is absolutely great. Check Qt. It has a great Python binding too, so you can easily prototype in Python, and when/if you need extra performance, porting to C++ is a mostly 1:1 translation.
But in fact, writing C++ isn't so hard either when you have a great platform, the worst part is writing all the class declarations :-)
If you want to build Windows applications that will run without frameworks such as .NET or virtual machines/interpreters, then your only really viable choices are going to be Visual Basic or C/C++
I've written some small Windows apps before in C++ code, and there is definitely a benefit in terms of speed and ease of deployment, at the expense of difficulty going up for development. C++ can be very fast, natively compiles, has many modern language features, and wide support. The trade off is that it's likely that you'll need to write more code in certain situations, or seek out libraries like Boost that provide the functionality you're after.
As a programmer, working in C++ and especially in C is good experience for helping you understand something just a tad closer to the machine than say, .NET, Java or a scripting language like VBScript, Python, Perl etc. It won't necessarily make you a better programmer, but if you are open to learning new lessons from it you may find that it helps you gain a new perspective on software. After all, most of the frameworks and systems you depend on are written in pure C, so it will never hurt you to understand the foundations. C++ is a different animal from straight C, but if you develop in C++ for Windows you'll likely find yourself working in a mix of C and C++ to work with Windows APIs, so it will have a trickle-down effect.
I wrote C++ windows apps for 10 years and switched to c# about 2 years ago to work on the latest product. I am embarrassed by how pathetic the C# app is. It takes 20 seconds to start up, you have to wait a second or so for it to switch between screens. I've used some third party GUI control library, and that leaks memory like a sieve! My app runs at 150 meg, and its doing hardly anything.
I am looking to go back to C++.
You can use MFC, it will be far quicker than .Net. Or, if you really want to burn, check out WTL - aLthough, there's not much documentation for that. I suggest you go with either MFC or Qt because you'll find plenty of good information and tutorials for them.
I can see that C# can be quicker to develop with, and maybe in some future version it will be quicker and smaller.
You will hate my answer:
The biggest bottlenecks in GUI development usually are not because of the language. After all most of the time in most applications the UI is idling, waiting for some user input. I can hear your screams already, but I said in most of the apps.
Let's put it this way: I am pretty sure that one can design a good UI on top of the .Net CLR. Learning C++ is a good thing, but will not solve the inherent problems of developing a good UI.
As always. It depends.
As long as you stay away from microsofts large Frameworks, as MFC, .net etc your applications can be blazing fast, but hard to code. Your benefit: You will really learn how windows is working behind its nice(?)surface. Just look into the initialisation code for COM-Objects and you know what I mean. You will never see such things in VB or C#
You have to program each button, each window and each control by yourself, sending silly window messages, however your applications are small, very small. This is an forgotten art:
Write small, fast programs
Good luck!
If you're committed to learning the raw, gritty details of Win32, then C++ will get you there. If you're not, then you'll end up using a bunch of wrappers anyway. For something like a small utility or especially something like a shell extension (where trying to use .NET will cause you problems anyway), C++ will let you write effective code with the absolute minimum in external dependencies. For a larger app, YMMV - a lot of the UI sluggishness out there comes from poor design: naive algorithms, an unwillingness to spin off non-trivial operations onto separate thread(s), reliance on badly-written 3rd-party components instead of custom controls... Mistakes easily made in any language.
Here is my honest answer to this.
First, I think every programmer should learn C/C++ just for the fact that by learning C++ you learn about programming. It is a systems-level language. You have to consider the finer details of memory management and so forth. I am shocked at how many programmers do not understand the foundational aspects of a programming language or computer system. By learning C/C++, you force yourself to understand programming at a more intimate level. On top of that, if you learn how to program in C/C++, you can program in almost anything.
That isn't to say C/C++ is always the right tool for the job. It can be a total pain to debug and take longer to write more meaningful code. However, it is perfect for those situations where you need absolute control of how a program executes.
This goes to say, I don't prefer C/C++ for UI programming. You still have to use a windowing framework specific to the OS you run on (MFC,Win32,Motif,GTK,QT,etc.). These frameworks don't lend themselves to easy learning curves. For at least Windows development, .NET is really the future of UI development (even though surprisingly MFC got a major overhaul for Vista that does stuff .NET doesn't even do yet). If you write your UI in .NET, it is easier to maintain and for others to maintain.
I typically write my UI in .NET and backend in C++.
Yes and no. It's all about optimization...And since C++ allows you to work on a lower level C++ is one of the best languages to write fast applications.
However those low-level mechanics implemented in C++ could be very annoying if you're used to more abstract approaches to OOP.
Testing your software in C++ is usually a long process.
If you are looking for speed anyway, C++ would definitely be one of the best choices.
C++ will indeed potentially get you a leaner, meaner and faster application (if you do it right).
However, the .NET framework is built for comfort from a developer point of view; a vast improvement over Win32 API or MFC, which may seem like hard work in comparison, So consider how you will implement the aspects for which your application depends on .NET (there are other frameworks available that may be easier than MFC or Win32 API), and also consider the costs and license issues of using such frameworks; for example the free VC++ Express Edition for example does not include MFC support.
If you know where you application is sluggish, C++/CLI may be a solution; allowing you to mix managed and native code to accelerate the parts that need it. However if it is the GUI that is intrinsically slow rather than the application processing; this may not be a useful path.