Problem when defining my own string.h

[s***@gmail.com]

Hi,

I'm having a weird problem when using Visual Studio. I'm creating a
small library with different utility classes. Thing is that everything
compiles ok, but when I create a string.h / string.cpp files, I get
the following errors:

***
\microsoft platform sdk for windows server 2003 r2\include
\guiddef.h(161) : error C3861: 'memcmp': identifier not found
\microsoft platform sdk for windows server 2003 r2\include
\stralign.h(101) : error C3861: 'wcscpy': identifier not found
***

Also, if I used std::string internally in my string class (to make my
class a wrapper over the std's string), then I'd get far more errors
(please note that 100+ errors are displayed)

***
1>c:\program files\microsoft visual studio 8\vc\include\cstring(18) :
error C2039: 'memchr' : is not a member of '`global namespace''
1>c:\program files\microsoft visual studio 8\vc\include\cstring(18) :
error C2873: 'memchr' : symbol cannot be used in a using-declaration
1>c:\program files\microsoft visual studio 8\vc\include\cstring(18) :
error C2039: 'memcmp' : is not a member of '`global namespace''
1>c:\program files\microsoft visual studio 8\vc\include\cstring(18) :
error C2873: 'memcmp' : symbol cannot be used in a using-declaration
1>c:\program files\microsoft visual studio 8\vc\include\cstring(19) :
error C2039: 'memcpy' : is not a member of '`global namespace''
1>c:\program files\microsoft visual studio 8\vc\include\cstring(19) :
error C2873: 'memcpy' : symbol cannot be used in a using-declaration
1>c:\program files\microsoft visual studio 8\vc\include\cstring(19) :
error C2039: 'memmove' : is not a member of '`global namespace''
1>c:\program files\microsoft visual studio 8\vc\include\cstring(19) :
error C2873: 'memmove' : symbol cannot be used in a using-declaration
1>c:\program files\microsoft visual studio 8\vc\include\cstring(19) :
error C2039: 'memset' : is not a member of '`global namespace''
1>c:\program files\microsoft visual studio 8\vc\include\cstring(19) :
error C2873: 'memset' : symbol cannot be used in a using-declaration
1>c:\program files\microsoft visual studio 8\vc\include\cstring(20) :
error C2039: 'strcat' : is not a member of '`global namespace''
1>c:\program files\microsoft visual studio 8\vc\include\cstring(20) :
error C2873: 'strcat' : symbol cannot be used in a using-declaration
1>c:\program files\microsoft visual studio 8\vc\include\cstring(20) :
error C2039: 'strchr' : is not a member of '`global namespace''
1>c:\program files\microsoft visual studio 8\vc\include\cstring(20) :
error C2873: 'strchr' : symbol cannot be used in a using-declaration
1>c:\program files\microsoft visual studio 8\vc\include\cstring(20) :
error C2039: 'strcmp' : is not a member of '`global namespace''
1>c:\program files\microsoft visual studio 8\vc\include\cstring(20) :
error C2873: 'strcmp' : symbol cannot be used in a using-declaration
1>c:\program files\microsoft visual studio 8\vc\include\cstring(21) :
error C2039: 'strcoll' : is not a member of '`global namespace''
1>c:\program files\microsoft visual studio 8\vc\include\cstring(21) :
error C2873: 'strcoll' : symbol cannot be used in a using-declaration
1>c:\program files\microsoft visual studio 8\vc\include\cstring(21) :
error C2039: 'strcpy' : is not a member of '`global namespace''
1>c:\program files\microsoft visual studio 8\vc\include\cstring(21) :
error C2873: 'strcpy' : symbol cannot be used in a using-declaration
1>c:\program files\microsoft visual studio 8\vc\include\cstring(21) :
error C2039: 'strcspn' : is not a member of '`global namespace''
1>c:\program files\microsoft visual studio 8\vc\include\cstring(21) :
error C2873: 'strcspn' : symbol cannot be used in a using-declaration
1>c:\program files\microsoft visual studio 8\vc\include\cstring(22) :
error C2039: 'strerror' : is not a member of '`global namespace''
1>c:\program files\microsoft visual studio 8\vc\include\cstring(22) :
error C2873: 'strerror' : symbol cannot be used in a using-declaration
1>c:\program files\microsoft visual studio 8\vc\include\cstring(22) :
error C2039: 'strlen' : is not a member of '`global namespace''
1>c:\program files\microsoft visual studio 8\vc\include\cstring(22) :
error C2873: 'strlen' : symbol cannot be used in a using-declaration
1>c:\program files\microsoft visual studio 8\vc\include\cstring(22) :
error C2039: 'strncat' : is not a member of '`global namespace''
1>c:\program files\microsoft visual studio 8\vc\include\cstring(22) :
error C2873: 'strncat' : symbol cannot be used in a using-declaration
1>c:\program files\microsoft visual studio 8\vc\include\cstring(23) :
error C2039: 'strncmp' : is not a member of '`global namespace''
1>c:\program files\microsoft visual studio 8\vc\include\cstring(23) :
error C2873: 'strncmp' : symbol cannot be used in a using-declaration
1>c:\program files\microsoft visual studio 8\vc\include\cstring(23) :
error C2039: 'strncpy' : is not a member of '`global namespace''
1>c:\program files\microsoft visual studio 8\vc\include\cstring(23) :
error C2873: 'strncpy' : symbol cannot be used in a using-declaration
1>c:\program files\microsoft visual studio 8\vc\include\cstring(23) :
error C2039: 'strpbrk' : is not a member of '`global namespace''
1>c:\program files\microsoft visual studio 8\vc\include\cstring(23) :
error C2873: 'strpbrk' : symbol cannot be used in a using-declaration
1>c:\program files\microsoft visual studio 8\vc\include\cstring(24) :
error C2039: 'strrchr' : is not a member of '`global namespace''
1>c:\program files\microsoft visual studio 8\vc\include\cstring(24) :
error C2873: 'strrchr' : symbol cannot be used in a using-declaration
1>c:\program files\microsoft visual studio 8\vc\include\cstring(24) :
error C2039: 'strspn' : is not a member of '`global namespace''
1>c:\program files\microsoft visual studio 8\vc\include\cstring(24) :
error C2873: 'strspn' : symbol cannot be used in a using-declaration
1>c:\program files\microsoft visual studio 8\vc\include\cstring(24) :
error C2039: 'strstr' : is not a member of '`global namespace''
1>c:\program files\microsoft visual studio 8\vc\include\cstring(24) :
error C2873: 'strstr' : symbol cannot be used in a using-declaration
1>c:\program files\microsoft visual studio 8\vc\include\cstring(25) :
error C2039: 'strtok' : is not a member of '`global namespace''
1>c:\program files\microsoft visual studio 8\vc\include\cstring(25) :
error C2873: 'strtok' : symbol cannot be used in a using-declaration
1>c:\program files\microsoft visual studio 8\vc\include\cstring(25) :
error C2039: 'strxfrm' : is not a member of '`global namespace''
1>c:\program files\microsoft visual studio 8\vc\include\cstring(25) :
error C2873: 'strxfrm' : symbol cannot be used in a using-declaration
1>c:\program files\microsoft visual studio 8\vc\include\new(53) :
error C2732: linkage specification contradicts earlier specification
for 'operator delete'
1> c:\program files\microsoft visual studio 8\vc\include
\new(53) : see declaration of 'operator delete'
1>c:\program files\microsoft visual studio 8\vc\include\new(54) :
error C2732: linkage specification contradicts earlier specification
for 'operator new'
1> c:\program files\microsoft visual studio 8\vc\include
\new(54) : see declaration of 'operator new'
1>c:\program files\microsoft visual studio 8\vc\include\new(80) :
error C2733: second C linkage of overloaded function 'operator
delete[]' not allowed
1> c:\program files\microsoft visual studio 8\vc\include
\new(80) : see declaration of 'operator delete[]'
1>c:\program files\microsoft visual studio 8\vc\include\new(83) :
error C2733: second C linkage of overloaded function 'operator new[]'
not allowed
1> c:\program files\microsoft visual studio 8\vc\include
\new(82) : see declaration of 'operator new[]'
1>c:\program files\microsoft visual studio 8\vc\include\new(88) :
error C2733: second C linkage of overloaded function 'operator new'
not allowed
1> c:\program files\microsoft visual studio 8\vc\include
\new(87) : see declaration of 'operator new'
1>c:\program files\microsoft visual studio 8\vc\include\new(91) :
error C2733: second C linkage of overloaded function 'operator new[]'
not allowed
1> c:\program files\microsoft visual studio 8\vc\include
\new(90) : see declaration of 'operator new[]'
1>c:\program files\microsoft visual studio 8\vc\include\new(94) :
error C2733: second C linkage of overloaded function 'operator delete'
not allowed
1> c:\program files\microsoft visual studio 8\vc\include
\new(93) : see declaration of 'operator delete'
1>c:\program files\microsoft visual studio 8\vc\include\new(97) :
error C2733: second C linkage of overloaded function 'operator
delete[]' not allowed
1> c:\program files\microsoft visual studio 8\vc\include
\new(96) : see declaration of 'operator delete[]'
1>c:\program files\microsoft visual studio 8\vc\include
\crtdbg.h(1160) : error C2732: linkage specification contradicts
earlier specification for 'operator new[]'
1> c:\program files\microsoft visual studio 8\vc\include
\crtdbg.h(1160) : see declaration of 'operator new[]'
1>c:\program files\microsoft visual studio 8\vc\include
\crtdbg.h(1177) : error C2732: linkage specification contradicts
earlier specification for 'operator delete[]'
1> c:\program files\microsoft visual studio 8\vc\include
\crtdbg.h(1177) : see declaration of 'operator delete[]'
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(39) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(122) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(154) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(291) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(406) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(436) :
error C2039: 'memcmp' : is not a member of '`global namespace''
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(436) :
error C3861: 'memcmp': identifier not found
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(466) :
error C2039: 'memchr' : is not a member of '`global namespace''
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(466) :
error C3861: 'memchr': identifier not found
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(489) :
error C2039: 'memset' : is not a member of '`global namespace''
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(489) :
error C3861: 'memset': identifier not found
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(520) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(533) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(542) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(549) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(556) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(565) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(577) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(585) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(591) :
error C2733: second C linkage of overloaded function
'std::_Traits_helper::copy_s' not allowed
1> c:\program files\microsoft visual studio 8\vc\include
\iosfwd(587) : see declaration of 'std::_Traits_helper::copy_s'
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(594) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(601) :
error C2733: second C linkage of overloaded function
'std::_Traits_helper::copy_s' not allowed
1> c:\program files\microsoft visual studio 8\vc\include
\iosfwd(597) : see declaration of 'std::_Traits_helper::copy_s'
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(604) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(612) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(618) :
error C2733: second C linkage of overloaded function
'std::_Traits_helper::move_s' not allowed
1> c:\program files\microsoft visual studio 8\vc\include
\iosfwd(614) : see declaration of 'std::_Traits_helper::move_s'
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(621) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(628) :
error C2733: second C linkage of overloaded function
'std::_Traits_helper::move_s' not allowed
1> c:\program files\microsoft visual studio 8\vc\include
\iosfwd(624) : see declaration of 'std::_Traits_helper::move_s'
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(633) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(636) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(639) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(642) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(645) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(648) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(651) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(654) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(657) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(661) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(665) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(669) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(673) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(676) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(679) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(682) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(687) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(690) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\iosfwd(693) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\utility(15) :
error C2894: templates cannot be declared to have 'C' linkage
1>c:\program files\microsoft visual studio 8\vc\include\utility(15) :
fatal error C1003: error count exceeds 100; stopping compilation
***

The really strange thing, at least to me, is that so far none of the
other files in my library relies on string.h, so it seems that its
sole existence confuses MSVC somehow. One solution I thought was
avoiding the system include directory, but the problem is that some of
the classes need access to win32 api, so I need it.

Simple solution so far: just renaming string.h to stringxxx.h and
everything works ok. But of course, I'd like to use string.h for
clarity sake. Is there any workaround for this?

Thanks in advance.

[Tom Serface]

My guess is that you'd fix your problem by just using a name that wasn't
already taken as one of the standard names. Did you include string.h in
your string.cpp file and include it in the project. That alone would be
enough to attempt to cause the problem. Maybe you could call yours
MyString.h or something like that.

Tom

Post by s***@gmail.com
Hi,
I'm having a weird problem when using Visual Studio. I'm creating a
small library with different utility classes. Thing is that everything
compiles ok, but when I create a string.h / string.cpp files, I get
***
\microsoft platform sdk for windows server 2003 r2\include
\guiddef.h(161) : error C3861: 'memcmp': identifier not found
\microsoft platform sdk for windows server 2003 r2\include
\stralign.h(101) : error C3861: 'wcscpy': identifier not found
***
Also, if I used std::string internally in my string class (to make my
class a wrapper over the std's string), then I'd get far more errors
(please note that 100+ errors are displayed)
***
error C2039: 'memchr' : is not a member of '`global namespace''
error C2873: 'memchr' : symbol cannot be used in a using-declaration
error C2039: 'memcmp' : is not a member of '`global namespace''
error C2873: 'memcmp' : symbol cannot be used in a using-declaration
error C2039: 'memcpy' : is not a member of '`global namespace''
error C2873: 'memcpy' : symbol cannot be used in a using-declaration
error C2039: 'memmove' : is not a member of '`global namespace''
error C2873: 'memmove' : symbol cannot be used in a using-declaration
error C2039: 'memset' : is not a member of '`global namespace''
error C2873: 'memset' : symbol cannot be used in a using-declaration
error C2039: 'strcat' : is not a member of '`global namespace''
error C2873: 'strcat' : symbol cannot be used in a using-declaration
error C2039: 'strchr' : is not a member of '`global namespace''
error C2873: 'strchr' : symbol cannot be used in a using-declaration
error C2039: 'strcmp' : is not a member of '`global namespace''
error C2873: 'strcmp' : symbol cannot be used in a using-declaration
error C2039: 'strcoll' : is not a member of '`global namespace''
error C2873: 'strcoll' : symbol cannot be used in a using-declaration
error C2039: 'strcpy' : is not a member of '`global namespace''
error C2873: 'strcpy' : symbol cannot be used in a using-declaration
error C2039: 'strcspn' : is not a member of '`global namespace''
error C2873: 'strcspn' : symbol cannot be used in a using-declaration
error C2039: 'strerror' : is not a member of '`global namespace''
error C2873: 'strerror' : symbol cannot be used in a using-declaration
error C2039: 'strlen' : is not a member of '`global namespace''
error C2873: 'strlen' : symbol cannot be used in a using-declaration
error C2039: 'strncat' : is not a member of '`global namespace''
error C2873: 'strncat' : symbol cannot be used in a using-declaration
error C2039: 'strncmp' : is not a member of '`global namespace''
error C2873: 'strncmp' : symbol cannot be used in a using-declaration
error C2039: 'strncpy' : is not a member of '`global namespace''
error C2873: 'strncpy' : symbol cannot be used in a using-declaration
error C2039: 'strpbrk' : is not a member of '`global namespace''
error C2873: 'strpbrk' : symbol cannot be used in a using-declaration
error C2039: 'strrchr' : is not a member of '`global namespace''
error C2873: 'strrchr' : symbol cannot be used in a using-declaration
error C2039: 'strspn' : is not a member of '`global namespace''
error C2873: 'strspn' : symbol cannot be used in a using-declaration
error C2039: 'strstr' : is not a member of '`global namespace''
error C2873: 'strstr' : symbol cannot be used in a using-declaration
error C2039: 'strtok' : is not a member of '`global namespace''
error C2873: 'strtok' : symbol cannot be used in a using-declaration
error C2039: 'strxfrm' : is not a member of '`global namespace''
error C2873: 'strxfrm' : symbol cannot be used in a using-declaration
error C2732: linkage specification contradicts earlier specification
for 'operator delete'
1> c:\program files\microsoft visual studio 8\vc\include
\new(53) : see declaration of 'operator delete'
error C2732: linkage specification contradicts earlier specification
for 'operator new'
1> c:\program files\microsoft visual studio 8\vc\include
\new(54) : see declaration of 'operator new'
error C2733: second C linkage of overloaded function 'operator
delete[]' not allowed
1> c:\program files\microsoft visual studio 8\vc\include
\new(80) : see declaration of 'operator delete[]'
error C2733: second C linkage of overloaded function 'operator new[]'
not allowed
1> c:\program files\microsoft visual studio 8\vc\include
\new(82) : see declaration of 'operator new[]'
error C2733: second C linkage of overloaded function 'operator new'
not allowed
1> c:\program files\microsoft visual studio 8\vc\include
\new(87) : see declaration of 'operator new'
error C2733: second C linkage of overloaded function 'operator new[]'
not allowed
1> c:\program files\microsoft visual studio 8\vc\include
\new(90) : see declaration of 'operator new[]'
error C2733: second C linkage of overloaded function 'operator delete'
not allowed
1> c:\program files\microsoft visual studio 8\vc\include
\new(93) : see declaration of 'operator delete'
error C2733: second C linkage of overloaded function 'operator
delete[]' not allowed
1> c:\program files\microsoft visual studio 8\vc\include
\new(96) : see declaration of 'operator delete[]'
1>c:\program files\microsoft visual studio 8\vc\include
\crtdbg.h(1160) : error C2732: linkage specification contradicts
earlier specification for 'operator new[]'
1> c:\program files\microsoft visual studio 8\vc\include
\crtdbg.h(1160) : see declaration of 'operator new[]'
1>c:\program files\microsoft visual studio 8\vc\include
\crtdbg.h(1177) : error C2732: linkage specification contradicts
earlier specification for 'operator delete[]'
1> c:\program files\microsoft visual studio 8\vc\include
\crtdbg.h(1177) : see declaration of 'operator delete[]'
error C2894: templates cannot be declared to have 'C' linkage
error C2894: templates cannot be declared to have 'C' linkage
error C2894: templates cannot be declared to have 'C' linkage
error C2894: templates cannot be declared to have 'C' linkage
error C2894: templates cannot be declared to have 'C' linkage
error C2039: 'memcmp' : is not a member of '`global namespace''
error C3861: 'memcmp': identifier not found
error C2039: 'memchr' : is not a member of '`global namespace''
error C3861: 'memchr': identifier not found
error C2039: 'memset' : is not a member of '`global namespace''
error C3861: 'memset': identifier not found
error C2894: templates cannot be declared to have 'C' linkage
error C2894: templates cannot be declared to have 'C' linkage
error C2894: templates cannot be declared to have 'C' linkage
error C2894: templates cannot be declared to have 'C' linkage
error C2894: templates cannot be declared to have 'C' linkage
error C2894: templates cannot be declared to have 'C' linkage
error C2894: templates cannot be declared to have 'C' linkage
error C2894: templates cannot be declared to have 'C' linkage
error C2733: second C linkage of overloaded function
'std::_Traits_helper::copy_s' not allowed
1> c:\program files\microsoft visual studio 8\vc\include
\iosfwd(587) : see declaration of 'std::_Traits_helper::copy_s'
error C2894: templates cannot be declared to have 'C' linkage
error C2733: second C linkage of overloaded function
'std::_Traits_helper::copy_s' not allowed
1> c:\program files\microsoft visual studio 8\vc\include
\iosfwd(597) : see declaration of 'std::_Traits_helper::copy_s'
error C2894: templates cannot be declared to have 'C' linkage
error C2894: templates cannot be declared to have 'C' linkage
error C2733: second C linkage of overloaded function
'std::_Traits_helper::move_s' not allowed
1> c:\program files\microsoft visual studio 8\vc\include
\iosfwd(614) : see declaration of 'std::_Traits_helper::move_s'
error C2894: templates cannot be declared to have 'C' linkage
error C2733: second C linkage of overloaded function
'std::_Traits_helper::move_s' not allowed
1> c:\program files\microsoft visual studio 8\vc\include
\iosfwd(624) : see declaration of 'std::_Traits_helper::move_s'
error C2894: templates cannot be declared to have 'C' linkage
error C2894: templates cannot be declared to have 'C' linkage
error C2894: templates cannot be declared to have 'C' linkage
error C2894: templates cannot be declared to have 'C' linkage
error C2894: templates cannot be declared to have 'C' linkage
error C2894: templates cannot be declared to have 'C' linkage
error C2894: templates cannot be declared to have 'C' linkage
error C2894: templates cannot be declared to have 'C' linkage
error C2894: templates cannot be declared to have 'C' linkage
error C2894: templates cannot be declared to have 'C' linkage
error C2894: templates cannot be declared to have 'C' linkage
error C2894: templates cannot be declared to have 'C' linkage
error C2894: templates cannot be declared to have 'C' linkage
error C2894: templates cannot be declared to have 'C' linkage
error C2894: templates cannot be declared to have 'C' linkage
error C2894: templates cannot be declared to have 'C' linkage
error C2894: templates cannot be declared to have 'C' linkage
error C2894: templates cannot be declared to have 'C' linkage
error C2894: templates cannot be declared to have 'C' linkage
error C2894: templates cannot be declared to have 'C' linkage
fatal error C1003: error count exceeds 100; stopping compilation
***
The really strange thing, at least to me, is that so far none of the
other files in my library relies on string.h, so it seems that its
sole existence confuses MSVC somehow. One solution I thought was
avoiding the system include directory, but the problem is that some of
the classes need access to win32 api, so I need it.
Simple solution so far: just renaming string.h to stringxxx.h and
everything works ok. But of course, I'd like to use string.h for
clarity sake. Is there any workaround for this?
Thanks in advance.

[s***@gmail.com]

Post by Tom Serface
My guess is that you'd fix your problem by just using a name that wasn't
already taken as one of the standard names. Did you include string.h in
your string.cpp file and include it in the project. That alone would be
enough to attempt to cause the problem. Maybe you could call yours
MyString.h or something like that.

Hi there,

Yes, of course I do #include "String.h" in the .cpp file, and also
both files are included in the project.

Renaming fixes this, but alas, given that this is intended to be a
library providing some api to replace the natives, it would have been
nice to call it "String.h".. Also, when compiling with other
toolchains (gcc), this doesn't cause any problem..

Thanks anyway.

[Alf P. Steinbach]

Post by s***@gmail.com
Hi,
I'm having a weird problem when using Visual Studio. I'm creating a
small library with different utility classes. Thing is that everything
compiles ok, but when I create a string.h / string.cpp files, I get

[snip]

Post by s***@gmail.com
The really strange thing, at least to me, is that so far none of the
other files in my library relies on string.h, so it seems that its
sole existence confuses MSVC somehow. One solution I thought was
avoiding the system include directory, but the problem is that some of
the classes need access to win32 api, so I need it.
Simple solution so far: just renaming string.h to stringxxx.h and
everything works ok. But of course, I'd like to use string.h for
clarity sake. Is there any workaround for this?
Thanks in advance.

Possibly the standard C library [string.h] is included instead of your [string.h].

To include the C library [string.h]:

#include <string.h>

To include your own, in the directory of the file containing this directive,

#include "string.h"

To avoid problems, choose some other name.


Cheers, & hth.,

- Alf

[s***@gmail.com]

Hi there,

Post by Alf P. Steinbach
Possibly the standard C library [string.h] is included instead of your [string.h].
#include <string.h>
To include your own, in the directory of the file containing this directive,
#include "string.h"

I do exactly that, I use "" for my own headers, and <> for system's.
It seems the problem is in the include directory search order..

Post by Alf P. Steinbach
To avoid problems, choose some other name.

Yes, I think I'll end up doing that.. it surprises me that noone faced
this issue before, as it's quite common to have a file named string.h
in your own project. And I've been looking other libs and they indeed
use string.h, but have makefiles so probably they avoid the issue some
other way.

Thanks.

[Doug Harrison [MVP]]

Post by s***@gmail.com
Yes, I think I'll end up doing that.. it surprises me that noone faced
this issue before, as it's quite common to have a file named string.h
in your own project. And I've been looking other libs and they indeed
use string.h, but have makefiles so probably they avoid the issue some
other way.

You certainly can have your own header file named "string.h". It works, and
you don't have to do anything special for it to work. You haven't shown any
code to diagnose the problem, but I have seen headers that wrongly #include
standard headers with the "" syntax, which could cause problems if there is
a like-named file in the same directory as the header making the #include.
You could also run into trouble if you used the same #include macro guard
as <string.h> and #included your "string.h" first. I'd recommend trying to
reproduce the problem in a tiny console program.

[s***@gmail.com]

Post by Doug Harrison [MVP]

Post by s***@gmail.com
Yes, I think I'll end up doing that.. it surprises me that noone faced
this issue before, as it's quite common to have a file named string.h
in your own project. And I've been looking other libs and they indeed
use string.h, but have makefiles so probably they avoid the issue some
other way.

You certainly can have your own header file named "string.h". It works, and
you don't have to do anything special for it to work. You haven't shown any
code to diagnose the problem, but I have seen headers that wrongly #include
standard headers with the "" syntax, which could cause problems if there is
a like-named file in the same directory as the header making the #include.
You could also run into trouble if you used the same #include macro guard
as <string.h> and #included your "string.h" first. I'd recommend trying to
reproduce the problem in a tiny console program.

Thanks Doug,

Your comment made me try a bit more when I was losing hope. I finally
found the problem I think. As you said, I made a small little project
with 3 files: main.cpp, string.cpp and string.h. When these files are
in the same folder, there's no problem. *But*, if I organize things a
bit, separating headers from source files into separate folders (like
using \inc and \src) then the problem appears again.

So it seems that using "" is ok for header files in the same directory
as the source file, *but* if header files are in different
directories, then the system include directories have precedence over
the ones defined by /I parameter, which is certainly a pity, as I'd
have expected the ones defined by /D to be used first in such case.
Anyway as a workaround, I think I'll use inline methods for windows
builds, and maybe usual methods in other cases. This way the problem
shouldn't appear with MSVC at least.

Cheers.

PS: If anyone cares, here are the files I used. You can just create a
project/solution with these. If the files are in the same folder, it
will work, but if you use a tree structure (\inc, \src) it won't.

-- String.h --
#ifndef STRING_H_
#define STRING_H_

#include <string>

namespace System {

class String
{
public:
String();
~String();

private:
std::string mString;
};

}

#endif // STRING_H_

-- String.cpp --
#include "String.h"

namespace System {

String::String()
{}

String::~String()
{}

}

-- test.cpp --
#include "String.h"

int main()
{
System::String str("Hello");

return 0;
}

[s***@gmail.com]

Post by s***@gmail.com
Anyway as a workaround, I think I'll use inline methods for windows
builds, and maybe usual methods in other cases. This way the problem
shouldn't appear with MSVC at least.

Well, of course it doesn't work as it's not related to the main issue,
as any client code (test.cpp in this case) trying to #include this
header will be mostly in another directory.

So I think changing the file name is the only thing to do..

[Doug Harrison [MVP]]

Post by s***@gmail.com
Your comment made me try a bit more when I was losing hope. I finally
found the problem I think. As you said, I made a small little project
with 3 files: main.cpp, string.cpp and string.h. When these files are
in the same folder, there's no problem. *But*, if I organize things a
bit, separating headers from source files into separate folders (like
using \inc and \src) then the problem appears again.

IME, there is no problem with this, even when you organize things.

Post by s***@gmail.com
So it seems that using "" is ok for header files in the same directory
as the source file, *but* if header files are in different
directories, then the system include directories have precedence over
the ones defined by /I parameter, which is certainly a pity, as I'd
have expected the ones defined by /D to be used first in such case.

In VC++, the only difference between "" and <> is that the former starts
the search in the directory containing the file making the #include. For
the detailed rules, see:

http://msdn2.microsoft.com/en-us/library/36k2cdd4(VS.71).aspx

Post by s***@gmail.com
Anyway as a workaround, I think I'll use inline methods for windows
builds, and maybe usual methods in other cases. This way the problem
shouldn't appear with MSVC at least.
Cheers.
PS: If anyone cares, here are the files I used. You can just create a
project/solution with these. If the files are in the same folder, it
will work, but if you use a tree structure (\inc, \src) it won't.
-- String.h --
#ifndef STRING_H_
#define STRING_H_
#include <string>
namespace System {
class String
{
String();
~String();
std::string mString;
};
}
#endif // STRING_H_
-- String.cpp --
#include "String.h"
namespace System {
String::String()
{}
String::~String()
{}
}
-- test.cpp --
#include "String.h"
int main()
{
System::String str("Hello");
return 0;
}

Again, there's not enough detail to tell what you're doing when it fails.
You need to state which directories contain which files and give the
command line you're using.

[s***@gmail.com]

Post by Doug Harrison [MVP]

Post by s***@gmail.com
So it seems that using "" is ok for header files in the same directory
as the source file, *but* if header files are in different
directories, then the system include directories have precedence over
the ones defined by /I parameter, which is certainly a pity, as I'd
have expected the ones defined by /D to be used first in such case.

In VC++, the only difference between "" and <> is that the former starts
the search in the directory containing the file making the #include. For
http://msdn2.microsoft.com/en-us/library/36k2cdd4(VS.71).aspx

Thanks for this, it helps, but from what I'm experiencing, it doesn't
behave the way it's documented.. or something else is going on..

Post by Doug Harrison [MVP]

Post by s***@gmail.com
Anyway as a workaround, I think I'll use inline methods for windows
builds, and maybe usual methods in other cases. This way the problem
shouldn't appear with MSVC at least.
Cheers.
PS: If anyone cares, here are the files I used. You can just create a
project/solution with these. If the files are in the same folder, it
will work, but if you use a tree structure (\inc, \src) it won't.
-- String.h --
#ifndef STRING_H_
#define STRING_H_
#include <string>
namespace System {
class String
{
String();
~String();
std::string mString;
};
}
#endif // STRING_H_
-- String.cpp --
#include "String.h"
namespace System {
String::String()
{}
String::~String()
{}
}
-- test.cpp --
#include "String.h"
int main()
{
System::String str;
return 0;
}

Again, there's not enough detail to tell what you're doing when it fails.
You need to state which directories contain which files and give the
command line you're using.

You can put the cpp files in \test\src and the h file in \test\inc
To compile, just use:

cl test.cpp String.cpp /I..\inc

It won't work.

But if you move the h file to the same directory as the source files,
(and removing the /I option of course) it will work.. well, you'll
need to add the EHsc switch..

Cheers.

[Doug Harrison [MVP]]

Post by s***@gmail.com
You can put the cpp files in \test\src and the h file in \test\inc
cl test.cpp String.cpp /I..\inc
It won't work.

Works here (VC 2008).

Post by s***@gmail.com
But if you move the h file to the same directory as the source files,
(and removing the /I option of course) it will work.. well, you'll
need to add the EHsc switch..

If you want, save it to a zip archive, preserving the folder structure, and
email it to me.

[David Wilkinson]

Post by s***@gmail.com
Thanks Doug,
Your comment made me try a bit more when I was losing hope. I finally
found the problem I think. As you said, I made a small little project
with 3 files: main.cpp, string.cpp and string.h. When these files are
in the same folder, there's no problem. *But*, if I organize things a
bit, separating headers from source files into separate folders (like
using \inc and \src) then the problem appears again.
So it seems that using "" is ok for header files in the same directory
as the source file, *but* if header files are in different
directories, then the system include directories have precedence over
the ones defined by /I parameter, which is certainly a pity, as I'd
have expected the ones defined by /D to be used first in such case.
Anyway as a workaround, I think I'll use inline methods for windows
builds, and maybe usual methods in other cases. This way the problem
shouldn't appear with MSVC at least.

sip:

I always use the full relative path when doing something like that

#include "inc/string.h"

Does this not work?

[s***@gmail.com]

Post by David Wilkinson
I always use the full relative path when doing something like that
#include "inc/string.h"
Does this not work?

Actually the few libs I've been looking, that have String.h files do
use this technique.. so this seems to be a known "idiom" among library
developers.. I didn't want to use such construct, as some sources
don't recommend it (due to portability issues), but I think I can make
this restriction a bit more loose.

Cheers

[David Wilkinson]

Post by s***@gmail.com

Post by David Wilkinson
I always use the full relative path when doing something like that
#include "inc/string.h"
Does this not work?

Actually the few libs I've been looking, that have String.h files do
use this technique.. so this seems to be a known "idiom" among library
developers.. I didn't want to use such construct, as some sources
don't recommend it (due to portability issues), but I think I can make
this restriction a bit more loose.

sip:

Portability? You mean forward or backward slash? Forward slash always works for
me (I only use VC and various Unix/Linux compilers).

[Doug Harrison [MVP]]

Post by s***@gmail.com

Post by David Wilkinson
I always use the full relative path when doing something like that
#include "inc/string.h"
Does this not work?

Actually the few libs I've been looking, that have String.h files do
use this technique.. so this seems to be a known "idiom" among library
developers.. I didn't want to use such construct, as some sources
don't recommend it (due to portability issues), but I think I can make
this restriction a bit more loose.

I don't know any compiler for which it doesn't work, and it's the least
error-prone method I know. You might find the discussion beginning here
interesting:

http://groups.google.com/group/microsoft.public.vc.ide_general/browse_frm/thread/31ec01c026a3b626/b9b23803645f566a?#b9b23803645f566a

[s***@gmail.com]

Post by Doug Harrison [MVP]

Post by s***@gmail.com

Post by David Wilkinson
I always use the full relative path when doing something like that
#include "inc/string.h"
Does this not work?

Actually the few libs I've been looking, that have String.h files do
use this technique.. so this seems to be a known "idiom" among library
developers.. I didn't want to use such construct, as some sources
don't recommend it (due to portability issues), but I think I can make
this restriction a bit more loose.

I don't know any compiler for which it doesn't work, and it's the least
error-prone method I know. You might find the discussion beginning here
http://groups.google.com/group/microsoft.public.vc.ide_general/browse...

That's certainly very good advise. Thanks for that, it's really
helpful and you make quite a good point there. I'll stick to this
then, as the idea is having some other higher level libs relying on
this one.

@David: I read somewhere (maybe a faq?) that using path separators in
#includes was not portable wise, as some OS (Mac?) used things like
":" as path separators. Anyway, I think this may be an outdated
advise, and honestly I don't expect to build this on such system
anytime soon. Besides, the problem with the order of include dirs that
Doug mentions far outweighs this.

Thanks a lot for the useful help guys. Much appreciated.

Cheers.

[Doug Harrison [MVP]]

Post by David Wilkinson
I always use the full relative path when doing something like that
#include "inc/string.h"
Does this not work?

That's what I do and recommend. In fact, if you use flattened paths and try
to fix it up with /I, you can run into trouble when multiple libraries try
to do the same thing.

[n***@gmail.com]

Post by Doug Harrison [MVP]

Post by David Wilkinson
I always use the full relative path when doing something like that
#include "inc/string.h"
Does this not work?

That's what I do and recommend. In fact, if you use flattened paths and try
to fix it up with /I, you can run into trouble when multiple libraries try
to do the same thing.

You absolutely right, now i undestand this. I had the same problem in Visual Studio 2012 nowdays, when i used /Inc /Src directories with /I option. Now i place all files in the same directory where the .vcproj is. And use relative paths.

Thx to this topic, i had the same problem, i had mass errors, i googled "guiddef.h(161): error C3861" and i found this place and i solved the problem. I would not solve this with only error messages that i had, without google.

[Lynn McGuire]

Post by n***@gmail.com

Post by Doug Harrison [MVP]

Post by David Wilkinson
I always use the full relative path when doing something like that
#include "inc/string.h"
Does this not work?

That's what I do and recommend. In fact, if you use flattened paths and try
to fix it up with /I, you can run into trouble when multiple libraries try
to do the same thing.

You absolutely right, now i undestand this. I had the same problem in Visual Studio 2012 nowdays, when i used /Inc /Src directories with /I option. Now i place all files in the same directory where the .vcproj is. And use relative paths.
Thx to this topic, i had the same problem, i had mass errors, i googled "guiddef.h(161): error C3861" and i found this place and i solved the problem. I would not solve this with only error messages that i had, without google.

Why not use "mystring.h"?

Reusing a commonly used name is dangerous and
the following programmers will curse your name.

Lynn

[n***@gmail.com]

Have the same problem in Visual Studio 2012,
not only with String.h, but also with TypeInfo.h.

This is not feature, this is definitely a visual studio BUG, because it doesnt understand difference between #include "string.h" and #include <string.h> as supposed to. Hello microsoft, you prooved you suck again.