|
It has been a long time, but the problem could be as simple as word alignment. The length of each scan line must be divisible by 4. That is, each line must be padded with zeros if it is not already word aligned.
Example: (assuming single-byte per pixel)
wrong_data[2][1] = {
{0x00},
{0xFF}
};
correct_data[2][4] = {
{0x00, 0x00, 0x00, 0x00},
{0xFF, 0x00, 0x00, 0x00}
};
I have not tested the above, but it looks right.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence." - Edsger Dijkstra
"I have never been lost, but I will admit to being confused for several weeks. " - Daniel Boone
|
|
|
|
|
I always thought I had a good grip on short circuit evaluation for Logical AND and Logical OR but I'm mixing the two and the results are not intuitive. The specification does not suggest the behavior I'm seeing with VC++ 2003 so I thought I'd post the test and results and see if anyone can tell me why "Eval3" never gets evaluated.
void Test()
{
if (Eval1() || Eval2() && Eval3()) {
TRACE("Result = TRUE\n");
} else {
TRACE("Result = FALSE\n");
}
}
BOOL Eval1(void)
{
TRACE("Eval1\n");
return TRUE;
}
BOOL Eval2(void)
{
TRACE("Eval2\n");
return TRUE;
}
BOOL Eval3(void)
{
TRACE("Eval3\n");
return FALSE;
}
Output:
Eval1
Result = TRUE
|
|
|
|
|
rather than worrying about short circuiting, you should pay attention first to precedence.
a || b && c
isn't
(a || b) && c
it is equivalent to
a || (b && c)
When a is true, no need to evaluate b nor c.
The and/or precedence rule is simple, it is very similar to the one for 1 + 2 * 3
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
For some reason I had thought && and || were at the same precedence level and evaluated left to right but what your saying makes sense now that you helped me focus.
thanks for your guidance.
|
|
|
|
|
you're welcome.
PS: when in doubt, add parentheses.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
Forget doubt, always use parentheses. Just make it bonehead simple and you never get what you don't expect. And you don't confuse people who are precedence challenged.
The wonderful thing about the Darwin Awards is that everyone wins, especially the members of the audience.
|
|
|
|
|
Luc Pattyn wrote: PS: when in doubt, add parentheses.
Words of wisdom.
Steve
|
|
|
|
|
How can I find how much memory my application is using up programatically? i.e Task Manager
|
|
|
|
|
|
It does not really matter, read this[^].
Watched code never compiles.
|
|
|
|
|
You can use GetProcessMemoryInfo[^] function.
This[^] is MSDN example for the usage of the function.
If you want to find the memory usage of your application only then you can pass GetCurrentProcess[^] as the process handle in order to get the information.
|
|
|
|
|
What I am trying to get at is find (private working set) like it shows on Task Manger per process. GetProcessmemoryInfo gets me workingsetsize which isn't the private. Do you know how I can calculate the private number?
Thanks
modified on Thursday, June 3, 2010 1:21 PM
|
|
|
|
|
Have you seen this?
"One man's wage rise is another man's price increase." - Harold Wilson
"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
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
|
The article was exactly what I am looking for.
Thanks
|
|
|
|
|
Glad to hear that. You're welcome.
|
|
|
|
|
Just reviewing some code...
In it, there is a line like this :
CString s;
//... do something with s.
if ( s.GetLength() > 0 )
{
}
my first reaction was to note that and propose change the GetLength with IsEmpty()
if ( !s.IsEmpty() )
{
}
Looking at the code CString code (VS2008 and VS2010) for IsEmpty() , it calls GetLength() . The generated code will probably be optimized to the same assembly.
Was there a time (I don't have VS2003 or VC6 installed to check) when GetLength and IsEmpty were "really" different ? or they are there for code readbility issue ?
Thanks.
Max.
Watched code never compiles.
|
|
|
|
|
Back when I used MFC in the early 90s IsEmpty was defined in terms ot GetLength .
if( str.IsEmpty() )
{
....
}
can almost be read as english text: "If str is empty..." Compare that with:
if( str.GetLength() == 0 )
{
}
which has to be read as "if str's length is zero" and then translated. There's less of a semantic gap between what's written and it's meaning.
Anyway, sorry about the verbose answer, overly complicated logical expressions are one of my hobby horses - change the code in your review, future generations will thank you for it.
Cheers,
Ash
|
|
|
|
|
Since they both reference the nDataLength member variable, it likely does not matter.
"One man's wage rise is another man's price increase." - Harold Wilson
"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
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
Saying if a text is empty and say how long a text is are two different concepts: the first is simpler (requires an immediate check) than the second (requires to count somehow the data).
So they have two distinct functions.
The fact that the actual implementation keeps track of the length as long as it changes, so that both methods take advantage by a same computation is an "implementation detail" that may vary in future releases.
!GetLength() is semantically the same as IsEmpty() but don't expect they will always do the same computation and result in the same performance.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
emilio_grv wrote: Saying if a text is empty and say how long a text is are two different concepts...
True, but saying if a text is empty and if the text's length is 0 are identical.
emilio_grv wrote: The fact that the actual implementation keeps track of the length as long as it changes, so that both methods take advantage by a same computation is an "implementation detail" that may vary in future releases.
It hasn't since day one and likely won't for the foreseeable future.
emilio_grv wrote: !GetLength() is semantically...
...wrong since GetLength() is not a boolean function and thus should not be treated as such.
"One man's wage rise is another man's price increase." - Harold Wilson
"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
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
It seems you are misunderstanding some of my points. Let me try to clarify.
DavidCrow wrote: True, but saying if a text is empty and if the text's length is 0 are identical.
Yes ... but what about the opostite? (saying it is not empty doesn't say the length. Moral: the concepts are not "identical" - in math sense- since the symmetrical property is not valid. But is is true that the length concept includes the empty concept in it. It not the same: it is more general, and requires more informations, in general terms)
DavidCrow wrote: It hasn't since day one and likely won't for the foreseeable future.
As far everybody can know(in technical sense) this fact gives to your assumption a very high probability to remain always true.
But this fact does not depend on you, so it is not something you should rely on. The CString documentation doesn't say that IsEmpty() will always be implemented the same as GetLength() . You are -in fact- reverse-engineering the current implementation. Good to learn how it works, but no more than this. You have to discover why the designers did it that way. But code tells you only how it is done.
DavidCrow wrote: ...wrong since GetLength() is not a boolean function
C++ operators are overridable, and C++ itself defines operator! for all integral types, with a precise definition.
I'm not "treating it as boolean". I'm evaluating an integer expression.
C++ is not C. Certain "good C practice" are not valid for C++, especially if you're thinking to generic code (where !!a is often used as a "pseudo operator" to convert whatever A supporting ! into a bool ean)
In any case, the most of all these things are much more matter of taste, than substance. I agree.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
Hi All,
I have been asked these question in a telephonic interview:
1) Why some header files have there definitions in itslef and don't have a '.cpp' for definition? Classic examples are vector.h and other STL files. What will be the impact of having definitions in a separate cpp file/
2) What is the disadvantage if I make all my functions inline and inline request is always acknowledged by the compiler?
I told him that recursion is not possible, load time will be more, page faults will be more, binary size will increase. But he was looking for some other things as well.
It will be very much helpful if someone can fulfill these queries with explanatory notes.
BR,
Akash
|
|
|
|
|
1. Most compilers don't support the export so you really need the definition of a template class in with it's declaration of you can't use the template class with arbitrary type parameters. The main impact of having everything in an h file is that it couples the class in the h file more tightly with your code. FREX if the implementation of std::vector changes everything that includes vector has to be recompiled. If export was supported you'd just need to compile vector.cpp and relink (and maybe do that intermediate step thing that EDG does when using exported templates) which would be a lot faster.
2. In addition to your comments the main problem is again dependencies. When you modify your class implementation (if it's all in an h file) you have to recompile ALL the source files that use that class. This can increase build times through the roof for a simple change.
Incidentally recursion would still be possible - a clever compiler could convert your inlined recursion into iteration.
Cheers,
Ash
|
|
|
|
|
thanks Aescleal
|
|
|
|