strcpy_s, undeclared identifier?
Author
i am working from home today and transferred my code into my machine to work on it. at work i am using Visual Studio Express(VC 8 i am guessing) and at home i am using Visual Studio 2003.
in my code i do this:
#include <string>
and then use strcpy_s(..)
yet it tells me this is undeclared. at work i got no such error using Studio Express. i think i will need to fix a couple of more problems that i might address in this thread but first of all i needed to get this one fixed. its really starting to piss me off actually.
any help on what i need to do?
<string> is for the string class in the C++ standard library. The old C string functions are in <string.h>.
edit: Or, if you use C++, use <cstring> instead.
edit: Or, if you use C++, use <cstring> instead.
Author
yeah but why did i not have any problems with studio express, no compiler errors and now i am getting them with visual studio 2003? anyway i changed it to strcpy just so i could get it to compile and now i am getting all these weird linker errors. i didnt have such errors with studio express...
....
...
rules error LNK2005: "public: __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::~basic_string<char,struct std::char_traits<char>,class std::allocator<char> >(void)" (??1?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@XZ) already defined in rules.obj
error LNK2005: __vsnprintf already defined in LIBCD.lib(vsnprint.obj)
error LNK2005: _atoi already defined in LIBCD.lib(atox.obj)
...
..
...
error LNK2005: _fflush already defined in LIBCD.lib(fflush.obj)rules error LNK2005: _strncpy already defined in LIBCD.lib(strncpy.obj)
rules fatal error LNK1169: one or more multiply defined symbols found
rules warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
what is all this crap??
....
...
rules error LNK2005: "public: __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::~basic_string<char,struct std::char_traits<char>,class std::allocator<char> >(void)" (??1?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@XZ) already defined in rules.obj
error LNK2005: __vsnprintf already defined in LIBCD.lib(vsnprint.obj)
error LNK2005: _atoi already defined in LIBCD.lib(atox.obj)
...
..
...
error LNK2005: _fflush already defined in LIBCD.lib(fflush.obj)rules error LNK2005: _strncpy already defined in LIBCD.lib(strncpy.obj)
rules fatal error LNK1169: one or more multiply defined symbols found
rules warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
what is all this crap??
the strcpy_s function doesn't exist in 2003. that function, along with all the other c library functions that end with _s were added to 2005 as part of Microsofts 'safe' string library stuff.
Clicky for info
Clicky for info
The _s version of the C string functions was introduced in VC8 if I remember correct, so they are not present in earlier versions.
i remember reading that now and just changed them to strcpy at this moment. will use functions later on but thanks.
Author
Quote:Original post by Anonymous Poster
i remember reading that now and just changed them to strcpy at this moment. will use functions later on but thanks.
oops that was me above..
There's no such function as strcpy_s in standard C++. If your compiler warns you about using strcpy then switch to std::copy - if it warns you about that, find out what you need to do to stop the compiler warning you.
Never use strcpy_s unless you never, ever, ever want your code to be compiled on any platform or compiler apart from MS Windows and Visual Studio 2005.
Never use strcpy_s unless you never, ever, ever want your code to be compiled on any platform or compiler apart from MS Windows and Visual Studio 2005.
.. Now that you know that there's this <string> header that provides the C++ definition of a *real* string class, and given that you're using C++ (i.e. didn't have problems compiling with that header included, at least on Express) - why don't you *use it*?
It will save you huge amounts of headaches. For one, it provides the "safety" of strcpy_s, except it (a) is fully portable and (b) doesn't impose any kind of limit on the string length. Not to mention all the benefits associated with automatic memory management, as well as, you know, *being an actual object type* instead of a pointer.
It will save you huge amounts of headaches. For one, it provides the "safety" of strcpy_s, except it (a) is fully portable and (b) doesn't impose any kind of limit on the string length. Not to mention all the benefits associated with automatic memory management, as well as, you know, *being an actual object type* instead of a pointer.
The right tool for the right job.
Decide what language you are programming in, firstly. If C++, then go ahead and use std::string.
If you're using C, then std::string does not exist, and use <string.h>. As someone mentioned, do *not* use and of the _s functions, they are MS specific, and *not* standard C.
If you are using C++ and absolutely *need* to use a C library function, #include the appropriate header. Don't include <math.h> in C++, instead include <cmath>.
If you are writing C, make sure your compiler knows this and make sure you are not compiling C++ mode! And vice versa.
If you are unsure whether a function is part of the standard library or MS specific, look up the C++ or C standards.
Decide what language you are programming in, firstly. If C++, then go ahead and use std::string.
If you're using C, then std::string does not exist, and use <string.h>. As someone mentioned, do *not* use and of the _s functions, they are MS specific, and *not* standard C.
If you are using C++ and absolutely *need* to use a C library function, #include the appropriate header. Don't include <math.h> in C++, instead include <cmath>.
If you are writing C, make sure your compiler knows this and make sure you are not compiling C++ mode! And vice versa.
If you are unsure whether a function is part of the standard library or MS specific, look up the C++ or C standards.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
