Thread: Request for sticky

Code:

//#define _SECURE_SCL 0

#include <iostream>
#include <string>
#include <vector>

int main()
{
std::string source("It might be ugly but at least it's standard!");

std::size_t length=source.length();

std::vector<char> target(length+1,'\0');

//msvc2005 says std::string::copy 'deprecated'. Unless _SECURE_SCL  is
//#defined as zero
source.copy(&target[0],length); //(<---msvc2005 say OUCH)

std::cout<<&target[0]<<std::endl;
}

Which, with msvc2005 gives rise to:

Originally Posted by msvc2005

warning C4996: 'std::basic_string<_Elem,_Traits,_Ax>::copy' was declared deprecated

If you uncomment the msvc2005 specific preprocessor definition in the example above and recompile it with msvc2005 it magically becomes 'standard' again, losing the warning. Obviously, with a real compiler ( ) like MinGW this isn't an issue.

So, what msvc2005 means by 'standard' in this context has little to do with the C++ standard but everything to do with an ms specific extension - and this, sadly, is default behaviour for msvc2005.

However, with a warning like that, a beginner who's new to c++ will understandly probably believe the warning and think that std::string::copy is, in fact, deprecated.

I don't believe this is good - and I second Bubba's excellent suggestion that before the mad rush of 'msvc2005 tells me it's wrong so it must be' posts really starts in earnest we have something in place to deal with it.

Read this thread for more details - in particular follow up some of the links posted there to read objections made by smarter people than me regarding why this tactic of microsoft's is potentially more than just a transient annoyance.

Originally Posted by Ken Fitlike

mment the msvc2005 specific preprocessor definition in the example above and recompile it with msvc2005 it magically becomes 'standard' again, losing the warning. Obviously, with a real compiler ( ) like MinGW this isn't an issue.

Real windows compiler. Seriously, if you plan on writing windows code and want full access to all things windows you're forced to use visual studio, heh. I'm not saying it's a good thing, but it's just something we've got to deal with until some underdog compiler comes around.

So in the end, valid point. I just wasn't sure what kind of code was causing this problem.

-edit-
And to clarify, I've evidently been out of the loop way too long as far as compilers as the name ming was unfamiliar to me, haha. *shakes head and explodes*

>>*shakes head and explodes*

I just had a lemmings flashback

This is definitely good to know if/when I get 2005 (still using VS 2003)

Edit: After reading about this C++/CLI crap, all I can say is yuck. I think they're trying to kill C++! Does this remind anyone else of C#? I haven't worked with it a lot, but some of this C++/CLI stuff seems eerily similar.

Let's wait until/if it becomes a problem before creating _another_ sticky.

<cough>FAQ</cough>

yeah, I'm with Sang here... don't want a whole big long list of stickies again...

Agreed.

Just trying to be a bit pro-active. Mark my word these types of threads will pop up more and more as everyone switches to .NET 2005. The help file confuses C++ and CLI so much and makes the line between them so thin, an inexperienced programmer may make the false assumption that Microsoft CLI and/or Microsoft extensions to C++ are actually part of the standard.

And with Microsoft pressing for standardization of their CLI I look for them to attempt to hijack C/C++, although at the present it does look like there are a great many opponents to CLI being mixed with C++.