Entering Data in a Code::Blocks Window

Sometimes it isn’t very obvious how to enter data into a Code::Blocks window. One of the windows that seems to be causing problems for a number of readers is the Watches window. You open this window by choosing Debug | Debugging Windows | Watches. The purpose of this window is to let you view the content of variables in your application, which is an essential part of the debugging process. In order to view the variable (or other expression) content, you must enter it in the Watches window. Book III of C++ All-In-One Desk Reference For Dummies tells you all about debugging.

One technique for entering the variable is to select it in the editing window and the drag it to the Watches window. The variable will appear in the Watches window along with its value. However, this approach only works for variables and expressions that actually appear in your code. You might want to enter some other expression (or manually enter the variable, rather than drag and drop it). The Watches window consists of rows and columns as shown here.

WatchEntry01

The name of the variable or the expression you want to view appears in the first column. To enter a new value into the Watches window, click directly in the first empty left column cell. The row will turn blue and you’ll see a red insertion point appear in the cell as shown in the screenshot. Now you can type the variable name or expression you want to work with and press Enter. Let’s say your variable is named i. It might look like this:

WatchEntry02

Notice that the row is now white because it isn’t selected. However, you can see the name of the variable, i, it’s value 1983844706, and it’s type int. The row is in red because the value of i has just changed (unchanged values appear in black so you can see them easier). As you debug your application, you can now watch the value of i for changes.

Sometimes it isn’t obvious how to enter information into Code::Blocks (or any other application for that matter). When that happens, the focus turns to the application, rather than the work you need to do, and the experience becomes frustrating. Let me know about your book-related Code::Blocks questions at [email protected] and I’ll do my best to answer them. Because I don’t have a direct connection to the vendor, my ability to answer other sorts of questions is limited.

 

Passing By Value Versus By Reference

A number of readers have written me about the examples that use pointers in the book. One of the most common questions comes from the example on page 149 of C++ All-In-One Desk Reference For Dummies. In this example, the application contains a function that accepts an argument by reference. The use of a reference seems to have many people confused and this post will hopefully clear the issue up.

The first thing you need to understand is that there isn’t any magic going on here. The process for working with functions remains constant in C++. When you call any function with an argument, the application creates memory to hold the argument. The memory is local to that function. When the function ends, the memory is released. What the memory holds, now that changes.

Think of the memory as a box. This box has an address that points to it. When you work with a pointer, you’re working with the address. On the other hand, when you work with the value, you’re working with the content pointed to by the pointer, or the contents of the box. Whether the box the function receives contains a pointer or the value depends on how you write the function and what you pass to it from the caller.

Now, let’s look at an example so that you can better understand what’s going on.  This example will do the same thing to the number each time, but using different techniques: by value, using a pointer, and by reference.

#include <iostream>
 
using namespace std;
 
void MessMeUpA(int myparam)
{
    myparam = myparam * 2 + 10;
}
 
void MessMeUpB(int* myparam)
{
    // Obtain the current value.
    int currentValue = *myparam;
 
    // Perform the required math.
    currentValue = currentValue * 2 + 10;
 
    // Save the result.
    *myparam = currentValue;
}
 
void MessMeUpC(int &myparam)
{
    myparam = myparam * 2 + 10;
}
 
int main()
{
    // Call by value.
    int mynumber = 30;
    MessMeUpA(mynumber);
    cout << "By Value: " << mynumber << endl;
 
    // Call using a pointer.
    mynumber = 30;
    MessMeUpB(&mynumber);
    cout << "By Pointer: " << mynumber << endl;
 
    // Call using a reference.
    mynumber = 30;
    MessMeUpC(mynumber);
    cout << "By Reference: " << mynumber << endl;
 
    return 0;
}

You may notice that part of this example comes directly from page 149. If you run this example, you’ll see this output:

PassingData01

When you pass the data by value, you’re passing the information, not a pointer to the information. As a result, MessMeUpA() receives a value of 30. It doesn’t receive a pointer to the initial variable, nor does it obtain a reference to the initial variable. As a result, when the application performs the calculation, the result is thrown away.

When the application calls MessMeUpB(), it provides a pointer to the variable. However, the pointer isn’t a value. As a result, you move the value pointed to by the pointer into a local variable, perform the required math, and then move the value back into the original pointer. As a consequence, the original value is altered to 70.

Finally, when the application calls MessMeUpC(), the function obtains a reference to the original memory location. When the function performs the math, it’s actually using the original value as pointed to by the reference, which means that this is a kind of pointer, just not passed from the caller. The changes made in MessMeUpC() are reflected in the original value because you’re using a pointer to that value and not a copy of the value in local memory.

I highly recommend that anyone trying to understand how code works use the debugger to trace through that code. It’s instructive to look at each of the functions to see how they look. Place a breakpoint in each of the functions and then start the debugger. Open the Watches window, if necessary, by choosing Debug | Debugging Windows | Watches. Here is the view of the Watches window when calling MessMeUpA().

PassingData02

