|
I am in college and we are using Turbo C++.
How can i perform the same here??
Thanks & Regards
PankajFrench is the language of love, for everything else there is c++ ...(anonymous)
|
|
|
|
|
I am sorry, I have no idea about how to do this in Turbo C. But you can take a look at the assembly code in my previous post to understand why 8 is displayed.
|
|
|
|
|
Pankaj D.Dubey wrote: int i = 2;
i = ++i + (++i)
cout<<i;
logically the="" code="" should="" print="" value="" '7'="" but="" i="" am="" getting="" '8'="" as="" output.
why="" is="" it="" so?
<="" blockquote="">
Actually, 8 is just as a correct answer as 7. To research this, search for the term "sequence points".
In ++i + (++i) for each ++i, i is first incremented, then the value is used. Also, the add will be done last. This does not fully define the order of evaluation of everything - and the implementation is free to choose the rest of the order.
So it could do things in the order you were thinking of. Another equally valid order is:
do the first increment ( i gets 3),
do the second increment ( i gets 4 ),
add current i to current i (8)
The bottom line is that you shouldn't write expressions where parts of the expression have side effects that could alter the value of other parts of the expression.Please do not read this signature.
|
|
|
|
|
If i take another variable say 'Y' and perform the evaluation in that like
Y = ++i + (++i);
cout<<y;
it will="" give="" '7'.="" now="" whats="" the="" reason="" behind="" this="" concept.<div="" class="signature">French is the language of love, for everything else there is c++ ...(anonymous)
|
|
|
|
|
 Exact same reason. You are using exactly the same expression on the right side of the equals sign. Since you didn't change anything relevant, nothing changed.
Edit: Yes, you did change the expression on the left side of the equals sign and got a different answer, but the issue is unchanged.Please do not read this signature.
modified on Wednesday, February 24, 2010 11:05 AM
|
|
|
|
|
Exactly 
thanks mate, thanks a ton
Thanks and Regards
PankajFrench is the language of love, for everything else there is c++ ...(anonymous)
|
|
|
|
|
It is safer not to use such code because you will get different results in different compilers.
IIRC I got different results in VC 6.0 when compiled in Windows application and console application.
|
|
|
|
|
| Definitely it is not safe. Even the same compiler in different situations in the source code could produce different results, as the OP seems to have experienced. The relative order of evaluation including application of side affects isn't fully specified by the standard, so the compiler gets to pick what's convenient - and can pick differently in different places. Please do not read this signature.
|
|
|
|
|
The standard DOES have something to say on this. In the Expressions section introduction, it specifically states <quote>Except when noted, the order of evaluation of operands of individual operators is undefined. In particular, if a value is modified twice in an expression, the result of the expression is undefined except when an ordering is guaranteed by the operators involved. For example,
i = v[i++];
i = 7,i++,i++;
</quote>
[Stroustrup, 2nd ed, p492]
So it's not that the standard fails to fully specify, it specifies that the result is undefined.
|
|
|
|
|
It seems it is easy to fall into this trap especially when somebody is new to C++.
|
|
|
|
|
people seem to fall into traps like this -- when they try to be cool.
there's no good reason to combine several distinct operations into single statement.
one thing I've learned in my years is that 'cool is costly' -- you could spend many many hours trying to debug that mistake.
write it simply and clearly (and readable) -- the compiler will optimize it for you.
-p
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br />
Peter Weyzen<br />
Staff Engineer<br />
<a href="http://www.soonr.com">SoonR Inc -- PC Power delivered to your phone</a>
|
|
|
|
|
| Clarification/correction accepted. When I wrote "relative order ... isn't fully specified", I meant "is not fully dictated" (hence, as you say, is officially undefined) rather than "is not talked about". Please do not read this signature.
|
|
|
|
|
I have this function..
void MyFunction(BSTR* param, int nArraySize);
and I'm supposed to pass an array of string ("String1", "String2", "String3") as param. How can I do this?
|
|
|
|
|
BSTR str[10];
for (int i = 0; i < 10; ++i)
str[i] = ::SysAllocString(_T("String"));
MyFunction(str, 10);
|
|
|
|
|
I use GDI+ in my project under windows Vista/7 without any problems.
But when i try to compile the code or run the code under windows XP, the program crashes/ the compiler throw an exception.
I found that pBmp1 is NULL under the windows XP:
HBITMAP hbmp1 = ::LoadBitmap(AfxGetInstanceHandle(), MAKEINTRESOURCE(IDB_BITMAP1));
ASSERT(hbmp1!=NULL);
Bitmap* pBmp1 = Bitmap::FromHBITMAP(hbmp1,NULL);
ASSERT(pBmp1->GetLastStatus() == Ok);
How can i Correct it?
Best,
MJM
|
|
|
|
|
First, you need to be more clear about the error. Is it a runtime error, or compile time?
What is the error?
|
|
|
|
|
Hey, what is this? You reading over my shoulder?
 L u n a t i c F r i n g e
