Do you read compilers warning & error messages?

Warnings are there for a reason. If you have warnings in your compiled code, I think you should (a) fix them, or (b) have a good reason for leaving the warning there.

:)

Viggy

That is the exact question I was thinking about Hobson.

I selected the first option becuase I do understand the error. I know what is wrong. Even if I don't know how to fix it I still know what the problem is

I selected first option then, I read every compiler message it emits, and my understanding of English is fair enough to know what they mean. However, my knowledge of C++ is not always enough to resolve an error :(

I read them all, the ones I don't understand, I go and type the error or warning code into MSDN(since I use VS)

However, my knowledge of C++ is not always enough to resolve an error
Same here. :D

The only warnings I leave are depracated functions(like sprintf, but I've been starting to use the new type safe ones sprintf_s) or a typecast warning(when I know it won't be a problem). All other warnings I'll go and fix.

So, even for me, error messages may not always be obvious the first time I meet them
Don't say. :D :lol:

I selected the first option ... with the word 'eventually' inserted mentally between 'and' & 'understand'. :D

Come on, Koko, you think any skilled programmer would vote anything else than "Yes, I read each error & warning message, and understand them perfectly"?
If I thought anything... I wouldn't have created this poll. ;)

I was surprised to see that the most votes till now have gone to option 1.

I was thinking that Option 3 should have got the most votes.

I doubt even a compiler writer can understand every warning and error

Come on, Koko, you think any skilled programmer would vote anything else than "Yes, I read each error & warning message, and understand them perfectly"?
I for one don't know all the error and warning messages by heart, so yes I sometimes have to look them up or think hard about them before understanding them. Understanding messages perfectly means to me that you know directly what causes it and how you can fix it. And unfortunately that's not always the case. If you understand each error message perfectly, I'm truly impressed.

For example, can you tell me the meaning of this warning?

C:\Projects\w3g\main.cpp(10) : warning C4800: 'int *' : forcing value to bool 'true' or 'false' (performance warning)

I for one don't know all the error and warning messages by heart, so yes I sometimes have to look them up or think hard about them before understanding them. Understanding messages perfectly means to me that you know directly what causes it and how you can fix it. And unfortunately that's not always the case. If you understand each error message perfectly, I'm truly impressed.

C:\Projects\w3g\main.cpp(10) : warning C4800: 'int *' : forcing value to bool 'true' or 'false' (performance warning)

For example, can you tell me the meaning of this warning?
Well, it is probably pointing out than conversion from int* to bool is not a no-op (thus it's only a performance warning for programmers who were acustomed to C and the absence of bool) even on ILP32 machines, because VC++ uses execlusively 1 for the representation of true... This may require a conditional jump on older machines (such as K6-2 CPU) while it could perhaps be possible (dependening on the context) to keep the int* type and test it at the appropriate place... The compiler generating a jz/jnz instead of two of them... Or instead of a setnz + jz/jnz.

Well, I might be wrong, since this "performance" problem seems a bit ridiculous... However, I guess that I could answer better in the light of the piece of code you compiled, especially line 10.

Note that not all warnings are obvious the first time you encounter them... However, in the context of the code, it becomes quite clear... Or reading the doc...
The point is that an advanced programmers who uses only a few compilers knows well all the error messages of those compilers.
Using a new compiler implies that more time is needed to read error messages... While, if you use your favorite compiler, you can understand an error message without reading its entirely... Only keywords and code line number.

Don't say. :D :lol:I know he is either kidding or being modest! :D ;)

The code line in question is:

int *pi = new int;
MyCComVariant v(pi);

Anyways, the problem that occurs here is that you have a class which has a constructor from bool and hence converts "anything" to bool that isn't a bool. Which is of course an error. I have had problems with this in ATL3's implementation of CComVariant and it was kind of hard to track down.

Well, yes, after reading the doc and looking at the code it becomes clear. Otherwise we wouldn't be programmers. But it's still often not very clear only from the error message itself.

Well, that's because the warning message was not supposed to detect a bug, but only a performance problem.
That's only by chance that it tracked your bug.
The message in itself doesn't point out that the decay to bool may be unintended... It says that it can reduce performances.

Moreover, I'd like to point out that once you've seen a compiler error, you remember forever what it means... My poll question was not "do you understand errors of compiler that you don't use?".

Moreover after all, I think that my guess about the source of the warning message (conversion from int* to bool) is correct... So, even without the doc & code, I understood it.

Googleing a bit, I can see that I was right:
http://msdn2.microsoft.com/en-us/library/b6801kcy.aspx

For example, most problems with templates are solved most easily by just realising that there is "something wrong" at that line. The quality of the error messages (especially VC6 e.g.) is not always something you can rely on. VS2005 is much better in that regard, but there are still cases where the error message isn't particularly helpful.
It's true that Visual C++ is really bad for warning & error messages... Particulary there are stupid useless warning messages.

Note that my question was not about how fast you correct the error, but whether you understand the message.
For example, if somebody tells you : "hey, your forgot your hat", you'll understand what it means, even if you might not immediately solve the problem (since your hat is at home, assuming you're at several kilometers from home).

Actually I find that compiler warnings are not always enough and will run Lint.

Lint covers alot of trouble spots in logic as well as finding all sorts of memory problems.

Try running lint on your program, you may be suprised to see what Scott Meyers thinks of your code. Chances are your code has fur-balls and you dont even know it.

Well known C++ Gurus rules have been added to PC-Lint.
Lint has both warnings and informationals. Warnings can be supressed if there are too many of em in your code... :lol:

Note that my question was not about how fast you correct the error, but whether you understand the message.

Well, it's still subjective, because of course you'll always be able to say what the error messages say. However you're not always sure about what they really mean. In your hat analogy it would be like somebody tells you that you have "invalid headwear". If you haven't encountered this situation before, it will take you some time to realize that what is actually meant is that you are missing your hat. And of course then you'll have to actually fix it by getting your hat.

Moreover, I'd like to point out that once you've seen a compiler error, you remember forever what it means...

Oh yes, I agree on this. However I cannot say that I've seen all compiler errors on the compilers I regularly use. Maybe my situation is different from others, since I regularly use 3 different compiler families and then there are many version differences.

So just to make my point clear: I understand every error and warning message if
- I have encountered it before and solved then
- I look at the source code and maybe read the documentation if required
But that's different from just reading the message itself.

And a final note about the "performance warning" thing in CComVariant. IMHO this actually is a bug in CComVariant, because it should not have a constructor from bool. When you use the wizards to insert COM events and use types which are valid in COM but not covered by CComVariant, you'll get "silent failure" since the type is converted to bool and you lose all information and even may get memory leaks. I put it in between quotes, because you do get this warning so you have at least a chance to to know that there is something fishy going on. But that particular warning is very misleading. If you don't care about performance at that stage in development, are you going to look into this warning? Maybe, maybe not. Yet it produces erroneous behaviour in the final program.

With this reasoning, you would say that you don't know if you are able to drive a bicycle because you've never tested all the ways and roads on the earth, so you can't know if you are able to do so on a far australian road... IMHO, you don't need to test it to know that it won't be a problem, because you've tested enough roads and you see that you've no problem driving a bicycle.

Testing all the ways and roads of earth would be the work of the test programmer in a big project or maybe somebody else. The point is testing is done to identify runtime errors not compile time errors. Compile time errors would idicate whether the construct of your bicycle is good or not based on what parts of the bicycle you currentlly use. There is no need to worry about the parts which you don't use.

My biggest problems occur when the program compiles without any errors or warnings, but then crashes or locks up when I run it. Even then I almost always find the mistake. =D

About 8 years ago, a gov't employee that I knew had a problem with her modification of a COBOL program. I voluntered to look it over if she brought the code to my place. (I assumed that she'd make a floppy or something.) Boy, was I suprised when she showed up with a binder containing about 900 pages of code!

She had changed 3 lines of code, and the changes crashed the app.

It took longer to trace the flow of the program up to the error module, than it was to initialize the variable that she forgot!

Never heard from her again, though!