Hottest Forum Q&A on CodeGuru - January 12th

Comment from the Author:

In last week's column, we got a question from Al_Pennyworth in which he needed to minimize a window in pure C. I asked you to submit some solutions because I didn't find any. Chuck Vogt, a CodeGuru member, helped me out here and sent me the required code to do this in C. Thanks to Chuck. Here is the solution.

LRESULT CALLBACK WndProc(HWND hWnd, UINT Msg, WPARAM wParam,
                         LPARAM lParam)
{
    switch(Msg)
    {
        // your stuff
        // received WM_SYSCOMMAND
        case WM_SYSCOMMAND:
        if (SC_MINIMIZE == (wParam&0xFFF0))
        {
            // calculate X, Y, CX and CY for the size of the window
            // when the user clicks Minimize, you resize instead
            X     = ??
            Y     = ??
            CX    = ??
            CY    = ??
            Flags = ??
            SetWindowPos(hWnd, HWND_TOP, X, Y, CX, CY, Flags);
            // has hWnd
            // uses HWND_TOP - not hwndTop
            // don't use DefWindowProc - we've handled the msg
            return 0;
       }
       break;
       // the rest of your stuff
    }
    return DefWindowProc(hWnd, Msg, wParam, lParam);
}

Introduction:

Lots of hot topics are covered in the Discussion Forums on CodeGuru. If you missed the forums this week, you missed some interesting ways to solve a problem. Some of the hot topics this week include:

• What is the difference between #include <file.h> and #include "file.h"?
• How can I avoid const_casts?
• How does software protection work with a USB stick?
• Should I use a map or a vector?
• When should I define a common base class?

Thread:

nsh123, a member, needs to know the difference between these directives. Do you know the difference?

What is the difference between the following two statements:
1. #include <abc.h>
2. #include "abc.h"

According to MSDN:

#include "path-spec"
#include <path-spec>

The path-spec is a filename optionally preceded by a directory specification. The filename must name an existing file. The syntax of the path-spec depends on the operating system on which the program is compiled.

Both syntax forms cause replacement of that directive by the entire contents of the specified include file. The difference between the two forms is the order in which the preprocessor searches for header files when the path is incompletely specified.

Syntax Form Action

Quoted form: This form instructs the preprocessor to look for include files in the same directory of the file that contains the #include statement, and then in the directories of whatever files that include (#include) that file. The preprocessor then searches along the path specified by the /I compiler option, then along paths specified by the INCLUDE environment variable.
Angle-bracket form: This form instructs the preprocessor to search for include files first along the path specified by the /I compiler option, and then along the path specified by the INCLUDE environment variable.

The preprocessor stops searching as soon as it finds a file with the given name. If you specify a complete, unambiguous path specification for the include file between two sets of double quotation marks (" "), the preprocessor searches only that path specification and ignores the standard directories.

According to the ISO standard (section 16.2)

2 A preprocessing directive of the form

# include <hcharsequence> newline

3 A preprocessing directive of the form

# include "qcharsequence" newline

# include <hcharsequence> newline

Thread:

treuss has read in several books that you should avoid const_casts whenever possible. He is trying to avoid it anywhere he can. But at one point, he really doesn't know whether avoiding would be a benefit.

As all C++ books I've read so far tell me that const_casts are
something really evil, I am trying to avoid them everywhere I can.
However, I came up with an issue where I don't really know whether
avoiding them is worth the extra work.

I am writing a class for a tree that stores elements of class Leaf.
A function search exists with several 100 lines of implementation.
The interface looks like:

class Leaf;
class LeafAttributes;

class Tree
{
public:
  [...]
  Leaf& search( const LeafAttributes& );
  const Leaf& search( const LeafAttributes& ) const;
}

Now, of course I don't want to really implement search twice because
the algorithm does not differ for the const and non-const versions.
So, what I'm doing at the moment is this:

class Leaf;
class LeafAttributes;

class Tree
{
public:
  [...]
  Leaf& search( const LeafAttributes& a )
  { return const_cast<Leaf&> _search( a ); }
  const Leaf& search( const LeafAttributes& ) const
  { return _search( a ); }
private:
  const Leaf& _search( const LeafAttributes& ) const
}

So, here's the question I'm asking: Is there a nice, clean way to
implent this without using the const_cast?

Well, the best solution, according to YvesM, is to use a non-const version, make _search return a non-const, and make the const version of search call the non-const version. Something like this:

class Leaf;
class LeafAttributes;

class Tree
{
public:
  [...]
  Leaf& search( const LeafAttributes& a )
  { return _search( a ); }
  const Leaf& search( const LeafAttributes& ) const
  { return _search( a ); }
private:
  Leaf& _search( const LeafAttributes& ) const
}

