C++ Mixed mode CLI problem/query

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,

I am writing a performence critical application, this require me to stick to unmanaged C++ as performance is much better using unmanaged C++ ( about 33% better ), Still, I am trying to avoid the usage of old style COM, my alternative is to expose my unmanaged interface through the CLI, to achieve that I have created a mixed mode DLL in which my unmanaged class are defined.
When referencing the DLL just described in another mixed mode EXE I can see the unmanaged methods through the 'Object browser' BUT, I can't reference them through code, the namespace of the DLL is not recognised....
When using a managed C# EXE to reference the unmanaged CLI assembly the namespace is identified BUT the contained objects are not...
Is it possible to expose unmanaged interface through the CLI??? is it possible to reference this type of interface through another mixed mode assembly? will VS2005 support this kind of functionality?

Bellow is a fragmet of the mixed mode ( unmanaged ) assembly I have created:
namespace Unmanaged
{
__nogc interface IBlockAllocator;
__nogc interface IDataBlock
{
virtual HRESULT Initialize(IBlockAllocator *pAlloc, const DWORD dwSize, void *pExArg) = 0;
virtual IBlockAllocator *Allocator()= 0;
virtual BYTE *Pointer()= 0;
virtual const DWORD Size()= 0;
virtual LONG AddRef() =0;
virtual LONG Release()= 0;
virtual void Dispose()= 0;
};

__nogc class CDataBlock : public IDataBlock
{
protected:
DWORD m_dwSize;
LONG m_lRefCount;
BYTE *m_pData;
IBlockAllocator *m_pAlloc;
public:
IBlockAllocator *Allocator() { return m_pAlloc;}
BYTE *Pointer() { return m_pData;}
const DWORD Size() { return m_dwSize;}
LONG AddRef() { return InterlockedIncrement(&m_lRefCount); }
LONG Release()
{
if(0 != InterlockedDecrement(&m_lRefCount))
return m_lRefCount;
m_pAlloc->ReturnToCache(this);
return 0;
}
void Dispose() { delete this; }
HRESULT Initialize(IBlockAllocator *pAlloc, const DWORD dwSize, void *pExArg = 0)
{
m_pAlloc = pAlloc;
m_dwSize = m_pAlloc->GetBlockSize();
m_pData = new BYTE[m_dwSize];
};
CDataBlock() : m_lRefCount(0)
{
}
~CDataBlock()
{
delete m_pData;
m_pData = 0;
m_pAlloc = 0;
}
};
};// Unmanaged

Nadav
http://www.ddevel.com
 
Create your methods as static members of a __value or __gc class. Then you
will be able to access them for the managed side.

Ronald Laeremans
Visual C++ team
 
