Related
Lately I've been contemplating whether I should start studying another framework since I only have a windows machine and I don't intend to make cross-platform software anytime soon. So to help me with that decision...
Is there any disadvantage to using a cross-platform framework when I don't intend to develop cross-platform? Intuitively I would say that a framework specialized for a certain platform would perform better in said platform than a cross-platform framework. But I am just assuming that.
Please enumerate frameworks and libraries that I can start studying for rapid application development on Windows using C++. One with lots of documentation is preferred. I would appreciate it if you included a link that can help me get started.
Is there any disadvantage to using a cross-platform framework when I don't intend to develop cross-platform?
It depends on the framework. Most frameworks limit themselves to functionality which is available across all platforms, which may limit you somewhat. You may also not be able to take advantage of the best features of a given platform or the best development environment on that platform.
Please enumerate frameworks and libraries that I can start studying for rapid application development on Windows using C++.
A good option here is Qt. It provides a very nice C++ based framework for Windows and other platforms. If you want Windows only, there are other options, including the Windows Runtime via C++ (for Windows 8 development), or the Microsoft Foundation Classes.
By using a cross-platform framework, you will miss out on platform-specific frills, like programmatic control over Windows 7 Jump Lists. Because of these things, it won't quite feel like a native application, but like a port of an application written for another OS. In many cases this doesn't matter.
A modern C++ framework built using templates isn't going to perform any worse simply because it's cross-platform. You'll simply miss out on features that don't exist on multiple platforms.
Generally the issue with cross platform frameworks are framework specific.
e.g. wxWidgets - They are fast, but not too many GUI classes available. Documentation is not excellent however updated properly.
GNome - It is widely used but requires a heavy runtime deployment, bit more heavy in terms of memory usage.
These both are UI Frameworks. both are GPL and hence you can use it.
Nokia Qt - It is an excellent cross platform framework and it is not just yet another UI but a complete framework for cross platform development. However, problem with Qt is metaobjectcompiler (mod). It is a kind of language extension.
I would recommend that you opt QT as your next framework. It is being actively developed, lightweight, recently being open sourced and is available under LGPL lic.
Just to second the other answers, Qt is a great framework (and is hopefully going to survive Nokia).
Cross platform frameworks have mainly two disadvantages: performance (often they add another layer that is not necessary in native platforms) and of course being cross-platform, i.e. often not supporting functinality that is specific to your target platform. With Qt, I never saw performance as a problem. Also Qt brings in so many libraries that actually extend what you can do natively in Windows, that also the second point is not really a disadvantage here.
The only problem with Qt is in fact the metaobjectcompiler (moc). In the beginning, you will stumble across some strange compiler errors, that come in the end from the moc. Just remember this and google for the errors, you will get used to this.
I've been looking at a lot of different options for creating a GUI windows application. Win32, Windows forms, MFC to name a few. I know my C++ well, I just need some advice on where I should start learning some GUI for windows. Thanks!
Qt has helpful tutorials. Easy to learn. Open source. Many resources on the web!
MFC is quite a dated technology now; The kinds of books/tutorials available for it are similarly aging. QT is becoming far more widely used and is likely a much better starting point from a learning perspective.
There are of course plenty of other alternatives beyond C++; C# and .NET are good choices if you are specifically interested in development on Windows. C++ programmers tend to find their feet in C# quite quickly, although any new language/environment does of course have an extra learning curve
I would look into Qt, OpenGL and SDL (Simple Directmedia Layer).
Qt provides an easy way to build GUIs, I would (loosely) compare it to Java's Swing.
OpenGL and SDL are more about plain graphics, both being used in various games and applications.
I use MFC commercially and I'd have to say for strictly GUI/Windows apps, you might want to look at C# (either Winforms and/or WPF). MFC is getting pretty dated. You can get a lot more done in the same amount of time with C#. Sure it might run a tiny bit slower, but for UI apps, I think programmer time is much more important metric than execution time.
If you want to use C++ for UI, maybe have a look at Qt. It is continually updated/enhanced and is not limited to a single platform like MFC is.
Good luck!
It is as helpful to develop a windows based applications! their are many open sources and Ides to develop windows applications.
One of them are Visual Studios, it is an IDE ie..(Integrated Development Environment) developed by Microsoft for both windows and web based applications development.As it has an advantage that an individual should be proficient in any programming language that he/she knows about.This IDE is integrated with the .net framework which have the capability to manage the code and compile with the help of Microsoft Intermediate Language (MSIL)and CLR common language at Run-time.The type checking is handled by Common type Specification for all Programming languages.JIT compiler is a compiler to execute to semi finished code and turns to code in to bytes.The main languages are handled by these IDE are C++,VC++,C#,Visual Basic,F#,J#..etc
Being a C#/Java programmer, I really need to know a fact: Has Windows Programming with Win32SDK/MFC/wxWidget become antiquated?
What is the status of popularity of these technologies in software industry now?
Being a C#/Java programmer, do I need to learn Win32SDK/MFC/wxWidget now?
I think that learning the Win32 SDK is useful because it helps you understand how Windows works internally. I found learning about hooks and subclassing very fascinating. So if it interests you then you should go for it. However, you probably don't need to know Win32. It's not yet antiquated today but it may be in the future.
I never had much interest in MFC because it requires the paid version of Visual Studio.
Yes, learn Win32, even if don't ever intend to write or maintain C/C++ apps.
No, don't bother learning MFC/wxWidget now. MFC does come with its source code, so you can study how some classes implement wrappers for Win32, but that is more interesting to C++ programmers. MFC is has decreased in popularity, though Visual Studio continues to support this older tech. Learn MFC/wxWidget only for an as-needed basis, if you need to maintain some older code.
With C#/Java, you can solve a lot of problems, but there are times when you will need to use Win32 directly to achieve some task. for a variety of reasons. Maybe some functionality is simply missing from .NET/Java, or has a bug that can be avoided by going directly to Win32. Maybe your particular problem to solve has unusual or strict requirements, and you would consider writing a portion of your app in native code using some Win32 calls as necessary. Lots of examples/situations really.
Another reason to learn Win32 is that both .NET/Java are higher level abstractions (which is in itself a good thing), but it really does help to understand the internals for these reasons:
You get an appreciation of how much work .NET/Java do for you. Of course, you can do the same things in C/C++, but it takes a lot more work. Consider these two compelling .NET technologies, WPF and WCF, which do a lot work for you.
You will better understand resource management. Specifically, both .NET/Java are garbage collected environments, but you must deterministically release OS resources (explicitly calling Dispose), for such things as network connections, window handles, kernel objects, and plenty more. You should never rely on the garbage collector to release these objects for you, since the GC is non-deterministic.
Debugging, knowing the internals seriously helps here.
Knowing Win32 can sometimes help explain the API design in .NET at least. Some parts of the .NET API are modeled on Win32 API, but some parts of the .NET API are extreme improvements over some truly heinous Win32 API designs (consider the API for using GDI for example).
Finally, knowing Win32 can help solve performance problems in your apps.
Win32 won't become antiquated, until the Microsoft's popular operating systems are based on something else. At one point, Microsoft was going to replace Win32/64 with .NET in Vista, but this didn't pan out. Even for whatever replaces Win32/64 is the future, you still need to understand the OS SDK. At the risk of sounding like a salesman, I will say that learning Win32 will in fact help you write more robust applications and will greatly aid your debugging skills, two important items to help you stay employed. I would never hire a windows programmer who doesn't have at least some experience with Win32.
I would suggest "Windows via C/C++" by Richter/Nasarre, as one example of a good book on Win32 (yes, it's obviously geared towards C/C++, but these authors do an excellent job explaining Win32).
Hope this helps.
I think Win32/64 SDK will never be antiquated, as drivers or other low level programs won't be written in .NET or Java because of the performance requirements. If you are going to develop in .NET, then MFC or wxWidget is useless for you.
I develop in .NET regularly, and sincerely, every program I've ever created in .NET called some Win32 API functions. So learning Win32/64 SDK isn't pointless, but is time-consuming.
I am an architect and I recommend that all new projects use newer technologies, like .NET or Java. The difference in productivity is tremendous, at least according to my own experience with C++ and .NET.
There are two exceptions:
- I work for a software company and we are bound by the requirements of our customer, usually including the programming environment. So, if a customer only has people knowing, say, MFC, we will make an MFC project. But this is becoming rarer and rarer. If we have the choice, we will go with .NET or Java.
- You have a team with expert people in these older technologies and they are quite productive with them.
There's plenty of work for people like you, so I'd advise not learning these for job purposes. We have some MFC apps, but that's partly because it's what we had and partly because we had more faith in C++ performance, and performance is very important for them.
I wouldn't call C++ or MFC antiquated, but there's relatively less new work in it. (I would very much like to never support another Win32 program, though.) The new C++ standard should be out in 200B, and people will continue to work on it, and Microsoft has been adding new classes to MFC, so obviously there's continued interest and continued work.
For professional development, I'd suggest you learn something different, but that would be something like Lisp or Haskell, rather than C++, and as far as I can tell there's no particular virtue in knowing MFC.
Realistically Microsoft forces business to use their latest and greatest technologies. There will always be work for someone who knows both technologies because someone has to port legacy code.
Many small devices (phones) or games require lighter solutions. If you intend to work in those areas you will definitely need those technologies.
You need to decide where you want to go. Once you have a map then you can lay in the right supplies for the journey.
I found Java horrendous to work with compared to Win32. Someone needs to cut about ninety percent of the inbuilt libraries.
I wouldn't call Win32 and such antiquated. As other people have said, it really depends on the app. As a game developer, I use Win32 less and DirectX a hell of a lot more. I could double or triple my Windows code, and it would still be an extremely small portion of the project.
However, if you're writing a primarily interface application with a relatively small and lightweight backend, .NET might well be a good choice for you.
As for Haskell, I just found that to be a truly terrible language in pretty much every respect. It seemed to me that it served some abstract mathematical definition of "functional", rather than a real definition of "programmable-in".
Win32 SDK is nowadays used in niche markets, where more modern technologies can't be used for some reasons (legacy Win32 systems, games, system drivers, Windows Embedded systems). If you aren't planning on pursuing a career on these markets, I wouldn't bother learning Win32 now. It is not that is useless and has no new things to teach you, but let's face it, there are so many new technologies coming out even at the time we speak. I have a dozen of technologies/languages in my waiting list to start learning and experimenting with. You can certainly find more interesting and more career favorable technologies to learn.
Performance critical apps (games) typically use C++ Win32 API.
C# and .NET are actually built on top of the Win32 API. To access some of the advanced features of Win32 that aren't exposed through C# and .NET you use Pinvoke to manually expose a C Win32 function to your C# app.
I have been writing C++ Console/CMD-line applications for about a year now and would like to get into windows GUI apps. For those of you who have taken this road before, what advice/tips can you give me. Ex: good readings, tutorials, approach tactics, etc...
I know this is a really broad question, but i really don't know how/where to start, thus not knowing how to ask this question properly.
I highly recommend the use of the Qt Libraries for several reasons:
The Framework is freely available for Windows, Linux, MacOS X, and a couple of mobile systems. Since version 4.5 the license is LGPL, which basically means that you can use Qt even in commercial applications.
The design of Qt is out-standing, e.g. they use modern design patterns and a very consistent interface design (I don't know many other libraries that use object-oriented ideas in such perfection). Using Qt is the same as using Boost: it will improve your own programming skills, because they use such beautiful concepts!
They are bloody fast, for instance in rendering (due to the different back-end for OpenGL, DirectX, etc.). Just have a look on this video and you see what can easily be done with Qt but is hard to achieve with native Windows, Mac, or Linux programming.
They have a really great documentation, with tons of tutorials and a very good reference. You can start learning Qt easily with the given docs! The documentation is also available online, so have a look and see by yourself.
As mentioned before, Qt is cross-platform; you have one source-base that works on all the important operating systems. Why will you limit yourself to Windows, when you can also have Mac and Linux "for free"?
Qt is so much more than "just" the user interface; they also offer network and database functionality, OpenGL bindings, a full-working web-browser control (based on WebKit), a multimedia playback library, and much much much more.
Honestly, I wasted a couple of years by developing software natively for Windows, while I could have been so much more productive.
For C++ you have two choices, Native or Managed.
For native development, my team (at Microsoft, in Windows) uses the Windows Template Library. It works very well for us.
You should learn the basics of Win32 and how Windowing works. The canonical tome is Programming Windows®
For Managed development you can use C++ with Windows Forms. However, windows forms has been supplanted by Windows Presentation Foundation (WPF).
Here is a good site that can get you up to speed.
This tutorial is useful
You can use Visual C++ 2008 Express Edition for your tools (they are free).
My best advice for Windows C++ GUI programming is don't do Windows C++ GUI programming.
I realize that is an extremely uninformative/smartass response if it's not qualified, so I'll note that you don't state that you need to do C++ Windows GUI programming, but that you "Would like to get into Windows GUI apps." If that is the case, and you don't have a very specific reason to use C++ (i.e. gigantic existing legacy codebase written in MFC or a bunch of C++ code that you want to build a front-end for but would be a pain to expose to .NET code), then it is going to be a lot easier and more productive to go the .NET route and start learning Windows Forms or better yet WPF using C# or another .NET language of your choice.
If you do need to go C++, then I would second the recommendations for 3rd party toolkits like Qt or wxWidgets, as the state of C/C++ GUI programming tools from Microsoft is now abysmal.
Most windowing libraries and technologies use similar idioms. Pick one and learn it.
The Windows Template Library is a very nice veneer for Microsoft Windows while sticking with C++.
For cross platform C++ windowing toolkits (they work on Microsoft Windows as well as other platforms) you can try QT or wxWidgets.
Well, for the Windows GUI, get used to referencing the MSDN a lot, assuming you want to deal with the API directly.
My favorite resource for learning the basics was theForger's tutorial, but there are hundreds of books and other sites out there.
I guess an important place to start is your toolkit. You tagged this visualc++, so I assume you are looking at that, however remember there are other toolkits like Qt.
I would suggest starting at Microsoft's tutorials.
+1 for Qt. I would put documentation at the top of my list of requirements for a GUI system. Qt has great docs and there's a huge community behind it. Also there are several books about it. Good docs are extremely important if you are working alone with no other team members to rely on. Alternatives are wxWidgets, MFC, WTL, FLTK and many more. They all have pros and cons. Eg FLTK is small and only provides GUI whereas Qt and wxWidgets also include networking, database access etc. Qt seems to have the most momentum at the moment after the Nokia buyout eg the release of Qt Creator which enables you to develop apps outside of Visual Studio.
It has been so long since I worked with C++ on Windows GUI, my word is always avoid C++ in Windows GUI unless you have a very good reason, I mean a good darn reason, if you need some performance C# is more than enough for 90% of the cases, and if you need more power write your performance critical thing in a C++ dll, and call it from a Windows Forms or WPF application.
It will save you hell of a lot time.
Still my opinion, if you have another I totally respect that
The first question is that do you want to develop Free, Open Source, for personal use or Commercial applications in C++?
If you want to develop for personal use! Then you can go with some good C++ Toolkit, Framework or API.
If you want to develop an GUI application that will be open source or free. Then you can go with C++ Toolkits, Frameworks or API's that have the GPL or any open source license that fits your needs.
Even you can develop Commercial applications with open source toolkits, frameworks or API's that have LGPL license.
The second question is that do you want to develop for the Windows, Mac, Unix or Linux? or these all, even for the mobile platform?
If you have a Windows user, as I am, and want to develop only for the Windows, I mean not for the cross platform, you can go with Win32 API, although, learning Win32 API is harder but it gives you the complete control over the machine. Believe me that no other tool would you provide the complete control over the machine. If you dislike Win32 API, for any reason, you can go with MFC, which is another technology from Microsoft, but is not free, old and has less attention now a days. If you decide to develop with .NET platform, you have C++/CLI, an extension to C++ language for developing .NET applications. .NET gives you the type safety, OOP and a built in garbage collector, provides you the all API's related to Windows and x86 or x64 machine in one package.
.NET has its own world! Microsoft has decided to port .NET to other operating systems too, Mono project is an example... You can develop nearly all kinds of applications using .NET.
If you want to develop C++ GUI applications for the cross platform, then Qt, WxWidgets and U++ are available for your help. You can write once and deploy anywhere with these libraries. Many open source IDE's and compliers are also available to develop C++ applications with ease. Note that if you do not want to develop for the cross platform, any cross platform library would be overhead and unavoidable increase in size of the executables.
Is your C++ knowledge is good enough to program software systems?
In fact, if your knowledge of C++ is not enough deep and you do not understand programming methods like OOP, Encupsolation, Classes, Interfaces, Types, Programming Patterns and so on, you can not use any toolkit with full potencial.
Do not forget that every Toolkit, Framework or API is implemented in some programming language. If you do understand the language very well, you can use the toolkit very well. I think, you would understand my point.
Put aside WPF or VC++ or Qt, You can also try out several libraries such as :
OpenFrameworks
Processing
...
there's an active project for developing Gui with Openframeworks here:
http://www.syedrezaali.com/blog/?p=2172
Are you familiar with Microsoft Visual Studio and .NET technologies? Since you want to develop for Windows platforms why don't you start by taking a look at Microsoft Visual C++ Express Edition.? Explore a little with the available tools from MS and search for some tutorials.
We are in 2020 but the question is still pertinent. I agree with Qt users, it's a great framework.
However, there is also C++Builder that offers you design GUI visually at design-time. C++Builder application can be built on both VCL (Windows only) and FireMonkey (cross-platorm) frameworks. Clang compiler can produce both 32 and 64-bits native executables. Community edition of C++Builder is free. Delphi integration is seamless: C++Builder project can include Delphi files directly and use any existing Delphi component packages and libraries.
I am working on a drawing-based product where I want to produce versions for iPhone, desktop OS/X, Windows Tablets, Silveright-based browser, Windows Mobile, and Windows in that order of priority.
For GUI portability, the classic answer is to keep the core in C++ and use Cocoa/Objective-C or WPF/C# thin layers.
However, Silverlight complicates the choices.
I wouldn't have any problem migrating my code into C++/CLI and maintaining a dual code base (with some macros to fake the C++/CLI contextual keywords and some judicial search and replace for ^ and %).
From what I've been able to find so far, it seems unlikely that C++/CLI will be supported in Silverlight. That leaves me with the options:
Once-off migration of a v1.0 C++ source base into C# and ongoing parallel maintenance
Live porting with a tool (recommendations please!) from C++ to C# or vice-versa, which is sufficiently smooth to be part of a build process.
Architectural separation of the Silverlight version so the C++ logic remains on a server. I'm a bit uncomfortable about the performance implications.
Can anyone suggest alternatives, provide good news on C++/CLI in Silverlight or recommend porting tools? I'm sufficiently comfortable in either language to make C++ or C# my main language for the backend provided a port is reliable.
Edit:
Looking at the range of products offered by Tangible Software Solutions, their notes on the converters make it clear that converting C# to C++ is easier than the other way. That is as I expected - it raises interesting thoughts as to constraining my C++ style to be least-common-OO-denominator.
Architectural separation of the Silverlight version so the C++ logic remains on a server. I'm a bit uncomfortable about the performance implications.
I'd do this. The performance is probably not as bad as you imagine.