i studied basics of c++ in college, we used the book object oriented programming in c++ by robert lafore.
i studied till pointers (almost half the book) and i still feel outdated using the console and not doing something other than that (forgive me for my ignorance) i want to do windows simple apps and knowing how to employ the little i learned.
the problem is when i open a win32 project in Visual studio for example it opens a lot of stuffs and many .cpp's and .h's .
is there a way to comprehend that and walking on the right path?
the code is complicated to me and mind teasing is it suppose to be like this ?intended to be like this for beginners ? is there a reliable tutorial to introduce me to that or do i need to learn the advanced concepts of c++ like templates and virtual functions and file i\o or they are not necessery ?
thank you.
There are simpler languages to learn programming in then C++, and less complicated concepts to be mastered in simple CLI applications. In fact, using C++ to write GUI software is probably one of the hardest things to learn to do well. If you are intent on learning only visual programming, and only in C++, then I suggest trying the programming toolkit QT (http://developer.qt.nokia.com/resources/getting_started/) as you will have a window on the screen faster and more logically then nearly anything else.
Otherwise, pick nearly any interpreted (VB, Python, Ruby) or quasi-compiled (Perl, Java, C#) language and work through a command line tutorial first, as your progress will be much more likely.
Create an empty project in Visual Studio, then it won't create a bunch of .cpp and .h files that you don't care about.
After that, to learn how to write a windows application from scratch, read Programming Windows by Charles Petzold, or google a windows programming tutorial on the web.
Later, get books by Jeff Richter (Windows via C/C++) to learn more advanced windows programming concepts.
win32/Visual Studio is not a good way to learn GUI programming --Visual Studio generates too many mysterious and unreadable pieces of code and the win32 API is a C API which carries a lot baggage from from the early versions of windows.
It would be much better to use a more organised and conceptualy cleaner framework like Qt or WxWidgets to learn GUI programming.
I would actually recommend you use wxPython to learn the basics of wX and switch to the c++ interface when you have a good understanding of the widgets etc.
Most of the c++ code you need for a GUI is just boiler plate property setting and exception handling which wont teach you much and is pretty tedious.
My tip on getting a hang of windows programming:
Read The Forgers tutorial.
Instead of choosing a project with stuff in it, just choose a blank project and start from scratch, it's actually not that hard once you get the hang of it. However, a basic Win32 program consists of approximately 70-100 lines, because:
You have to set up a unique window (this includes registering your window in Windows and creating it correctly)
You have to handle all the messages that are sent to your window
You have to react to the messages that are sent to your window
Especially check out the Simple Window that TheForger created, then start fideling with the flags (dwExStyle and dwStyle) in CreateWindowEx, check out the wndProc function and see what the messages are (I think the most interesting you should focus on is WM_CREATE, WM_PAINT and WM_SIZE). Hopefully, after some time you will get a feel for what everything is and how it interacts.
It takes some time but I guess most stuff in programming does if you want to learn it. When you have your basic knowledge of a window, you should probably see how you should move on, if you should start with 3D (DirectX or OpenGL) or stay with 2D (GDI+). Or take up Qt like suggested by James Anderson, it really depends on what you want to do. But I do think that you should take that decision then and not now. StackOverflow will most likely assist if you ask what direction you should take if you know what kind of a project you want to do.
You need to start somewhere. So yes, you need to learn all those things you mentioned and then some. The then some includes writing console apps until you really understand whats going on. The only reason I can speak is because I am in a similar boat. I would say, from the sound of it, that I am probably more "advanced" than you and I still find doing some assignments/projects in the console challenging.
The problem is: Windows and stuff is complicated, you have all these events (clicks, keys, mouse stuff etc) and you are interacting heavily with the operating system. It is good that you start with console apps, because there you can focus on the actual programming, i.e., learning how to use loops, functions, classes etc.
To learn how to make windows, you should absolutely understand what classes are and how to use them, because in my opinion, all window toolkits worth learning make use of classes.
So, how does this windows stuff work? The good news: A lot of work has already been done. No need for you to re-program a "print file"-dialogue, no need to hand-draw windows with their symbols and menus etc. This is all readily available in so-called frameworks, and there is a bunch of them out there. You can use the Microsoft Foundation Classes (MFC), or Nokia's Qt or wxWidgets etc.
Google for tutorials on these, and this should get you on the way. First look around which framework looks best to you and then do the Hello World examples.
Once you gain some experience, you'll see that it isn't THAT scary. The only scary thing is the unknown that is yet to be conquered.
(A more gentle introduction would be to first do Java/Swing as I find this VERY easy, but the C++ alternatives aren't too hard, really)
Just play around visual studio if you want to get familiar with Visual studio or any IDE. VS does lots of things on behalf of you. Its interactive, select one option, look into auto generated files .h or .cpp, compile it. If you get any error google it. I myself learned this way.
For learning C++ lafore is good book to start with. The most important way of learning any language is writing lots of code. Dont get tempted to look solution in book. The best way is:
a) Read the problem properly
b) Write your logic on paper first
c) Identify interfaces
d) Convert your logic into programme
e) Compile it
f) remove the errors
g) remove all the warnings
Related
I am producing a piece numerical software in C++ and want to add a GUI (mainly for Windows). I know how to produce GUIs using comfortable editors in modern languages like Java or .NET. Now my question is what is the easiest and most comfortable way to add a GUI frontend for my program. In the choice of the tools am completely free (open source and portability would be nice), but please also keep in mind how much boilerplate code and interfaces that have to be maintained are required if the GUI is implemented in another language (Like C#).
Please don't suggest switching the whole project from C++! And note that the program does not require not much interaction between the C++ code and the GUI.
The statements about ISO C++ in this answer's comments are poorly edited. None of the solutions presented here would impose on the computational code a requirement of changing to a different dialect of C++. The GUI code itself might be another story.
The answers about using Windows Forms with managed C++ are probably the most practical. A lot of the UI-related code would be in a dialect (extension) of C++ where the .NET-garbage-collected pointers would be living alongside the traditional ISO C++ pointers. I haven't used this method but from what I read it might be better than what I have used.
MFC might be more practical if you don't want to invest in .NET knowledge for this task. It uses standard C++ constructs to wrap the Windows API. The Windows API uses a particular calling convention which C++ doesn't normally use, and it takes an extension to C++ to work with that, but this is no different than having a C++ program that calls some functions that are extern "C". Visual Studio has a GUI layout tool that is really good at layout of dialogs and at interfacing the dialog widgets to variables that reflect the state of the widgets. I've used this. If you can boil your GUI down to a dialog box then this would be a great option, otherwise you'd be using one of MFC's layout-managed windows.
Obviously the above options do not handle other platforms you might have in mind.
There are also various toolkits that were born on other platforms and have been decently ported to Windows. GTK, QT, FLTK, and WxWindows come to mind. I haven't used any of the dialog-layout/application designer tools that work with those, and I haven't used QT at all. When I last reviewed QT it had a special preprocessing pass for the GUI code. Other than that these portable tool kits are pure ISO C++ as far as I know.
As a really-out-there option one could program to the X Window System protocol using "libx". As far as I know this would involve no non-ISO C++ code.
Qt is a decent choice. It's stable, has a wonderful C++ interface (as opposed to MFC) and has a convenient designer tool.
The overhead of learning it from scratch might however be more that what you're willing to invest. It does have a certain learning curve.
wxWidgets would a good choice for a cross platform GUI for C++
As much as I love C++, it's difficult to build a GUI with. I'd build a quick C# WinForms application which would let you use things like Visual Studio's visual designers (Drag and drop buttons and such), and call your C++ application using P/Invoke.
C++ will often produce smoother and nicer GUIs, but it takes a bit more work out of the box.
If it's going to be just a simple GUI consisting mostly of standard controls I would do it with MFC. It may be outdated and was never really good, but it's still useful to get a native Windows GUI up and running quickly.
I have to chuckle at all the ways to skin this cat. Life is good. My response is a product I manage. XVT can do it for you. The easiest way is let us do it for you or give you a template to get there. It's just a matter of if you have more money than time. Then I'd look at us. It would be the fastest and least amount of effort on your part.
MFC Dialog Based application could answer the needs.
Depending on what you need, there's a nice imgui made by Mikko floating around that you can simply plug-in and use fairly quickly. It's done in opengl though so it won't be your standard windows-gui but it's really small and really easy to work with. You can download r'lyeh's version from here: http://code.google.com/p/colony9/source/browse/include/goo/imgui.h.
That's the easiest and most comfortable way I know, it is dependent on SDL though.
I recently started C++. I am using PHP right now and decided to take a look at C++. Web programming had me working with a couple of languages, with a couple of people. I wanted to do programming where I only had to bother with one language and create small utility apps (mostly not web-based). I wanted a compiled, strongly-type language without memorizing a tome of classes. Basically I wanted to learn C++ for the following:
mobile programming (I don't ever want to go touching Java, and I don't have a Mac for Objective C or IPhone SDK)
small desktop apps like DTRs, POSs
creating small desktop-based games
creating small Air-like applications that can access the web for additional content
I heard that C++ is not beginner-friendly and is mostly used for huge projects with lots of calculations and fine details (like 3D games). Is it practical or even possible for me to use C++ for the above cases? (Sorry, I haven't delved on C++ that much yet, so aside from "huge, monolithic project", I don't know any other uses for it)
You can certainly use C++ in all the areas you mention, though whether it is best of breed for any of them is open to debate. C++ is very large and complex language, and requires a fair bit of effort to get up to speed on. If I were you, I would pick one of the areas you mention that you are most interested in, and then find out which language(s) are best suited for that area and learn that.
If you are set on learning C++ you will need to read at least one book on it - you cannot learn it from internet resources alone. See this question The Definitive C++ Book Guide and List for a book list.
On the droid you can use other languages aside from Java - check out their ASE (Active Scripting Environment). C++ / C should really only be used when you have no other choice - i.e. speed critical code, operating systems etc. It's very easy to make a mistake that's difficult to diagnose and there are lots of task where it'll take way longer than it should to write and odds are others have already done so and done it way better - reinventing the wheel is bad. If it interests you though by all means learn and eventually you may master it. It's an excellent skill to have.
It's also not a completely object oriented language however, it's a hybrid one that supports most object oriented features, but some such as inheritance and polymorphism are a bit awkward to deal with in C++ - for example you have to define methods as virtual in base classes in order to be allowed to redefine them in subclasses - sort of like predicting the future - will this method every be desired to be redefined by an inheritor? Really what happens in that case is you make the base class method virtual later on to enable it to be redefinable - that is if you happen to have access to the source code to do just that - if not then oh well. For an example of this confusing stuff in C++ and other gotchas: Pitfalls
Look at other languages such as Ruby or Python - in particular Stackless Python where a combination of it and C++ (used where necessary) was used to create EVE Online as well as the functional languages such Erlang and Haskell.
For 2, 3 and 4, I recommend C# over C++, for the reasons I wrote here.
About 1, you can do iPhone development with .NET but I've never tried it and I don't know how viable it is.
Edit
To answer your actual question: yes, it's totally practical to write small and large desktop apps in C++. Especially if you use quality tools like Visual Studio and Qt. It's just that I think it'd waste a lot of your time for no reason, unless you intend to go into professional game development eventually.
I went to C++ from PHP like you, but I was more interested in 3D games and such. Now I have moved on to C# and find it much more enjoyable than C++.
As for your specific areas of interest however, C++ is certainly an option but C# may be better.
Mobile programming with C++ is probably not a good idea. I know it's possible with NDKs and such but for a beginner it's probably not so good. For iPhone development, other than the official SDK, the next best option is the (commercial) MonoTouch framework from Novell. However, you may still need a mac to deploy (I don't know). In terms of Android, if you don't want to touch Java (don't blame you) I believe a C# framework (similar to MonoTouch) is in development and other languages may be available. Other platforms? No idea.
Small desktop apps is also very possible with C++. Assuming you're running Windows, you can use the Win32 API (pain) or the C++/CLI API (better). You could also use a different GUI framework like Qt, wxWidgets or GTK+ which are all also supported on other platforms. Again coming back to C#, GUI development using GTK# in MonoDevelop is so much fun. Having used WinForms in Visual C# Express back in my Windows days, I can say that I now enjoy the process whereas I didn't before.
Games are my main area of interest and the reason I originally picked up C++. Seeing as you've said small and desktop-based, using C++ for performance reasons is way overkill IMO. You could make a decent, fun, playable game in Python using pygame without the pain of using a language like C++. In C# (yes, I'm trying to sell it to you) you could create awesome games using the XNA framework from Microsoft or other frameworks like (my personal favorite) OpenTK.
Rich internet applications. C++ is probably not the right tool to use here. It's certainly possible but seeing as C++ has no standard networking library, you would have to figure some of this stuff out yourself. C# may not be the right tool either but it makes it a little easier. There are other options as well (like Python) but it's not something I know much about.
Despite what I've said about it, I still think C++ is a good language to learn. It teaches you about lower-level things you never think about in PHP land. If you want to learn it, the book that really helped me was "C++: A beginners guide" by Herbert Schildt and also "Programming" by Bjarne Stroustrup.
Yes, your use cases can all be done with C++, more or less (YMMV on mobile devices).
To some degree or another, a language like C# will be more rapid to develop in, however.
In my opinion, once you get away from the straight-up form design features and hack for a while in a language & application, language feature comparisons begin to diminish in meaningfulness.
I recommend C++ as a first "heavyweight" language; see here for my most recent discussion on it.
I'm getting a little tired of building web applications. Feels like same thing over and over again. Are there any other cool things you can do. I'm maybe getting to start coding in C++.
Any suggestions for tips in that area? Should I delve into Qt or MFC? Any suggestions?
My latest interest is in Robotics. You can get a microcontroller for about $30 (arduino.cc) - and miscellaneous motors off of E-bay. I also have some cheap rangefinders and a GPS receiver - each of them under $30...
I build web apps as well. I'm not really tired of it, but I spend all my spare time programming in C.
If you're just starting out in C++, I recommend starting with some simple console-based applications first. Get used to the syntax and some fundamentals like strong typing, pointers, and understanding the difference between pointers and references. (Depending on your experience as a developer, you may already know all or most of the theory behind these concepts.)
If you're comfortable with these things, building GUI applications is easier (although still far from trivial.) I'd recommend going with a toolkit like Qt rather than MFC, which is largely deprecated in favor of dot NET, if I'm not mistaken.
Edit: also, consider trying out a language like C# instead. C# is newer, a little more cohesive, and lets you use dot NET for building Windows GUI applications.
Write a game. An action game. Like, a shoot-them up for example.
You'll discover the other face of programming. Use whatever you want to make it. C++ is a good choice, but any language will be good. C++ will be harder to "master" than other languages but learning it will make you understand a lot about other languages. But that's your choice : the project domain is more important than the language (that is just the tool).
Just try to make a game, I think it will really be different and you'll discover a lot of interesting things. I recommand a shoot them up because it's visual, make you learn basic graphic rendering, basic collision management and is a good base for a potentially interesting game (if you add a feature that makes it stand appart) that will keep your motivations for learning.
Look into mobile application development like on Android or iphone. C/C++ will come in handy.
C++ is great and all, but writing GUIs in MFC is just stupidly painfully compared to any other reasonable framework out there, like .NET (VB, C#, C++/CLI, pick your language) or Cocoa/Obj-C on the Mac OS X / iPhone OS. Qt is probably better than MFC.
Buy "The C Programming Language" by Kernighan and Ritchie and work through it.
Ideally, you also have access to an OSX/Linux system and can work on that. (C and Unix go hand in hand).
If you're used to working in relatively high-level languages such as C# or PHP, going back to something like C++ where you need to do your own memory allocation and other low-level stuff will probably seem cumbersome. Personally, I was happier making the switch in the other direction, and having much more done for me.
But if you do want a challenge, C++ could be a good option. Or, go straight to embedded. Robotics is a very fun topic, try to fit interesting things (that really move!) inside the 2-KB RAM environment of a PIC microcontroller :-)
I would recommend trying to implement something useful in C/C++. Is these a utility in your operating system you don't like? That you think you could improve? Have you always wanted to do X easily and have a good idea? No matter how big it might seem, research it. Learning an OSes API will teach you a lot about C/C++. Add a user interface in the library of your choice to learn even more. Basically, push the envelope a bit - building a calculator is great or a little console app for learning a few things, but building a fully fledged app with a purpose will really teach you things.
Add intelligence to a simple game using a neural network. I've always wanted to add a neural net to Oware to see if it improves its wins.
If your into pain, you could correct flaws on Windows Vista and 7. :-(
I'd recommend moving to Python rather than C++ if you're coming from a web design background. Get good at object-oriented programming, encapsulation, and related things before you go to C++ and have to deal with pointers and cleaning up after yourself.
I'm looking to be able to build GUI applications quickly and painlessly as possible. I'm competent (though not expert, and have no formal training) in C++, but have never used a GUI building toolkit or framework or anything. I am not a professional programmer and am totally inexperienced and ignorant when it comes to building GUI apps. Have spent hours researching trying to figure out what to do; only getting more confused and discouraged though.
Qt and wxWidgets seem like the most popular options for cross-platform apps, though cross-platform isn't necessarily all that important to me; Windows-only is fine if that means the fastest learning curve.
Qt seems cool and the Qt Creator is sweet looking with lots of good demos, except it has its own classes for everything, and I'm not overly keen on learning a bunch of stuff that's only applicable to the Qt platform itself rather than more generally. I suppose I could avoid using the Qt classes except for the GUI stuff where I have to use them, but I have no idea how wise or unwise that would be.
I was thinking Visual Studio would have the smallest learning curve, but when I open a test GUI app, I see a bunch of foreign looking stuff like carats (^) all over the place - I found online that these mean "handles", which I have trouble even understanding the definition or purpose of ("sort of like pointers but not really" is basically how I've read people define them).
I know pretty much nothing about wxWidgets, or how it compares with Qt.
So every option has a big learning curve - and ideally I'd like to know which one minimizes the time you have to spend learning the toolkit/framework itself. Since I'm likely never going to be making money from the programs I create, the time I spend learning a specific toolkit would be pretty costly. I just want to be able to make a functional program using the C++ knowledge I have, but in GUI form. At the moment it seems if I want to make a GUI app, I'd have to spend way more time learning the GUI framework I'd use than writing the functional part of the app itself.
Any input from people wiser and more experienced than me would be appreciated :)
First and foremost, start simple. There's a lot to the subject. If you are finding it hard, don't try and take it in all at once.
Most of the good GUI packages have tutorials. The best advice I can give is that you try each of them, or at least a couple of them. They are the best short introduction you can have to the library you choose and if they are any good they narrow down what you need to absorb at first. That will give you some basis for comparison, because they are each trying to do very similar things (and you will see some of them before you are done), but they have different feels. You will likely find you have a preference for one and that's the one to get serious with. It will also give you a sense of what's hard about GUI programming as separate from the particulars of one package, which, if you have only used one, you won't have seen. Personally I find this sort of knowledge very helpful, because it makes me less intimidated by particulars.
Here's a list of tutorials in one place, though you have likely seen them already:
Qt's tutorial
WxWidgets' tutorial
Gtkmm book. Not quite a tutorial, though there are lots of examples.
.NET tutorials, either for WinForms or for WPF.
Second, it sounds to me that you need to get some in depth understanding of the concepts of GUI programming, not just a particular library. Here there is no substitute for a book. I don't know all of them by a long shot, but the best of the bunch will not just teach you the details of a toolkit, they will teach you general concepts and how to use them. Here are some lists to start with though (and once you have titles, Amazon and Stack Overflow will help to pick one):
List of Qt books
WxWidgets book (PDF version)
There are tons of WPF and WinForms books. I can't make a good recommendation here unfortunately.
Third, take advantage of the design tools (Qt Creator, VS's form building and so on). Don't start by trying to read through all the code they generate: get your own small programs running first. Otherwise it's too hard to know what matters for a basic program and what doesn't. The details get lost. Once you've got the basics down though, Do use them as references to learn how to do specific effects. If you can get something to work in the design tools, then you can look at particular code they generate to be able to try on your own hand-written programs. They are very useful for intermediate learning.
I'm not overly keen on learning a bunch of stuff that's only applicable to the Qt platform itself rather than more generally.
I second the comment of GRB here: Don't worry about this. You are going to need to learn a lot specific to the toolkit no matter which toolkit you use. But you will also learn a lot that's general to GUI programming with any of the decent toolkits, because they are going to have to cover a lot of the same ground. Layouts, events, interaction between widgets/controls, understanding timers -- these will come up in any GUI toolkit you use.
However do be aware that any serious GUI package is an investment of time. You will have a much easier time learning a second package if you decide to pick one up, but every large library has its personality and much of your time will be spent learning its quirks. That is, I think, a given in dealing with any complex subject.
I suppose I could avoid using the Qt classes except for the GUI stuff where I have to use them, but I have no idea how wise or unwise that would be.
You do not need most of the non-GUI classes of Qt to use Qt's GUI properly. There are a handful of exceptions (like QVariant) which you'll need just because the GUI classes use them. I found you can learn those on a case-by-case basis.
Which is the easiest to learn is really going to depend on how you personally learn.
Personally, I've found Qt to be the easiest to learn so far. The GUI classes are rather nice to use, but I've found the non-GUI classes to be excellent, making it easy to avoid a lot of common issues you'd normally get with a more basic API. The documentation is excellent, IMO, as are the books, the examples, etc. It's also being very actively developed, with a few new technologies coming in the near future (like DeclarativeUI).
I've found Visual Studio/Windows API/.Net to be a good bit more complicated to learn. The API documentation on MSDN is rather complicated and not really organized in a manner that I find intuitive.
I've tried learning WxWidgets a few times, but I've never liked the API documentation.
All this is just my personal experience, YMMV of course. I'd say just dabble in all of them and see which one takes you the furthest, it won't hurt to try multiple.
As a person who learned C++ through Qt, I can only say that they work very well together. C++ purists (like I have become) will find lots of things in Qt not to their liking (the moc preprocessor, e.g., and the continued absence of exceptions for error reporting), but looking back, Qt provided a very gentle introduction to C++ for me.
And if you're like me, you throw in a handful of boost libs in each Qt project, because we want to write "real" C++, not the softened thing Qt uses :)
I would suggest wxWidgets. To me, it's pretty intuitive and looks nice.
Code::Blocks was built with it, so check that out to see if you like the graphics.
There are also a slew of bindings for wxWidgets, such as wxPython, wxErlang, and others, so if you decide to switch off of C++, you can take wxWidgets with you.
I also use wxWidgets and use it all the time for Windows-only applications (the only downside is that wxWidgets is notorious for large .exe filesizes, which may or may not be a problem for you). I found it very simple to use from the start, especially when combined with a GUI designer (personally I use wxDev-C++).
I've never used Qt, so I can't speak to its simplicity, but I doubt the difficulty is on a vastly different scale than that of wxWidgets. However, what I can say is that no matter what API you use (wxWidgets, Qt, WinAPI, etc) your code will be "locked into" that particular platform, so don't worry if you feel that learning Qt will lock you into the Qt platform (because the same thing will happen with any of those APIs).
If you're working solely on Windows however, you may want to do a few simple programs with WinAPI first. That way you have a basic understanding of the lowest level of Windows GUI programming before you move onto Qt/wxWidgets. That said, if you're really into cross-platform programming, then don't worry about that and go straight into Qt/wxWidgets.
I can't intelligently comment on the learning curve aspect, but a quick survey of StackOverflow questions shows about twice as many Visual C++ questions as Qt questions. Probably means that there is a larger support group in place for Visual C++. Might make learning it a little easier if there are more folks to help out.
No matter what you pick, I am quite sure it won't be easy and painless.
Having said that, I know that in some schools they use FLTK because they consider it relativelly easy to learn. I have never tried it.
In my everyday work I use WTL which is as close to the system as it gets while still providing some level of abstraction over pure Win32. I am not sure if I would consider it easy to learn, though, especially given the lack of documentation.
I recommend codegear C++ builder (previously known as borland C++ builder) from codegear which comes with a 30 trial. The nicest thing about it is that the GUI provides you with components that you drop onto a form in a WYSIWYG fashion and make functional by adding code to handle the events it fires. It comes with a whole bunch of compontents out of the box and you can add 3rd party components to it too, like the awesome ExpressQuantumGrid from devexpress, or write your own. It's very powerfull if you know what you're doing but intuitive enough that a beginner can write a database CRUD application in about 20 lines of very simple code.
Since nobody has mentioned it yet, for the sake of completeness, have a plug for the Fox toolkit. This is the one I used last time I did any C++ UI work of my own volition. There are also binding for this to Ruby and Python (the latter being many years out of date, though).
In general, the choice of a toolkit for self-directed work comes down to personal preferences for
the layout manager style
the event handler registration style
How native the widget set looks/can be made to look
If cross-platforming is not necessary, try .net + msvs or delphi. easy, all-in-one, no pain.
Qt is the best option for you. It's the easiest to learn, the most elegant and powerful and it is completely free.
Visual C++: This is an IDE, but it comes with its own GUI library called MFC. MFC is an old library with many quirks and it is difficult to learn and use. Many C++ programmers use it on Windows because it comes from MS, it's fast and it's free if you buy Visual C++. Since VC++ is an IDE, you can also use wxWidgets and Qt with it, although in your particular case I would recommend Qt Creator instead.
You seem to have experimented with Managed C++. Don't use that, even MS recommends that you only use Managed C++ as glue between C++ and C#.
wxWidgets: This one was a strong contender up to the day when Qt became free for commercial projects. It was always in the shadow of Qt and it is known that the documentation is not very good and the API is not as easy to learn as Qt's. Cross-platform MFC would be a good way to describe it.
C++ Builder: Borland made too many mistakes with C++ Builder and ended up getting out of the dev tools business altogether. It was a good product and I originally learned Windows GUI programming in one of the first versions, but I won't use it any more. There are better options and it is too expensive.
I want to learn C++ GUI programming using Visual Studio 2008. I'm not sure where to start though. I learned C++ in high school, but not GUI. I've been doing C# for about 3 years now and thats how I "learned" GUI programming. Now I want to learn how to write GUI's without the use of the .NET framework, so where do I start?
Charles Petzold's "Programming Windows 5th Edition" is the Bible for Windows programming.
http://www.charlespetzold.com/pw5/
Since you say you've been doing C# GUI programming for about 3 years, I'll assume that means Windows Forms. One way to dip your toe in the water is to remember that WinForms is really just an object-oriented wrapper around user32. So load up Reflector and take a look at the way some of the controls are implemented. You'll see that these strange messages like WM_PAINT and WM_KEYDOWN are pumped to the WndProc of the various controls by Windows. In plain old Win32 or MFC programming, the same thing is still going on. Doing this will let you slowly peel back the layers of the onion; you'll get a better feel for how Windows Forms works, too. From there, I'd recommend picking up Programming Windows by Petzold; it's old, but the native APIs in Windows don't move around that much. Have fun!
MFC is almost outdated now. I would recommend to use WTL instead .
Well it is also not a good idea just to start programming for GUI in C++ when there are so many good frameworks available like QT cross platform framework.
Some heretical opinions...
I wouldn't recommend C++ for writing complex Windows GUIs - language/library combos like C# or Delphi are so much more productive. If you want to get into C++ programming I'd suggest using it to write a multi-threaded server of some sort - a simple Web server would do for starters.
And if you really want to understand the underlying Windows APIs, I think there is something to be said for writing a simple application (like, say, a simplified version of notebook) in C (not C++). You'll only want to do it once, but you will learn a lot in the process.
And before anyone starts madly down-voting, let me say that I am a C++ programmer of over 20 years standing, and really love the language.
Would it be OK with you to write GUIs in VC++ using Microsoft Foundation Classes or MFC? That is how I would and have written VC++ GUIs in the past.
There have been many books written on MFC over the years. I'm sure any one of them will do nicely. You may find in the literature the reference ATL which is a Microsoft iteration on STL. MFC and ATL kind of merged over the years so anything ATL is also applicable to an MFC app these days.
Good luck and have fun!
Ah I know how you feel, old interpreted languages programmer that want to know the magic behind compiled programing. Well I can't find the tutorial that I used to learn windows programing, but just know that there is good win32 tutorials around, so you don't waste your time buying a book just yet.
I found it: http://www.relisoft.com/win32/index.htm
Neatest tutorial around, trust me.
As of now (Windows 8), WinRT, a completely new API has been brought to the audience by Microsoft and I'm quite excited about it. Never done MFC programming, but saw some code samples and they look weirdly 90's C-style (modern C-style is often better!). So, without going to start directly with MFC, I think I will start with WinRT
:)