 |
|
 |
It still does not disable errors from STL include files that are included indirectly, such etc.
Anyone has a method that works? Those warnings are really annoying.
|
|
|
|
 |
|
 |
Why not address the warnings instead of disabling them? I think warnings are there for a reason.
|
|
|
|
 |
|
 |
Because this warnings are caused by the STL provided with the microsoft compiler. Their STL implementation is causing this warnings. They have nothing to do with user code and they flood your logwindow. As a result you wont find the warnings that you have to address any more.
|
|
|
|
 |
|
 |
Hello,
When I use std::string, the compiler still issues warning 4018 (from xlocnum).
The reason for this is that the file xlocale (included in xlocnum) sets the warning 4018 back to the default. This is also the case for warning 4663.
Multiply it by infinity and take it beyond eternity and you'll still have no idea about what I'm talking about.
|
|
|
|
 |
|
 |
I was able to compile all of the above code without including .
I lowered my warning level to 3 while including the STL headers like this:
#ifndef STL_STRING_HEADER
#define STL_STRING_HEADER
//
#pragma warning( push, 3 )
#pragma warning( disable: 4018 )
#pragma warning( disable: 4100 )
#pragma warning( disable: 4146 )
#pragma warning( disable: 4244 )
#pragma warning( disable: 4245 )
#pragma warning( disable: 4511 )
#pragma warning( disable: 4512 )
#pragma warning( disable: 4663 )
#pragma warning( disable: 4710 )
#pragma warning( disable: 4786 )
#include
#pragma warning( push )
#endif // STL_STRING_HEADER
|
|
|
|
 |
|
 |
At first thank you (all) for your sharing ...
The thing I found tonight, after reading your
posts and trying to get it to work is:
The annoying warnings problem consists of TWO problems!
Things to do:
1. Create a file where you disable the warnings
that annoy you by setting the needed '#pragma ...'
lines and include it right before you include any
STL files like 'vetor.h' or 'map.h', etc.
In 'STLport' I found two (example?) files that you can use:
'stlport-4.5.3\stlport\config\_msvc_warnings_off.h'
and
'stlport-4.5.3\src\vc_warning_disable.h'.
But if you want to add or modify the content you should
copy one of that files to your project.
That solves the problem of annoying warning
messages, but if you use precompiled headers
you have to do a second thing to avoid the
(MSVC-Bug?!?) warnings again.
2. The 'C4786 warning' coming up again in your precompiled
header (StdAfx.cpp/.h) comes from 'std::string' the only fix
I found was to create a wrapper ('class') for that string ('type'):
// file 'StringWrapper.h'
class StringWrapper : public std::string
{
public:
// overload standard ctor function
StringWrapper()
{
std::string::string();
};
// overload copy ctor function
StringWrapper(StringWrapper& TheCopy)
{
std::string::string((std::string&) TheCopy);
};
// overload init ctor function
StringWrapper(const char * pTheInitText)
{
std::string::string(pTheInitText);
};
};
Maybe you have to insert more overloading functions ...
The compiler will tell you if needed
Now you replace all 'std::string' occurrences to 'StringWrapper'
I used before: 'typedef std::string MyString;'
That became: 'typedef StringWrapper MyString;'
And now all my 'lists', 'vectors' and 'maps' that contained
the (STLport) 'strings' stoped annoying me
BTW:
The compiler optimizes the single line constructor calls
declarated in 'StringWrapper' to be 'inline'.
If you think there could be anyway a performance problem
with that, you can write something like this:
#ifdef _DEBUG
// string type in debug mode
typedef StringWrapper MyString;
#else
// string type in release mode
typedef std::string MyString;
#endif
That works for me on MSVC 6 with installed STLport.
Maybe this is usefull to someone ... good night
|
|
|
|
 |
|
 |
