I use Microsoft Visual C++ 2010 and Windows 7.
I have the DataDecoder class to decode some data. Here it is:
template< typename T >
class DataDecoder
{
private:
T lpData;
public:
DataDecoder() { lpData = NULL; }
DataDecoder( T lpSource ) { lpData = (T)DecodeStaticData(lpSource); }
~DataDecoder() { if(lpData) free(lpData); }
operator T() { return lpData; }
};
This class works perfectly. Also I have this macro:
#define _STR_A(x) DataDecoder<char*>(x)
It works perfectly too. But there is another construction in my code:
LPVOID lpAdditionalData = NULL;
LPSTR lpTemp = lpAdditionalData ? _STR_A("SOMEDATA") : NULL;
At this point weird things begin to happen. First of all I get NULL parameter in my DecodeStaticData(). But it could not be true: _STR_A() applies to valid parameter only. Then I decided to look at disassembly:
0011843A cmp dword ptr [lpAdditionalData],0
00118441 je WinMain+172h (118462h)
00118443 push offset string "SOMEDATA" (124068h)
00118448 lea ecx,[ebp-0C2Ch]
0011844E call DataDecoder<char *>::DataDecoder<char *> (117770h)
00118453 or dword ptr [ebp-0C14h],1
0011845A mov dword ptr [ebp-0C34h],eax
00118460 jmp WinMain+18Ch (11847Ch)
00118462 push 0
00118464 lea ecx,[ebp-0C28h]
0011846A call DataDecoder<char *>::DataDecoder<char *> (117770h)
As you can see, class constructor is called in BOTH cases, for "SOMEDATA" and for NULL too!
Is it correct behavior? How can I deal with this?
UPDATE: I turned on preprocessing to file and this is what I see:
LPSTR lpTemp = lpAdditionalData ? DataDecoder<char*>("SOMEDATA") : 0;
So, it is not preprocessor problem.
Like any expression, one involving a conditional operator must have a type. An expression c ? a : b can't magically have a type that changes at run-time depending on the value of c - the type of a sometimes, the type of b other times. Instead, if a and b are of different types, there are complicated rules that determine the final type of the overall expression, by trying to coerce one to the type of the other.
In your case, DataDecoder<char*>(x) can't be coerced to the type of NULL, but NULL can be coerced to DataDecoder<char*>, by way of a user-defined conversion DataDecoder<char*>(NULL). This is what you observe.
Related
TL;DR : Should we use fn(Interface* pMaybeNull) or fn(Interface& maybeNullObject) -- specifically in the case of "optional" function arguments of a virtual/abstract base class?
Our code base contains various forms of the following pattern:
struct CallbackBase {
virtual ~CallbackBase() = default;
virtual void Hello(/*omitted ...*/) = 0;
};
...
void DoTheThing(..., CallbackBase* pOpt) {
...
if (pOpt) { pOpt->Hello(...); }
}
where the usage site would look like:
... {
auto greet = ...;
...
DoTheThing(..., &greet);
// or if no callback is required from call site:
DoTheThing(..., nullptr);
}
It has been proposed that, going forward, we should use a form of the Null-Object-Pattern. like so:
struct NoopCall : public CallbackBase {
virtual void Hello(/*omitted ...*/) { /*noop*/ }
};
void DoTheThing2(..., CallbackBase& opt) {
...
opt.Hello(...);
}
... {
NoopCall noop;
// if no callback is required from call site:
DoTheThing2(..., noop);
}
Note: Search variations yield lots of results regarding Null-Object (many not in the C++ space), a lot of very basic treatment of pointer vs. references and if you include the word "optional", as-in the parameter is optional, you obviously get a lot of hits regarding std::optional which, afaik, is unsuitable for this virtual interface use case.
I couldn't find a decent comparison of the two variants present here, so here goes:
Given C++17/C++20 and a halfway modern compiler, is there any expected difference in the runtime characteristics of the two approaches? (this factor being just a corollary to the overall design choice.)
The "Null Object" approach certainly "seems" more modern and safer to me -- is there anything in favor of the pointer approach?
Note:
I think it is orthogonal to the question posed, whether it stands as posted, or uses a variant of overloading or default arguments.
That is, the question should be valid, regardless of:
//a
void DoTheThing(arg);
// vs b
void DoTheThing(arg=nullthing);
// vs c
void DoTheThing(arg); // overload1
void DoTheThing(); // overload0 (calling 1 internally)
Performance:
I inspected the code on godbolt and while MSVC shows "the obvious", the gcc output is interesting (see below).
// Gist for a MCVE.
"The obvious" is that the version with the Noop object contains an unconditional virtual call to Hello and the pointer version has an additional pointer test, eliding the call if the pointer is null.
So, if the function is "always" called with a valid callback, the pointer version is a pessimization, paying an additional null check.
If the function is "never" called with a valid callback, the NullObject version is a (worse) pessimization, paying a virtual call that does nothing.
However, the object version in the gcc code contains this:
WithObject(int, CallbackBase&):
...
mov rax, QWORD PTR [rsi]
...
mov rax, QWORD PTR [rax+16]
(!) cmp rax, OFFSET FLAT:NoopCaller::Hello(HelloData const&)
jne .L31
.L25:
...
.L31:
mov rdi, rsi
mov rsi, rsp
call rax
jmp .L25
And while my understanding of assembly is certainly near non existent, this looks like gcc is comparing the call pointer to the NoopCaller::Hello function, and eliding the call in this case!
Conclusion
In general, the pointer version should produce more optimal code on the micro-level. However, compiler optimizations might make any difference near non-observable.
Think about using the pointer version if you have a very hot path where the callback is null.
Use the null object version otherwise, as it is arguably safer and more maintainable.
I have a callback function (ouside my class) which i'm passing a BassMusicPlayer class object as parameter. If do a breakpoint inside it, i can see all the variables and methods in 'self'.
If i try to read/print those values, it won't compile and will give error C2027: use of undefined type 'BassMusicPlayer'. I also added static to the class definition as suggested by others. I could use global variables as a workaround but i really want to avoid doing that.
This is what i have in my class file:
class BassMusicPlayer;
void __stdcall LoopSyncProc(HSYNC handle, DWORD channel, DWORD data, void *user) {
BassMusicPlayer * self = reinterpret_cast<BassMusicPlayer*>(user);
//printf("%d\n", self->loop_start);
//if (!BASS_ChannelSetPosition(channel, self->loop_start, BASS_POS_BYTE))
if (!BASS_ChannelSetPosition(channel, 0, BASS_POS_BYTE)) // try seeking to loop start
BASS_ChannelSetPosition(channel, 0, BASS_POS_BYTE); // failed, go to start of file instead
}
class BassMusicPlayer {
private:
std::string m_filename;
int m_filetype;
int m_music_handle;
BassMusicPlayer* m_music;
HWND m_handle;
DWORD m_sample_rate;
SYNCPROC* m_callback_proc;
public:
QWORD loop_start, loop_end;
// constructor
BassMusicPlayer(HWND handle, DWORD sample_rate, SYNCPROC* callback_proc) {
m_handle = handle;
m_sample_rate = sample_rate;
m_callback_proc = LoopSyncProc;
}
bool OpenMusicFile(std::string filename, QWORD seek_start, QWORD file_length, bool start_playing, bool loop, QWORD loopstart, QWORD loopend) {
loop_start = loopstart;
loop_end = loopend;
m_music_handle = BASS_MusicLoad(false, filename.c_str(), 0, 0, BASS_MUSIC_POSRESET, m_sample_rate);
BASS_ChannelSetSync(m_music_handle, BASS_SYNC_END | BASS_SYNC_MIXTIME, 0, m_callback_proc, this);
}
};
Why is my BassMusicPlayer class not being recognized only when i want to access its variables?
Your BassMusicPlayer cannot be recognized because you have this:
class BassMusicPlayer;
This is called a forward declaration. It tells the compiler that the class BassMusicPlayer exists, but it doesn't tell it what that class is, how much space its objects require, or what members it has. Because pointers are just integers and it doesn't matter what they point to until you try to do something with them, the compiler can use pointers just fine, but the moment you attempt to dereference one of them (such as by accessing its functions or variables with the -> operator), the compiler fails because it doesn't know how to do this. It doesn't find out until the class is actually declared later, after your callback.
To fix this, move your callback to after the declaration of the class. Because you have to know about the function in your class, you should forward declare the function instead, like this:
void __stdcall LoopSyncProc(HSYNC handle, DWORD channel, DWORD data, void *user);
The overall order of your code should be:
Forward declare the LoopSyncProc function
Declare the class
Define the LoopSyncProc function
At that point in your code where you define LoopSyncProc, you have merely declared BassMusicPlayer. You've told the compiler: "there exists a class called BassMusicPlayer", nothing more.
You can take a pointer to a forward-declared class, but you can't access the object itself - at that point the compiler doesn't know anything about the object's class, or how to access it.
You need to move LoopSyncProc below BassMusicPlayer. For that to work, you need to forward-declare LoopSyncProc:
void __stdcall LoopSyncProc(HSYNC handle, DWORD channel, DWORD data, void *user);
class BassMusicPlayer {
...
};
void __stdcall LoopSyncProc(HSYNC handle, DWORD channel, DWORD data, void *user) {
BassMusicPlayer * self = reinterpret_cast<BassMusicPlayer*>(user);
//printf("%d\n", self->loop_start);
//if (!BASS_ChannelSetPosition(channel, self->loop_start, BASS_POS_BYTE))
if (!BASS_ChannelSetPosition(channel, 0, BASS_POS_BYTE)) // try seeking to loop start
BASS_ChannelSetPosition(channel, 0, BASS_POS_BYTE); // failed, go to start of file instead
}
The problem is that at the point of compilation of that function, the type is not fully defined. The bare declaration (class BassMusicPlayer;) is not a full definition.
The solution is to move the function definition so that the whole class definition is already in scope.
There is a macro written in VBA, that I'd like to call from C++:
Public Function MacroName() As DOMDocument
I'm doing it like this:
_variant_t ret = d_pApp->Run(_bstr_t("MacroName")).bstrVal;
Now, I'd like to cast this ret to IXMLDOMDocumentPtr...
IXMLDOMDocumentPtr d_plDomDocument;
d_plDomDocument = static_cast<IXMLDOMDocumentPtr>(ret);
Well, that doesn't work. The error says, that the type is wrong.
What is the proper way to cast then?
Your error is here:
_variant_t ret = d_pApp->Run(_bstr_t("MacroName"))>>>>>.bstrVal;<<<<
It should be:
_variant_t ret = d_pApp->Run(_bstr_t("MacroName"));
Once you do that you may find that your static_cast works - I cannot remember offhand. Otherwise, you can use the following method.
First ret.ChangeType(VT_UNKNOWN) then if that succeeds then use d_plDomDocument = ret.punkVal;. This will do a QueryInterface under the hood.
Or in a single step:
d_plDomDocument = IXMLDOMDocumentPtr(ret);
This will return a NULL _com_ptr_t if the variant cannot be converted to an object.
Hello and good day to you.
Situation:
For some reason, from time to time I run into situation when I need to override one or two methods of a COM interface (that is being used for some older application without source code), which is normally Direct3D/DirectInput related (i.e. it is created by calling a DLL method, not by CoCreateInstance). Normally I deal with situation by writing a proxy DLL that overrides a method that creates interface I need to "modify", and replace original interface with my own. Normally this is required to make some older application work properly without crashing/artifacts.
Compiler:
I use Visual Studio express 2008 on windows machine, so there are no C++0x features. The system has msysgit, msys, python, perl, gnu utilities (awk/sed/wc/bash/etc), gnu make and qmake (Qt-4.7.1) installed (and available within PATH).
Problem:
Overriding one method of a COM interface is a pain (especially if original interface has a hundred of methods or so), because I need to forward many calls to original interface, and currently I see no way to simplify or automate the process. For example, override of IDirect3D9 looks like this:
class MyD3D9: public IDirect3D9{
protected:
volatile LONG refCount;
IDirect3D9 *orig;
public:
STDMETHOD(QueryInterface)(THIS_ REFIID riid, LPVOID * ppvObj){
if (!ppvObj)
return E_INVALIDARG;
*ppvObj = NULL;
if (riid == IID_IUnknown || riid == IID_IDirect3D9){
*ppvObj = (LPVOID)this;
AddRef();
return NOERROR;
}
return E_NOINTERFACE;
}
STDMETHOD_(ULONG,AddRef)(THIS){
InterlockedIncrement(&refCount);
return refCount;
}
STDMETHOD_(ULONG,Release)(THIS){
ULONG ref = InterlockedDecrement(&refCount);
if (refCount == 0)
delete this;
return ref;
}
/*** IDirect3D9 methods ***/
STDMETHOD(RegisterSoftwareDevice)(THIS_ void* pInitializeFunction){
if (!orig)
return E_FAIL;
return orig->RegisterSoftwareDevice(pInitializeFunction);
}
STDMETHOD_(UINT, GetAdapterCount)(THIS){
if (!orig)
return 0;
return orig->GetAdapterCount();
}
STDMETHOD(GetAdapterIdentifier)(THIS_ UINT Adapter,DWORD Flags, D3DADAPTER_IDENTIFIER9* pIdentifier){
if (!orig)
return E_FAIL;
return orig->GetAdapterIdentifier(Adapter, Flags, pIdentifier);
}
STDMETHOD_(UINT, GetAdapterModeCount)(THIS_ UINT Adapter,D3DFORMAT Format){
if (!orig)
return 0;
return orig->GetAdapterModeCount(Adapter, Format);
}
/* some code skipped*/
MyD3D9(IDirect3D9* origD3D9)
:refCount(1), orig(origD3D9){
}
~MyD3D9(){
if (orig){
orig->Release();
orig = 0;
}
}
};
As you can see, this is very inefficient, error-prone and requires a lot of copy-pasting.
Question:
How can I simplify overriding of a single method of a COM interface in this situation? I would like to specify only method I change, but I currently see no way to do so. I also don't see a way to elegantly shorten "forwarded" methods with macros or templates or macros, because they have variable number of arguments. Another approach I saw is to use directly patch method table returned by another method (modify access right using VirtualProtect, then write into method table), which I don't exactly like.
Limitations:
I would prefer to solve in C++ source code (macros/templates) and without code generators (unless code generator usage is extremely simple/elegant - i.e. writing code generator is not ok, using already available code generator I can set up in minutes and solve the whole thing in one line of code is ok). Boost is okay only if it doesn't add extra DLL dependency. MS-specific compiler directives and language extensions are also ok.
Ideas? Thanks in advance.
Okay, since I don't like unanswered questions...
To implement "COM implementation inheritance" there's currently no sane and compact solution written in pure C++. This is mostly because in C++ it is forbidden to create an instance of abstract class or manipulate virtual method table directly. As a result, there are 2 commonly used solutions:
Write method forwarding for every method manually.
Hack dispatch table.
Advantage of #1 is that this approach is safe and you can store additional data within custom class.
Disadvantage of #1 is that writing a wrapper for every single method is extremely tedious procedure.
Advantage of #2 is that this approach is compact. You replace single method.
Disadvantage of #2 is that dispatch table might be located in write-protected space (most likely it wouldn't happen, but it could happen in theory) and you can't store custom data in hacked interface. As a result, although it is simple/short, it is quite limiting.
And there's a 3rd approach. (which nobody has suggested for some reason)
Short description: instead of using virtual method table provided by C++, write non-virtual class that will emulate virtual method table.
Example:
template<typename T1, typename T2> void unsafeCast(T1 &dst, const T2 &src){
int i[sizeof(dst) == sizeof(src)? 1: -1] = {0};
union{
T2 src;
T1 dst;
}u;
u.src = src;
dst = u.dst;
}
template<int Index> void __declspec(naked) vtblMapper(){
#define pointerSize 4 //adjust for 64bit
static const int methodOffset = sizeof(void*)*Index;
__asm{
mov eax, [esp + pointerSize]
mov eax, [eax + pointerSize]
mov [esp + pointerSize], eax
mov eax, [eax]
add eax, methodOffset
mov eax, [eax]
jmp eax
};
#undef pointerSize
}
struct MyD3DIndexBuffer9{
protected:
VtblMethod* vtbl;
IDirect3DIndexBuffer9* orig;
volatile LONG refCount;
enum{vtblSize = 14};
DWORD flags;
bool dynamic, writeonly;
public:
inline IDirect3DIndexBuffer9*getOriginalPtr(){
return orig;
}
HRESULT __declspec(nothrow) __stdcall QueryInterface(REFIID riid, LPVOID * ppvObj){
if (!ppvObj)
return E_INVALIDARG;
*ppvObj = NULL;
if (riid == IID_IUnknown || riid == IID_IDirect3DIndexBuffer9){
*ppvObj = (LPVOID)this;
AddRef();
return NOERROR;
}
return E_NOINTERFACE;
}
ULONG __declspec(nothrow) __stdcall AddRef(){
InterlockedIncrement(&refCount);
return refCount;
}
ULONG __declspec(nothrow) __stdcall Release(){
ULONG ref = InterlockedDecrement(&refCount);
if (refCount == 0)
delete this;
return ref;
}
MyD3DIndexBuffer9(IDirect3DIndexBuffer9* origIb, DWORD flags_)
:vtbl(0), orig(origIb), refCount(1), flags(flags_), dynamic(false), writeonly(false){
dynamic = (flags & D3DUSAGE_DYNAMIC) != 0;
writeonly = (flags & D3DUSAGE_WRITEONLY) != 0;
vtbl = new VtblMethod[vtblSize];
initVtbl();
}
HRESULT __declspec(nothrow) __stdcall Lock(UINT OffsetToLock, UINT SizeToLock, void** ppbData, DWORD Flags){
if (!orig)
return E_FAIL;
return orig->Lock(OffsetToLock, SizeToLock, ppbData, Flags);
}
~MyD3DIndexBuffer9(){
if (orig){
orig->Release();
orig = 0;
}
delete[] vtbl;
}
private:
void initVtbl(){
int index = 0;
for (int i = 0; i < vtblSize; i++)
vtbl[i] = 0;
#define defaultInit(i) vtbl[i] = &vtblMapper<(i)>; index++
//STDMETHOD(QueryInterface)(THIS_ REFIID riid, void** ppvObj) PURE;
unsafeCast(vtbl[0], &MyD3DIndexBuffer9::QueryInterface); index++;
//STDMETHOD_(ULONG,AddRef)(THIS) PURE;
unsafeCast(vtbl[1], &MyD3DIndexBuffer9::AddRef); index++;
//STDMETHOD_(ULONG,Release)(THIS) PURE;
unsafeCast(vtbl[2], &MyD3DIndexBuffer9::Release); index++;
// IDirect3DResource9 methods
//STDMETHOD(GetDevice)(THIS_ IDirect3DDevice9** ppDevice) PURE;
defaultInit(3);
//STDMETHOD(SetPrivateData)(THIS_ REFGUID refguid,CONST void* pData,DWORD SizeOfData,DWORD Flags) PURE;
defaultInit(4);
//STDMETHOD(GetPrivateData)(THIS_ REFGUID refguid,void* pData,DWORD* pSizeOfData) PURE;
defaultInit(5);
//STDMETHOD(FreePrivateData)(THIS_ REFGUID refguid) PURE;
defaultInit(6);
//STDMETHOD_(DWORD, SetPriority)(THIS_ DWORD PriorityNew) PURE;
defaultInit(7);
//STDMETHOD_(DWORD, GetPriority)(THIS) PURE;
defaultInit(8);
//STDMETHOD_(void, PreLoad)(THIS) PURE;
defaultInit(9);
//STDMETHOD_(D3DRESOURCETYPE, GetType)(THIS) PURE;
defaultInit(10);
//STDMETHOD(Lock)(THIS_ UINT OffsetToLock,UINT SizeToLock,void** ppbData,DWORD Flags) PURE;
//defaultInit(11);
unsafeCast(vtbl[11], &MyD3DIndexBuffer9::Lock); index++;
//STDMETHOD(Unlock)(THIS) PURE;
defaultInit(12);
//STDMETHOD(GetDesc)(THIS_ D3DINDEXBUFFER_DESC *pDesc) PURE;
defaultInit(13);
#undef defaultInit
}
};
To swap it with real interface, you'll have to use reinterpret_cast.
MyD3DIndexBuffer9* myIb = reinterpret_cast<MyD3DIndexBuffer9*>(pIndexData);
As you can see this method requires assembly, macros, templates combined together with casting class method pointer to void*. Also it is compiler-dependent(msvc, although you should be able to do same trick with g++) and architecture-dependent (32/64-bit). Plus it is unsafe (as with dispatch table hacking).
The advantage compared to dispatch tables you can use custom class and store additional data within interface. However:
All virtual methods are forbidden. (as far as I know, any attempt to use virtual method will instantly insert invisible 4-bytes pointer at the beginning of the class, which will break everything).
Calling convention must be stdcall (should work with cdecl, though, but for everything else you'll need different wrapper)
You have to initialize entire vtable yourself (very error-prone). One mistake, and everything will crash.
I have a hack program; it injects some functions into a target process to control it. The program is written in C++ with inline assembly.
class GameProcMain {
// this just a class
};
GameProcMain* mainproc; // there is no problem I can do =(GameProcMain*)0xC1EA90
Now I want to define a class function (which set ecx to class pointer) instead of writing assembly.
PPLYDATA GetNearblyMob(__Vector3* cordinate) {
__asm {
mov ecx, 0xC1EA90
enter code here
push cordinate
mov edi, 0x4A8010
call edi
}
}
I want to define it and call it like.
PPLYDATA (DLPL::*GetNearblyMob)(__Vector3* cordinate);
mainproc->GetNearblyMob(ADDR_CHRB->kordinat)
When I try GetNearblyMob=(PPLYDATA (DLPL::*)(__Vector3*)) 0x4A8010;
It says something like error: invalid type conversion: "int" to "PPLYDATA (DLPL::*)(int, int)"
but I can do this to set the pointer:
void initializeHack() {
__asm {
LEA edi, GetNearblyMob
MOV eax, 0x4A8010
MOV [edi], eax
}
}
Now I want to learn "how I can set GetNearblyMob without using assembly and legitimately in C++".
The problem is that member functions automatically get an extra parameter for the this pointer. Sometimes you can cast between member and non-member functions, but I don't see the need to cast anything.
Typically it's easier to reverse-engineer into C functions than into C++. C typically has a more straightforward ABI, so you can keep the data structures straight as you work them out.
So, I would recommend
PPLYDATA (*GetNearblyMob)(DLPL *main_obj, __Vector3* cordinate) = 0x12345UL;
and then define your own function
class DLPL {
GetNearblyMob( __Vector3* cordinate ) {
return ::GetNearblyMob( this, cordinate );
}
// ... other program functions
};
I am a bit surprised that it won't you cast like that.
You can try to do something like
GetNearblyMob=reinterpret_cast<PPLYDATA (DLPL::*)(__Vector3*)> (0x4A8010);
If that still does not work, try
*(int*)(&GetNearblyMob) = 0x4A8010;