What GUI toolkit you should chose does sometimes depend on what kind of result you want. The two big cross-platform ones are wxWidgets and Qt.
wxWidgets is just a thin wrapper around the platforms native controls, so it will always use the native GUI widgets of the platform, while Qt simluates them instead. This can cause subtle differences between your program and other programs on the platform. If that is a big deal to you, wxWidgets might be better. If it's not, you could use Qt.
Yes, it bloody is. Take it from someone who's worked professionally with it for over a decade.
I'm glad that you are talking from experience. Most people who shout "MFC sucks" have never used it extensively. I used to be one of those people myself.
I have worked with it professioanlly for six years. I have alwo worked with other toolkits. They all have quirks that make them suck in some way. Often these ways of suckage are the same as in MFC. Perhaps you could elaborate on what aspects of MFC it is that you think makes it suck so much more than other toolkits?
So if you're only targeting windows, why wouldn't you use the infinitely better winforms?
There could be lots of reasons. Perhaps you want write all of your program in one language? It's not like it's an order of magnitude more difficult to use MFC than to use winforms.
Yes, and if you have a legacy code base that uses MFC, that is exactly what you should do. If you're writing new code, use something else and leverage the huge library of code for that.
I am not completely against using MFC for new projects today. It does make certain types of UI a lot easier to create than any other toolkit. Also, unlike what was claimed in this thread, MFC is just as supported as any other library that comes with Visual Studio, and it is still being actively developed. There also exists excellent third-party components (BCGsoft, CodeJock) for it that have been refined for a very long time, and contain some stuff that really doesn't exist for other toolkits.
Of course, it would not be my first choice, but if the situation and type of application is such that using MFC could save a lot of time, I would at least seriously consider it. Shipping on time is a nice feature to have.
It's ancient, unsupported, non-idiomatic C++, and full of evil pitfalls and gotchas. It really needs to just go die in a corner somewhere.
It's not that terrible. If you only want to target Windows, it's perfectly fine. MFC is structurally pretty much like wxWidgets, but I never hear people complaining about that being evil.
In fact, you can save lots of time, as the OP is attempting to do, by using some of the ready-made stuff in MFC. It's pretty easy to set up a GUI that works exactly like some common MS programs (office, VS) and be done with it.
I see NSIS has been mentioned aready. I admit it has been long since I last tried NSIS, but I always found Inno Setup more straight forward to use. It's free, and definitely worth a look: http://www.jrsoftware.org/
That's not one of the warning's I'd consider useless. Pointing a non-const pointer at const memory is bad juju. Why not just use a const char * instead?
Please, no religion Half of the people will say one should rewrite everything to const char * the other half will say it's an insane idea and this topic will turn into a discussion about good coding practices.
I just want to know how to disable it
It's not really religion... It's just plain wrong. If you attempt to write to your char* that is actually a const char*, you might in fact crash your program.
Anyways... If you're sure what you are doing I will offer this little tip, although I haven't used Code::Blocks much.
There most certainly should be some kind of project option where you can specify custom command line arguments for the compiler. If you can't find any place in Code::Blocks to specify a custom command line, you could try adding it to your CXXFLAGS environment variable.
Your professor is correct. Using a debugger to make poorly designed and written software just barely maybe work is lazy and an ineffective use of resources.
Using a debugger to analyze a problem or to learn how existing code works is appropriate use of the tool. Using it in place of understanding a problem or instead of thinking through and designing a solution is not.
This is absolutely true. I remember when I was a young lad learning to program. I used the debugger a lot. Then one day I wanted to try and see how it is to do without all the fancy stuff, so I started a project using Emacs and GCC. Because GDB is pretty cumbersome to use in comparison to "some other" debuggers, I only used it when absolutely necessary.
Needless to say, I learned a lot from that project. Another way of thinking, you could say. A way of thinking that has helped me when coming back to the "fancy" tools. It's hard to explain exactly what I mean, but it has caused more defensive programming, and when something is wrong, a quick browse around the code is usually all it takes to figure it out.
For all people learning, I recommend doing some kind of learning project without too many "crutches" to try it out.
Remember that it can cause confusion that there are two different ways (that are completely unrelated) to sign assemblies. Using an snk file in the project options is called "strong name assemblies". This has nothing to do with the level of trust placed in the assembly, it's just a way of making sure the assembly "name" is unique. This is not what you want, if I understand your request properly.
If you want digital signatures with trust (and from your first post I gather that you do), you need to use a certificate obtained from someone like Verisign and use it with the tool linked in my previous post.