|
I have tried running your code with the various different configurations but cannot see how to tell that a particular part of the release version does not work. In each case the output is similar, although when using the for statement the program crashes.
I must get a clever new signature for 2011.
|
|
|
|
|
This sounds like an optamisation bug.
there is a similar bug with the following:
int x = 0;
int y = ++x + ++x;
You would expect this to be y = 1 + 2 (=3) which it is when optimisations are disabled, but the value of y when optimisations are turned on is 4
Try disabling optimisations in the release build. They don't help all that much unless you are after extreme speed or a tiny image.
If this helps, you can try re-enabling them 1 at a time if you want optimisation.
|
|
|
|
|
It's not a bug, it's standard behaviour. If you write statements with more than one sub-expression in it that writes to a variable then the compiler can generate any old rubbish it wants.
modified on Tuesday, February 1, 2011 2:32 PM
|
|
|
|
|
I agree, it could very well be an optimisation 'feature'.
It might be worth it to give this a shot:
while(nVector[nPos + 1] == (nVector[nPos] + 1))
modified 13-Sep-18 21:01pm.
|
|
|
|
|
It still doesn't work.
I also suspect it's an optimization 'feature'.. just read the other day about the bogosort on wikipedia (http://en.wikipedia.org/wiki/Bogosort) and wanted to play a little with it and discovered this little gem between debug and release versions.. and this is by no means an application, just a little fun I was having, but such an 'optimization' in a big and important program could really have a serious problematic impact.
|
|
|
|
|
hi guys
probably already discussed but I did not find the explenation:
in the above code:
My question is why I have to use reference to the pointer
when returning from mGetPt?
If this pointer whould have been used inside the function,
and for example used in constructor to allocate memory
if I have an Get function like CInner* mGetPt(void)
I am able to use the pointer as I want.
but in the above example it is required to return a reference.
(this is the return value, is not a function param; OK I know in case of function params I have to use reference to pinter)
Please someone clarify me why?
class CInner
{
public:
int mx;
CInner()
{
mx=1;
}
};
class CTest
{
private:
CInner *pt;
public:
CTest()
{
pt= NULL;
}
CInner*& mGetPt(void)
{
return pt;
}
};
int _tmain(int argc, _TCHAR* argv[])
{
CTest *obj= new CTest();
obj->mGetPt() = new CInner();
cout<<obj->mGetPt()->mx;
cin.get();
return 0;
}
|
|
|
|
|
You need to return a reference to the pointer if you want an outsider to be able to change the value of that pointer. It looks like an ugly attempt to make dependency injection. A setter/getter would IMO be clearer. Who's responsible for deallocating the instance? The contract isn't clear at all. If trying something like that, a massive comment block describing responsibilities would be a minimum.
|
|
|
|
|
Firstly, I agree with Niklas, this is terrible style and structure. A class should be responsible for allocating and deallocating all its memory.
To answer your question, returning a pointer allows you to modify the data that is pointed to (in your case this is NULL, so it would result in an access violation).
Returning a reference allows you to modify the value of the original variable returned (think of reference as "another name for the variable X")
So, in order to modify the value of the variable pt rather than the data it points to, you can either return a reference to the variable, or a pointer to the variable itself.
You are returning the reference, to return a pointer you would use it like:
CInner** mGetPt(void) {
return &pt;
}
*obj->mGetPt() = new CInner();
Having said that, this is still bad style, and you would be much better off with something like:
class CInner {
public:
CInner() : mx(1) { }
int GetMX() { return mx; }
void SetMX(int nNewMx) { mx = nNewMx; }
private:
int mx;
};
For CTest you have 2 choices, you can either allocate pt = new CInner in the constructor or when it is needed.
class CTest {
public:
CTest() : pt(new CInner) { }
~CTest() {
if (pt != NULL) {
delete pt;
}
}
CInner *mGetPt() { return pt; }
private:
CInner *pt;
};
class CTest {
public:
CTest() : pt(NULL) { }
~CTest() {
if (pt != NULL) {
delete pt;
}
}
CInner *mGetPt() {
if (pt == NULL) {
pt = new CInner;
}
return pt;
}
private:
CInner *pt;
};
You can then use it like:
int _tmain(int argc, TCHAR *argv[]) {
CTest *obj = new CTest();
cout << obj->mGetPt()->GetMX();
cin.get();
return 0;
}
|
|
|
|
|
Hi all,
I have a problem using CMemDC class in my project. I am using Visual Studio 2010, when i include and compile the class it gives error like:-
error C2011: 'CMemDC' : 'class' type redefinition
my class is working fine in visual studio 2008.
I am not getting what exactly problem is...
Thanks in advance
|
|
|
|
|
Are you using your own CMemDC class, other than the one provided by MFC Feature Pack (or VS 2010 - though iam not sure)? Then you have to rename your class to some thing else. There is a built in CMemDC Class as part of Internal Classes of MFC Feature Pack.
|
|
|
|
|
Thanks i renamed it and it worked
|
|
|
|
|
I am starting to get into the habit of putting all my own stuff into my own namespace. Proving to be the best way of avoiding naming conflicts between my stuff and MFC stuff.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good - Use it!
|
|
|
|
|
|
Hi!
I've seen the following pair of preprocessor directives before the class declaration:
#ifndef somename
#define somename
This directive appears at each and every header file. What is the use of it?
|
|
|
|
|
It is very common that a header file will be included more than once in a single .cpp file.
If this happens then anything that is declared or defined in the header file will be defined more than once, even tho it is the same definition it will cause a compile error.
This is called a macro guard, and it ensures that the contents of the header file are only included once. an alternative to this is a single #pragma once at the top of the header file, however this only works with Visual Studio 7.0 and later.
Consider the folowing:
class Base {
};
#include "Base.h"
class Sub1 : public Base {
};
#include "Base.h"
class Sub2 : public Base {
};
#include "Sub1.h"
#include "Sub2.h"
int main() {
Sub1 s1;
Sub2 s2;
return 0;
}
Then the file Base.h will be included twice, hence the class Base will be defined twice.
This can happen with function definitions as well, so you should always use the macro guard.
Just note that at the end of the .h file there is also a #endif if you us the #ifndef
EDIT: The macro that is defined with #define and tested with #ifndef should be the same within the 1 header file, and unique amongst your project as well as any headers from other projects and libraries that you are using
|
|
|
|
|
In addition to your excellent reply, adding a #pragma once increases compilation speed since the compiler doesn't have to re-open/re-parse the file after the first #include . To make it both fast and portable, use both.
|
|
|
|
|
[edit]Please ignore this, see responses below[/edit]
Using #pragma once still forces the compiler to at least reopen the header file. If you want to prevent that as well you have to place the guards outside the header file, around every inclusion, such as this:
#define MY_GUARD_A_H
class A {
};
#ifndef MY_GUARD_A_H
#include "A.h"
#endif
I've done it like that in a project once, some 20+ years ago, but it was a hell to maintain. It did help a lot though, as it was really a huge project, and computers (and specifically file system calls) weren't all that fast at the time.
modified on Tuesday, February 1, 2011 5:55 AM
|
|
|
|
|
I don't know for sure, but I see no reason that Niklas Lindquist's comment would be wrong.
When the preprocessor sees the #pragma once in a file, it should mark that file as having been included and that it does not need to be included again.
This list would need to be kept in order for the directive to work, so there is no reason that it should need to re-open the same file to realise this.
|
|
|
|
|
I am sorry, I've just looked up the description of #pragma and according to what it says you, and Niclas, are indeed correct.
I always thought the preprocessor would always have to resolve #include statements until coming to a #pragma , but when I think about it, it's trivial to keep a list of files that have #prgama once specified. My bad for never looking for the exact definition of this feature...
|
|
|
|
|
Don't feel bad, I never knew it until Niclas said it.
And even then, I only assumed he was right because it would be rather silly to not do it that way.
|
|
|
|
|
Andrew Brock wrote: it would be rather silly to not do it that way
indeed it would.
|
|
|
|
|
No worries
|
|
|
|
|
I would like to point out that even if you do not #include the same header multiple times within the same file, the multiple inclusion issue still exists: the reason is that you might indirectly include a header multiple times through #include statements in header files that you include, for example:
class A {
};
#include "A.h"
class B : public A {
};
#include "B.h"
#include "A.h"
The first statement in B.cpp includes B.h, which in turn includes A.h. B.cpp then continues to include A.h again, which will cause a compiler error.
|
|
|
|
|
this[^] would help you. I prefer you to go through the "Conditional inclusions (#ifdef, #ifndef, #if, #endif, #else and #elif)" section of the article and 'Avoiding Including Files Multiple Times (idempotency)' section of this [^]link.
|
|
|
|
|
Hi there,
I am developing a custom print dialog and page setup for my Win32 program. Since the code is legacy, I can't take much advantage from MFC view/doc architecture. As a result, I wrote a printing code completely from scratch.
I setup CPrintInfo, instantiate my custom print dialog box and hook this dialog box to the CPrintInfo I just created. When my custom print dialog is up, I have a radio button to let a user toggles the page orientation. For some reasons, I couldn't modify the current DEVMODE at the run-time. As a result, every page I print will end up as a portrait.
<b>Here is the code I have:</b>
void PrintSomething(CWnd* currentWnd)
{
// Create CPrintInfo
CPrintInfo* pPrintInfo = new CPrintInfo;
SetupPrintInfo(pPrintInfo); // simply setup some member variables of CPrintInfo
// Create a custom print dialog and use this dialog box during instead of the default CPrintDialog
CustomPrintDlg* pCustomPrtDlg = new CustomPrintDlg(FALSE, PD_ALLPAGES | PD_USEDEVMODECOPIES | PD_NOPAGENUMS
| PD_HIDEPRINTTOFILE | PD_NOSELECTION, pPrintInfo, currentWnd);
SetupPrintDialog(pPrintInfo,pCustomPrtDlg);
if ( AfxGetApp()->DoPrintDialog(pCustomPrtDlg) == IDOK ) {
... // proceed a print loop
}
}
void SetupPrintDialog(CPrintInfo* pPrintInfo,CustomPrintDlg* pCustomPrtDlg)
{
delete pInfo->m_pPD;
pInfo->m_pPD = pCustomPrtDlg;
pInfo->m_pPD->m_pd.hInstance = AfxGetInstanceHandle();
pInfo->m_pPD->m_pd.lpPrintTemplateName = MAKEINTRESOURCE(IDD_CUSTOM_PRTDLG);
// Set the Flags of the PRINTDLG structure as shown, else the
// changes will have no effect.
pInfo>m_pPD->m_pd.Flags |= PD_ENABLEPRINTTEMPLATE;
// Set the page range.
pInfo>m_pPD->m_pd.nMinPage = 1; // one based page numbers.
pInfo>m_pPD->m_pd.nMaxPage = 0xffff; // how many pages is unknown.
}
When a user toggles the radio button to Landscape, this function will be invoked:
void CustomPrintDlg::OnLandscapeChecked()
{
// set the current Devmode to landscape
LPDEVMODE pDevMode = GetDevMode();
GlobalUnlock(pDevMode);
pDevMode->dmOrientation = DMORIENT_LANDSCAPE;
}
class CustomPrintDlg: public CPrintDialog {
... // just override some methods from CPrintDialog
};
Even if I manually set pDevMode->dmOrientation to DMORIENT_LANDSCAPE when the dialog is up, the printing result is still ended up in Portrait. I am really not sure why this is happening. Please help.
Thank you in advance for any help.
Un
Un
-- Modified Thursday, February 3, 2011 10:30 PM
|
|
|
|