Transition from C++ to Visual C++

[badgerer]

Hello,

I started learning C++ a couple of weeks ago, bought Bjarne Stroustrum's book and have been working through it. The book itself doesn't seem to deal with GUIs a great deal or what I would consider the "front end" of programming. So with that in mind, I was wondering how long it might be before I can envisage myself building programs that would actually be used for practical purposes? I have a couple of projects in mind and am mindful of the fact that it will take some time before I am ready to start them, but it would be good to know what kind of path I'm on, as I am very unfamiliar with the whole programming learning process.

Thanks!

[Paul McKenzie]

Hello,

I started learning C++ a couple of weeks ago, bought Bjarne Stroustrum's book and have been working through it. The book itself doesn't seem to deal with GUIs a great deal

That is because the goal of that book is to present the C++ language to you. The rules, syntax, etc. You can't program anything without knowing these things. Also, I would have another book for learning C++, as Stroustrup's book is more of a reference.

Secondly, GUI's are not part of the C++ language. Windows is not the only GUI -- you have X-Windows for UNIX, and other GUI frameworks. The C++ language doesn't deal with any of these things.

C++ is a general purpose computer language developed by Bjarne Stroustrup that is used to build all types of applications. Visual C++ is a compiler made by Microsoft that compiles C++ source code. There are many other C++ compilers other than Visual C++ such as gcc, Intel, etc.

So Visual C++ is not a different C++. It is just a brand of C++ compiler created by Microsoft.

So with that in mind, I was wondering how long it might be before I can envisage myself building programs that would actually be used for practical purposes?

That implies that command-line programs have no practical purpose. Some of the most complex programs are command-line programs and utilities. As a matter of fact, many, if not most of the programs you run are command-line programs, but you don't know it because the author put a GUI wrapper around them.

I have a couple of projects in mind and am mindful of the fact that it will take some time before I am ready to start them, but it would be good to know what kind of path I'm on, as I am very unfamiliar with the whole programming learning process.

There are two learning curves, the first being learning the C++ language. C++ is a complex language -- it takes at least a few months to be competent enough to create anything substantial, stable, and easy to maintain, regardless of the type of application you're creating, and that is only minimum to intermediate competency. It takes years to be a fully-fledged, no-nonsense, "I know what to do without asking all sorts of questions" C++ programmer.

The second learning curve is writing GUI programs. That has nothing to do with learning C++. There are programmers who have never programmed a GUI app in their lives, but are excellent, if not ace C++ programmers.

Writing a GUI program requires you to use some sort of library, study the API that the OS provides, etc. to display windows, menus, buttons, etc. and other GUI related items. To do this, you must know the language you're using to write the GUI program.

Too many newcomers make the mistake of trying to write a complex GUI program, and they know very little about the language (in this case C++) that they're using. What ends up happening are poorly written, unstable programs.

So those simple looking command-line programs serve a purpose -- they are there to teach you the basics of the language. If it's a set of good books, then you learn how to organize a program, create functions, class design, usage of the language library etc. None of these things requires GUI.

Regards,

Paul McKenzie

[ttrz]

I'm sure that many would argue that a GUI front-end does not have anything to do with the practical uses of a program. In any case, I think it depends on how low-level you want to go. If you are looking for low-level Windows programming, you should work directly with Win32. In this case, I'd recommend this book.

[ahoodin]

Visual Studio is the IDE. It is pretty much ANSII compliant these days so you can use it to write Good C++.

Well Win32 is not really C++. Its a whole lotta C!

MFC is C++ but it is not really good C++.

[ttrz]

I'd also recommend reading and understanding Paul's response before deciding what you want to do. As usual, he is right on target.

And hey, I have nothing against old time C programmers.

[badgerer]

Hello all. Paul - thank you for your advice and forgive me for my ignorance. I am more than happy to gain a grasp of the core elements before progressing to GUI applications. It is not my intention to try to run before I can walk. Do you have any recommendations for another book?

