|
Well, I think, the main reason would be that because y is not marked as volatile, the compiler might have read y (into a register) before the the while loop not knowing that the variable could be modified externally.
Without that clue, I would have probably assumed that it always works... And it probably does in many cases (platform, compiler and compiler options).
Philippe Mori
|
|
|
|
|
Well his answer was that this wouldn't happen on a single processor, but would happen on multi CPU ssytems... He said that the instructions at may get out of order as the compiler might re-arrange instructions for optimization for example, so it might load x before it does y... he said this could be avoided obviously by locks which I mentioned to him, but he said that there is also this idea of "memory fence" where you tell it by some commad "asm something..", which tells the compiler to put a fence between the instructions so the instructions don't get re-arranged...
|
|
|
|
|
This is a classic case and should be something you learn to watch for in any multithreaded application.
You have multiple variables (x, y) that must be in a consistent state (when x != 0, y must have the correct value) in order for the relationship between them to be correctly interpreted.
The only way to ensure this state is to use some form of mutual exclusion around the Setter and the Tester so that both variables are looked at as a single atomic item.
As Philippe said, it might work on some platforms and some compilers but if you are ever to take your multithreaded programming skills to other platforms then you need to learn how to avoid cases like this in the general case and use the tools in the multithreaded API to control access.
|
|
|
|
|
I am not sure if you understood my post. I did answer that I would use mutex to synchrnonize and avoid wrong results. But, his question was explain how I can get the wrong result in this case and this had nothing to do with synchronization. He wanted me to see if I understood "memory fence" which I clearly never heard of to not allow instructions to be out of order while compiler optimization. 
|
|
|
|
|
Like already pointed out, not declaring x and y as volatile could be a problem: the compiler might optimize away the test on x, i. e. pull it outside the loop, or it may just load x into a register and never bother to reload it from memory. In fact, since x is not declared as volatile, the compiler may feel obliged to make sure x is never reloaded from memory!
|
|
|
|
|
Thanks for the explanation, it does make sense.
|
|
|
|
|
I am in learning process:
here I am trying to create a custom control in mfc
file 1:
InserEdit.h
#pragma once
#include <afxwin.h>
#define INSERTWINDOWCLASS L"INSERTWINDOWCLASS"
class CInsertEdit :
public CWnd
{
DECLARE_DYNAMIC(CInsertEdit)
protected:
CEdit *cid,*UserName,*PhoneNumber,*DateOfBirth,*Nationalities;
BOOL PreCreateWindow(CREATESTRUCT& cs);
void PreSubclassWindow();
public:
CInsertEdit();
~CInsertEdit(void);
BOOL Create(CWnd* pParentWnd, const RECT& rect, UINT nID, DWORD dwStyle);
DECLARE_MESSAGE_MAP()
private:
BOOL RegisterWindowClass();
};
InsertEdit.cpp
#include "InsertEdit.h"
BEGIN_MESSAGE_MAP( CInsertEdit, CWnd)
END_MESSAGE_MAP()
IMPLEMENT_DYNAMIC(CInsertEdit, CWnd)
CInsertEdit::CInsertEdit()
{
RegisterWindowClass();
return;
}
BOOL CInsertEdit::RegisterWindowClass()
{
WNDCLASS wndcls;
HINSTANCE hInst = AfxGetInstanceHandle();
if (!(::GetClassInfo(hInst, INSERTWINDOWCLASS, &wndcls)))
{
memset(&wndcls, 0, sizeof(WNDCLASS));
wndcls.style = CS_DBLCLKS | CS_HREDRAW | CS_VREDRAW;
wndcls.lpfnWndProc = ::DefWindowProc;
wndcls.cbClsExtra = wndcls.cbWndExtra = 0;
wndcls.hInstance = hInst;
wndcls.hIcon = NULL;
wndcls.hCursor = AfxGetApp()->LoadStandardCursor(IDC_ARROW);
wndcls.hbrBackground = (HBRUSH) (COLOR_WINDOW);
wndcls.lpszMenuName = NULL;
wndcls.lpszClassName = INSERTWINDOWCLASS;
wndcls.cbWndExtra = NULL;
if (!AfxRegisterClass(&wndcls))
{
AfxThrowResourceException();
return FALSE;
}
}
return TRUE;
}
CInsertEdit::~CInsertEdit(void)
{
}
BOOL CInsertEdit::PreCreateWindow(CREATESTRUCT& cs)
{
return CWnd::PreCreateWindow(cs);
}
void CInsertEdit::PreSubclassWindow()
{
CWnd::PreSubclassWindow();
cid=new CEdit();
BOOL what=cid->Create(WS_VISIBLE|WS_CHILD|WS_BORDER,CRect(0,0,100,24),this,1);
}
BOOL CInsertEdit::Create(CWnd* pParentWnd, const RECT& rect, UINT nID, DWORD dwStyle)
{
return CWnd::Create(INSERTWINDOWCLASS,L"",dwStyle,rect,pParentWnd,nID);
}
The problem is when i run the program it triggers to debug break point. it is created in PreSubclassWindow class. on line 3 with cig->Create calling. can anyone point out what I am doing wrong?
modified on Saturday, June 18, 2011 4:57 AM
|
|
|
|
|
This is quite difficult to read. Please edit your message and replace the <code> tags by <pre> tags for correct code block formatting. you could also help by marking the line of code where your error occurs.
The best things in life are not things.
|
|
|
|
|
Thank you for your reply.
The error occur in PreSubclassWindow() function on line(I cant tell you exact Line Number) BOOL what=cid->Create(WS_VISIBLE|WS_CHILD|WS_BORDER,CRect(0,0,100,24),this,1);.
But here is some confusing issue. I have used PreSubClassWindow instead of onCreate Window message. And I also get some example that is created based on PreSubClassWindow. They failed at the same point. i.e. creating child window.
Later I changed it to onCreate and it solved my problems.
By the way I am using Visual Studio 2010
Thank you
|
|
|
|
|
Probably the function was called too soon like before the actual HWND was allocated and it was failing at a check done by MFC.
Philippe Mori
|
|
|
|
|
Hi, I've a modal dialog box and I've tried to set a bitmap background:
case WM_ERASEBKGND:
{
HDC memDC, hdc;
HBITMAP hBmp;
BITMAP bmp;
RECT rcc;
hdc = GetDC(hDlg);
hBmp = LoadBitmap(hInst, MAKEINTRESOURCE(IDB_BMP));
memDC = CreateCompatibleDC(hdc);
SelectObject(memDC,hBmp);
GetObject(hBmp, sizeof(bmp), &bmp);
GetClientRect(hDlg,&rcc);
SetStretchBltMode(hdc, HALFTONE);
StretchBlt(hdc,
0,0, rcc.right,rcc.bottom,
memDC,
0,0,bmp.bmWidth, bmp.bmHeight,
SRCCOPY);
DeleteDC(memDC);
DeleteObject(hBmp);
ReleaseDC(hDlg,hdc);
return (INT_PTR)TRUE;
}
this code set a background bitmap, but when I move or resize the dialog controls(edit,button,listbox,...) disappear under the bitmap...what's wrong?how can i repaint correctly the dialog?
|
|
|
|
|
Hi,
Try creating the window with the WS_CLIPCHILDREN window style. Also... you might be better off painting the bitmap in WM_PAINT and returning TRUE in your WM_ERASEBKGND handler to avoid flicker.
|
|
|
|
|
Please see the order if u are give the order for bitmap at the last the it will overwrite ur textbox and other things 
|
|
|
|
|
Hi, I seem to remember trying this in the past, though failed miserably (presumably for the same reason) I recall using a frame based window, since I could define the background image (as a HBRUSH) in the windows class (ms class, not c++ class)
Anyhow, I just ad a few fresh ideas and seem to have resolved the issue. I'll admit I didn't try with a bmp, but since trying to paint a solid color resulted in the same behaviour, I'll (perhaps foolishly?) assume that the solution would be valid if I had.
[EDIT: yup - it works just fine with a bitmap too]
It's just a simple matter of calling InvalidateRect along with the hWnd of the dialog, the client area (or NULL for all of it) and False - for do not redraw.
I.e, just add the line
InvalidateRect(hwndDlg, NULL, false);
after you've done the clean-up and before you return true.
Something like so:
case WM_ERASEBKGND:
{
HDC memDC, hdc;
HBITMAP hBmp;
BITMAP bmp;
RECT rcc;
hdc = GetDC(hwndDlg);
hBmp = LoadBitmap(hInst, MAKEINTRESOURCE(IDB_BITMAP1));
memDC = CreateCompatibleDC(hdc);
SelectObject(memDC,hBmp);
GetObject(hBmp, sizeof(bmp), &bmp);
GetClientRect(hwndDlg,&rcc);
SetStretchBltMode(hdc, HALFTONE);
StretchBlt(hdc, 0,0, rcc.right,rcc.bottom, memDC, 0,0,bmp.bmWidth, bmp.bmHeight, SRCCOPY);
DeleteDC(memDC);
DeleteObject(hBmp);
ReleaseDC(hwndDlg,hdc);
InvalidateRect(hwndDlg, NULL, false);
return (INT_PTR)TRUE;
}
|
|
|
|
|
I am new to C++ MFC programming and -- though I've read a lot concerning the subject -- none of recipes seems to work in my case. The snippet of code is as follows:
void CPatchDlg::OnStart()
{
...
CWinApp* pApp = AfxGetApp() ;
pApp->SetRegistryKey(lpszRegistryKey) ;
}
Function SetRegistryKey(lpszKey) is a protected member of CWinApp class and cannot be used directly:
error C2248: 'SetRegistryKey' : cannot access protected member declared in class 'CWinApp'...
Please, help me to work around the problem.
|
|
|
|
|
what you are trying to achieve?
|
|
|
|
|
I've been trying to write into the registry some data not related to the application in case.
As it happens CWinApp functions are not intended for such usage -- they are intended to write the registration data of the running application. In that case the correct usage is as follows:
1. Place call to the SetRegistryKey function in the "InitInstance". For example,
BOOL DerivedApp::InitInstance()
{
LPCTSTR lpszRegistryKey = "SomeSection" ;
SetRegistryKey(lpszRegistryKey) ;
. . .
}
2. Place call to the other necessary functions in the proper place of your application.
For example,
void SomeClass::OnStart()
{
. . .
LPCTSTR lpszSection = "SomeSection" ;
LPCTSTR lpszStringItem = "SomeString" ;
LPCTSTR lpszValue = "SomeStringValue" ;
if (!AfxGetApp()->;WriteProfileString(lpszSection, lpszStringItem, lpszValue))
AfxMessageBox("Registry settings weren't modified.") ;
. . .
}
I've checked it -- it works. But not in the case if you have to write into the Registry some data not related to your application.
Regards to all of you, chaps!
|
|
|
|
|
Since its a protected member method, it can only be accessed from the CWinApp. Find your CWinApp derived class and you should be ale to make that call there.
|
|
|
|
|
Sorry, Albert,
I don't undersdand what you suggest. Suppose I derive an auxiliary class as follows:
class CAux : public CWinApp
{
public:
void SetRegistryKey(LPCTSTR lpszKey);
};
Then in some other place I make a call:
CAux::SetRegistryKey("somekey");
Trying to compile, I got the following message:
error C2352: 'CAux::SetRegistryKey' : illegal call of non-static member function
I don't understand how to avoid the access rights for the protected member function.
Regards,
Anatoly
|
|
|
|
|
You don't need to redefine SetRegistryKey() in your derived class. Just code it as follows somewhere within one of your CAux class functions:
SetRegistryKey("somekey");
The best things in life are not things.
|
|
|
|
|
If you used the application wizard to start your application building, and you specified that you were building an MFC application... then you should already have a CWinApp derived class somewhere in your project. Don't redefine the call, just call it from somewhere in there (if you redefine you'll override the original call).
And you can only the CAux::SetRegistryKey(); method without initializing an object if the call is static (something you don't want to do anyway).
|
|
|
|
|
Thanks, Albert,
You are completely right and it was my fault. Indeed, my application has a CwinApp derived class which is called CPatchApp:
class CPatchApp : public CWinApp
{
public:
CPatchApp();
...
}
All I had to do then is to declare
(CPatchApp *) pApp = AfxGetApp();
and to use that pApp pointer to access protected SetRegistryKey function like:
pApp->SetRegistryKey( LPCTSTR lpszRegistryKey );
Instead I wrote
(CWinApp *) pApp = AfxGetApp();
|
|
|
|
|
Sorry, it doesn't work either.
I do have a CWinApp derived class in my project (refer to my previous reply).
It is a simple dialog application. I need to write to the registry some value
and -- before using WriteProfileString -- I try to call SetRegistryKey.
There is the code snippet:
AfxGetApp()->SetRegistryKey(lpszRegistryKey);
At compiling I got the following message:
patchdlg.cpp(229) : error C2248: 'SetRegistryKey' : cannot access protected member declared in class 'CWinApp'
which returns us to the beginning of the discussion.
Is it possible to avoid that error at all? What is it there that I have overlooked?
|
|
|
|
|
Where are you making that call from? You have to make it from within the CWinApp derived class (since it is protected).
|
|
|
|
|
Hi, Albert,
I'd tried various approaches until I found an excellent C++ Tutorial (http://www.learncpp.com/) and got the understanding that my problem is related to the inheritance subject. As it is clearly stated in the tutorial:
2. The protected access specifier allows derived classes to directly access members of the base class while not exposing those members to the public.
I see now that I have to make call within but my derived class. It does work except that there reveals another problem -- WriteRegisterString needs an access to the m_pszRegistryKey variable which is an attribute of CWinApp class. IAE, I have to learn a bit more on the subject.
The discussion was very helpful and I thank you for the time you spent on it.
Regards,
Anatoly
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
