using std::string produces copious warnings 
Author Message
 using std::string produces copious warnings

We have a policy at our company that compiles must be warning free even at
warning level 4 (so that a warning that that really be a flaw is not missed)

So why when I compile this program (VC++ 6.0):

#include <string>

std::string mystring;

int main(int, char**)
{
 return 0;

Quote:
}

Do I get this output? What am I suppose to do to prevent these warnings? Any
suggestions must adhere to our policy, so don't suggest warning level 3, or
#pragma's please.

Compiling...
stdstring.cpp
c:\program files\microsoft visual studio\vc98\include\xmemory(39) : warning
C4100: '_P' : unreferenced formal parameter
c:\program files\microsoft visual studio\vc98\include\xmemory(41) : warning
C4100: '_P' : unreferenced formal parameter
c:\program files\microsoft visual studio\vc98\include\xlocale(242) : warning
C4511: 'codecvt_base' : copy constructor could not be generated
        c:\program files\microsoft visual studio\vc98\include\xlocale(223) : see
declaration of 'codecvt_base'
c:\program files\microsoft visual studio\vc98\include\xlocale(242) : warning
C4512: 'codecvt_base' : assignment operator could not be generated
        c:\program files\microsoft visual studio\vc98\include\xlocale(223) : see
declaration of 'codecvt_base'
c:\program files\microsoft visual studio\vc98\include\xlocale(296) : warning
C4663: C++ language change: to explicitly specialize class template 'codecvt' use
the following syntax:
        template<> class codecvt<unsigned short,char,int> ...
c:\program files\microsoft visual studio\vc98\include\xlocale(398) : warning
C4511: 'codecvt<unsigned short,char,int>' : copy constructor could not be
generated
        c:\program files\microsoft visual studio\vc98\include\xlocale(296) : see
declaration of 'codecvt<unsigned short,char,int>'
c:\program files\microsoft visual studio\vc98\include\xlocale(398) : warning
C4512: 'codecvt<unsigned short,char,int>' : assignment operator could not be
generated
        c:\program files\microsoft visual studio\vc98\include\xlocale(296) : see
declaration of 'codecvt<unsigned short,char,int>'
c:\program files\microsoft visual studio\vc98\include\xlocale(387) : warning
C4018: '<' : signed/unsigned mismatch
c:\program files\microsoft visual studio\vc98\include\xlocale(420) : warning
C4511: 'ctype_base' : copy constructor could not be generated
        c:\program files\microsoft visual studio\vc98\include\xlocale(410) : see
declaration of 'ctype_base'
c:\program files\microsoft visual studio\vc98\include\xlocale(420) : warning
C4512: 'ctype_base' : assignment operator could not be generated
        c:\program files\microsoft visual studio\vc98\include\xlocale(410) : see
declaration of 'ctype_base'
c:\program files\microsoft visual studio\vc98\include\xlocale(519) : warning
C4663: C++ language change: to explicitly specialize class template 'ctype' use
the following syntax:
        template<> class ctype<char> ...
c:\program files\microsoft visual studio\vc98\include\xlocale(611) : warning
C4511: 'ctype<char>' : copy constructor could not be generated
        c:\program files\microsoft visual studio\vc98\include\xlocale(519) : see
declaration of 'ctype<char>'
c:\program files\microsoft visual studio\vc98\include\xlocale(611) : warning
C4512: 'ctype<char>' : assignment operator could not be generated
        c:\program files\microsoft visual studio\vc98\include\xlocale(519) : see
declaration of 'ctype<char>'
c:\program files\microsoft visual studio\vc98\include\xlocale(552) : warning
C4100: '_D' : unreferenced formal parameter
c:\program files\microsoft visual studio\vc98\include\xlocale(554) : warning
C4100: '_D' : unreferenced formal parameter
c:\program files\microsoft visual studio\vc98\include\ostream(50) : warning
C4512: 'sentry' : assignment operator could not be generated
        c:\program files\microsoft visual studio\vc98\include\ostream(38) : see
declaration of 'sentry'
        c:\program files\microsoft visual studio\vc98\include\ostream(373) : see
reference to class template instantiation 'std::basic_ostream<char,struct
std::char_traits<char> >' being compiled
c:\program files\microsoft visual studio\vc98\include\ostream(50) : warning
C4512: 'sentry' : assignment operator could not be generated
        c:\program files\microsoft visual studio\vc98\include\ostream(38) : see
declaration of 'sentry'
        c:\program files\microsoft visual studio\vc98\include\ostream(379) : see
reference to class template instantiation 'std::basic_ostream<unsigned
short,struct std::char_traits<unsigned short> >' being compiled
c:\program files\microsoft visual studio\vc98\include\xlocale(513) : warning
C4511: 'ctype<unsigned short>' : copy constructor could not be generated
        c:\program files\microsoft visual studio\vc98\include\istream(573) : see
