COM Creation & Crashing Issue

I have read some tutorials on creating COM objects using Visual C++ 2003. I am getting some errors though (expected). Say I threw in a .lib file, the .h file, and the dll in the debug folder. For example, there are two static member methods in the class X3D::Util. This line runs well...

X3D::Util::ClearLog();

However, say X3D::Util::Log in a if-condition, the program crashes. Does this have anything to do with the COM object being static? Why does the first once succeed?

The output window reads:
HEAP[T3D Console.exe]: Invalid Address specified to RtlValidateHeap( 00860000, 00883CC0 )
Unhandled exception at 0x7c901230 in T3D Console.exe: User breakpoint.

A user breakpoint is presented in the file dbgheap.c.

This COM object worked fine in a small console program. When I put it into my Windows application, it just started causing this issue. Could it have anything to do with the way this DLL was compiled with this code? I can only think each member is static so the class is never really allocated globally, but its just used on the spot when needed (each member is static), so making an object of it doesn't make much sense.

Side note too: Sometimes it works just fine. Other times it doesn't. In this case, if X3D::Util::Log() is in a if-block, it freaks out. Put this outside of the if-block, and it works just fine.

Is there something I'm missing?

COM .h file:

Code:

---

#ifndef _X3DUTIL_H_
#define _X3DUTIL_H_

#include <iostream>
#include <fstream>
#include <string>
#include <windows.h>

namespace X3D
{
  class __declspec(dllexport) Util
  {
  public: 
      static bool Log(std::string debugText, std::string filepath = "log.txt");
      static bool ClearLog(std::string filepath = "log.txt");
  };
}

#endif

---

COM .cpp file:

Code:

---


#include "X3DUtil.h"
 
bool X3D::Util::Log(std::string debugText, std::string file)
{
  std::ofstream out(file.c_str(), std::ios::out | std::ios::app);
  if (!out.is_open())
      return false;

  out << debugText << std::endl;
  out.close();

  return true;
}
 
bool X3D::Util::ClearLog(std::string file)
{
  std::ofstream out(file.c_str(), std::ios::out);
  if (!out.is_open())
      return false;

  out.close();

  return true;
}

---

This is really odd...

// intentional to go in block for example
if (RegisterClassEx(&wc)) {
X3D::Util::Log("Message.");
return 1;
}

Works fine. Now put two or three words in the string and BAM! Error.

How's this for brilliant? I got rid of the C++ code in the Log function and everything is working now. I just used the origional fopen(), fclose(), etc. and it worked. C++ can be daunting sometimes. I'd like to know exactly what went wrong though.

What you've you shown isn't really a COM object - it's just a class object implemented in a DLL.

Couple things. You should use __declspec(dllexport) when building the DLL, and __declspec(dllimport) when the client application includes the header file. Easiest way to do this is with a macro in the header:

Code:

---

#ifdef MY_DLL_BUILD
#  define MY_DLL_API  __declspec(dllexport)
#else
#  define MY_DLL_API  __declspec(dllimport)
#endif

class MY_DLL_API MyClass {...}

---

The other thing is that you should avoid passing CRT objects from one module (dll/exe) to another. This includes things like std::string. So a safer API for your string parameters would be to use "const char*".

http://msdn2.microsoft.com/en-us/lib...60(VS.80).aspx

gg

Thanks for the response. It sounds like there's a lot of do's and don'ts in this type of project, but I guess that's true with anything. Can you tell me when it's okay to use C++ code in a DLL project? I'm assuming its a no when passing parameters like std::string, but in the body of the function it is fine?

You can do what you want in the body of the function. Just use simple types for parameters and for any member variables of classes you expose.

gg

Thanks for clarifying. I'm curious though why this rule exists though. Is it a bug, feature, or just how DLL/EXE's work in C/C++ programs?

Well, it's more of a "rule of thumb".

In your case, suppose a user of your DLL decides they want to use the STLport library instead of the STL implementation which was used to compile your DLL.

If both the client and DLL are built against the same runtime DLL (not static), then you could pass around std::string's and other CRT objects. It's just dangerous.

gg