Hi Ronald, Thanks for your response, Still, I have some open issues:
1. Is it possible to define an unmanaged class ( not static ) and expose it using CLI in a way that it would be able to be accessed from managed and unmanaged code? ( i didn't find any in the current VS version and in VS2005.Beta ), My alternative is to use COM which I would really like to avoid...
2. I Did several performance tests with VS2005.Beta, unmanaged C++ if far more efficient then C#, one of the tests I have done involved mixed mode C++ ( using VS2005 ), I have wrapped my (efficient) unmanaged project with a managed wrapper, running this project result performance of about 90 Precent of the original unmanaged project, note that the managed code used merely as an entry point to execute the unmanaged code ( e.g. MyObj->RunUnmanaged() ), why does performance is lost? it seems that loading the CLR it-self causes a performance loss...
2.1. Some words of the test application: it is a winsock app that use IOCompletion port for async IO.

P.S.
How do the guys in Microsoft treat this kind of problems? What language is used for performance critical modules ( I guess it is unmanaged C++ ) that should interact with managed assemblies? What would be the best way of implementing a performance critical module ( CLI, COM, ... ) that should interact with managed code ?

Nadav
http://www.ddevel.com

Ronald Laeremans said:
Create your methods as static members of a __value or __gc class. Then you
will be able to access them for the managed side.

Ronald Laeremans
Visual C++ team

Nadav said:
Hi,

I am writing a performence critical application, this require me to stick
to unmanaged C++ as performance is much better using unmanaged C++ ( about
33% better ), Still, I am trying to avoid the usage of old style COM, my
alternative is to expose my unmanaged interface through the CLI, to
achieve that I have created a mixed mode DLL in which my unmanaged class
are defined.
When referencing the DLL just described in another mixed mode EXE I can
see the unmanaged methods through the 'Object browser' BUT, I can't
reference them through code, the namespace of the DLL is not
recognised....
When using a managed C# EXE to reference the unmanaged CLI assembly the
namespace is identified BUT the contained objects are not...
Is it possible to expose unmanaged interface through the CLI??? is it
possible to reference this type of interface through another mixed mode
assembly? will VS2005 support this kind of functionality?

Bellow is a fragmet of the mixed mode ( unmanaged ) assembly I have
created:
namespace Unmanaged
{
__nogc interface IBlockAllocator;
__nogc interface IDataBlock
{
virtual HRESULT Initialize(IBlockAllocator *pAlloc, const DWORD dwSize,
void *pExArg) = 0;
virtual IBlockAllocator *Allocator()= 0;
virtual BYTE *Pointer()= 0;
virtual const DWORD Size()= 0;
virtual LONG AddRef() =0;
virtual LONG Release()= 0;
virtual void Dispose()= 0;
};

__nogc class CDataBlock : public IDataBlock
{
protected:
DWORD m_dwSize;
LONG m_lRefCount;
BYTE *m_pData;
IBlockAllocator *m_pAlloc;
public:
IBlockAllocator *Allocator() { return m_pAlloc;}
BYTE *Pointer() { return m_pData;}
const DWORD Size() { return m_dwSize;}
LONG AddRef() { return InterlockedIncrement(&m_lRefCount); }
LONG Release()
{
if(0 != InterlockedDecrement(&m_lRefCount))
return m_lRefCount;
m_pAlloc->ReturnToCache(this);
return 0;
}
void Dispose() { delete this; }
HRESULT Initialize(IBlockAllocator *pAlloc, const DWORD dwSize, void
*pExArg = 0)
{
m_pAlloc = pAlloc;
m_dwSize = m_pAlloc->GetBlockSize();
m_pData = new BYTE[m_dwSize];
};
CDataBlock() : m_lRefCount(0)
{
}
~CDataBlock()
{
delete m_pData;
m_pData = 0;
m_pAlloc = 0;
}
};
};// Unmanaged

Nadav
http://www.ddevel.com
Click to expand...
Click to expand...
 
Hi Ronald, Thanks for your response, Still, I have some open issues:
1. Is it possible to define an unmanaged class ( not static ) and expose it using CLI in a way that it would be able to be accessed from managed and unmanaged code? ( i didn't find any in the current VS version and in VS2005.Beta ), My alternative is to use COM which I would really like to avoid...
2. I Did several performance tests with VS2005.Beta, unmanaged C++ if far more efficient then C#, one of the tests I have done involved mixed mode C++ ( using VS2005 ), I have wrapped my (efficient) unmanaged project with a managed wrapper, running this project result performance of about 90% of the original unmanaged project, note that the managed code used merely as an entry point to execute the unmanaged code ( e.g. MyObj->RunUnmanaged() ), why does performance is lost? it seems that loading the CLR it-self causes a performance loss...
2.1. Some words of the test application: it is a winsock app that use IOCompletion port for async IO.

P.S.
How do the guys in Microsoft treat this kind of problems? What language is used for performance critical modules ( I guess it is unmanaged C++ ) that should interact with managed assemblies? What would be the best way of implementing a performance critical module ( CLI, COM, ... ) that should interact with managed code ?

Nadav
http://www.ddevel.com

Ronald Laeremans said:
Create your methods as static members of a __value or __gc class. Then you
will be able to access them for the managed side.

Ronald Laeremans
Visual C++ team

Nadav said:
Hi,

I am writing a performence critical application, this require me to stick
to unmanaged C++ as performance is much better using unmanaged C++ ( about
33% better ), Still, I am trying to avoid the usage of old style COM, my
alternative is to expose my unmanaged interface through the CLI, to
achieve that I have created a mixed mode DLL in which my unmanaged class
are defined.
When referencing the DLL just described in another mixed mode EXE I can
see the unmanaged methods through the 'Object browser' BUT, I can't
reference them through code, the namespace of the DLL is not
recognised....
When using a managed C# EXE to reference the unmanaged CLI assembly the
namespace is identified BUT the contained objects are not...
Is it possible to expose unmanaged interface through the CLI??? is it
possible to reference this type of interface through another mixed mode
assembly? will VS2005 support this kind of functionality?

Bellow is a fragmet of the mixed mode ( unmanaged ) assembly I have
created:
namespace Unmanaged
{
__nogc interface IBlockAllocator;
__nogc interface IDataBlock
{
virtual HRESULT Initialize(IBlockAllocator *pAlloc, const DWORD dwSize,
void *pExArg) = 0;
virtual IBlockAllocator *Allocator()= 0;
virtual BYTE *Pointer()= 0;
virtual const DWORD Size()= 0;
virtual LONG AddRef() =0;
virtual LONG Release()= 0;
virtual void Dispose()= 0;
};

__nogc class CDataBlock : public IDataBlock
{
protected:
DWORD m_dwSize;
LONG m_lRefCount;
BYTE *m_pData;
IBlockAllocator *m_pAlloc;
public:
IBlockAllocator *Allocator() { return m_pAlloc;}
BYTE *Pointer() { return m_pData;}
const DWORD Size() { return m_dwSize;}
LONG AddRef() { return InterlockedIncrement(&m_lRefCount); }
LONG Release()
{
if(0 != InterlockedDecrement(&m_lRefCount))
return m_lRefCount;
m_pAlloc->ReturnToCache(this);
return 0;
}
void Dispose() { delete this; }
HRESULT Initialize(IBlockAllocator *pAlloc, const DWORD dwSize, void
*pExArg = 0)
{
m_pAlloc = pAlloc;
m_dwSize = m_pAlloc->GetBlockSize();
m_pData = new BYTE[m_dwSize];
};
CDataBlock() : m_lRefCount(0)
{
}
~CDataBlock()
{
delete m_pData;
m_pData = 0;
m_pAlloc = 0;
}
};
};// Unmanaged

Nadav
http://www.ddevel.com
Click to expand...
Click to expand...
 
Hi Ronald, Thanks for your response, Still, I have some open issues:
1. Is it possible to define an unmanaged class ( not static ) and expose it using CLI in a way that it would be able to be accessed from managed and unmanaged code? ( i didn't find any in the current VS version and in VS2005.Beta ), My alternative is to use COM which I would really like to avoid...
2. I Did several performance tests with VS2005.Beta, unmanaged C++ if far more efficient then C#, one of the tests I have done involved mixed mode C++ ( using VS2005 ), I have wrapped my (efficient) unmanaged project with a managed wrapper, running this project result performance of about 90% of the original unmanaged project, note that the managed code used merely as an entry point to execute the unmanaged code ( e.g. MyObj->RunUnmanaged() ), why does performance is lost? it seems that loading the CLR it-self causes a performance loss...
2.1. Some words of the test application: it is a winsock app that use IOCompletion port for async IO.

P.S.
How do the guys in Microsoft treat this kind of problems? What language is used for performance critical modules ( I guess it is unmanaged C++ ) that should interact with managed assemblies? What would be the best way of implementing a performance critical module ( CLI, COM, ... ) that should interact with managed code ?

Nadav
http://www.ddevel.com
 
Hi Ronald, Thanks for your response, Still, I have some open issues:
1. Is it possible to define an unmanaged class ( not static ) and expose it using CLI in a way that it would be able to be accessed from managed and unmanaged code? ( i didn't find any in the current VS version and in VS2005.Beta ), My alternative is to use COM which I would really like to avoid...
2. I Did several performance tests with VS2005.Beta, unmanaged C++ if far more efficient then C#, one of the tests I have done involved mixed mode C++ ( using VS2005 ), I have wrapped my (efficient) unmanaged project with a managed wrapper, running this project result performance of about 90% of the original unmanaged project, note that the managed code used merely as an entry point to execute the unmanaged code ( e.g. MyObj->RunUnmanaged() ), why does performance is lost? it seems that loading the CLR it-self causes a performance loss...
2.1. Some words of the test application: it is a winsock app that use IOCompletion port for async IO.

P.S.
How do the guys in Microsoft treat this kind of problems? What language is used for performance critical modules ( I guess it is unmanaged C++ ) that should interact with managed assemblies? What would be the best way of implementing a performance critical module ( CLI, COM, ... ) that should interact with managed code ?

Nadav
http://www.ddevel.com
 
inline.

Nadav said:
Hi Ronald, Thanks for your response, Still, I have some open issues:
1. Is it possible to define an unmanaged class ( not static ) and expose
it using CLI in a way that it would be able to be accessed from managed
and unmanaged code? ( i didn't find any in the current VS version and in
VS2005.Beta ), My alternative is to use COM which I would really like to
avoid...
Click to expand...
No, it isn't in a practical sense of the word. I am not sure why you want to
avoid using a managed class though. That is a far superior mechanism to COM
in any way I could think of. AT least in the aspects of performance,
maintainability and ease of development.
2. I Did several performance tests with VS2005.Beta, unmanaged C++ if far
more efficient then C#, one of the tests I have done involved mixed mode
C++ ( using VS2005 ), I have wrapped my (efficient) unmanaged project with
a managed wrapper, running this project result performance of about 90% of
the original unmanaged project, note that the managed code used merely as
an entry point to execute the unmanaged code ( e.g.
MyObj->RunUnmanaged() ), why does performance is lost? it seems that
loading the CLR it-self causes a performance loss...
Click to expand...
If your API is very chatty (e.g. method executions only take a few to a few
hundreds of instructions) then the interop overhead could explain this. If
you are measuring only a very small timeframe and your measurement includes
startup (rather that steady state performance) that could indeed be an
explanation. If it is neither, I fear that only using a decent profiler will
get you closer to understanding where you are losing the 10% in performance.
2.1. Some words of the test application: it is a winsock app that use
IOCompletion port for async IO.

P.S.
How do the guys in Microsoft treat this kind of problems? What language is
used for performance critical modules ( I guess it is unmanaged C++ ) that
should interact with managed assemblies? What would be the best way of
implementing a performance critical module ( CLI, COM, ... ) that should
interact with managed code ?
Click to expand...
Internally the guidelines are to use C++ and not COM interop. COM interop is
used internally only to intercat with existing COM objects. We never create
new COM interfaces just to be able to use COM interop as the interaction
point.

Nadav
http://www.ddevel.com

Ronald Laeremans said:
Create your methods as static members of a __value or __gc class. Then
you
will be able to access them for the managed side.

Ronald Laeremans
Visual C++ team

Nadav said:
Hi,

I am writing a performence critical application, this require me to
stick
to unmanaged C++ as performance is much better using unmanaged C++ (
about
33% better ), Still, I am trying to avoid the usage of old style COM,
my
alternative is to expose my unmanaged interface through the CLI, to
achieve that I have created a mixed mode DLL in which my unmanaged
class
are defined.
When referencing the DLL just described in another mixed mode EXE I can
see the unmanaged methods through the 'Object browser' BUT, I can't
reference them through code, the namespace of the DLL is not
recognised....
When using a managed C# EXE to reference the unmanaged CLI assembly the
namespace is identified BUT the contained objects are not...
Is it possible to expose unmanaged interface through the CLI??? is it
possible to reference this type of interface through another mixed mode
assembly? will VS2005 support this kind of functionality?

Bellow is a fragmet of the mixed mode ( unmanaged ) assembly I have
created:
namespace Unmanaged
{
__nogc interface IBlockAllocator;
__nogc interface IDataBlock
{
virtual HRESULT Initialize(IBlockAllocator *pAlloc, const DWORD
dwSize,
void *pExArg) = 0;
virtual IBlockAllocator *Allocator()= 0;
virtual BYTE *Pointer()= 0;
virtual const DWORD Size()= 0;
virtual LONG AddRef() =0;
virtual LONG Release()= 0;
virtual void Dispose()= 0;
};

__nogc class CDataBlock : public IDataBlock
{
protected:
DWORD m_dwSize;
LONG m_lRefCount;
BYTE *m_pData;
IBlockAllocator *m_pAlloc;
public:
IBlockAllocator *Allocator() { return m_pAlloc;}
BYTE *Pointer() { return m_pData;}
const DWORD Size() { return m_dwSize;}
LONG AddRef() { return InterlockedIncrement(&m_lRefCount); }
LONG Release()
{
if(0 != InterlockedDecrement(&m_lRefCount))
return m_lRefCount;
m_pAlloc->ReturnToCache(this);
return 0;
}
void Dispose() { delete this; }
HRESULT Initialize(IBlockAllocator *pAlloc, const DWORD dwSize, void
*pExArg = 0)
{
m_pAlloc = pAlloc;
m_dwSize = m_pAlloc->GetBlockSize();
m_pData = new BYTE[m_dwSize];
};
CDataBlock() : m_lRefCount(0)
{
}
~CDataBlock()
{
delete m_pData;
m_pData = 0;
m_pAlloc = 0;
}
};
};// Unmanaged

Nadav
http://www.ddevel.com
Click to expand...
Click to expand...
Click to expand...
 
Hi Ronald, Thanks for your detailed responce, I would just like to clarify a thing: in youre responce you ve saied: "Internally the guidelines are to use C++ and not COM interop..." by saying 'the guidelines are to use C++' do you reffer to mixed mode C++? what is the guidlines for exposing an unmanaged code to a managed code?

Nadav
http://www.ddevel.com


Ronald Laeremans said:
inline.

Nadav said:
Hi Ronald, Thanks for your response, Still, I have some open issues:
1. Is it possible to define an unmanaged class ( not static ) and expose
it using CLI in a way that it would be able to be accessed from managed
and unmanaged code? ( i didn't find any in the current VS version and in
VS2005.Beta ), My alternative is to use COM which I would really like to
avoid...
Click to expand...
No, it isn't in a practical sense of the word. I am not sure why you want to
avoid using a managed class though. That is a far superior mechanism to COM
in any way I could think of. AT least in the aspects of performance,
maintainability and ease of development.
2. I Did several performance tests with VS2005.Beta, unmanaged C++ if far
more efficient then C#, one of the tests I have done involved mixed mode
C++ ( using VS2005 ), I have wrapped my (efficient) unmanaged project with
a managed wrapper, running this project result performance of about 90% of
the original unmanaged project, note that the managed code used merely as
an entry point to execute the unmanaged code ( e.g.
MyObj->RunUnmanaged() ), why does performance is lost? it seems that
loading the CLR it-self causes a performance loss...
Click to expand...
If your API is very chatty (e.g. method executions only take a few to a few
hundreds of instructions) then the interop overhead could explain this. If
you are measuring only a very small timeframe and your measurement includes
startup (rather that steady state performance) that could indeed be an
explanation. If it is neither, I fear that only using a decent profiler will
get you closer to understanding where you are losing the 10% in performance.
2.1. Some words of the test application: it is a winsock app that use
IOCompletion port for async IO.

P.S.
How do the guys in Microsoft treat this kind of problems? What language is
used for performance critical modules ( I guess it is unmanaged C++ ) that
should interact with managed assemblies? What would be the best way of
implementing a performance critical module ( CLI, COM, ... ) that should
interact with managed code ?
Click to expand...
Internally the guidelines are to use C++ and not COM interop. COM interop is
used internally only to intercat with existing COM objects. We never create
new COM interfaces just to be able to use COM interop as the interaction
point.

Nadav
http://www.ddevel.com

Ronald Laeremans said:
Create your methods as static members of a __value or __gc class. Then
you
will be able to access them for the managed side.

Ronald Laeremans
Visual C++ team

Hi,

I am writing a performence critical application, this require me to
stick
to unmanaged C++ as performance is much better using unmanaged C++ (
about
33% better ), Still, I am trying to avoid the usage of old style COM,
my
alternative is to expose my unmanaged interface through the CLI, to
achieve that I have created a mixed mode DLL in which my unmanaged
class
are defined.
When referencing the DLL just described in another mixed mode EXE I can
see the unmanaged methods through the 'Object browser' BUT, I can't
reference them through code, the namespace of the DLL is not
recognised....
When using a managed C# EXE to reference the unmanaged CLI assembly the
namespace is identified BUT the contained objects are not...
Is it possible to expose unmanaged interface through the CLI??? is it
possible to reference this type of interface through another mixed mode
assembly? will VS2005 support this kind of functionality?

Bellow is a fragmet of the mixed mode ( unmanaged ) assembly I have
created:
namespace Unmanaged
{
__nogc interface IBlockAllocator;
__nogc interface IDataBlock
{
virtual HRESULT Initialize(IBlockAllocator *pAlloc, const DWORD
dwSize,
void *pExArg) = 0;
virtual IBlockAllocator *Allocator()= 0;
virtual BYTE *Pointer()= 0;
virtual const DWORD Size()= 0;
virtual LONG AddRef() =0;
virtual LONG Release()= 0;
virtual void Dispose()= 0;
};

__nogc class CDataBlock : public IDataBlock
{
protected:
DWORD m_dwSize;
LONG m_lRefCount;
BYTE *m_pData;
IBlockAllocator *m_pAlloc;
public:
IBlockAllocator *Allocator() { return m_pAlloc;}
BYTE *Pointer() { return m_pData;}
const DWORD Size() { return m_dwSize;}
LONG AddRef() { return InterlockedIncrement(&m_lRefCount); }
LONG Release()
{
if(0 != InterlockedDecrement(&m_lRefCount))
return m_lRefCount;
m_pAlloc->ReturnToCache(this);
return 0;
}
void Dispose() { delete this; }
HRESULT Initialize(IBlockAllocator *pAlloc, const DWORD dwSize, void
*pExArg = 0)
{
m_pAlloc = pAlloc;
m_dwSize = m_pAlloc->GetBlockSize();
m_pData = new BYTE[m_dwSize];
};
CDataBlock() : m_lRefCount(0)
{
}
~CDataBlock()
{
delete m_pData;
m_pData = 0;
m_pAlloc = 0;
}
};
};// Unmanaged

Nadav
http://www.ddevel.com
Click to expand...
Click to expand...
Click to expand...
 
Hi Nadav,

The 2 preferred mechanisms are:
1) In general use C++ with its IJW mechanism to write a translation/warpping
layer, or to write a thick implementation for a managed API that eventually
calls down to the ative API.
2) In case the native API a) has a very simple interface (mostly built in
types, not structures of pointers to variable length lists of structure or
some ilk) and b) is stable (not under active development) and c) is a C API
or COM API and not a C++ API and d) you are writing more than a thin
wrapper, alternatively use C#/VB with DLLImport statements to write the
managed API.

