I don't really understand why, but sure, why not. (Note: The following is a discussion of how things currently exist. For almost two years I've been working on cleaning up the vast majority of code I've written over the last thirteen years so that I could publish it with the modest hope that it might be useful and educational.)
They are all just variable names of course. The types are the important bit.
smart_pointer): A fairly generic smart pointer implementation using my variant of policy based design. (My variant is a bit more portable and complete--in that the policy classes support, for example, multiple virtual inheritance and are themselves derived through other policies and traits.)
Code:
template
<
typename element_T,
typename dictionary_T
>
class reference;
some_class): The type representing the abstract interface for images, surfaces, and surface manipulation. It describes the interface for several vector and bitmap drawing methods. (Yes, it is a derived from a template, but that isn't important and is only implemented in this way because the default implementation of certain meta-functions "knows" how to obtain an interface in this way.)
Code:
template
<
typename dictionary_T
>
surface<interface, dictionary_T>;
factory): An instance of the class derived by instantiating a factory generator--a template class. I do not write factories that know how to process more than one type. This is basically an instance of the type that results from gluing several of such tiny factories together.
Code:
template
<
typename employee_T,
typename dictionary_T
>
factory;
whatever): An instance of 'reference<surface<interface>::type>::type'.
Now then, apparently your getting confused because of the word involved and the existence of the "factory pattern". (Sorry if you aren't, but that seems to be the case.) The variable 'factory' as in my example is a candidate for the factory pattern, but that isn't really the intent, and possibly I should attempt to find a more suitable name--or at least one with fewer collisions. The interface of the factories I write do spawn instances of objects, but, by and large, they perform processing the objects themselves aren't capable of to support formal input and output. (They, the objects themselves, could be capable of such processing; I just don't like the design that results.)
Virtually every object in my library is capable of "simple" input and output. (Every object knows how to serialize and deserialize themselves using whatever dictionary and format--binary or text--is associated with the current stream.) This, for example, means that 'std::cout << *my_image' in one application piped to 'std::cin >> *my_image' in another application should result in the second application having a nice copy of '*my_image'. However, such source does not spawn any object; the source for the input application must know exactly what dictionary and format needs to be associated with the stream and what kind of object is to be expected. This is sufficient for a great many applications, but not nearly all of them.
For one, this simple model isn't sufficient for any purposes involving third-party applications. For example, there are a handful of CLI imaging utilities that can operate on named pipes, but can't do anything with the input my library would give it. My library obviously needs to provide a mechanism to process the objects for such formal purposes. This is where my factories come in; yes, they provide a mechanism to spawn new objects as expected, but they also provide processing on the output side of the equation.
As it is, the library offers a variant of '3' as originally posted.
Soma