|
|
|
|
|
|
mostafa_pasha wrote: But when i try to compile the code or run the code under windows XP, the program crashes/ the compiler throw an exception.
Which is it? Does it fail to compile, or does it crash when you run it? If it fails to compile, what is the specific error message?L u n a t i c F r i n g e
|
|
|
|
|
first, it is runtime error!
I said that when i debug the code under windows XP! (it means i can compile and run the program), pBmp1 which is the GDI+ object is NULL!!! but under windows vista/7, All is OK.
My program is MDI. My project setting is USED MFC LIBRARY AS SHARED DLL!
Does it depend on the updates for windows XP or Not?
Best,
MJM
|
|
|
|
|
mostafa_pasha wrote: I said that when i debug the code under windows XP! (it means i can compile and run the program), pBmp1 which is the GDI+ object is NULL!!!
Noooo, you said this:
mostafa_pasha wrote: But when i try to compile the code or run the code under windows XP, the program crashes/ the compiler throw an exception.
There is a difference, although I take it from the second post that the first was incorrect; that is, you say now that you CAN compile under XP.
mostafa_pasha wrote: My program is MDI.
Probably irrelevant.
mostafa_pasha wrote: My project setting is USED MFC LIBRARY AS SHARED DLL!
Again, probably irrelevant, although you could build the project with MFC linked as a static library to eliminate the possibility.
mostafa_pasha wrote: Does it depend on the updates for windows XP or Not?
Perhaps; I don't know if the GDI+ runtime was affected by any updates, but it's always advisable to make sure your system is fully up to date. If it isn't, that's a good place to start, although I wouldn't hold out TOO much hope.
Have you tried using LoadImage instead of LoadBitmap? LoadImage will allow you to specify that you want the image loaded as a DIBSection, which is device independent. (Are your display settings different in XP? LoadBitmap tries to load the image in a display-compatible format; LoadImage might get you around any problem associated with this.)L u n a t i c F r i n g e
|
|
|
|
|
I think you can debug into Bitmap::FromHBITMAP() function and see what is going wrong.
|
|
|
|
|
return NULL
It means can not initilaize Bitmap!!!
Does it mean it can not initialize the GDI+?
inline Bitmap*
Bitmap::FromHBITMAP(
IN HBITMAP hbm,
IN HPALETTE hpal
)
{
return new Bitmap(hbm, hpal);
}
|
|
|
|
|
mostafa_pasha wrote: return NULL
If it returns NULL then it means the function failed and you should use GetLastError() to find out why. Incidentally the code above is somewhat different from the code in your original message. Try to use exactly the same code and trace through it with the debugger noting all the values of your variables.txtspeak is the realm of 9 year old children, not developers. Christian Graus
|
|
|
|
|
the code is here:
HBITMAP hbmp1 = ::LoadBitmap(AfxGetInstanceHandle(), MAKEINTRESOURCE(IDB_BITMAP1));
ASSERT(hbmp1!=NULL);
Bitmap* pBmp1 = Bitmap::FromHBITMAP(hbmp1,NULL);
hbmp1 0xb8051055
pBmp1 0x00000000
in LoadBitmap function:
inline Bitmap*
Bitmap::FromHBITMAP(
IN HBITMAP hbm,
IN HPALETTE hpal
)
{
return new Bitmap(hbm, hpal);
}
void* (operator new)(size_t in_size)
{
return DllExports::GdipAlloc(in_size);
}
in_size = 16
return 0x000000000
Best,
MJM
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
