If you will be in an English speaking environment, then English would be a good choice, since being able to express yourself clearly in a discussion is very useful, regardless of what programming language your future job will require.Quote:
But I would like to know one language for everything. So, considering that I don't know what my feature job will require, do you think I should go for C++ or something newer, like C# or Java?
Honestly, what's stopping you from learning C++, C# and Java? And Common Lisp? And Haskell? And Prolog? Why must your choice be limited to exactly one of them? You can always start with one, then when you are reasonably proficient in your first choice, go on to your second choice. You will develop general programming skills along the way, and that will serve you better in the long run than any one language.
And yes, I mean it when I say that English is a good choice. Likewise, having some understanding of say, UML, design patterns, software development methodology, etc, will all come in handy at some point. Oh, and of course, algorithms and data structures, which you may already have some grounding in. Programming is not all about programming languages, after all.
I'm sorry I have to completely disagree on this one having used both at work and home. I have not use wxWidgets but the continual mentions of it is making me a bit curious. Personally my development time with C# and with MFC are about equal. In the end the most time is spent on getting the controls to do what you want. The actual placement of controls and addition of the controls into code takes about the exact amount of time in both.Quote:
Despite my obvious bias towards C++ and my obvious preference for wxWidgets, anyone will have an hard time convincing me some C++/Qt/wxWidgets/MFC combination can match the development speeds and the features of C# or VB.Net under Windows Forms.
MFC is extremely easy and gets a bad rep for the MDI horrors and document/view architecture. Usually this is the fault of the programmer because MFC forces you to use OOP concepts when using doc/view and quite honestly most programmers try to break that at every turn in an MFC app. I will not say that MFC is easier than C# because MFC, in my opinion, is a bit lacking in controls. This is more the fault of the Win32 API than MFC but it is true that .NET offers far more when it comes to complete controls. .NET concentrated on making their controls complete and workable while Win32 concentrated on ...well...I dunno what they concentrated on but it was not the controls.
C# is also extremely easy. There is one thing about C# that bugs me to death. The fact that everything is a message which means that calling certain functions for the control may lead to some very unexpected results. This means I had to make use of the user defined data quite often in a control to ensure my control acted as it should. MFC does not suffer from this problem.
C# now has some very nice generics (in later version of .NET) but the early container types were a bit ugly.
I'm a fan of both of these but they both have their downfalls. However a blanket statement saying that GUI in C++ with MFC is much harder than C# is simply not true. Most people who say that rarely use MFC and the less you use something the more you forget which inevitably makes it harder to use. MFC is not hard and is extremely easy to use for dialog-based apps which most GUI apps fall into. C# is not hard and is extremely easy to use for dialog-based apps. However, both get a little more involved if you want to create something robust like an SDI or MDI application.
As always development time is proportional to the programmer's experience in that language or API. If you have a programmer who is familiar with both MFC and C# choosing which one to use usually comes down to what the company has been using thus far in their tools. The only route I would never take is to use pure Win32 since it is just ugly.
If we are going to compare languages, as we so often do here, let's compare them on how well they do what they were designed to do. C++ was not designed to create GUIs so using that as a measuring stick of it's usefulness is unfair.
Moved to GD board.
I didn't mean to put MFC in there, really. Only reason I did was because I reasoned since .Net Framework is meant to replace MFC, new more improved features would be present. But on second thought, that alone still doesn't make it; I must remember at all times when discussing anything to do with MFC, my experience with it was entirely with a different programming language.
I will however stick to my arguments on the issue of 3rd party GUI libraries the likes of Qt and wxWidgets that despite being excellent alternatives to MFC, by no means their own tools can match MFC based RAD tools, and necessarily Windows Forms (or WPF, the one technology that could bring back my interest in post-Vista windows development). Libraries like Qt or wxWidgets are simply not RAD friendly... so far.
For example I run the gui designer, place all windows, dialogs and controls I need and save. Then I run the code editor and connect my backend functionality to signals/events and controls.
How exactly can this be improved by C# (in which I've no experience)?
Forms are a hideous way to design a GUI. Fair enough it may be a little faster if youre doing something simple, but you cant dynamically change the content and they generally tend to lock you out of the code. Blegh. Once you know the API laying out content is not going to be much harder than laying out a webpage, unless the API sucks.
These tools have several problems, mainly to do with the fact they run by basically applying generic code to your design choices.
I run a GUI layout and place my controls for either resizeable or fixed windows. Then I'm forced to alter the generated code. Because of several reasons:
- It doesn't conform to my code practices.
- Those variable names that are automatically generated are never acceptable names.
- Many times, after adding, deleting, and moving controls on the designer, you are left with code artifacts that need to be removed.
- Code is generic. Consequently is often not acceptable in the presence of performance requirements or in the interest of code maintenance. You need to trim and rearrange the code.
- Control indexing system is offered in several forms. wxWidgets, of the top of my head, offers 4 different ways to index your controls. However, the best option is usually a combination of 2 of them or your own personal and entirely customized system. As you know, this is an essential feature since you are going to address those controls often in your code. Either you adapt to what the GUI designer offers you, or you are forced to also here alter the code.
- Code is tied to the designer one way. This is essentially a code generator and parser with little to no heuristics coded in. If you alter the code, the designer can no longer understand it.
If you wish I can further that list, but it will probably become a boring read.
I don't know exactly what kind of applications you have been developing on Qt (I believe that's the one you use, right? I use wxWidgets. But have already studied Qt - which I must say also liked). But pheres, that is simply not true for anything other than simple applications. Heck! Even on most cases adding your application functionality to the generated code is enough to break the designer.Quote:
Originally Posted by pheres
I quickly learned, when I started learning GUI development with these libraries, that their GUI designers are excellent choices for quick window layout. This is after all, a boring and error prone task to be done in code only. But that's that. While I fully support these libraries for their unquestionable worth (free, powerful, portable), I cannot defend their RAD capabilities.
i think I see there our differences in usage experiences come from, so your extended elaborations was not useless :)
it seems you expect some form of round trip engineering capability from your gui design tools (work on gui->work on code->continue to work on gui).
Do you really need that? Can't you just completely seperate the gui from the logic, I think the wxw XRC system should be able to do what, doesn't it? Then you should be able to edit the gui continuousely. And I'm pretty shure most of the editors allow to edit the names of the controls.
Well, we are talking of GUI logic here. Not application logic. I work by separating application logic from presentation, certainly. What I cannot do however is separate presentation logic from err,... presentation.Quote:
Originally Posted by pheres
If the tool ties its functionality to the code and can't parse outside it's limited set of rules, that tool cannot help me past the initial stages of development.
But you don't need to define a copy constructor in C++ unless you do something different.
Smart pointers gets rid of the whole copy problem with classes.
In Java you wouldn't need to worry about memory at all due to the GC, but with smart pointers in C++, it's the same.
Hey, I'm getting old. I cherish time that would otherwise be spent in traffic, in line at the supermarket, or managing memory. :-)
Maybe I should use a C++ GC and stop complaining so much.