reference to class template instantiation 'std::ctype<unsigned short>' being
compiled
c:\program files\microsoft visual studio\vc98\include\xlocale(513) : warning
C4512: 'ctype<unsigned short>' : assignment operator could not be generated
        c:\program files\microsoft visual studio\vc98\include\istream(573) : see
reference to class template instantiation 'std::ctype<unsigned short>' being
compiled
c:\program files\microsoft visual studio\vc98\include\streambuf(181) : warning
C4100: '_Loc' : unreferenced formal parameter
        c:\program files\microsoft visual studio\vc98\include\streambuf(182) :
while compiling class-template member function 'void __thiscall
std::basic_streambuf<char,struct std::char_traits<char> >::imbue(const class
std::locale &)'
c:\program files\microsoft visual studio\vc98\include\streambuf(181) : warning
C4100: '_Loc' : unreferenced formal parameter
        c:\program files\microsoft visual studio\vc98\include\streambuf(182) :
while compiling class-template member function 'void __thiscall
std::basic_streambuf<unsigned short,struct std::char_traits<unsigned short>

Quote:
>::imbue(const class std::loca

le &)'
c:\program files\microsoft visual studio\vc98\include\xstring(600) : warning
C4245: 'initializing' : conversion from 'const int' to 'const unsigned int',
signed/unsigned mismatch
        c:\program files\microsoft visual studio\vc98\include\xmemory(59) : while
compiling class-template static data member 'const unsigned int
std::basic_string<char,std::char_traits<char>,std::allocator<char> >::npos'

stdstring.obj - 0 error(s), 22 warning(s)



Fri, 03 Oct 2003 21:26:56 GMT  
 using std::string produces copious warnings

Quote:

> We have a policy at our company that compiles must be warning free even at

warning level 4 (so that a warning that that really be a flaw is not missed)

Quote:

> So why when I compile this program (VC++ 6.0):

> #include <string>
> std::string mystring;
> int main(int, char**)
> {
>  return 0;
> }

> Do I get this output? What am I suppose to do to prevent these warnings? Any
> suggestions must adhere to our policy, so don't suggest warning level 3, or
> #pragma's please.

Unfortunately, I was not given the requirement that the library should be silent
at warning level 4 when Microsoft asked me to package it for VC++. Even more
unfortunately, Dinkumware was unable to provide upgrades for a spell. But V7
should be *much* quieter at level 4. If you can't wait, I fear your only
alternative is to license the upgrade library we provide at our web site.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com



Fri, 03 Oct 2003 22:07:45 GMT  
 using std::string produces copious warnings
P.J.,

Is this for real? I truely don't want to offend, but WHAT would make you
think that Microsoft WOULDN'T want their STL to compile clean at warning
level 4? Please don't think I'm ignorant about business practices. I
understand that sometimes we ship shoddy work because we're under time
constraints - and if the requirement was not in the contract, then it's the
first thing to get cut in a pressing schedule. But please don't try to
convince us that you did this because you didn't think Microsoft would care
or want clean /W4 compilations. ;-)

John


Quote:



> > We have a policy at our company that compiles must be warning free even
at
> warning level 4 (so that a warning that that really be a flaw is not
missed)

> > So why when I compile this program (VC++ 6.0):

> > #include <string>
> > std::string mystring;
> > int main(int, char**)
> > {
> >  return 0;
> > }

> > Do I get this output? What am I suppose to do to prevent these warnings?
Any
> > suggestions must adhere to our policy, so don't suggest warning level 3,
or
> > #pragma's please.

> Unfortunately, I was not given the requirement that the library should be
silent
> at warning level 4 when Microsoft asked me to package it for VC++. Even
more
> unfortunately, Dinkumware was unable to provide upgrades for a spell. But
V7
> should be *much* quieter at level 4. If you can't wait, I fear your only
> alternative is to license the upgrade library we provide at our web site.

> P.J. Plauger
> Dinkumware, Ltd.
> http://www.dinkumware.com



Sat, 04 Oct 2003 05:08:35 GMT  
 using std::string produces copious warnings

Quote:

> Is this for real? I truely don't want to offend, but WHAT would make you
> think that Microsoft WOULDN'T want their STL to compile clean at warning
> level 4?

1) They didn't tell me, for whatever reason.

2) At the time, VC++ was just one of several compilers I was packaging
for. I was personally unaware of such niceties as changeable warning
levels, or the cultural significance of level 4.

Once I became aware of the lapse, I fixed it. And I naturally provided
the fixed version to Microsoft as part of our support agreement.