In general the bulk of the unmanaged code will stay compiled native although
there are probably going to several cases where a majority does get compiled
to IL.

Ronald

Nadav said:
Hi Ronald, Thanks for your detailed responce, I would just like to clarify
a thing: in youre responce you ve saied: "Internally the guidelines are to
use C++ and not COM interop..." by saying 'the guidelines are to use C++'
do you reffer to mixed mode C++? what is the guidlines for exposing an
unmanaged code to a managed code?

Nadav
http://www.ddevel.com


Ronald Laeremans said:
inline.

Nadav said:
Hi Ronald, Thanks for your response, Still, I have some open issues:
1. Is it possible to define an unmanaged class ( not static ) and
expose
it using CLI in a way that it would be able to be accessed from managed
and unmanaged code? ( i didn't find any in the current VS version and
in
VS2005.Beta ), My alternative is to use COM which I would really like
to
avoid...
Click to expand...
No, it isn't in a practical sense of the word. I am not sure why you want
to
avoid using a managed class though. That is a far superior mechanism to
COM
in any way I could think of. AT least in the aspects of performance,
maintainability and ease of development.
2. I Did several performance tests with VS2005.Beta, unmanaged C++ if
far
more efficient then C#, one of the tests I have done involved mixed
mode
C++ ( using VS2005 ), I have wrapped my (efficient) unmanaged project
with
a managed wrapper, running this project result performance of about 90%
of
the original unmanaged project, note that the managed code used merely
as
an entry point to execute the unmanaged code ( e.g.
MyObj->RunUnmanaged() ), why does performance is lost? it seems that
loading the CLR it-self causes a performance loss...
Click to expand...
If your API is very chatty (e.g. method executions only take a few to a
few
hundreds of instructions) then the interop overhead could explain this.
If
you are measuring only a very small timeframe and your measurement
includes
startup (rather that steady state performance) that could indeed be an
explanation. If it is neither, I fear that only using a decent profiler
will
get you closer to understanding where you are losing the 10% in
performance.
2.1. Some words of the test application: it is a winsock app that use
IOCompletion port for async IO.

