www.digitalmars.com         C & C++   DMDScript  

c++.stlsoft - CoInitializer

reply "JAVIER ESTRADA" <ljestrada verizon.net> writes:
Matthew,

I missed a RAII that wraps the calls to CoInitialize(Ex) and CoUninitialize.
I make heavy use of such a simple wrapper, and it can serve as a base class
for "active" classes--those that create their own thread and enter a COM
apartment, or as an automatic variable when entering COM is necessary for
the length of a function call:

#ifndef _WIN32_DCOM
#define _WIN32_DCOM
#endif

#include <windef.h>   // DWORD
#include <winerror.h> // FAILED, SUCCEEDED macros
#include <objbase.h>  // CoInitializeEx, CoUninitialize

class CoInitializer
{
  CoInitializer(CoInitializer const&);
  CoInitializer& operator=(CoInitializer const&);

public:

  explicit CoInitializer(DWORD dwCoInit = COINIT_APARTMENTTHREADED)
  {
    if (FAILED(::CoInitializeEx(0, dwCoInit)))
      /*a throw clause here if desired*/;
  }

  ~CoInitializer() { ::CoUninitialize(); }
};
Feb 25 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"JAVIER ESTRADA" <ljestrada verizon.net> wrote in message
news:c1judk$1knu$1 digitaldaemon.com...

 Matthew,

 I missed a RAII that wraps the calls to CoInitialize(Ex) and




 I make heavy use of such a simple wrapper, and it can serve as a base




 for "active" classes--those that create their own thread and enter a COM
 apartment, or as an automatic variable when entering COM is necessary for
 the length of a function call:



Check out comstl_initialisers.h, which contains the com_initialiser and
ole_initialiser classes. There's a test program in the
test\comstl\initialisers_test subdirectory.

They currently use a half-hearted mechanism to attempt to prevent
inheritance, so may not serve your needs in their current form.

There's also a problem with them is that they're not spelled correctly for
US-English speakers, so I'm adding the appropriate typedefs in the next
version. This may be how you missed them (although I would have assumed that
you'd grep for CoInitialize.)

However, I'm including the latest version, which have these issues addressed
now.


 #ifndef _WIN32_DCOM
 #define _WIN32_DCOM
 #endif

 #include <windef.h>   // DWORD
 #include <winerror.h> // FAILED, SUCCEEDED macros
 #include <objbase.h>  // CoInitializeEx, CoUninitialize

 class CoInitializer
 {
   CoInitializer(CoInitializer const&);
   CoInitializer& operator=(CoInitializer const&);

 public:

   explicit CoInitializer(DWORD dwCoInit = COINIT_APARTMENTTHREADED)
   {
     if (FAILED(::CoInitializeEx(0, dwCoInit)))
       /*a throw clause here if desired*/;
   }

   ~CoInitializer() { ::CoUninitialize(); }
 };



This is wrong! You need to match a call to CoUninitialize() *only* with a
successful call to CoInitialize(), CoInitializeEx(), and the same follows
for OleInitialize() and OleUninitialize(). MSDN says:

"A thread must call CoUninitialize once for each successful call it has made
to CoInitialize or CoInitializeEx. Only the CoUninitialize call
corresponding to the CoInitialize or CoInitializeEx call that initialized
the library can close it."


I'm including the latest version here. This will get into 1.7.1, so you are
pretty safe using it as is.

btw, I'm thinking of changing them to allow for parameterisation by an
error-handling policy, so as to throw exceptions if it fails. But don't
worry, as I'll make sure that all current typenames will be valid
instantiations of the templates with the same semantics as they now have. :)

Cheers

Matthew
Feb 25 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
No time like the present. Here's the policy-based version.

Thanks for providing the impetus. :)

Matthew


"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c1k3b1$1tg4$1 digitaldaemon.com...

 "JAVIER ESTRADA" <ljestrada verizon.net> wrote in message
 news:c1judk$1knu$1 digitaldaemon.com...

 Matthew,

 I missed a RAII that wraps the calls to CoInitialize(Ex) and




 I make heavy use of such a simple wrapper, and it can serve as a base




 for "active" classes--those that create their own thread and enter a COM
 apartment, or as an automatic variable when entering COM is necessary







 the length of a function call:



 Check out comstl_initialisers.h, which contains the com_initialiser and
 ole_initialiser classes. There's a test program in the
 test\comstl\initialisers_test subdirectory.

 They currently use a half-hearted mechanism to attempt to prevent
 inheritance, so may not serve your needs in their current form.

 There's also a problem with them is that they're not spelled correctly for
 US-English speakers, so I'm adding the appropriate typedefs in the next
 version. This may be how you missed them (although I would have assumed




 you'd grep for CoInitialize.)

 However, I'm including the latest version, which have these issues




 now.


 #ifndef _WIN32_DCOM
 #define _WIN32_DCOM
 #endif

 #include <windef.h>   // DWORD
 #include <winerror.h> // FAILED, SUCCEEDED macros
 #include <objbase.h>  // CoInitializeEx, CoUninitialize

 class CoInitializer
 {
   CoInitializer(CoInitializer const&);
   CoInitializer& operator=(CoInitializer const&);

 public:

   explicit CoInitializer(DWORD dwCoInit = COINIT_APARTMENTTHREADED)
   {
     if (FAILED(::CoInitializeEx(0, dwCoInit)))
       /*a throw clause here if desired*/;
   }

   ~CoInitializer() { ::CoUninitialize(); }
 };



 This is wrong! You need to match a call to CoUninitialize() *only* with a
 successful call to CoInitialize(), CoInitializeEx(), and the same follows
 for OleInitialize() and OleUninitialize(). MSDN says:

 "A thread must call CoUninitialize once for each successful call it has




 to CoInitialize or CoInitializeEx. Only the CoUninitialize call
 corresponding to the CoInitialize or CoInitializeEx call that initialized
 the library can close it."


 I'm including the latest version here. This will get into 1.7.1, so you




 pretty safe using it as is.

 btw, I'm thinking of changing them to allow for parameterisation by an
 error-handling policy, so as to throw exceptions if it fails. But don't
 worry, as I'll make sure that all current typenames will be valid
 instantiations of the templates with the same semantics as they now have.




 Cheers

 Matthew
Feb 25 2004