Quote:
>         Please don't think I'm ignorant about business practices. I
> understand that sometimes we ship shoddy work because we're under time
> constraints - and if the requirement was not in the contract, then it's the
> first thing to get cut in a pressing schedule. But please don't try to
> convince us that you did this because you didn't think Microsoft would care
> or want clean /W4 compilations. ;-)

I'm not trying to convince you of anything. I gave a factual reply to
a query.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com



Sat, 04 Oct 2003 06:05:30 GMT  
 using std::string produces copious warnings


Quote:
>We have a policy at our company that compiles must be warning free even at
>warning level 4 (so that a warning that that really be a flaw is not
missed)

>So why when I compile this program (VC++ 6.0):

Microsoft didn't agree to your companies policy.  They're under no
requirement to make sure code compiles without any warnings.

Quote:
>Do I get this output? What am I suppose to do to prevent these warnings?
Any
>suggestions must adhere to our policy, so don't suggest warning level 3, or
>#pragma's please.

Then you have no recourse but to not use the STL that comes with VC.

Your companies policy is too restrictive.  There are many kinds of warnings
that the compiler produces that are simply informative (as some of these
are, though they are annoying).

Further, you can't use VC at all if your company policy dictates that no
#pragmas can be used, since MS's headers use #pragma's quite generously in
every header file.



Sat, 04 Oct 2003 06:18:58 GMT  
 using std::string produces copious warnings
I think the idea is no warnings by internal code unless one has a good
reason (which seem quite rare).  The problem is that all the Microsoft
warnings cause so much clutter.  Maybe the STL error message filter
mentioned by Leor Zolman would be helpful.  Anyone tried it?

Jeff


Quote:


> >We have a policy at our company that compiles must be warning free even
at
> >warning level 4 (so that a warning that that really be a flaw is not
> missed)

> >So why when I compile this program (VC++ 6.0):

> Microsoft didn't agree to your companies policy.  They're under no
> requirement to make sure code compiles without any warnings.

> >Do I get this output? What am I suppose to do to prevent these warnings?
> Any
> >suggestions must adhere to our policy, so don't suggest warning level 3,
or
> >#pragma's please.

> Then you have no recourse but to not use the STL that comes with VC.

> Your companies policy is too restrictive.  There are many kinds of
warnings
> that the compiler produces that are simply informative (as some of these
> are, though they are annoying).

> Further, you can't use VC at all if your company policy dictates that no
> #pragmas can be used, since MS's headers use #pragma's quite generously in
> every header file.



Sun, 05 Oct 2003 00:45:32 GMT  
 using std::string produces copious warnings
P.J.,

I'm really sorry. By the tone of your response, it appears that I offended
you. My real point is this:

Most compilers provide multiple warning levels and they have since the early
days of computing. I personally like to believe that warnings can be
disabled in groups in this manner so that legacy code will compile cleanly
under newer tools - in other words, it's a shallow form of marketing trick
used to make new compilers look good on old code.

With that assertion in mind, if you have a compiler that will, with a
command-line switch, warn you about potential pitfalls in your code,
wouldn't you want to use that feature? I know some programmers who don't use
the highest warning level, but when cornered, their reasons always come down
to something like, "I couldn't figure out what the compiler was trying to
tell me, so I told it to shut up."

In general, this attitude scares me. The problem with it is that computers
(as the old addage goes) do exactly what you tell them to do. If you tell
them to do something wrong, you should consider yourself lucky if they
attempt to discern what you had in mind and warn you about your potentially
wrong code so you can catch a bug before your customers do.

The fellow who originated this thread stated that his company has a policy
that the highest warning level must be enabled and that he can't use pragmas
to disable individual warnings. For the most part, I agree with this policy,
not because it has some "cultural" significance, but rather because it
forces programmers to understand their code in much greater detail. This
understanding almost always leads to cleaner code in the final product.

Where I disagree with strict enforcement of this policy is when you have a
coding style that the compiler disagrees with on some level. You thoroughly
understand the nature of the warning, yet you like your code the way it is.
In this case, I will use a pragma to disable the individual warning, but I
still use warning level 4.

In fact, in my recent endeavours to use the STL that ships with VC6, I've
gone as far as to use warning level 4 globally, but use the #pragma
warning(push, 3) and #pragma warning(pop) around the inclusion of STL
headers. I truely dislike this because it clutters up my code with
statements whose only function are to fix problems with header files that
ship with the compiler. However, it's better than disabling an entire
category of warnings across my own code, where I'm perhaps not as sure about
what's going on as the standard library writers were.

In the final analysis, I believe there is something inately wrong with a
tool that disagrees with itself, but you probably have a different viewpoint
simply because you don't perceive your STL libraries to be as closely
related to Microsoft tools as Microsoft customers perceive them to be.

