Re: Templates HowTo?
On 21 Feb, 15:15, "Alf P. Steinbach" <al...@start.no> wrote:
* ke...@bytebrothers.co.uk:
<snip code>
Now you can probably see what I'm trying to do with this 'index' call;
it has to return the result of find_cipher("ciphername"). The problem
is that at compile time, I get the following error:
ltc.h: In member function 'int Cipher<CFunctions>::index() [with
CFunctions = AESCipher]':
x.cc:47: instantiated from here
ltc.h:40: error: object missing in reference to 'AESCipher::index'
ltc.h:93: error: from this location
I can't see what it is that's missing. If someone can clarify, or
even better, show me a better way to do what I'm trying to do, I'd be
grateful. Meanwhile, I'm learning a _lot_ doing this stuff!
Well, AESCipher::index is non-static data member, that is, it only
exists in instances of AESCipher, one per instance.
To access it you'd need an AESCipher instance, but AESCipher is
currently not designed for instantiation: it's only designed as a
compile time carrier of addresses (by the way, I forgot, those function
types should probably all be 'extern "C"', but that's just a nit).
OK, I understand that.
What you need seems to be singletons, and for singletons the usual way,
when you don't have other requirements, is the "Meyer's singleton"
class SingletonType
{
private:
SingletonType( SingletonType const& );
SingletonType& operator=( SingletonType const& );
public:
static SingletonType& instance()
{
static SingletonType theInstance; // Add constructor args
return theInstance;
}
};
Sorry, I don't see how to apply this to what I'm doing. I think it's
getting time for more coffee... Can you expand a little for me?
It might also be a good idea to put all initialization calls in
constructors, and all cleanup calls in destructors. That is, no "setup"
or "cleanup" functions visible to client code at the C++ level. Of
course there may be some requirement I don't know or understand, but
usually, constructors and destructors are best for initialization and
cleanup: it automates the calls, and makes for better exception safety.
All of that is fair, and once I have the thing doing what I want, I
will probably move that stuff out of sight.
Thanks again for the help so far.