|
Thanks a lot Rajesh, you rounded it up for me.
I really don't know much of all libraries used by C++ apps.
But I do know C++ (not too deep, but I can get around). OO concepts are natural to me as I've been using C# and data structures for several years now.
Thanks again, very helpful.
Regards,
Fábio
|
|
|
|
|
You're welcome.
A good understanding of OOP would let you learn C++ faster. Knowledge of data structures is a definite bonus! But like I said in the post below, do not get lost. It is very easy to get lost, because there is aplenty to learn. So, break up everything clearly and set intermediate goals that would lead to your final achievement - becoming a proficient Windows Programmer. The first step, like I said is C++ and STL and I've given link to you to the page where you can freely download an excellent book (actually two parts).
After reading this reply of your, I have a feeling that you must be able to learn C++ and STL faster. So, MFC would be next in the pipeline, sometime soon. Good luck.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
Thanks! You are right, I can get lost pretty easily. I started to look around when I bought the book Windows Via C/C++. After I started reading it I figured out that I might have jumped the gun.
My next books will be the Effective ATL and the MFC one. Then I will go back to Windows Via C/C++
In the mean time I will work with Qt, to get a feeling in case I want to develop a cross plataform app (Maybe mobile?).
I Also have to take a look at Boost (I'm already getting lost), but I will leave that to a later point.
Thank you
Regards,
Fábio
|
|
|
|
|
Fabio Franco wrote: Windows Via C/C++
That's a terrific book and is most decidetly not for a rookie! It's just the single most outstanding book if you really want to know the gory details of Windows operating system. Keep it at the bottom of your book pile and don't touch it until you've got a good working knowledge of the rest of the stuff.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
Yeah, I figured that! It will be there in the bottom.
However it was still usefull to me when I needed to call Windows APIs from my C# apps. Hooks and stuff, all great.
|
|
|
|
|
Don't be lost or confused with the whole of the stuff.
Think only about C++, along with which you would learn STL. For this, I'd recommend Thinking in C++[^], by Bruce Eckel. The book is neatly written and organised. The books (two parts) are legally available for downloading from the author's own site for free! You may learn boost later, as your goal is to start doing windows programming first.
After you have working knowledge of C++, you may proceed to learn MFC (I already recommended a book). MFC will sometime need you to have knowledge of Windows programming (which has a pretty steep learning curve). However, it won't do so much of harm if you start it right with MFC and learn Windows programming and the gory Win32 API programming aside.
Your first goal is C++ with STL, so get started with Bruce Eckel's book. After you feel confident with it, come back here and tell us your status and people here will guide you further.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
I started programming with MFC in the early 90s and used it professionally for years. More recently, I've been doing my own projects exclusively and found MFC far to bloated and rigid for my tastes. Plus, I want portability and to distance myself from Microsoft. For about the last year, I've been using wxWidgets and found the transition easy and there's a good support community with lots of extensions and examples available. It has the advantage of being totally open source and free.
As was pointed out by someone else ATL isn't really for applications but the extension to it, WTL which is open source, is. However, you're currently still tied to Microsoft because you need ATL and they only ship that with their full C++ compiler. After MFC and before wxWidgets, I played with WTL for a while but gave up. I found it a bit cryptic to use and there's a shortage of documentation and good examples. The one decent source of information on WTL is the Yahoo support group. I simply got tired of fighting with it to figure out how to do what should have been easy.
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
|
|
|
|
|
I understand what you're saying. And I rather not be tied to microsoft either. The problem is that in the market (at least here in Brazil) there is much more demand for MFC skilled proefessionals than the open source opportunities. As you're using wxWidgets, I plan to use Qt which is also Open source. But, I feel I need to learn MFC to have better chances to land on good jobs.
I later intend to rely only on Qt if the opportunity comes up. Hopefully it will and hopefully the skills I learn in MFC will help me to quickly learn Qt.
Thanks for sharing your experience.
Regards,
Fábio
|
|
|
|
|
I understand you problem. It's about the same here and when I was working, I had to keep up with every kneejerk that Bill had. However, it paid me a reasonable living abeit an annoying one. Now I'm retired and do my own projects and I find I have much less tolerance for Microsoft. Their APIs all seem to be half baked thesis ideas that some grad student cooked up and have serious drawbacks in the real world. The other thing that really pisses me off is Microsoft's blatant attempts to undermine any standards process they feel is in their way to further their monopoly. I just on the edge of going through the learning curve of moving to Linux and GCC.
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
|
|
|
|
|
Aye, I feel your pain. Microsoft's model pisses me off in every way. The one thing I like to work on is Visual Studio, but I'm screwed if I need portability or support.
Support is crap, despite how expensive you pay on their products you don't have the right to have support (you have to pay for support) even if it is a bug that is their responsability. It's like buying a car that the engine stops in the first week of use and have to pay to the manufacturer to take a look under the hood. I'd rather pay for support on free products than for very expensive products.
I couldn't stop writing if I would say all bad things about microsoft. Unfortunatelly most people depend on Microsoft based products, hopefully in time this will change.
|
|
|
|
|
Back when, the best source for support for MFC was a USENET group. I remember when a new release broke my code and Mike Blaszczak, the MFC lead at the time, told me it was a feature. In the next release though it went back to the original behavior. Mike was good about lording his position over the people there. If you called him on his behavior or pointed out his advice was incorrect, there was a group of toadies who'd come down on you because they were afraid he'd leave them. One day a long thread appeard with the subject "Mike Blaszczak is a Pr*ck"!
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
|
|
|
|
|
For creating UI, MFC is still the right choice.
MFC also has a feature pack which helps to create advanced UI applications.
There is also an unsupported library called WTL.
ATL is mostly used to create COM and COM based components.
The most important library for any C++ application is STL.
Be sure to learn that.
STL is definitely portable across platforms.
|
|
|
|
|
Thanks! Very interesting.
Just wish to understand the STL role. What role does it play? Is it for UI? Or it is a general purpose library?
I'll have to take a look around to decide what path to take. There are also other libraries recommended by Rajesh (OpenSource crossplataform) that I will have to take a look.
Thanks again for your feedback.
REgards,
Fábio
|
|
|
|
|
It is a general purpose library like Rajesh already explained.
After you have learnt STL, you need to look at the Boost[^] libraries.
The new C++ standard yet to come out, takes a lot of stuff from the Boost libraries.
|
|
|
|
|
If you want to port to other platforms, use qt from the start; do not start using proprietary non-portable libraries because it will make things harder later on if you want to make things portable.
Max.
This signature was proudly tested on animals.
|
|
|
|
|
I thought of that. I seriouly plan to look at Qt. If I want to do portable apps, that's the choice I've made.
Thanks!
Fábio
|
|
|
|
|
Many people move from MFC to C#.NET. Why do you want to move back?
|
|
|
|
|
Because he came to his senses?
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
|
|
|
|
|
You said "I've been using wxWidgets". This means you don't like MFC any more.
|
|
|
|
|
No, I gave up on MFC. It's become bloated with every "new" Microsoft technology that they've tried to shoehorn into it. Also, Microsoft has bungled the whole DLL thing and made a mess of it. .NET is Microsoft's shiny new baby and I expect them to put MFC on the back shelf as soon as they can reasonably pull the plug. They tried once but did it too soon and got a fierce backlash they weren't expecting. My current focus is robotics and I want what I do portable to Linux. Someday I may just tell Bill and his merry crew to buzz off.
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
|
|
|
|
|
For several reasons:
1 - Learning something new opens up the mind, it's harder and allows me to understand better the underworks of a system. Also, Unmanaged code interops better directly with OS and it's specially useful to control hardware.
2 - I intend to build performance critical applications that managed code can't handle.
3 - I want to open up new job opportunities. There's still plenty of market for C++ jobs and the candidates are beggining to grow hard to find. The jobs are getting better paid.
4 - I don't plan to really "MOVE" from C#, I plan to add it to my set of skills
5 - It's fun.
Regards,
Fábio
|
|
|
|
|
Hope some day Microsoft will make MFC just like QT.
|
|
|
|
|
I doubt it. Microsoft seems to insist on building technologies that will work with their own. Heck, even their own products are so tightly developed that won't work on their own systems (take Sharepoint 2005 and Windows Server 2008 for example, a lot of hassle).
Even if they support something that will work across platforms, they won't release the code and won't directly support it (case of mono/C#).
|
|
|
|
|
1) Choosing MFC is not a good way to learn the basics of the Win32 API. I would choose WTL or similar. Remember Winforms is also just a wrapper around the Win32 API.
2) There are very few places where managed code will fail. If dealing with a very performance critical code, then one will wrap this in a dll and call it from managed code.
3) Learning C++ is not a bad idea, it will allow you to see how many places .NET is holding your hand. But always choose the right tool for the job.
4) I would then focus on learning how to interop between managed and unmanged code. Instead of learning something as awful as MFC.
5) Can't argue with that
|
|
|
|
|
1) The purpose I have on MFC is not really learning the Win32 API, I have the Windows via C/C++ for that. The purpose of MFC is to learn something that's still in demand on the market and allows me to build performance critical desktop apps, including drawing in GDI. I have to take a look on WTL, don't know how productive that will be and if it has demands on the market (that's the reason I'm choosing MFC), anyways, I heard it's an easy transition from MFC too. And yes, Winforms wraps the Win32API so good that I had no idea on how it works through it, needed to learn stuff from other plaeces so I could do some OS level operations not available natively in .Net
2) This is on of the greatest advantages of managed code, I'm aware of that, garbage collector can do miracles, but even using unmanaged code from managed code will defeat the performance purpose. I know that the operation done inside the dll will be fast, but all the rest will not, beginning with app startup.
3) Aye, I figure Visual Studio is still the tool. As for the libraries and frameworks, I will have to work on that.
4) That I do already, I had to do several native code calls from my manged applications. This include Windows APIs and native code libraries (COM).
5) Hehehe, I guess you know what I mean then
|
|
|
|