Is my compiler crazy? (OK, it's VC++ 6.0, so that might be a trick question).
Code such as the following gives me C4127: conditional expression is constant
How can those conditions possibly be constant??Code:ASSERT(m_reader.m_szSourceCurrent + nNumEndSkip >= m_szSourceCurrent); ASSERT(this == &pNode->GetParent()); ASSERT(it != m_children.end());
It depends on the code
but if for example in the line above you have initialized
m_reader.m_szSourceCurrent = m_szSourc;
and nNumEndSkip is unsigned int
then first condition will be always true
All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
I don't really see how, since nNumEndSkip can be any number, but I wonder if it has something to do with this being in an inline function?
Code:inline void Bookmark::GetSubString(String& strString, int nNumEndSkip) { ASSERT(m_reader.m_szSourceCurrent + nNumEndSkip >= m_szSourceCurrent); ... }
Doesn't this warning tell you that an expression will always evaluate to true or false (that is, there is no real point in evaluating it at all)? C4127
I might be wrong.
Quoted more than 1000 times (I hope).Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
I suppose so - compiler looks at the code there the parameters of the function are initialized - and probably makes some optimization - resulting in the conditional expression to be constantbut I wonder if it has something to do with this being in an inline function?
All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
Yes, hence my confusion.Originally Posted by anon
I did a search for all the places where that function is called, and it looks like it always passes positive a constant as the 2nd parameter.
I'm not sure about all the other lines with that warning, but I'm guessing it's for a similar reason.
I hate when 3rd party code doesn't test their code with the highest warning levels...
Sometimes optimizations throw too many warnings that are irrelevant. If its just a warning then ignore it. I leave warning on, but generally I ignore 99% of them.
Warnings are thrown because you aren't supposed to ignore them.
... unless they really are irrelevant. But yeah, leaving them on and then ignoring them may result in ignoring relevant warnings.Warnings are thrown because you aren't supposed to ignore them.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
But if they are irrelevant, then you should suppress them. And in most cases, many warnings are not unfounded (read: not irrelevant).
Whereas turning them off and then ignoring ensures you miss relevant ones. By ignoring, I don't mean I don't read them the first itme, it just means mostly I take no action as they are irrelevant. e.g.
\blah.cpp(15) : warning C4101: 'pTemp' : unreferenced local variable
irrelevant. used for debugging purposes, so Im not about to remove its definition, but irrelevant to the proper operation fo the app. And I dont realyl have the time to put in a pragma for every warning liek this.
You can just add "pTemp;" to get rid of it. Temporarily.
I somehow doubt that the compiler can emit warnings based on what parameters the function was called with. If it is warning that some condition will be always true/false, I would expect there to be something in the code that makes it so sure about it.
It is telling you that the code as it is, is potentially wrong. It shouldn't mean that in the context of this current program, some condition is always true/false - if that might change if the function is called with different arguments. In this case it means that you might be asserting things that cannot happen because of the code logic.
Do all those ASSERTs trigger the warning? Could you perhaps post the full function (and class declaration)?
I might be wrong.
Quoted more than 1000 times (I hope).Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
And get an "expression has no effect" warning instead?
(Debug things probably might be compiled conditionally in the first place?)
I might be wrong.
Quoted more than 1000 times (I hope).Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
It doesn't do that. Not in Visual Studio at the very least.And get an "expression has no effect" warning instead?