What you see here is a function argument—an integer that contains the value of 30. Now, let’s look at MessMeUpB().

PassingData03

In this case, you see a local variable, currentValue, that contains the updated value and a pointer to the variable used by the caller in myparam. The pointer gives you access to the value held by the caller and allows you to change it. Finally, let’s look at MessMeUpC().

PassingData04

Look at the function argument, myparam. The debugger is giving you a valuable insight here. See the address provided with the variable? Match that address to the pointer provided to MessMeUpB() and you’ll see that they’re the same. The reference is simply another sort of pointer, but one that gives you direct access to the memory without having to go through the extra steps required by pointers. The debugger even shows you that the current value of that memory is 30 (the math hasn’t been performed as of yet).

A function argument is simply a box that holds either a value or a pointer. Whether that pointer is an actual pointer or a reference depends on how you write you code. That’s the point of the example. Pointers don’t have to be mysterious or hardthey’re simply an address for an area of memory (a box if you will) that holds a specific value. Please let me know if you have any questions about this issue at [email protected].

 

Review of ADO.NET 4 Step by Step

Microsoft has created a plethora of database technologies over the years. The managed form of ActiveX Data Objects (ADO) is just another in a long series of ways to access data from within an application. Because some older technologies, such as Open DataBase Connectivity (ODBC), are so entrenched, there isn’t any way that a single book can tell you everything there is to know about working with databases from a Microsoft perspective. When you add in all of the potential database products (SQL Server, MySQL, AskSAM, Oracle, DB2, and many, many others), the task becomes impossible. So, when I reviewed this book (supplied to me by the publisher), I didn’t consider completeness from the perspective of providing a single source solution to database management. In fact, given 25 years of experience, I feel that such a book is impossible to write—at least as a single useable volume. When shopping for a database management book, be sure you look for a book that covers both the required access technology (such as ODBC, ADO, or ADO.NET) and the database manager (such as SQL Server or MySQL) that you need for your project.

Tim Patrick has written ADO.NET 4 Step by Step with ADO.NET and SQL Server in mind. In fact, the book is incredibly focused and I applaud the author’s single minded devotion to this combination of technology and product. Other database books I’ve read just don’t seem to get the idea that watering down the message won’t work. While it might be possible to include multiple products in a book, trying to cover multiple technologies seldom works because there is too much to discuss and, even if the author successfully writes about each technology in an unbiased way, the reader tends to become confused. So the first thing you must know about this book is that it’s strictly about ADO.NET and SQL Servertry another book if you need any other combination.

This is the second Step by Step book that I’ve reviewed (see Review of HTML5 Step by Step for details of the other review). As with that other book, this book is heavy on hands on involvement and light on theory, which is just fine because many people learn better using hands on tasks. However, database management is a more complex task than creating a Web page because you have data integrity rules and other issues to consider that simply don’t come into play when working with a Web site. (To be fair, Chapter 12 does discuss data integrity, but mainly from a hands on perspectiveyou end up understanding how, but not what, why, or when.) I mention this because the hands on approach in this book does help you create applications fast, but it doesn’t provide you with everything you need to know to create good applications. For example, the discussion of ADO.NET components consumes a scant two pages. Database normalization is covered in a two paragraph sidebar in Chapter 2. The author is cramming a huge amount of theory in an incredibly small space and glossing over a lot of details. I would have liked to have seen some notes, tips, or sidebars with online resources as a minimum so the reader could fill in the missing theoretical details later.

The best part about this book is the activity. I was able to create a basic application in less than an hourfar faster than any other book I can remember using, even my own books. By the time you reach the end of Chapter 1 (about 15 pages), you’ve already learned how to create a connection to your data. Chapter 2 has you creating tables using several different techniques.

I loved the quick references at the end of each chapter. They act as a quick method of ensuring you got all of the details out of each chapter. If you read the entire chapter, you can go back to the quick reference later as a reminder of the things you learned.

Patrick provides a relatively good discussion of every aspect of managing the database and the information it contains using both C# and Visual Basic examples. Support for both languages is a good addition to the book. In addition, the support isn’t sporadic as it is in many books that favor one language or the otheryou’ll find most information discussed equally in both languages so neither language feels like a second class citizen.

Chapter 8 does discuss external connectivity, but it feels like Patrick is discussing the topic from the perspective of the developer who normally uses ADO.NET exclusively, which is absolutely correct for this book. You’ll discover how to interact with OLE DB and ODBC data sources. Unfortunately, as with many other areas of the book, the author digs right into using the connections without providing any theory whatsoever. This is another area where it would have been nice to have resources provided so that the confused reader could learn more. Still, everything works as promised, so there is something to be said for that. Many readers don’t want to know how it works, they simply want to know how to do something black box style and this chapter fits in perfectly with that mindset.

