I think the answer by Niall is good and the accepted answer is correct, but wish to add a bit in the vein of using Singletons.
The Singleton pattern is a bit like Communism. It looks good on paper, but when you mix it with people things tend to fall apart.
The thing is that the Singleton pattern isn't, inherently, an anti-pattern. It's more that most (naive) implementations of it tend to skim over important aspects or cause possible issues.
For example, in C++, a globally initialized Singleton can be allocated pretty much whenever sometime before the main loop starts. Combining multiple Singletons this way means you have no idea what order they will initialize relative to each other. The order of cleanup is similarly arbitrary (but generally the reverse of the order they were initialized in).
(There are SOME basic rules for this, but mostly it's left up to the nasal demons.)
Global and readily accessible objects also tend to end up veering into the realms of a God Class, which is very much an anti-pattern. Ideas like "I already have a Manager class, I'll just stick it there," are easy and the solution is quick. This is a case of Technical Debt.
A controlled Singleton managed correctly can be very useful and not cause problems, but they are a more difficult pattern to get right than people tend to expect. The worst part is that the examples out of text books tend to teach really bad habits for Singletons.
For your specific case, since you have no state and don't need to load or unload, you don't need an object. A static function or equivalent should suit your needs.
And, since I can't comment (shakes fist), I want to second Niall's point on understanding what a pattern solves and where it works. I'd also recommend researching how it works and how best to implement it, as implementing a pattern correctly is at least as important as choosing the right pattern.