I am currently wrapping a bunch of C++ classes inside of an in-proc
COM server.

My COM classes have a member variable that is a pointer to my C++
class.

example:

COMClassA
{
 STDMETHODIMP DoSomething(IUnknown* pCOMClassB);
 STDMETHODIMP CreateClassB(IUnknown** ppCOMClassB);

 ClassA m_pCPPClassA;

COMClassB
{
 ClassB m_pCPPClassB;  // points to ClassB object created in
CreateClassB()

Everything works well, until I call DoSomething() and try to access my
COMClassB directly.

DoSomething(IUnknown* pCOMClassB)
{
 COMClassB* pCOMClassB = reinterpret_cast<COMClassB*>(pCOMClassB);

 I want to access : pCOMClassB->m_pCPPClassB

Is this possible? I recognize this isn't Interface driven, but in my
case I don't care. I'm simply wrapping my classes so they can be
accessed from VB.

Thanks...

I suggest you don't try to get from interface back to raw C++ pointer.
This scheme breaks real quick in the presence of marshaling. Imagine two
clients using your DLL and one client passing your interface pointer to
another. What that other client gets is a proxy. You cannot cast a proxy
pointer to C++ class pointer (well, you can but you'll get an AV shortly
afterwards), and even if you add a method on your interface to retrieve
raw pointer, that pointer would be meaningless in the address space of
another process.

Instead, I recommend you expose all the necessary functionality via COM
interfaces. If you have some functionality you need to use internally
but don't want to make available to clients, define a custom interface
that publishes this functionality, implement it alongside your primary
interface, don't document it anywhere and don't publish it in the TLB.
Then your DoSomething method will query for this interface and, if it is
available, use it to access internal functionality. If the interface is
not available, DoSomething will report that the client has given it a
wrong object.
--
With best wishes,
    Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken