 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Michi
Guest
|
 Posted: Fri Nov 18, 2005 12:06 am Post subject: Visual Studio 8 deprecates functions in ::std :-( |
 |
|
Visual Studio 8 has introduced some interesting warnings. For example,
the expression
::std::equal(m.begin(), m.end(), p)
raises the following warning:
C:Program FilesMicrosoft Visual Studio 8VCincludexutility(2674) :
warning C4996: 'std::_Equal' was declared deprecated
C:Program FilesMicrosoft Visual Studio
8VCincludexutility(2661) : see declaration of 'std::_Equal'
Message: 'You have used a std:: construct that is not safe. See
documentation on how to use the Safe Standard C++ Library'
Wow. Thanks a lot. The same thing happens for a whole raft of other
standard functions, such as copy, set_difference, replace, remove,
merge, etc.
Note the interesting wording: 'std::_equal' was declared deprecated. I
was under the distinct impression that only the C++ standards committee
could deprecate anything in the std namespace...
The work-around is not pretty either. You have to basically redefine
all the affected templates:
namespace PortabilityHacks
{
template<class InputIterator1, class InputIterator2>
bool
equal(InputIterator1 first1, InputIterator1 last1, InputIterator2
first2)
{
#if _WIN32 && _MSC_VER == 1400
return ::stdext::unchecked_equal(first1, last1, first2);
#else
return ::std::copy(first1, last1, first2);
#endif
}
}
The fact that unchecked_equal() isn't documented doesn't help either.
(Although, to be fair, some of the other "deprecated" templates do have
documentation for the checked and unchecked versions in the stdext
namespace.)
Having written the workaround, I can go and add the PortabilityHacks
namespace to all points where I call one of the standard template
functions that MS have decided to deprecate. My big thanks for this
change go to the MS C++ team: you have just broken my code in many
hundreds of places :-(
I can disable the warning by setting the warning level to 4, but that
doesn't really help me. For one, I don't like to disable warnings;
certainly not with a pragma in a header file because that affects all
the customer code that includes my header file, and also not with a
compiler option. I like my code to compile clean, without warnings.
If this misfeature is the Visual C++ team's idea of standard
compliance, I'm not impressed :-(
Michi.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
wizofaus@hotmail.com
Guest
|
| Posted: Fri Nov 18, 2005 10:23 am Post subject: Re: Visual Studio 8 deprecates functions in ::std :-( |
|
|
Michi wrote:
| Quote: | Visual Studio 8 has introduced some interesting warnings. For example,
the expression
::std::equal(m.begin(), m.end(), p)
raises the following warning:
C:Program FilesMicrosoft Visual Studio 8VCincludexutility(2674) :
warning C4996: 'std::_Equal' was declared deprecated
C:Program FilesMicrosoft Visual Studio
8VCincludexutility(2661) : see declaration of 'std::_Equal'
Message: 'You have used a std:: construct that is not safe. See
documentation on how to use the Safe Standard C++ Library'
|
I just downloaded Vis Studio Express 2005 and compiled:
#include <iostream>
#include <algorithm>
#include <deque>
#pragma warning(push, 4)
int main()
{
std::deque<int> a, b;
if (std::equal(a.begin(), a.end(), b.begin()))
std::cout << _MSC_VER << std::endl;
}
With no warnings at all...FWIW, it prints 1400.
I have to agree with MS though that the design decision behind
functions like std::equal() and std::copy() (assuming the "output"
range is are the same size as the "input" range) is questionable at
best. In fact, I would fully expect std::equal( ) to be able to take
two separate iterator ranges, and as a first check, confirm the ranges
are the same size.
std::copy()'s a little more difficult, as it could logically either a)
truncate the results if the output range was smaller or b) generate an
error (throw an exception?). I would tend to prefer a), with good
implementations supplying a run-time warning*.
Are there plans for the next C++ to have "safe" versions of these
functions?
* How many C++ libraries, especially including implementions of the std
library, have much in the way of run-time warnings? MFC does, and I've
been saved by them more than once. It's a little surprising I've never
seen a "warn_assert" type thing be proposed.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Jakob Bieling
Guest
|
| Posted: Fri Nov 18, 2005 10:26 am Post subject: OT: Visual Studio 8 deprecates functions in ::std :-( |
|
|
"Michi" <michi (AT) zeroc (DOT) com> wrote
| Quote: | certainly not with a pragma in a header file because that affects all
the customer code that includes my header file, and also not with a
compiler option. I like my code to compile clean, without warnings.
|
Push the warning level at the beginning of your header, disable the
warnings and pop the old warning state again. Then only your code will
be affected by the pragmas.
This does not make VS8 any better, but at least it is an acceptable
work-around.
hth
--
jb
(reply address in rot13, unscramble first)
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Dilip
Guest
|
|
| Back to top |
|
|
Jeffrey Schwab
Guest
|
| Posted: Fri Nov 18, 2005 4:33 pm Post subject: Re: Visual Studio 8 deprecates functions in ::std :-( |
|
|
Michi wrote:
| Quote: | Visual Studio 8 has introduced some interesting warnings. For example,
the expression
::std::equal(m.begin(), m.end(), p)
raises the following warning:
C:Program FilesMicrosoft Visual Studio 8VCincludexutility(2674) :
warning C4996: 'std::_Equal' was declared deprecated
C:Program FilesMicrosoft Visual Studio
8VCincludexutility(2661) : see declaration of 'std::_Equal'
Message: 'You have used a std:: construct that is not safe. See
documentation on how to use the Safe Standard C++ Library'
Wow. Thanks a lot. The same thing happens for a whole raft of other
standard functions, such as copy, set_difference, replace, remove,
merge, etc.
|
Are std::equal et al deprecated, or just the std::_* implementation
functions?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
P.J. Plauger
Guest
|
| Posted: Fri Nov 18, 2005 4:35 pm Post subject: Re: Visual Studio 8 deprecates functions in ::std :-( |
|
|
<wizofaus (AT) hotmail (DOT) com> wrote
| Quote: | I have to agree with MS though that the design decision behind
functions like std::equal() and std::copy() (assuming the "output"
range is are the same size as the "input" range) is questionable at
best. In fact, I would fully expect std::equal( ) to be able to take
two separate iterator ranges, and as a first check, confirm the ranges
are the same size.
std::copy()'s a little more difficult, as it could logically either a)
truncate the results if the output range was smaller or b) generate an
error (throw an exception?).
|
Or c) extend the ranges as needed, like an inserting iterator does.
In this case, copy is perfectly safe.
| Quote: | I would tend to prefer a), with good
implementations supplying a run-time warning*.
Are there plans for the next C++ to have "safe" versions of these
functions?
|
The current version has checked iterators turned on by default.
For any iterators returned by containers, an attempt to do an
equal comparison or a copy off the end results in a suitable
error message.
| Quote: | * How many C++ libraries, especially including implementions of the std
library, have much in the way of run-time warnings? MFC does, and I've
been saved by them more than once. It's a little surprising I've never
seen a "warn_assert" type thing be proposed.
|
Most Standard C++ libraries offer roughly the same kind of iterator
checking option I described above.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Pete Becker
Guest
|
| Posted: Fri Nov 18, 2005 4:37 pm Post subject: Re: Visual Studio 8 deprecates functions in ::std :-( |
|
|
[email]wizofaus (AT) hotmail (DOT) com[/email] wrote:
| Quote: |
I have to agree with MS though that the design decision behind
functions like std::equal() and std::copy() (assuming the "output"
range is are the same size as the "input" range) is questionable at
best.
|
The design of STL emphasizes speed. The assumption behind this
"questionable" decision is that functions will be called with valid
data. The way to do this is to check for validity at the point where you
create the data. Checking every time you use it is a great recipe for
writing applications that are big and slow.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Herb Sutter
Guest
|
| Posted: Fri Nov 18, 2005 4:38 pm Post subject: Re: Visual Studio 8 deprecates functions in ::std :-( |
|
|
On 17 Nov 2005 19:06:43 -0500, "Michi" <michi (AT) zeroc (DOT) com> wrote:
| Quote: | Visual Studio 8 has introduced some interesting warnings. For example,
the expression
::std::equal(m.begin(), m.end(), p)
raises the following warning:
|
That's true if p is a raw pointer (or otherwise an uncheckable iterator).
It's not the algorithm that generates the warning, but the use of the
algorithm with unchecked iterators -- typically raw pointers that are
unchecked and so often prone to buffer overruns.
But we need to do better, and will:
| Quote: | Note the interesting wording: 'std::_equal' was declared deprecated. I
was under the distinct impression that only the C++ standards committee
could deprecate anything in the std namespace...
|
Update to the other replies: We've already agreed to change this (in
particular, the use of the word "deprecated" was not intended to mislead
but clearly is a bad choice and will be changed) and are working with
standards committee members to provide the easiest way to turn the
warnings off for specific uses, and for third-party libraries.
I'm just heading out the door, but see this other set of replies:
http://www.informit.com/discussion/index.asp?postid=21b98add-e468-4b24-b263-169a47215124#21b98add-e468-4b24-b263-169a47215124
(search for "hijack"  )
Herb
---
Herb Sutter (www.gotw.ca) (www.pluralsight.com/blogs/hsutter)
Convener, ISO WG21 (C++ standards committee) (www.gotw.ca/iso)
Contributing editor, C/C++ Users Journal (www.gotw.ca/cuj)
Architect, Developer Division, Microsoft (www.gotw.ca/microsoft)
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Bo Persson
Guest
|
| Posted: Sat Nov 19, 2005 10:20 am Post subject: Re: Visual Studio 8 deprecates functions in ::std :-( |
|
|
<wizofaus (AT) hotmail (DOT) com> skrev i meddelandet
news:1132288305.113680.126800 (AT) o13g2000cwo (DOT) googlegroups.com...
| Quote: | I have to agree with MS though that the design decision behind
functions like std::equal() and std::copy() (assuming the "output"
range is are the same size as the "input" range) is questionable at
best. In fact, I would fully expect std::equal( ) to be able to
take
two separate iterator ranges, and as a first check, confirm the
ranges
are the same size.
|
But that would limit its use to sequences where the ranges are known
in advance.
| Quote: | std::copy()'s a little more difficult, as it could logically either
a)
truncate the results if the output range was smaller or b) generate
an
error (throw an exception?). I would tend to prefer a), with good
implementations supplying a run-time warning*.
|
Or, c) use an insert iterator to extend the target sequence as needed.
The STL concepts are extremely general, and therefore very useful. You
should be careful not to add extra cost or limitations for its use.
Bo Persson
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Michi
Guest
|
| Posted: Sat Nov 19, 2005 10:22 am Post subject: Re: OT: Visual Studio 8 deprecates functions in ::std :-( |
|
|
Yes, I've come to the same conclusion: disabling the warning is easier
than to change the code to avoid it.
The code that generates the warning isn't particularly intelligent. For
example, the following produces the warning, even though I can
statically prove that the code is correct:
char src[10];
char dest[20];
copy(src, src + sizeof(src) / sizeof(*src), dest);
Cheers,
Michi.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Gene Bushuyev
Guest
|
| Posted: Sat Nov 19, 2005 10:24 am Post subject: Re: Visual Studio 8 deprecates functions in ::std :-( |
|
|
<wizofaus (AT) hotmail (DOT) com> wrote
[...]
| Quote: | std::copy()'s a little more difficult, as it could logically either a)
truncate the results if the output range was smaller or b) generate an
error (throw an exception?). I would tend to prefer a), with good
implementations supplying a run-time warning*.
|
And how is your implementation going to handle this common case?
std::copy(a.begin(), a.end(), std::back_inserter(b))
If you need to validate the preconditions of these functions, you can do it
explicitly. There is no need (nor sometimes possibility) to burden a general
algortihm with that.
-- Gene Bushuyev
----------------------------------------------------------------
There is no greatness where there is no simplicity, goodness and truth. ~ Leo
Tolstoy
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
wizofaus@hotmail.com
Guest
|
| Posted: Sat Nov 19, 2005 10:26 am Post subject: Re: Visual Studio 8 deprecates functions in ::std :-( |
|
|
Pete Becker wrote:
| Quote: | wizofaus (AT) hotmail (DOT) com wrote:
I have to agree with MS though that the design decision behind
functions like std::equal() and std::copy() (assuming the "output"
range is are the same size as the "input" range) is questionable at
best.
The design of STL emphasizes speed. The assumption behind this
"questionable" decision is that functions will be called with valid
data. The way to do this is to check for validity at the point where you
create the data. Checking every time you use it is a great recipe for
writing applications that are big and slow.
Well that's always a risk, but I can't see the sort of checking I'm |
talking about making that significant an impact on performance or size.
And I don't know of anyone making that complaint about, say, strncpy
over strcpy.
There will always be "extreme low-level" alternatives to abstractions
like the STL, if you really need performance above all other
considerations.
That said of course, any function that takes iterators as parameters is
at the mercy of the validity of those iterators, so the STL will never
be "truly" safe. However the current design of std::equal is
comparable to a version of strcmp that just assumes the second string
is the same length as the fist. The extensions I mentioned are, if
anything, a functional addition to the library, allowing you safely
compare (or copy) between two ranges of iterators, without needing to
ensure first that they are the same size.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
wizofaus@hotmail.com
Guest
|
| Posted: Sat Nov 19, 2005 4:11 pm Post subject: Re: Visual Studio 8 deprecates functions in ::std :-( |
|
|
P.J. Plauger wrote:
| Quote: | wizofaus (AT) hotmail (DOT) com> wrote in message
news:1132288305.113680.126800 (AT) o13g2000cwo (DOT) googlegroups.com...
I have to agree with MS though that the design decision behind
functions like std::equal() and std::copy() (assuming the "output"
range is are the same size as the "input" range) is questionable at
best. In fact, I would fully expect std::equal( ) to be able to take
two separate iterator ranges, and as a first check, confirm the ranges
are the same size.
std::copy()'s a little more difficult, as it could logically either a)
truncate the results if the output range was smaller or b) generate an
error (throw an exception?).
Or c) extend the ranges as needed, like an inserting iterator does.
In this case, copy is perfectly safe.
|
True, so the single output iterator version of std::copy() is useful
for the case of the inserting interators, but otherwise, it would seem
preferable to be able to specify the output range. It's true that in
principle std::copy() is no different than, say, memcpy, which only
takes one size value, but that size isn't so obviously tied to either
the input or output range as is the case with std::copy().
| Quote: | I would tend to prefer a), with good
implementations supplying a run-time warning*.
Are there plans for the next C++ to have "safe" versions of these
functions?
The current version has checked iterators turned on by default.
|
By that I assume you mean the current version of the Dinkumware
implementation of the C++ std library? I was actually referring to the
language itself - I should have been more clear.
| Quote: | For any iterators returned by containers, an attempt to do an
equal comparison or a copy off the end results in a suitable
error message.
|
You mean a run-time assert?
| Quote: |
* How many C++ libraries, especially including implementions of the std
library, have much in the way of run-time warnings? MFC does, and I've
been saved by them more than once. It's a little surprising I've never
seen a "warn_assert" type thing be proposed.
Most Standard C++ libraries offer roughly the same kind of iterator
checking option I described above.
Which I believe are mostly asserts, and hence, in most environments, |
execution halting.
(I pretty much avoid standard asserts for this reason - being able to
continue execution after an assert is often a powerful debugging
technique).
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
wizofaus@hotmail.com
Guest
|
| Posted: Sun Nov 20, 2005 4:56 pm Post subject: Re: Visual Studio 8 deprecates functions in ::std :-( |
|
|
Bo Persson wrote:
| Quote: | wizofaus (AT) hotmail (DOT) com> skrev i meddelandet
news:1132288305.113680.126800 (AT) o13g2000cwo (DOT) googlegroups.com...
I have to agree with MS though that the design decision behind
functions like std::equal() and std::copy() (assuming the "output"
range is are the same size as the "input" range) is questionable at
best. In fact, I would fully expect std::equal( ) to be able to
take
two separate iterator ranges, and as a first check, confirm the
ranges
are the same size.
But that would limit its use to sequences where the ranges are known
in advance.
|
I can't realistically foresee a scenario when using std::equal() that
this would not be the case (yes, in principle, you could use it with an
input iterator - the safety of which can be left to the reader's
judgement). At any rate, I'm certainly not proposing removing the
existing versions.
| Quote: |
std::copy()'s a little more difficult, as it could logically either
a)
truncate the results if the output range was smaller or b) generate
an
error (throw an exception?). I would tend to prefer a), with good
implementations supplying a run-time warning*.
Or, c) use an insert iterator to extend the target sequence as needed.
That option already exists, and I'm not suggesting any need to remove |
it.
| Quote: |
The STL concepts are extremely general, and therefore very useful. You
should be careful not to add extra cost or limitations for its use.
I'm not sure I see how adding safer versions of existing algorithms can |
add extra cost or limitations.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
P.J. Plauger
Guest
|
| Posted: Sun Nov 20, 2005 5:04 pm Post subject: Re: Visual Studio 8 deprecates functions in ::std :-( |
|
|
<wizofaus (AT) hotmail (DOT) com> wrote
| Quote: | P.J. Plauger wrote:
[email]wizofaus (AT) hotmail (DOT) com[/email]> wrote in message
news:1132288305.113680.126800 (AT) o13g2000cwo (DOT) googlegroups.com...
I have to agree with MS though that the design decision behind
functions like std::equal() and std::copy() (assuming the "output"
range is are the same size as the "input" range) is questionable at
best. In fact, I would fully expect std::equal( ) to be able to take
two separate iterator ranges, and as a first check, confirm the ranges
are the same size.
std::copy()'s a little more difficult, as it could logically either a)
truncate the results if the output range was smaller or b) generate an
error (throw an exception?).
Or c) extend the ranges as needed, like an inserting iterator does.
In this case, copy is perfectly safe.
True, so the single output iterator version of std::copy() is useful
for the case of the inserting interators, but otherwise, it would seem
preferable to be able to specify the output range.
|
It might seem preferable to some, but that's just one solution to
the problem, and not necessarily the best one.
| Quote: | It's true that in
principle std::copy() is no different than, say, memcpy, which only
takes one size value, but that size isn't so obviously tied to either
the input or output range as is the case with std::copy().
|
The other difference is that std::copy() is written in C++,
which has a broader spectrum of techniques it can bring to bear.
| Quote: | I would tend to prefer a), with good
implementations supplying a run-time warning*.
Are there plans for the next C++ to have "safe" versions of these
functions?
The current version has checked iterators turned on by default.
By that I assume you mean the current version of the Dinkumware
implementation of the C++ std library?
|
Yes.
| Quote: | I was actually referring to the
language itself - I should have been more clear.
|
The distinction between language, library, and implementation
is fuzzier in C++.
| Quote: | For any iterators returned by containers, an attempt to do an
equal comparison or a copy off the end results in a suitable
error message.
You mean a run-time assert?
|
That's one form, yes. Not the only form.
| Quote: | * How many C++ libraries, especially including implementions of the std
library, have much in the way of run-time warnings? MFC does, and I've
been saved by them more than once. It's a little surprising I've never
seen a "warn_assert" type thing be proposed.
Most Standard C++ libraries offer roughly the same kind of iterator
checking option I described above.
Which I believe are mostly asserts, and hence, in most environments,
execution halting.
(I pretty much avoid standard asserts for this reason - being able to
continue execution after an assert is often a powerful debugging
technique).
|
Then you're in luck. IIRC, Microsoft already lets you replace at
least some of the handlers for checked iterators. The next (and
imminent) release of the Dinkumware libraries will let you replace
all of them.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