Some of the most complex programs are command-line programs and utilities. As a matter of fact, many, if not most of the programs you run are command-line programs, but you don't know it because the author put a GUI wrapper around them.

I don't conceptually understand what you are saying here - could you expand?

It sounds like you are saying that I should not even consider working with GUI compilers until I have an acceptable grasp of the core elements of C++, but when will I know that is the case?

[Lindley]

I don't conceptually understand what you are saying here - could you expand?

A GUI program has a particular type of program flow. First, objects corresponding to all the different GUI elements---windows, buttons, fields, etc---are created and organized. Each of these elements is called a widget. Then, you enter the "main loop".

Once you're in the main loop, you have handed off primary control to the GUI framework you're using. At that point, your own code only executes via callbacks that you have attached to widget events such as button clicks. However, these callbacks must execute fast----if you stop to do extensive processing in a callback, then the GUI will become unresponsive. The GUI framework needs to call periodic repaints and the like and it can't do that while you have the processor.

For this reason, GUIs are usually organized so that the "real work" is done in background "worker" threads, and the callbacks simply assign them some work to do. Therefore, you should *at the least* have a good understanding of multithreading and the thread pool pattern.

However, if you're going to segregate the "real work" from the GUI-specific code anyway, then you may as well put the "real work" into an entirely separate command-line program which is invoked by the GUI. This is sometimes done; more often, a GUI is created to wrap an existing command-line program in an easier interface.

[Paul McKenzie]

I don't conceptually understand what you are saying here - could you expand?

Many of the programs that have a GUI interface are really just shells around a command-line program. Note that many programs you use have a command-line interface and accept command-line arguments (read the documentation of these programs, and many of them have a section on how to use them without GUI).

A major example is the program you're using right now -- Visual C++. You can build programs without the IDE. Why? Let's say you have an automated build process, where at 2AM on Monday, a build of several apps must be done. Are you going to sit there and click buttons on an IDE at 2AM every Monday? The programs cl.exe, link.exe, rc.exe, and several others are the core of the build process for Visual C++, not the fancy GUI IDE.

Another example is batch processing. What if you need to run the program 300 times without stopping? Are you going to sit at the computer and click "OK" 300 times? Of course not. So you write a command-line program that accepts arguments, and just create a batch process.

When you open up task manager, and you see all those programs, how many of them are GUI? Many are services running in the background (which are not GUI), some are the command-line guts of certain programs (which are not GUI), and the rest are for the most part, the GUI apps/shells. So just opening task manager and seeing all of these running processes, where most of them are not GUI programs, should convince you that command-line/non-GUI programs are the core to your entire Windows desktop.

Another mistake that programmers writing GUI apps make is that do not do what Lindley stated, and that is make the non-GUI part of their app separate from the GUI part of the app. A sign that this mistake has been done are apps that cannot function correctly (or at all) without that button press or some other GUI action being involved. What is done is that the programmer coded the business logic into the GUI, which is a bad design. What eventually happens is that the programmer now wants to create a command-line version of their app, and instead of a smooth transition in creating a command-line version of their app, the programmer is ripping their GUI app to pieces trying to consolidate all the business logic together to create a command-line version of their application.

So if possible, if your app has some utility, always create it as a command-line version, and then wrap it up later in a GUI. The GUI just calls the command-line version of the program with the correct arguments (that is exactly what Visual Studio's IDE does when building a program).

Regards,

Paul McKenzie

[Arjay]

So if possible, if your app has some utility, always create it as a command-line version, and then wrap it up later in a GUI. The GUI just calls the command-line version of the program with the correct arguments (that is exactly what Visual Studio's IDE does when building a program).

I believe that Visual Studio is an exception as most GUI apps don't just wrap a console app. If you are concerned about being able to create a gui and console app, then put the core functionality into a reusable component (like a dll). Then call the dll from either the console or GUI app.