At first thank you (all) for your sharing ...
The thing I found tonight, after reading your
posts and trying to get it to work is:
The annoying warnings problem consists of TWO problems!
Things to do:
1. Create a file where you disable the warnings
that annoy you by setting the needed '#pragma ...'
lines and include it right before you include any
STL files like or <map.h>, etc.
In 'STLport' I found two (example?) files that you can use:
'stlport-4.5.3\stlport\config\_msvc_warnings_off.h'
and
'stlport-4.5.3\src\vc_warning_disable.h'.
But if you want to add or modify the content you should
copy one of that files to your project.
That solves the problem of annoying warning
messages, but if you use precompiled headers
you have to do a second thing to avoid the
(MSVC-Bug?!?) warnings again.
2. The 'C4786 warning' coming up again in your precompiled
header (StdAfx.cpp/.h) comes from 'std::string' the only fix
I found was to create a wrapper ('class') for that string ('type'):
// file 'StringWrapper.h'
class StringWrapper : public std::string
{
public:
// overload standard ctor function
StringWrapper()
{
std::string::string();
};
// overload copy ctor function
StringWrapper(StringWrapper& TheCopy)
{
std::string::string((std::string&) TheCopy);
};
// overload init ctor function
StringWrapper(const char * pTheInitText)
{
std::string::string(pTheInitText);
};
};
Maybe you have to insert more overloading functions ...
The compiler will tell you if needed
Now you replace all 'std::string' occurrences to 'StringWrapper'
I used before: 'typedef std::string MyString;'
That became: 'typedef StringWrapper MyString;'
And now all my 'lists', 'vectors' and 'maps' that contained
the (STLport) 'strings' stoped annoying me
BTW:
The compiler optimizes the single line constructor calls
declarated in 'StringWrapper' to be 'inline'.
If you think there could be anyway a performance problem
with that, you can write something like this:
#ifdef _DEBUG
// string type in debug mode
typedef StringWrapper MyString;
#else
// string type in release mode
typedef std::string MyString;
#endif
That works for me on MSVC 6 with installed STLport.
Maybe this is usefull to someone ... good night
|
|
|
|
 |
|
 |
STL fit is THE solution for this problem!
Check it at http://www.bdsoft.com/tools/stlfilt.html
Jonathan de Halleux, Belgium.
|
|
|
|
 |
|
 |
STLFilt is a very useful tool, but it does not solve this problem.
|
|
|
|
 |
|
 |
