Questions:

This question related to the article Self-Registering Objects in C++ by Jim 
Beverage in Dr. Dobbs Joural, August 1998, pp. 38-41 You can get the rest of the 
code for this article from the Dr. Dobbs web site Get "register.zip". This code is 
also available in a subdirectory of my home directory in the CS file servers. See 
~crowley/register. 
1. In the first paragraph of the article he mentiones that C++ does not have "virtual 
contructors". Explain what would be hard about putting this feature into C++. 
2. Suppose we wanted to add a new file converter to this existing system. What steps 
would you have to take to do this? What code have to be written? What code 
would have to be changed? What code would have to be recompiled? How would 
the library change? 
3. What is the purpose of the proxy classes? How does this relate to the solution I 
gave in class for Singleton Factory creation which also used proxies? 
4. On page 40 of the article in the last paragraph of the column he says "All 
functions in Listing Four are completely defined. The proxy class does not need to 
be modified for each class that it represents." What does he mean by this and why 
it is it significant? Will there be a Proxy class for each file converter or will there 
only be one FileConverterProxy? 
5. In Listing Five the functions GetExtension and IsCompressed are static. Why are 
they static? Why are the other functions not static? 
6. Explain how this system uses lazy construction. 
7. In the left-hand column on page 41 in the second paragraph of the section labeled 
"The Specialty Store" they describe a problem with initialization in C++ and their 
solution to the problem. In your own words, describe what the problem is and 
how his solution solves the problem. 


Answers:

1.
It would be hard because due to the semantics of C++ until the constructor has been 
invoked there is no “this” object through which the virtual dispatch could take place.

2.
To add a new file converter class (say with file extensions of hobbit) to the specialty store 
system you would have to make the HobbitFileConverter class. The HobbitFileConverter 
class would be a FileConverter (an isa relationship).You also would have to make a 
HobbitFileConverterProxy class that derives from FileConverterProxyBase using the 
FileConverterProxy class which is a template class. Then, Add TYPE_HOBBIT to the 
enum (listing 1(a)) and to the switch (listing 1(b)). Add the strcmp(ext, *.hobbit) and 
creation of the new HobbitFileConverter to the if statements in CreateConversionObject 
(listing 2(a)). The libraries would have to be recompiled.

3.
The purpose of the proxy class is 


This relates to the solution you gave in class because


4.
By modified he means that no methods or variables will have to be added. This is 
significant because it provides a standard interface for obtainig information about the 
class. There will be a proxy class for each file converter. Each proxy must create and pass 
commands along to the class it is a proxy for. Proxys are made using the 
FileConverterProxy class, which is a template class.


5.
They are static because all instances of this class can share them. All instances will 
always return “.tiff” for the extension and true for isCompressed(). The other functions 
are not static because filename is different for each instance of the class. Also (see below) 
you don’t even need an instance of the class to call these functions.


6.
This is so funky. I thought  the proxy had a create object function for no good reason.
Because right below it is a call to T.GetExtension() (I am to used to java) so T must have 
already been made, but noooo upon closer inspection the call is T::GetExtension taking 
advantage of the static nature of these functions to delay making the object untill it is 
actually needed. The object is made by the FileConverterStore  CreateByExtension 
function only if it is needed for a file on hand. Totally cool.

7.
The global pointer he is talking about is: 
ConverterVector* m_pConverters;
This is declared in store.h but c++ will not allow it to be set there. It is set (after a 
check to insure this only happens once) in the Init() function which is called in the 
register() function by the proxy constructors. This is done because the constructors for 
the proxies can be called before the constructor for store. At the bottem of cvtTiff.cpp the 
proxy is decleared globaly. When the program starts the first thing done is to make all the 
globals and in C++ there is no gureente about the order in wich this occurs. As a result if 
you waited until the store constructor was called to set the pointer it could get written 
over. Or I see it as writing to something that dosnt exists yet.