For me, the highlight of the book was Chapter 16. In this chapter, the author cuts through all of the usual garbage associated with objects and shows the bare essentials to use technologies such as LINQ. This is possibly the shortest, yet best conceived, coverage of the topic that I’ve seen anywhere. Again, you’ll find yourself lacking theoretical details, but the how discussed in an elegant way that will enable most readers to make use of these newer technologies in an incredibly short time. In fact, Part IV of the book goes on to cover LINQ in detail. I’m convinced that LINQ will eventually become the data query technique of choice because it’s relatively easy to understand, requires little code, and generally produces optimized results with little effort on the part of the developer. Obviously, the author agrees with me on this matter.

Overall, ADO.NET 4 Step by Step is a fantastic book for teaching you the “how” of database management using SQL Server and ADO.NET. In fact, you’ll learn how to perform many tasks that other tomes simply leave out. However, if you want to know why you’re doing something, when to do it, or understand the theory behind a task, you’ll need another book. I recommend this book to anyone who wants to get started quickly. You can always obtain a theoretical book to fill the gaps in your knowledge and you experience programming scenarios you don’t understand. The best addition the author could make to a next edition is some online sources to help the confused reader. Writing a database management book is tough, but it’s important to recognize that there are limits to what you can do and provide the reader with help in overcoming those limitations.

 

Understanding the Connection Between Application Output and ErrorLevel

Many readers have a disconnect between application output and the ErrorLevel variable found in batch files. I’ve received more than a few e-mails where readers don’t quite understand the whole concept behind the ErrorLevel variable. They think it actually signifies some sort of mystical operating system derived error, when it isn’t anything of the sort.

A large part of the problem is that those readers who commonly work with batch files aren’t developers and many developers don’t work with batch files. In fact, even though many administrators are moving back to command line utilities because working with the GUI is time consuming and inefficient, many developers have decided to eschew the console application in favor of GUIs with fancier user interfaces.

Another problem is that ErrorLevel is inappropriately named. It should really be named ApplicationOutput. I’m sure that at one time the intention truly was to convey some sort of error information, but even Microsoft uses ErrorLevel for other purposes.

Let’s take a practical look at the whole concept of ErrorLevel beginning with a simple C# application to generate the codes. When working with C#, you’ll find that the output is now called an ExitCode as shown here.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
 
namespace GenerateOutput
{
    class ExitCode
    {
        static void Main(string[] args)
        {
            // Create a variable to hold the exit
            // value.
            Int32 Value;
 
            // Make sure there is a variable provided as input.
            if (args.Count() > 0)
            {
 
                // Determine whether the input is actually a number.
                if (Int32.TryParse(args[0], out Value))
 
                    // If it is, then exit using that number.
                    Environment.Exit(Value);
                else
 
                    // Otherwise, exit with an error value of -2.
                    Environment.Exit(-2);
            }
            else
 
                // Exit with an error value of -1
                Environment.Exit(-1);
        }
    }
}

The only purpose of this application is to generate exit codes given certain circumstances. The first check determines whether the user has supplied any sort of input at all. If not, if the user simply types GenerateOutput without any arguments at all, then the application exits with a value of -1 to indicate an error. Likewise, if the user types something other than a number, such as GenerateOutput Hello, the application exits with a value of -2 to indicate a different sort of error. Only when the user supplies a number does the application exit with a numeric value.

The batch file used to test this application is equally simple. All it does is call GenerateOutput with the value (if any) that the user provides to the batch file, TestOutput.bat. Here’s the batch file code.

@Echo Off
 
REM Run the application.
GenerateOutput %1
 
REM Most application output are status indicators.
If ERRORLEVEL 2 GOTO HighOutput
 
REM You can perform specific actions for a specific status.
If ERRORLEVEL 1 GOTO ValueOne
 
REM Applications can also provide a success indicator.
If ERRORLEVEL 0 GOTO Success
 
REM Errors are normally negative numbers, but can be anything.
If ERRORLEVEL -1 GOTO Error1
If ERRORLEVEL -2 GOTO Error2
 
:HighOutput
ECHO The value you provided is higher than 1.
GOTO End
 
:ValueOne
ECHO You provided an input of precisely 1.
GOTO End
 
:Success
ECHO An output value of 0 indicates success!
GOTO End
 
REM Here is the beginning of the various messages.
:Error1
ECHO You must supply a number as an argument!
GOTO End
 
:Error2
ECHO You must supply a number and not text or special characters!
GOTO End
 
REM Here is the ending point.
:End

As you can see, the tests check for errors, success messages, and non-error application output. Any combination of console application and batch file can do the same thing provided the developer and administrator get together to work out the details or the developer at least documents the exit codes.

The process is the same each time. Test for an ErrorLevel value, then go to the label specified, execute the directions, and then go to the end of the batch file. The ErrorLevel values must appear in order from greatest to least in order to work correctly. Here is some test output from this test application and batch file pair.

ErrorLevel01

The point of this exercise is to ensure that developer and administrator alike realize the importance of the exit code (ErrorLevel). The application should use it to provide some sort of status information that the administrator can then use to track how well the application works in an automated setting. Let me know if you have any questions at [email protected].