Alternatives to the singleton pattern

I have read different opinions about the singleton pattern.Some maintain that it should be avoided at all costs and othersthat it can be be useful in certain situations.

One situation in which I use singletons is when I need a factory(let's say an object f of type F) to create objects of a certain class A.The factory is created once using some configuration parameters and thenis used each time an object of type A is instantiated. So every part ofthe code that wants to instantiate A fetches the singleton f and createthe new instance, e.g.

F& f                   = F::instance();boost::shared_ptr<A> a = f.createA();

So the general my scenario is that

1. I need only one instance of a class either for optimization reasons (I do not need multiple factory objects) or for sharing common state (e.g. the factory knows how many instances of A it can still create)
2. I need a way to have access to this instance f of F in different places of the code.

I am not interested in the discussion whether this pattern is good or bad,but assuming I want to avoid using a singleton, what other pattern can I use?

The ideas I had were (1) to get the factory object from a registry or(2) to create the factory at some point during program start up and thenpass the factory around as a parameter.

In solution (1), the registry itself is a singleton, so I have just shiftedthe problem of not using a singleton from the factory to the registry.

In case (2) I need some initial source (object) from which the factory objectcomes so I am afraid that I would again fall back to another singleton(the object that provides my factory instance).By following back this chain of singletons I can maybe reduce the problemto one singleton (the whole application) by which all other singletonsare directly or indirectly managed.

Would this last option (using one initial singleton that creates all otherunique objects and injects all other singletons at the rightplaces) be an acceptable solution?Is this the solution that is implicitly suggested when one advises not touse singletons, or what are other solutions, e.g. inthe example illustrated above?

EDIT

Since I think the point of my question has been misunderstood by some,here is some more information. As explained e.g. here, the wordsingleton can indicate (a) a class with a single instance object and(b) a design pattern used to create and access such an object.

To make things clearer let us use the term unique object for (a) andsingleton pattern for (b). So, I know what the singleton patternand dependency injection are (BTW, lately I've been using DI heavilyto remove instances of the singleton pattern from some code I am working on).

My point is that unless the whole object graph is instantiated froma single object living on the stack of the main method, there will always bethe need to access some unique objects through the singleton pattern.

My question is whether having the complete object graph creation andwiring depend on the main method (e.g. through some powerful DI frameworkthat does not use the pattern itself) is the onlysingleton-pattern free solution.