Steffen, you're right and I did it always like you wrote. I made an static initialisation class. This way I don't get the problems anymore. If I had done a singleton with reference counting it could be possible that someone decrements the count to zero and all things for deinitialisation are called and afterwards someone constructs and initialises again and gets the error.
So now everything works fine. Thanks to all for the help. Frank > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Im Auftrag von > Steffen DETTMER > Gesendet: Mittwoch, 2. April 2008 10:47 > An: openssl-users@openssl.org > Betreff: Re: Problem after removing memory leak > > * Wockenfuß, Frank wrote on Wed, Apr 02, 2008 at 09:07 +0200: > > Thank you for that hint. > > I will try to rebuild the class as singleton. This could help, but > > isn't really nice. > > I think you'd need multiple classes. For things done once a > program life time, a C++ class (singleton) may not be suited, > a simple ordinary init function may be sufficient. However, > such an instance could make sense for instance if used on > stack around main in something like this: > > int main() > { > OpenSSLAllEverything allocation; > return main_(); > } > > to ensure that it is released exactly once even in case of > exceptions. Maybe the class assert()s that it is constructed > only once to help application developers to find usage > problems quickly. > > I think it is essential and required to call RAND_seed once > and only once. Functions like X509_verify_cert may be desired > as X509Certificat::verify(). > > > > Doing it per-object creation is unnecessary and error prone (as > > > maybe the case here). I believe it should be possible to > do it once > > > per program lifetime without changing your C++ class too much. > > Maybe having a static instance counter, so resources could be > freed if the last instance is destroyed? But to much > automagic handling may not be good; imagine, this would be > linked with a similar class that also has its own instance counter... > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on > Ingenico for secure and expedient electronic transaction > acceptance. Ingenico products leverage proven technology, > established standards and unparalleled ergonomics to provide > optimal reliability, versatility and usability. This > comprehensive range of products is complemented by a global > array of services and partnerships, enabling businesses in a > number of vertical sectors to accept transactions anywhere > their business takes them. > www.ingenico.com This message may contain confidential and/or > privileged information. If you are not the addressee or > authorized to receive this for the addressee, you must not > use, copy, disclose or take any action based on this message > or any information herein. If you have received this message > in error, please advise the sender immediately by reply > e-mail and delete this message. Thank you for your cooperation. > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
