strcpy depreciated?!?!?

as many of you know, the Visual Studios 2005 "Express" edition is available for free download on the MS site. I got a copy of everything up there, started compiling some of my own projects in the new version just to see if they would work, and found weirdness.

The C string functions are declared with a "DEPRECATED" type. The compiler gives warnings when you use them as well.

Can anyone offer an explanation other than the "Micro$oft is the devil!" response? Actually, I'm wondering if this is a C or C++ spec thing. Prelude? you out there?

Did by chance list a newer function to use?

Only thing I could think of is them trying to force you to use C++ strings.

That and M$ is the devil

>Prelude? you out there?
I know for a fact that strcpy isn't deprecated in either C or C++. However, if you're compiling as C++ and using <string.h> I can easily see a warning about it as the C++ standard deprecated the .h C-style headers in favor of the <c*> headers.

>The C string functions are declared with a "DEPRECIATED" type.
Does the warning say "depreciated" or "deprecated"? If it's the latter, see my comment above, otherwise I have no idea what they're talking about.

deprecated of course.

jeeeeezzz

This is how the deprecated thing looks:

#define _CRT_INSECURE_DEPRECATE __declspec(deprecated)

and in string.h

_CRT_INSECURE_DEPRECATE char * __cdecl strcpy(char *, const char *);

Solutions, in order of preference:

1. Use winapi strsafe functions such as StringCchCopy(), StringCchPrintf(), etc declared in <strsafe.h>
2. Use new 'safe' versions of crt functions with _s suffix such as strncpy_s(). These functions are preliminary and subject to change so you are better off using strsafe at this stage.
3. Declare _CRT_SECURE_NO_DEPRECATE and keep using the old insecure functions such as strcpy().

http://msdn.microsoft.com/library/en...asp?frame=true

I think solution 3 is closest to what I will want. I have always been somewhat skeptical when it comes to the use of microsoft functions in place of standard ones. I have to see more benefit first. There are some cases when the benefit is there. File access functions for instance are faster than the standard ones. Calling standard functions deprecated seems odd to me.

I do like this new IDE. I wish they had gotten the resource editor working though. I brought over a couple of my Win32 projects and managed to get them working under VS 2005. Very promising.

I like how Microsoft takes control and deprecates something that they believe is unsafe without the blessing of the standard. It would be much better if they simply added a switch to allow this behavior as an extension (which is what it is) rather than forcing it on us by default (which is what it sounds like they're trying to do).

>Calling standard functions deprecated seems odd to me.
It raises my warning flags if it makes you feel better.

>1. Use winapi strsafe functions such as StringCchCopy(), StringCchPrintf(), etc declared in <strsafe.h>
>2. Use new 'safe' versions of crt functions with _s suffix such as strncpy_s(). These functions are preliminary and

So much for portability if you go with these two options. In fact, you might as well just start using C# instead.

I just did a pragma to disable the warning. It still compiles so I don't really care too much. This is going to be a good version. Has anyone played with the VB express?

It seems like they want you to start using their String class, and not iostream's. Just like they wanted me to start using the STL and such by taking away my export , but I won't go without a fight!

What about using strncpy? This would be safer and would avoid the security concerns.

>This would be safer and would avoid the security concerns.
strncpy is tricky though. People end up surprised when they find out its quirks.

Mainly the lack of a guartnee that the dest will be null terminated

strncpy is deprecated as well in VC8