Sorry for the lengthy response,
John



Quote:

> > Is this for real? I truely don't want to offend, but WHAT would make you
> > think that Microsoft WOULDN'T want their STL to compile clean at warning
> > level 4?

> 1) They didn't tell me, for whatever reason.

> 2) At the time, VC++ was just one of several compilers I was packaging
> for. I was personally unaware of such niceties as changeable warning
> levels, or the cultural significance of level 4.

> Once I became aware of the lapse, I fixed it. And I naturally provided
> the fixed version to Microsoft as part of our support agreement.

> >         Please don't think I'm ignorant about business practices. I
> > understand that sometimes we ship shoddy work because we're under time
> > constraints - and if the requirement was not in the contract, then it's
the
> > first thing to get cut in a pressing schedule. But please don't try to
> > convince us that you did this because you didn't think Microsoft would
care
> > or want clean /W4 compilations. ;-)

> I'm not trying to convince you of anything. I gave a factual reply to
> a query.

> P.J. Plauger
> Dinkumware, Ltd.
> http://www.dinkumware.com



Sun, 05 Oct 2003 12:47:54 GMT  
 using std::string produces copious warnings

Quote:

> In the final analysis, I believe there is something inately wrong with a
> tool that disagrees with itself, but you probably have a different viewpoint
> simply because you don't perceive your STL libraries to be as closely
> related to Microsoft tools as Microsoft customers perceive them to be.

Not at all. I agree that the library is an integral part of the compiler.
You asked why the library headers are not quiet at warning level 4 and I
explained that it was simply an oversight. We've corrected that oversight
in the upgrade library we license directly. It is also corrected in V7.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com



Mon, 06 Oct 2003 22:11:47 GMT  
 using std::string produces copious warnings

...

Quote:
> The fellow who originated this thread stated that his company has a policy
> that the highest warning level must be enabled and that he can't use pragmas
> to disable individual warnings. For the most part, I agree with this policy,
> not because it has some "cultural" significance, but rather because it
> forces programmers to understand their code in much greater detail. This
> understanding almost always leads to cleaner code in the final product.

I can agree with the policy if it does not require that the compilations should
not generate warnings. Not all warnings in modern compilers have something to do
with actual problems in the code.

Quote:
> In the final analysis, I believe there is something inately wrong with a
> tool that disagrees with itself, but you probably have a different viewpoint
> simply because you don't perceive your STL libraries to be as closely
> related to Microsoft tools as Microsoft customers perceive them to be.

No. AFAIK both Dinkumware and MS do perceive the library as part of the
compiler.

As a matter of fact that kind of policies are a problem. As of my very best
knowledge MS is working {*filter*} having VC7 compile clean of W4 level warnings
with all standard headers and under most if not all switch settings.

However a lot depends on the policy of the user. Not everibody knows that W4
does not mean "all warnings on". With VC7 you can easily have /W4 compilations
with no warnings. A bit harder would be to have it compile silently with /Wall.
And personally I believe that not all code could be made to compile silently
with /Wall. But /Wall is not accessible as an IDE check box setting, so maybe
there will be no policy that requires that.

Of course I'd be very happy if headers that come with the compiler (at least the
STL headers, leaving MFC and other Windows specific stuff out) could compile
with no warning at all under as many switch settings as possible. Expecially if
they do so with as fiew pragmas as possible (in the headers themself, I mean).
But I will not be desperate if this is not the case.

The policy I adopt is to have the "standard" warning settings to as hight as
possible in order to catch actual problems and not be annoying (that used to be
/W3 for VC6 and is /W3, /W4 or /Wall depending on the project for VC7) and once
upon a time have a full rebuild under /Wall and go investigate every single
warning I get just to be sure. Then I do not clutter code with pragmas, I just
revert to a more sensible warning level. My experience under VC6 is that most of
/W4 warnings are just no-problems, /W3 is a workable standard setting. And I
expect /W4 to be standard on VC7 and /Wall to be just a bit too paranoic.

--

Andrea Ferro

---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info http://www.*-*-*.com/



Sun, 12 Oct 2003 01:28:40 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. Warnings for std::vector<std::string>

2. convert non std::string to std::string

3. using std::string and string::npos...

4. WARNING! std:string Weird Behaviour Found

5. Warnings using STL Map<string,string>

6. C4251 warning using std::vector<std::string>

7. Calling an unmanaged DLL function that uses a std::string parameter

8. using std::string with windows classes gives error

9. convert between std::string and std::wstring

10. problem using std::string as base class

11. bug in vc++ 5.0 using std::string

12. problem using std::string in exported class to be puit in a DLL

 

 
Powered by phpBB® Forum Software