Archived

This topic is now archived and is closed to further replies.

How do you 'shut-up' warnings?

This topic is 5182 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Well, warnings often-times need to be fixed just as errors do...people who disable warnings are basically ignoring help from their compiler telling them something is wrong.

EDIT: That is called taking the address of a temporary variable...that is a bad thing. And yes, I believe you *are* supposed to create three temporary vars (if they're all to 0,0,0 though, you could just create one and reference it 3 times).

[edited by - AikonIV on October 10, 2003 8:58:48 AM]

Share this post


Link to post
Share on other sites
I always set my c++ compiler settings to Level 4 (sticter settings that expose more warnings). I wish that was the DEFAULT behavior.

Pipo can you post more code (and the warning message)? I did similar things and I want to compare any differences.

Share this post


Link to post
Share on other sites
There''s not a universal standard but many compilers support a "#pragma warning" construct. Look it up in your help and see if your compiler supports it.

Share this post


Link to post
Share on other sites
Ignoring warnings should be done with extreme caution. As others have pointed out, it''s usually a sign that something is wrong with your program. I''ve worked with programmers who happily ignore warnings because, after all, "they''re just warnings". Then they don''t understand why the program crashes unexpectedly in production.

--
Dave Mikesell
d.mikesell@computer.org
http://davemikesell.com

Share this post


Link to post
Share on other sites
quote:
DirectX9 SDK document
D3DXMATRIX matView;
D3DXMatrixLookAtLH( &matView, &D3DXVECTOR3( 0.0f, 3.0f,-5.0f ),
&D3DXVECTOR3( 0.0f, 0.0f, 0.0f ),
&D3DXVECTOR3( 0.0f, 1.0f, 0.0f ) );
g_pd3dDevice->SetTransform( D3DTS_VIEW, &matView );

quote:
Dev-C++ 5 beta (mingw??)
[ Warning ] taking address of temporary


I REALLY REALLY don''t think this warning will crash my program, or create a bug somewhere in it.
Thanks MauMan, I''ll have a look.

.lick

Share this post


Link to post
Share on other sites
use #pragma warning (disable:error#)
Some warnings are stupid...for example, warning 4786. 4786 means that you have a symbol with too long of a name. So if you use a lot of templates and you have something like type < type2 < type< a, b >,type3 < g,h,j > > > that is too long, it will generate warning # 4786. This is not bad programming, you just violated a compiler rule for exporting debugging info. The arbitrary limit on debugging symbol names is simply a lack of foresight, like the Y2K bug.


Brian J
DL Vacuum - A media file organizer I made | MM

EDIT: i guess I haven't posted template code on here for a while...HTML ate it.

[edited by - bjmumblingmiles on October 11, 2003 1:24:42 AM]

Share this post


Link to post
Share on other sites
Warnings are generally not something to worry about as much as errors but disabling them isn''t a good idea. Why? Because you did something wrong in your code and even after compiling properly it may eventually crash unexpectedly when you least expect it.

Most warnings I see involve a simple little bit of typecasting. Nothing serious, it still works, right? Suppose I goofed and placed the wrong variable in an equation. Maybe I forgot a set of parentheses or got mixed up with operator precedence without really noticing. I''ll get a warning about using an int at the wrong place. No big deal...

A week later, my code crashes. I find a horrible bug that just doesn''t seem to make sense. Can''t quite isolate it... Why does it happen? Because the warnings I was ignoring were actually important.

You can disable them if you really, REALLY want to using #pragma warning, though it''d be a bad idea unless you''re sure of what you''re doing.

Share this post


Link to post
Share on other sites
And in the case of the warning your getting, that''s a problem. Make sure you understand the warning before disabling it (in some cases I''ve had warnings due to assinging a value -1 to a unsigned int -- but in that case I knew what I was doing [for the record GCC removed that warning in recent versions])

In the case of your example, your getting an address to a temporary object. The problem is you don''t know when that object is no longer invalid, so they pointer would fail at any given time. In the case of your example you MAY be safe, but I wouldn''t want to bet on it.

Share this post


Link to post
Share on other sites
quote:
Original post by UberGeek
In the case of your example, your getting an address to a temporary object. The problem is you don't know when that object is no longer invalid, so they pointer would fail at any given time. In the case of your example you MAY be safe, but I wouldn't want to bet on it.

No, a temporary object will exist as long as the const reference that it initialises.

[ Google || Start Here || ACCU || STL || Boost || MSDN || GotW || CUJ || MSVC++ Library Fixes || BarrysWorld || E-Mail Me ]

[edited by - Lektrix on October 11, 2003 1:04:15 PM]

Share this post


Link to post
Share on other sites
quote:

No, a temporary object will exist as long as the reference/pointer that it initialises.



That''s true in Java. It''s not true in C++.


class X {
public:
X( int a, int b ) : a_(a), b_(b) {}
int a_, b_;
};

void func()
{
X * x = &X(1,2);
// at this point, "x" is alive, but points at undefined memory
}


"x" in this case is "the reference/pointer that it initializes". GCC correctly identifies this as a problem:


/tmp> cc -c foo.cpp
foo.cpp: In function `void func()'':
foo.cpp:9: warning: taking address of temporary
/tmp>


However, in the particular case that the original poster asks about, the temporary objects will exist for the lifetime of the function call, so as long as the function called doesn''t stash the pointers somewhere for later use, it''s safe. To silence the warning, either disable it with #pragma warning, or re-write the code using temporary variables on the stack. I''d prefer temporary variables on the stack, because if you disable the warning, and then introduce a problem nearby in the code, you might not hear about it. Typically, the code generated will be identical; you can force it to be identical (but no warning) by scoping the temporaries and function call using braces.

Share this post


Link to post
Share on other sites
I shouldn't have said pointer - typo. It is stated that a temporary object will exist as long as the const reference that it initialises. You shouldn't be able to apply the address-of operator to a temporary, as it is an rvalue, and therefore not addressable.

[ Google || Start Here || ACCU || STL || Boost || MSDN || GotW || CUJ || MSVC++ Library Fixes || BarrysWorld || E-Mail Me ]

[edited by - Lektrix on October 11, 2003 1:35:58 PM]

Share this post


Link to post
Share on other sites