Create a new directory (e.g. "stlwrap") to store wrapper headers. Add this directory to your compiler's search path before the path to the standard library. Create wrapper headers in this directory for each stl header you ever use. For instance, if you use the vectors from stl, you would want to create a file "vector" in your wrapper directory, containing something like the following:
#if !defined(_STL_WRAPPERS_DISABLED)
# if !defined(__STL_WRAPPER_VECTOR_INCLUDED__)
# define __STL_WRAPPER_VECTOR_INCLUDED__
# pragma warning ( push, 3 )
# pragma warning ( disable : 4018 4284 4146 4290 )
# include "../vector"
# pragma warning ( pop )
# endif // !defined(__STL_WRAPPER_VECTOR_INCLUDED__)
#else // !defined(_STL_WRAPPERS_DISABLED)
# include "../vector"
#endif
The four disabled warnings are a result of me using a script to generate new header files. If you have access to unix (clone), you can use the following piece of code to generate new headers:
#!/bin/bash
if [ $# -eq 0 ]; then
echo "You should provide at least one filename as argument."
fi
for f in $*; do
echo "Creating wrapper for $f..."
rm -f $f
touch $f
chmod 644 $f
F=`echo $f | capitalize -u`
echo "// Wrappers created by Boye Hoeverstad to remove warnings" >>$f
echo "// in standard library when compiling with Visual C++ 6 and warning level 4." >>$f
echo -e "\n\n" >>$f
echo "#if !defined(_STL_WRAPPERS_DISABLED)" >>$f
echo "" >>$f
echo "# if !defined(__STL_WRAPPER_${F}_INCLUDED__)" >>$f
echo "# define __STL_WRAPPER_${F}_INCLUDED__" >>$f
echo "# pragma warning ( push, 3 )" >>$f
echo "# pragma warning ( disable : 4018 4284 4146 4290 )" >>$f
echo "# include \"../$f\"" >>$f
echo "# pragma warning ( pop )" >>$f
echo "# endif // !defined(__STL_WRAPPER_${F}_INCLUDED__)" >>$f
echo "" >>$f
echo "#else // !defined(_STL_WRAPPERS_DISABLED)" >>$f
echo "# include \"../$f\"" >>$f
echo "#endif" >>$f
done
I find this solution more flexible and easier to use when working in a team and on several projects. Add the files to a zip and put them on the web, and everybody in your company can use them.
Cheers,
Boye
|
|
|
|
 |
|
 |
Brilliant, thanks a lot. At least I don't have to modify my source now
|
|
|
|
 |
|
 |
First, great article... This is something that has been bugging me for quite a while, but never enough to put everything else on the backburner and figure this out on my own.
Second, just a little gripe. This is probably a moot point, but...
using namespace std; // ???
You surely are not using that in your REAL code!? I cannot begin to tell you the evils of that line.
For those less educated, a proper way of using namespace elements would be to qualify them explicitly when and where used.
// i.e.
#include
std::string s = "some value";
An acceptable shortcut would be to declare usage of elements that are used in the scope of this file.
// i.e.
#include
using std::string;
string s = "some value";
The second method will cause some problems in VC6.0 when using containers and their associated iterators.
// i.e.
#include
using std::list;
list::iterator it;
Compiler will complain that list is not a valid namespace. You can easily fix that by explicitly declaring its scope or declare its usage.
// first case
std::list::iterator it;
// second case
using std::list;
list::iterator it;
Stephen Slezic
(@)
|
|
|
|
 |
|
 |
I've always agreed that using namepsace std is a "bad thing" on principle, but why is it actually evil ?
It's one of those things you take for granted, but my gut feeling is that it is the C++ committee's fault for allowing "using namespace" in the first place...
Thanks
Jimbo
|
|
|
|
 |
|
 |
using namespace std is bad in the header files. It's ok in the CPP files, because then you can deal with it on your own.
However, in the header files, anyone who directly or indirectly includes a header file with using namespace std (or any other namespace or using declaration for that matter) will inherit this declaration. This can cause to some hard-to-trace and unusual ambiguous or duplicate definition errors. While typically easy to work around in your own code, other libraries that you are using may be conflicting with std identifiers.
Some more info and explanation.
- Oleg
|
|
|
|
 |
|
 |
// Assumption: Warning level is 4 by default
//
#pragma warning(push, 3)
// include STL files here
#pragma warning(pop)
Even when you are disabling several warnings it is possible to
restore all of them to the previous level with a single pop e.g.
#pragma warning(push)
#pragma warning(disable: 999 666 1234)
#pragma warning(disable: 4321)
#pragma warning(pop)
These methods are documented in MSDN.
|
|
|
|
 |
|
 |
Unfortunately for me, I have tried exactly this and I haven't got it to work.
Bugs in VC6? My incompetence? I don't know.
What I have tried with a lot more success is that I set the warning level to 4 and include all the STL files in stdafx.h (my precompiled header). I then set the warning level for stdafx.cpp only to 3 (or 0, 1 or 2).
My reasoning being this: The files I include in my precompiled header I don't have any control of. Therefore I am not concerned about warnings since I can't modify them anyway. However, my own files I am most concerned in and I wish to compile all of them using warning level 4.
|
|
|
|
 |
|
 |
I've found this way to work quite well but I prefer to put the
pragmas right into stdafx.h. Quite possibly changing the
warning level on stdafx.cpp stops the warning on that cpp
files but they get emitted for all other files. Can't verify
this because I've started using VC.net now.
|
|
|
|
 |
|
 |
Gautam Sarup wrote: #pragma warning(push, 3)
// include STL files here
#pragma warning(pop)
Wow, thanks for the info. I just got rid of just about every STL warning the complier was spitting out. Turns out I have a couple of type cast problems (they where buried in all of the other warnings ).
ZeePain! wrote: This seems like one of those programs that started small, grew incrementally, building internal pressure, and finally barfed all over its source code sneakers. Or something.
thedailywtf.com[^]
|
|
|
|
 |
|
 |
Warning 4786 can be disabled (although microsoft says it can't).
Include this at the beginning of stdafx.h (or somewhere before including STL files):
#pragma warning (disable : 4786)
#include
Don't ask how the inclusion of iostream does it's job.
Regards
Andre
|
|
|
|
 |
|
 |
Hi!
I recommend to disable warning 4503 too:
#pragma warning(disable : 4786 4503)
I got no negative effects with that .
-----
Compiler Warning (level 1) C4503
'identifier' : decorated name length exceeded, name was truncated
The decorated name was longer than the maximum the compiler allows (247), and was truncated. To avoid this warning and the truncation, reduce the number of arguments or name length of identifiers used.
(Best Regards,)
Patrick Hoffmann
-------------------------------------------------------------------------------
Technical and Operations Manager, System Analyst, Software Architect
PGP: http://www.novacom.net/pgp/PatrickHoffmann.asc
-------------------------------------------------------------------------------
veturo, der kostenlose NOVACOM Routenplaner für Europa... http://www.veturo.de
--------------------------------------------------------------------------
|
|
|
|
 |
|
 |
Looks like Andre's fix didn't convert properly to html. It should look like: #pragma warning (disable : 4786) #include <iostream> I just tried his fix and it worked! Thanks, Andre.
|
|
|
|
 |
|
 |
I've got it working under EVC with just having the #pragma...
|
|
|
|
 |
|
 |
To avoid including something you don't need, I cooked up some code until these remains were left. This seems to make #pragma warning(disable:4786) work reliably. Any attempy to further simplify this bizarre code thwarts its effect.
#if defined __cplusplus
namespace shutting_up_MSVC_warning_C4786 {
template <typename T> struct Nut {
virtual void f() {
new T[1];
}
};
struct Nuts : Nut< Nut< Nut<int> > > {
};
}
#endif
|
|
|
|
 |
|
 |
Man, this had been bugging me for so long! The iostream trick worked for me
A programmer with a dream can accomplish anything. So, start by implementing your castle in the clouds and then working on its interface to a foundation
Quote by: Jeremy Pemberton-Pigott
|
|
|
|
 |
|
 |
Yes, but not in one file, please!!!
You wrote:
"To use it in your code (I always place it the precompiled header file)"
I NEVER use precompiled headers because it introduces unnecessary dependencies (and more often than not cause more problems than it solves). Any file that includes stdafx.h CAN NOT BE REUSED! To solve this you could of course reuse a special stdafx.h that includes ALL FILES YOU'LL EVER NEED! No, no, no.
OK, got that off my chest
Now for the rest... May I suggest you create a single header file for each STL header you want to encapsulate. If you move the original STL headers to a "private" place (so they wont be picked up by the compiler) and name YOUR files the exact same as the originals in a place where the compiler WILL find them, you're half way there. As an example I use your wrapper of :
*** In your file :
// STL neccessary declaration for string
// warning numbers get enabled in yvals.h
#pragma warning(push)
#include
#pragma warning(disable: 4018) // signed/unsigned mismatch
#pragma warning(disable: 4100) // unreferenced formal parameter
#pragma warning(disable: 4146) // unary minus operator applied to unsigned type, result still unsigned
#pragma warning(disable: 4244) // 'conversion' conversion from 'type1' to 'type2', possible loss of data
#pragma warning(disable: 4245) // conversion from 'type1' to 'type2', signed/unsigned mismatch
#pragma warning(disable: 4511) // 'class' : copy constructor could not be generated
#pragma warning(disable: 4512) // 'class' : assignment operator could not be generated
#pragma warning(disable: 4663) // C++ language change: to explicitly specialize class template 'vector'
#pragma warning(disable: 4710) // 'function' : function not inlined
#pragma warning(disable: 4786) // identifier was truncated to 'number' characters in the debug
information
#pragma warning(disable: 4514) // unreferenced inline/local function has been removed
#pragma warning(disable: 4710) // 'function' : function not inlined
#pragma warning(disable: 4786) // identifier was truncated to 'number' characters in the debug information
#include
#pragma warning(pop)
NOTE: I moved the last #pragmas up before #include because I thought you had made a mistake.
Please note that these #pragmas are in effect for ALL code following the inclusion of this header (same for your original).
Needless to say I haven't tried this out and I make no guarantee as to the usefulness or quality of the above
|
|
|
|
 |