How to typedef a memeber function type? thx!
class CCvdVolume
{
public:
typedef NTSTATUS (*QC_M_FUNC)(int Irp);
QC_M_FUNC f_Create;
static NTSTATUS Create(int Irp)
{
return 0;
}
void _Init()
{
f_Create = Create;
}
};
PM
typedef NTSTATUS (CCvdVolume::*QC_M_FUNC)(PIRP Irp);
> QC_M_FUNC f_Create;
> NTSTATUS Create(PIRP Irp)
> {
> return 0;
> }
> void _Init()
> {
> f_Create = Create;
f_Create = &CCvdVolume::Create;
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
Maybe I should use virtual member function instead. but the system must
malloc the heap memory one more time for virtual function list. do you
have a good idea?
"Igor Tandetnik" <itand...@mvps.org> 写入消息
news:eS5obCsL...@TK2MSFTNGP04.phx.gbl...
Not true. There's one vtable per class, not per instance. It is
statically linked into your code. No additional memory needs to be
allocated for it at run-time.
> do you have a good idea?
I have a few, yes. At least I think they are good.
Ah, you are probably not asking about my ideas in general, but
specifically about ideas that would help you solve your problem. No, I
don't have any - for the simple reason that you never described the
problem you are trying to solve.
I try to write a windows WDM driver with c++;
For I don't know the vtable is statically linked, so
I think virtual member function is not a good idea;
and so I think that It is not good that the DeviceExtension
link to a additional memory . then I try to implement
a member function pointer variable to replace virtual
member function.
Maybe It doesn't matter that I use virtual member function.?
below is my Pseudo-code:
////////////Code begin/////////////
__inline void* __cdecl operator new(size_t size)
{
return ExAllocatePoolWithTag(NonPagedPool, size, 'ppck');
}
class CCvdVolume
{
public:
typedef NTSTATUS (*QC_M_FUNC)(int Irp);
QC_M_FUNC f_Create;
static NTSTATUS Create(int Irp)
{
return 0;
}
void _Init()
{
f_Create = Create;
}
CCvdVolume()
{
_Init();
}
};
class CCvdVolFile : public CCvdVolume
{
public:
static NTSTATUS Create(int Irp)
{
return 0;
}
void _Init()
{
f_Create = Create;
}
CCvdVolFile()
{
_Init();
}
};
class CCvdVolxxx : public CCvdVolume
{
public:
static NTSTATUS Create(int Irp)
{
return 0;
}
void _Init()
{
f_Create = Create;
}
CCvdVolxxx()
{
_Init();
}
};
PDEVICE_OBJECT DevObj = NULL;
IoCreateDevice(DrivObj, sizeof(CCvdVolFile), ..., &DevObj);
CCvdVolume* pVolume = new(DevObj->DeviceExtension) CCvdVolFile();
...
pVolume->Creat(Irp);
...
////////////Code end/////////////
"Igor Tandetnik" <itand...@mvps.org> 写入消息
news:u93dqGu...@TK2MSFTNGP03.phx.gbl...
In other words, you are implementing manually exactly what the compiler
would do for you automatically. I suggest you reconsider. Make it run,
make it right, make it fast - in this order.
> Maybe It doesn't matter that I use virtual member function.?
Very likely.
I think whether the v-table is statically linked is not a question nor the
problem.
But whether it is placed in non-pageable RAM is a very important question.
>> and so I think that It is not good that the DeviceExtension
>> link to a additional memory . then I try to implement
>> a member function pointer variable to replace virtual
>> member function.
>
> In other words, you are implementing manually exactly what the
> compiler would do for you automatically. I suggest you reconsider.
> Make it run, make it right, make it fast - in this order.
Pretty sure he is implementing the pattern used by existing driver APIs in
Windows, Linux, etc.
>
>> Maybe It doesn't matter that I use virtual member function.?
>
> Very likely.
Do it the way Windows does.
Of course, the function pointer method allows unlimited hooking. If you
don't need that, then maybe a switch statement would be better. I
understand it's not considered as desirable from a extensibility perspective
but it gives you several advantages: First, all possible paths are
explicitly listed, so static code analysis, whether automated or by hand,
can do a much better job of identifying race conditions, lock inversions,
etc. Next, it's more robust and stable because you aren't as likely to
bring the system down hard if the value is corrupted. You at least get the
chance to perform some validation on your object, notice the wrong branch
was taken, and gracefully stop operation. If a function pointer was
corrupted on the other hand, game over and possible malicious code execution
and privilege escalation.
Do it the way Windows does.
---- Ben Voigt
Thx!
Funfound schrieb:
> I try to write a windows WDM driver with c++;
There is an article about why it is at least dangerous to write device drivers
in C++. You should know very precisely what you are doing:
http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx
Norbert
> Maybe I should use virtual member function instead. but the system must
> malloc the heap memory one more time for virtual function list. do you
> have a good idea?
Haven' looked at your code, but instead of using virtual functions or member
pointers, have a look at the new std::tr1::function and std::tr1::bind (if you
do not have a tr1 compiler you can use the boost implementations). They allow
binding function/member/functors to any function objects that can be used as
simple as plain callbacks.
Norbert
"Funfound" <funf...@hotmail.com> wrote in message
news:#5VsqY$LJHA...@TK2MSFTNGP03.phx.gbl...