Modify Your Base Class Interface in Derived Classes-2 : Page 2

Demonstrating the Problem
Suppose you're implementing a file system that uses a class hierarchy like this one:

class File
{
public:
 int Open(const string & path);
 int Read (char * buff, size_t bytes);
 int Write (char *buff, size_t bytes); 
//..
};

class DiskFile: public File
{
public:
 int Defragment();
//..
};

class NetworkFile : public DiskFile
{
//.. 
};

Class NetworkFile implements a special type of file that can be stored and accessed remotely. At this stage, the designer faces two problems. First, unlike a local disk file, network files require a more rigorous authorization check to ensure that only authorized users may access them. Secondly, because the file may reside on a remote machine, it's necessary to overload the Open() member function to support additional types of path names, or, wstring names. A naive designer might include an additional overloaded version of this function like this:

class NetworkFile : public DiskFile
{
public:
 int Open(const wstring & path);//seemingly overloading
 //..
};

This code compiles okay. However, it doesn't exactly overload File::Open—instead, it hides it:

string path="\\usr\\image.bmp";
NetworkFile nf;
nf.Open(path); //compilation error

Here's the problem: when a compiler employs the overload resolution algorithm, it stops searching at the first scope in which a viable candidate is found. In this example, it finds NetworkFile::Open(const wstring & ) and the search terminates. However, the argument passed to the function is of type string &. Because of the type mismatch the compilation fails.

Previous Page

Next Page