|
Member 476468 wrote: Does anyone know how to solve this?
Solve what? 
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
In Visual Studio 2008, what replaces tapi.h?
|
|
|
|
|
Have you looked in the two include folders to see if the file exists, or search the .h files to see if they contain TAPI-related functions?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
Hi,
I have derived class which has 2 base calsses CSyncObject and CSingleLock
Since the input to the CSingeLock is a pointer to a CSyncObject my question is
if I first create the CSyncObject can I reference that object object when executing
the Constructer for the CSingleLock with the "this" pointer
e.g. class mylock() : public CSyncObject(NULL) , public CSingeLock(this->
my question really is am I going down the right path
I would assume the "this" pointer gets initialized after excuting the first
contructer
|
|
|
|
|
ForNow wrote: I would assume the "this" pointer gets initialized after excuting the first contructer
No, you should be OK - this code does 'the right thing':
#include <iostream>
class A
{
public:
A(int x) { x_ = x; }
int x_;
};
class B
{
public:
B(A* a) { std::cout << a->x_ << std::endl; }
};
class C : public A, public B
{
public:
C(int y) : A(y), B(static_cast<A*>(this)) {}
};
int main(int, char**)
{
C c(33);
}
VC++ (unlike gcc) does raise a warning[^] about doing this, but reading the warning description, I don't think it applies in this case.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
It worked
Please explain what is the value of "this" pointer on entrance to B from my undertanding static_cast<a*> is just a cast
????
|
|
|
|
|
ForNow wrote: from my undertanding static_cast<a*> is just a cast
Not in the presence of multiple inheritance - with multiple inheritance, you have two bases whose members you have to contain in your object. That means that for (say) class C : public class A, public class B, you have this layout in memory:
+---------------+
| A members |
+---------------+
| B members |
+---------------+
| C members |
+---------------+
So, to cast a C* to a B*, you will have an offset, equal to the size of A's members.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Hi,
class mylock : public CSyncObject, public CSingleLock
{
public:
mylock(BOOL bInitialLock);
BOOL Unlock();
};
mylock :: mylock(BOOL bInitialLock) : CSyncObject(NULL), CSingleLock(static_cast<CSyncObject*>(this), bInitialLock)
{
bInitialLock = FALSE;
}
Made a breakpoint when I tried to instatiate mylock with following code mylock my_threadlock(init_s);
at mylock the this value was 1feb8 as I steped into CsyncObject it remained 1feb8 when I got to CsingleLock's
contructer this value was bumped to 1FEC0 However m_hObject value was 1FEB8 CsyncObject value
Still have some debugging to do but thankx
this article also elucidates the point you tried to make
http://carcino.gen.nz/tech/cpp/multiple_inheritance_this.php
thankx again
|
|
|
|
|
I disagree with Stuart. The "this" pointer should rarely be used in an initializer list. This is especially apt here since CSyncObject has virtual classes and the virtual table hasn't been set up at this point.
I also think your class is a mistake and misunderstands CSyncObject() and CSingleLock(). The point is that there is one synchronization object with multiple threads locking that object. That locking is done by instantiated CSingleLock() at the start of a scope and upon exit of that scope, CSingleLock will be destructed regardless regardless of how the scope was exited.
Moreover, with your code, what does CSyncObject even represent?
Finally, note that CSyncObject will be destructed before CSingleLock which will attempt to unlock the destructed CSyncObject.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
Joe Woodbury wrote: The "this" pointer should rarely be used in an initializer list.
It all depends whether he actually uses what the this pointer points at in the constructor or just stores it for later use. Storing for later use? Yeah, you'll be OK.
Joe Woodbury wrote: ...the virtual table hasn't been set up at this point.
The vtable will be consistent with the definition of the base class in the base class constructor (see this Scott Meyers article[^] for confirmation).
However, you do need to be very careful and aware of what's happening...which is why I probably shouldn't have said the OP would be OK with using this.
Joe Woodbury wrote: I also think your class is a mistake and misunderstands CSyncObject() and CSingleLock(). The point is that there is one synchronization object with multiple threads locking that object. That locking is done by instantiated CSingleLock() at the start of a scope and upon exit of that scope, CSingleLock will be destructed regardless regardless of how the scope was exited.
Yeah, I wasn't even looking that far 
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
As Far CsingLeObject Being Distructed I can always Create on the Heap as it will exist for the Life time of the app
Since threads are always Coming and going it may not be a bad idea to have to around
|
|
|
|
|
I think you need to redesign a bit your architecture. You first have the problems explained by Joe but it also feels completely wrong: your class IS a CSingleLock object and IS a CSyncObject ? This is akward. I guess you are trying to make something without really understanding what you are doing.
Maybe if you explain what you are trying to do (conceptually I mean, not low level code like here), we could help you design a better solution...
|
|
|
|
|
As far as what Joe Pointed the Csync Object getting destroyed before the Lock Object
the thread is in constant loop while(1) waitting to get signalled so it never ends
What I was trying to do since a CSingleLock needs a CsyncObject pointer make it all part of
one SuperClass
as said my code is a thread waitiing to get signaled when it does I single thread via the Lock
until the code finishes executing
thnakx
|
|
|
|
|
Following Cedric's response (which is quite correct) that your class shouldn't be both a lock and a sync object, here's a further suggestion that avoids both that confusion and the use of this in constructor calls.
Look at this page from Boost[^] describing the 'base-from-member' idiom.
Now, you could re-factor your code as:
struct mylock_pbase
{
mylock_pbase() : syncObject(NULL) {}
CSyncObject syncObject;
};
class mylock : private mylock_pbase, public CSingleLock
{
public:
mylock(BOOL bInitialLock) : mylock_pbase(),
CSingleLock(&syncObject, bInitialLock)
{
}
BOOL Unlock();
};
You could use the boost::base_from_member class, but it would only remove the need to declare mylock_pbase.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
I understand your just mylockphase create a CsyncObject named syncobject
IS there a need for the : syncobject(NULL) wont the CsyncObject get created without it
btw what does the "explicit" qualifer in Font of the CSyncObject signify
|
|
|
|
|
ForNow wrote: syncobject(NULL)
I put that there because you had it in your original post 
ForNow wrote: btw what does the "explicit" qualifer in Font of the CSyncObject signify
That the constructor can't be used (by the compiler) to perform implicit type-casts. It only really matters for single parameter constructors and should probably be used for most single-parameter constructors just to make sure you don't create objects unless you really meant to. Look at the documentation for it[^].
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
modified on Thursday, April 2, 2009 3:33 AM
|
|
|
|
|
|
Hello. I have an application in VC++6.0 with MFC. I use ADO for Read/Write on file *.mdb.
When I link in DEBUG mode is OK.
When I link in RELEASE mode I get this error.
Which *.lib I must adding in link parametr? Or I must adding line code in my code source?
Thanks
error LNK2001: unresolved external symbol __imp__CoUninitialize@0
error LNK2001: unresolved external symbol __imp__CoInitialize@4
error LNK2001: unresolved external symbol "void __stdcall _com_issue_error(long)" (?_com_issue_error@@YGXJ@Z)
error LNK2001: unresolved external symbol "unsigned short * __stdcall _com_util::ConvertStringToBSTR(char const *)" (ConvertStringToBSTR@_com_util@@YGPAGPBD@Z)
error LNK2001: unresolved external symbol "char * __stdcall _com_util::ConvertBSTRToString(unsigned short *)" (?ConvertBSTRToString@_com_util@@YGPADPAG@Z)
error LNK2001: unresolved external symbol "void __stdcall _com_issue_errorex(long,struct IUnknown *,struct _GUID const &)" (?_com_issue_errorex@@YGXJPAUIUnknown@@ABU_GUID@@@Z)
error LNK2001: unresolved external symbol __imp__CLSIDFromProgID@8
error LNK2001: unresolved external symbol __imp__CLSIDFromString@8
error LNK2001: unresolved external symbol __imp__OleRun@4
error LNK2001: unresolved external symbol __imp__CoCreateInstance@20
fatal error LNK1120: 10 unresolved externals
Error executing link.exe.
|
|
|
|
|
Antonio2929 wrote: When I link in DEBUG mode is OK.
When I link in RELEASE mode I get this error.
Check your linker settings to make sure Debug and Release match.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
In DEBUG mode I use default libreries.
In RELEASE mode I must check "Ignore all default libreries" otherwise I get other error: type redefinition, ecc ecc..
|
|
|
|
|
Antonio2929 wrote: In RELEASE mode I must check "Ignore all default libreries" otherwise I get other error: type redefinition, ecc ecc..
No - you must not check Ignore all default libreries - you must work out why those other errors are occurring and then fix them. I suspect a mixing of C runtime libraries.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Hello everyone,
I want to set a break point and wants it to be triggered when a piece memory (begin address and length are known) are changed. I am working on Windows Server 2003 x64 platform. Either solution in Windbg or solution in Visual Studio are fine. My purpose is to monitor when the memory content is changed.
thanks in advance,
George
|
|
|
|
|
George_George wrote: ...solution in Visual Studio are fine.
Which version?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
In VS2008 (possibly previous versions), you want to create a new data breakpoint. That will watch a block of memory and break when any of it changes.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
I have posted this a few days ago in connect microsoft but apart from an automatic reply I had no more feedback and I was wondering if anybody here had already found this bug before.
It seems the WM_NCCALCSIZE message is not being correctly processed by Windows Vista when Desktop Composition is enabled. The identified behavior was only detected when Desktop Composition is enabled. If Desktop Composition is disabled, everything works fine. It also works fine on XP.
The idea behind the tests that lead to the bug was to use the WM_NCCALCSIZE message and the NCCALCSIZE_PARAMS structure to implement a window client area preservation scheme, in order to minimize flickering due to unnecessary processing of WM_PAINT messages. The window style was registered without the (CS_HREDRAW | CS_VREDRAW) flags.
The goal was to avoid having to process the WM_PAINT message when the window was being resized due to the dragging of the window left border to the right. The usual procedure, in most applications (e.g. Notepad), would be to keep the client area content aligned left. In my case a bitmap is being displayed on the client area and the intention was to keep it right aligned (not left aligned) when the window left border was being dragged. So, dragging the left border to the right would cover some portion on the left part of the bitmap, originally displayed on the client area. The remaining part of the bitmap (the part on the right) could be completely preserved and processing the WM_PAINT message could be avoided.
The rectangles on the NCCALCSIZE_PARAMS structure were processed so that the system would copy the window image that is within the source rectangle and clips the image to the destination rectangle. In this case both source and destination client area rectangles refer to the same coordinates (the bit map right portion, not covered by the drag of the left border to the right). As the result of processing the WM_NCCALCSIZE message (and NCCALCSIZE_PARAMS structure), WVR_VALIDRECTS was returned, according to the documentation.
If Windows Vista Desktop Composition is enable the content of the NCCALCSIZE_PARAMS structure seems to be ignored and the bitmap on the client area is kept left aligned (dragged to the right as the window left border is dragged to the right). Everything works fine if Desktop Composition is disabled.
An identical bug can be reproduced by resizing the window dragging the top window border in the bottom direction (the bottom part of the bitmap should be preserved and instead it is top alligned and dragged down).
The following steps describe a small sample code intended to demonstrate the behaviour previously described and nothing else.
A new empty win32 project was created.
A global variable was created to accommodate the bitmap handle:
HANDLE g_hBitmap;
The window style is registered in MyRegisterClass as
wcex.style = CS_DBLCLKS ;
In InitInstance a bitmap is loaded after CreateWindow:
g_hBitmap=LoadImage(0,
TEXT("bitmap.bmp"),
IMAGE_BITMAP,
0,
0,
LR_CREATEDIBSECTION|LR_LOADFROMFILE);
In the WndProc callback the following variables and references were defined to support the following code:
HDC hdcMem;
RECT rect;
LONG& width=rect.right;
LONG& height=rect.bottom;
In the WndProc callback the following code was inserted:
case WM_PAINT:
hdc = BeginPaint(hWnd, &ps);
GetClientRect(hWnd,&rect);
hdcMem=CreateCompatibleDC(hdc);
SelectObject(hdcMem, g_hBitmap);
BitBlt(hdc,0,0,width,height,hdcMem,0,0,SRCCOPY);
DeleteDC(hdcMem);
EndPaint(hWnd, &ps);
break;
case WM_NCCALCSIZE:
if(wParam==TRUE)
{
RECT r, ro;
NCCALCSIZE_PARAMS& s=*((NCCALCSIZE_PARAMS*)lParam);
r.left=s.rgrc[2].left+(s.rgrc[0].left-s.rgrc[1].left);
r.right=s.rgrc[2].right+(s.rgrc[0].right-s.rgrc[1].right);
r.top=s.rgrc[2].top+(s.rgrc[0].top-s.rgrc[1].top);
r.bottom=s.rgrc[2].bottom+(s.rgrc[0].bottom-s.rgrc[1].bottom);
s.rgrc[0]=r;
if(IntersectRect(&ro,&r,&s.rgrc[2]))
{
s.rgrc[1]=s.rgrc[2]=ro;
return WVR_VALIDRECTS;
}
return 0;
}
else
return DefWindowProc(hWnd,message,wParam,lParam);
break;
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