Thread:

ergas is interested in using a USB stick as a software protection, but really doesn't know how they work.

Is it possible to use memory stick as an alternative for hard lock?
Recently, in one discussion I heard an idea to use USB memory stick
to protect software. The idea is pretty interesting because memory
sticks are not expensive and are available in any shop.

Something like this: Write some unique information to the memory
stick, lock it, and make it unpossible to copy it.

Is it possible or not, and if yes, how secure is it?

To get real protection, you'd need a processor on the memory stick. Otherwise, you'll have the problem of getting the (secret) key out of the stick for processing on the host computer and in this very moment your concept is or will be broken. Expensive protection systems pass data to the dongle for processing—that makes the difference compared to cheap solutions.

Thread:

Eggman002 needs a collection that will associate a string with an integer. Now, he is thinking about whether to use a map or a vector. What do you think?

I need a collection that will associate a string with an integer.
The strings will be added numerically and so the number associated
with the first string added will be 0, the second 1, etc. I was
thinking I would use a vector, but the problem is that I then want
to be able to search the collection for the string and find the
integer related to it. A vector does not seem to have an existing
search algorithm (am I wrong?). I could write one myself, but I was
hoping there was another way.

I also looked at using a map, but I am finding the interface to a
map to be needlessly complex. The example I have looked at shows:

theMap.insert(INT2STRING::value_type(0,"Zero"));

where I would rather just use:

theMap.insert(0,"Zero");

and searching the map involves iterators, and all sorts of other
needless garbage when I just want to have a method like:

int find(string searchString);

So, do I need to write a custom class or method, or is there
something I am not seeing?

Well, a vector and map are different containers.

• vector is a template class that is a perfect replacement for the good old C-style arrays
• map is a sorted associated container that associates objects of type key with objects

So, it's clear that Eggman002 should use a map here. And here is how:

#include <map>
#include <string>
#include <iostream>

class NumberName
{
public:

    typedef std::pair<std::string,int> PAIR; // needed for some
                                             // versions of VC++

    void insert(const std::string& name, int value)
    {
        theMap[name] = value;
    }

    int find(const std::string& name)
    {
        std::map<std::string,int>::iterator it = theMap.find(name);

        if (it != theMap.end())
            return it->second;
        else
            return -1;
    }

    // or maybe
    bool find(const std::string& name , int& value)
    {
        std::map<std::string,int>::iterator it = theMap.find(name);

        if (it != theMap.end())
        {
            value = it->second;
            return true;
        }
        else
            return false;
    }

private:

    std::map<std::string,int> theMap;
};

using namespace std;

int main()
{
    NumberName theMap;

    // add to the map
    theMap.insert("zero",0);
    theMap.insert("one",1);
    theMap.insert("two",2);


    // search in the map
    int i = theMap.find("one");

    if (i >= 0)
        cout << "found : " << i << endl;

    // or using the second method
    if (theMap.find("two",i))
        cout << "found : " << i << endl;

    return 0;
}

Thread:

Mza is wondering when he should derive from a base class and when he should not.

This is more a general OO question, but I was wondering when to
define a base class and when not to. For instance, I have a couple
of classes (not derived), all with a few common attributes but no
common operations and also a lot of specific attributes. Also, I do
not think these classes are subject to very much change. I can
imagine that in a case where two classes only have one common
attribute, that it would make no sense defining a base class.

I read somewhere here on CodeGuru that it is not wise to
automatically derive your classes in MFC from CObject because of
the overhead. So, I was wondering whether deriving a class in C++
has a negative impact on the speed of your application and whether
it is faster to have seperate, unrelated classes. Or, is this
negligible? I realize that there is probably not a clear guideline,
but I was just curious about your opinions.

It always depends on whether your classes have similar functions that are related to other. Then, it would make sense. Graham, a senior member, explained the solution very well. Here is what he says:

Is the common stuff similar because the two classes are fundamentally related to each other? In other words, are the two classes specific examples of a single, more general, class? For example, "Car" and "Bus" would both have an engine because they are both specific examples of the more general "MotorVehicle" class. However, a "Radio" and a "Thermostat" might both have dials and displays, but it's hard to justify a relationship. Of course, the detail of what you are modelling plays a part here—"Sunflower" and "Zebra" may or may not share a base class depending on whether your model is of "LivingThings", or some lower classification (where animals are not related to plants). As a general rule, I would say "if in doubt, don't inherit." Certainly, don't inherit just for the sake of reusing apparently similar members—there has to be a genuine exact correspondence between the members of the two classes, and the two classes should have a real hierarchical relationship with each other.

Besides that, take a look at the article from Herb Sutter: GOTW