|
You're quite right.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
The book "Linkers & Loaders" by John R. Levine is a good resource for questions involving this and similar subject matter.
|
|
|
|
|
hello guys... I have this piece of code. Lets say my name contains 'u' one time, my code will reduce the string size by 1, exludes the 'u' from string and displays it on screen.
if (chr[i] == 'u'){
count++;
}
else{
cout<<chr[i];
}
cout<<"\nIt has "<<strlen(chr) - count<<" characters.";
Now I am using if - else here...can these two tasks be done in just if ? Like incrementing count and displaying name in if without using else.
|
|
|
|
|
Yes:
if(chr[i] != 'u' || !++count) {
cout << chr[i];
}
Whether you should do this or not is another question - it's a lot harder to understand.
|
|
|
|
|
Ummmm, definitely not advisable:
1. Whether this works or not is compiler dependend - a compiler is free to evaluate the left or right side of an || operator in whatever order it likes!
2. Like you said, hardly anyone will understand, and even those that do will doubt what it does was actially intended, and might decide to 'fix' it wrongly.
Apart from that - interesting thought; I was about to answer 'no'
|
|
|
|
|
Stefan63 wrote: 1. Whether this works or not is compiler dependend - a compiler is free to evaluate the left or right side of an || operator in whatever order it likes!
Erm... hold on a sec here... Short-circuiting IS mandated, and can only work if it's evaluated in order. It's always true for PODs.
The only caveat is, if it is a class, and that class has an overloaded && or || operator. Then, both sides will be evaluated, so that the compiler can pass the element on the right hand side as a parameter.
One (very) good reason to never, ever overload them.
At least, this is the way I understand it, and I can't imagine anything undoing that, as tons of code that did this:
if( pszString != NULL && *pszString != '\0' )
would randomly crash if *pszString was evaluated first. Course, in this example the actual comparisons can be removed, but I was trying to be explicit.
N'est pas?
-- CraigL
|
|
|
|
|
I've learned not to rely on evaluation order, but I just looked it up and found my argument would only be true in cases where both argument sneed to be evaluated in any case, such as in an addition. In fact, Stroustrup explicitely names the exception, and that exception is exactly what you said:
"The operators ' (comma), && (logical and), and || (logical or) guarantee that their left-hand operand is evaluated before their right-hand operand."
(Bjarne Stroustrup, The C++ Programming Language, Third edition, page 123)
So I stand corrected.
Thanks for pointing this out.
|
|
|
|
|
I think there's some piece of information missing: Your code doesn't show a loop, or any other construct that loops through the characters in chr , and there's no point in displaying count before the end of that loop. Then in your request you suggest displaying 'name' within your if block, but there's no variable name, and if this should refer to chr , there is no point in displaying it fully for every value of i that you use in that if statement.
Unless your string chr will always be exactly "u" (i. e. a string of 1 character, which is 'u'), your question, taken literally, doesn't make much sense.
Besides, why do you want to get rid of that else statement?
|
|
|
|
|
How create a GUI to allow screen capture?
|
|
|
|
|
You mean other than the built in windows one? Do you only want a subset of your screen captured?
|
|
|
|
|
I want to implement a mechanism that allows users to easy select the capture area (the entire screen, the window of a program, a rectangle, ...)...is it possible?
|
|
|
|
|
Yes it's possible.
Which part are you not sure about?
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
|
This is possible. One of the early editions of Petzold's Windows books - "Programming Windows 95" gives an example of the BitBlt() which does exactly this. This is done in raw Windows API. You can, of course, redo it in C# or your favorite language.
|
|
|
|
|
yes, i know BitBlt(), but how can i get the handle of the window that mouse over?how can i select, with mouse, a rectangle of the screen?
|
|
|
|
|
Member 2965471 wrote: but how can i get the handle of the window that mouse over?how can i select, with mouse, a rectangle of the screen?
This is relatively simple if you know anything about Win32 UI/graphics programming. Since you seem to want to skip that part, why not just search for examples?
Binging "win32 draw selection rectangle on desktop" finds many examples, including this...
Screen Capture (Simple Win32 Dialog Based)[^]
Mark Salsbery
Microsoft MVP - Visual C++
modified on Saturday, May 14, 2011 12:44 PM
|
|
|
|
|
Hi
Does anyone know how to get/use the red squiggly line used in Ms word for spelling mistakes
thanks
simon
|
|
|
|
|
This is not the proper forum for this question... this is "Forum: C / C++ / MFC"
|
|
|
|
|
How do you know the OP is not asking about how to implement spell check in CRichEditCtrl?
|
|
|
|
|
|
How does anyone know...
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: How does anyone know... You really never do. That's why God made else .
|
|
|
|
|
you will have to draw it yourself, if you want such a thing.
|
|
|
|
|
As in link: http://msdn.microsoft.com/en-us/library/e5ewb1h3%28v=VS.80%29.aspx[^]
I defined
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
and call _CrtDumpMemoryLeaks() in 2 places:
place 1. from a menu Item.
in this case, I see leaking info as:
Detected memory leaks!
Dumping objects ->
{3443} normal block at 0x02EE9BF8, 373376 bytes long.
Data: < > C0 C0 C0 C0 C0 C0 00 00 00 00 00 00 00 00 00 00
afxtempl.h(330) : {3273} normal block at 0x01DCD530, 4 bytes long.
Data: <( > 28 10 07 02
strcore.cpp(118) : {3272} normal block at 0x01DCF2A0, 22 bytes long.
Data: < H a > 01 00 00 00 04 00 00 00 04 00 00 00 48 00 61 00
E:\Develops\MyProgram\MyUser.cpp(101) : {3258} client block at 0x01DCF890, subtype 0, 152 bytes long.
a CWnd object at $01DCF890, 152 bytes long
strcore.cpp(118) : {3256} normal block at 0x01DCE130, 22 bytes long.
Data: < N e > 01 00 00 00 04 00 00 00 04 00 00 00 4E 00 65 00
I think info above is not meaningful because app has not exited and many operator "new"s have not been deleted.
place 2. at exit point (MFC - destructor of CWinApp's subclass)
this time, I still see
Detected memory leaks!
Dumping objects ->
{3473} normal block at 0x01DA20C0, 28 bytes long.
Data: < !Ce > BC DF AF AB 21 43 65 87 83 00 00 00 00 00 00 00
{3443} normal block at 0x02EE9BF8, 373376 bytes long.
Data: < > C0 C0 C0 C0 C0 C0 00 00 00 00 00 00 00 00 00 00
But, this time, there is no any info about my program files, such as in case 1:
E:\Develops\MyProgram\MyUser.cpp(101) : {3258} client block at 0x01DCF890, subtype 0, 152 bytes long.
a CWnd object at $01DCF890, 152 bytes long
strcore.cpp(118) : {3256} normal block at 0x01DCE130, 22 bytes long.
Data: < N e > 01 00 00 00 04 00 00 00 04 00 00 00 4E 00 65 00
My Q is:
Does info in place 2 mean that my program has no memory leaks because there are no my files there?
Or how to find solution without my files related info?
|
|
|
|
|
includeh10 wrote: Does info in place 2 mean that my program has no memory leaks because there are no my files there?
No, it means that whatever section of the code is causing the leak, didn't provide the expanded information. Usually you have to set certain flags to get the expanded information. Look that up in MSDN.
includeh10 wrote: Or how to find solution without my files related info?
If you can't figure out how to activate the proper flags for the section of code doing this (to get expanded info), you can still find the leaking data by doing a bit of detective work. You can look for allocations of that size, look for for all allocations without matching deallocations (new/delete as well as malloc/dealloc), look at whether the content (labeled "Data:") provides any clue as to what it may be, and look at memory allocations within the program, usually heap is allocated in chunks and you get allocations in memory that are next to one another (don't know if that makes a lot of sense, but what I mean is if there are two allocations in calls next to one another, they are likely to have addresses in memory that are close to one another, so you can use this to narrow the location of the leak).
|
|
|
|
|