P.S.
How do the guys in Microsoft treat this kind of problems? What language
is
used for performance critical modules ( I guess it is unmanaged C++ )
that
should interact with managed assemblies? What would be the best way of
implementing a performance critical module ( CLI, COM, ... ) that
should
interact with managed code ?
Click to expand...
Internally the guidelines are to use C++ and not COM interop. COM interop
is
used internally only to intercat with existing COM objects. We never
create
new COM interfaces just to be able to use COM interop as the interaction
point.

Nadav
http://www.ddevel.com

:

Create your methods as static members of a __value or __gc class. Then
you
will be able to access them for the managed side.

Ronald Laeremans
Visual C++ team

Hi,

I am writing a performence critical application, this require me to
stick
to unmanaged C++ as performance is much better using unmanaged C++ (
about
33% better ), Still, I am trying to avoid the usage of old style
COM,
my
alternative is to expose my unmanaged interface through the CLI, to
achieve that I have created a mixed mode DLL in which my unmanaged
class
are defined.
When referencing the DLL just described in another mixed mode EXE I
can
see the unmanaged methods through the 'Object browser' BUT, I can't
reference them through code, the namespace of the DLL is not
recognised....
When using a managed C# EXE to reference the unmanaged CLI assembly
the
namespace is identified BUT the contained objects are not...
Is it possible to expose unmanaged interface through the CLI??? is
it
possible to reference this type of interface through another mixed
mode
assembly? will VS2005 support this kind of functionality?

Bellow is a fragmet of the mixed mode ( unmanaged ) assembly I have
created:
namespace Unmanaged
{
__nogc interface IBlockAllocator;
__nogc interface IDataBlock
{
virtual HRESULT Initialize(IBlockAllocator *pAlloc, const DWORD
dwSize,
void *pExArg) = 0;
virtual IBlockAllocator *Allocator()= 0;
virtual BYTE *Pointer()= 0;
virtual const DWORD Size()= 0;
virtual LONG AddRef() =0;
virtual LONG Release()= 0;
virtual void Dispose()= 0;
};

__nogc class CDataBlock : public IDataBlock
{
protected:
DWORD m_dwSize;
LONG m_lRefCount;
BYTE *m_pData;
IBlockAllocator *m_pAlloc;
public:
IBlockAllocator *Allocator() { return m_pAlloc;}
BYTE *Pointer() { return m_pData;}
const DWORD Size() { return m_dwSize;}
LONG AddRef() { return InterlockedIncrement(&m_lRefCount); }
LONG Release()
{
if(0 != InterlockedDecrement(&m_lRefCount))
return m_lRefCount;
m_pAlloc->ReturnToCache(this);
return 0;
}
void Dispose() { delete this; }
HRESULT Initialize(IBlockAllocator *pAlloc, const DWORD dwSize,
void
*pExArg = 0)
{
m_pAlloc = pAlloc;
m_dwSize = m_pAlloc->GetBlockSize();
m_pData = new BYTE[m_dwSize];
};
CDataBlock() : m_lRefCount(0)
{
}
~CDataBlock()
{
delete m_pData;
m_pData = 0;
m_pAlloc = 0;
}
};
};// Unmanaged

Nadav
http://www.ddevel.com
Click to expand...
Click to expand...
Click to expand...
 
Back
Top