Problem when defining my own string.h

[sip.a...@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

<sip.a...@gmail.com> wrote in message
news:efd61d70-2a59-4024...@41g2000hsc.googlegroups.com...

[Alf P. Steinbach]

* sip.a...@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:
>

[snip]

>
> 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

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[sip.a...@gmail.com]

On Feb 29, 4:35 pm, "Tom Serface" <tom.nos...@camaswood.com> wrote:
> 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.

[sip.a...@gmail.com]

Hi there,

> 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"

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..

> 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]]

On Fri, 29 Feb 2008 08:21:53 -0800 (PST), sip.a...@gmail.com wrote:

>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.

--
Doug Harrison
Visual C++ MVP

[sip.a...@gmail.com]

On Feb 29, 7:01 pm, "Doug Harrison [MVP]" <d...@mvps.org> wrote:

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;
}

[sip.a...@gmail.com]

On Feb 29, 9:13 pm, sip.addr...@gmail.com wrote:
> 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]]

On Fri, 29 Feb 2008 12:13:48 -0800 (PST), sip.a...@gmail.com wrote:

>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.

>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

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.

[David Wilkinson]

sip.a...@gmail.com wrote:
> 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?

--
David Wilkinson
Visual C++ MVP

[sip.a...@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

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..

> > 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.

[sip.a...@gmail.com]

> 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

[Doug Harrison [MVP]]

On Fri, 29 Feb 2008 13:59:04 -0800 (PST), sip.a...@gmail.com wrote:

>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.

Works here (VC 2008).

>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.

[Doug Harrison [MVP]]

On Fri, 29 Feb 2008 16:46:04 -0500, David Wilkinson <no-r...@effisols.com>
wrote:

>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.

[David Wilkinson]

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]]

On Fri, 29 Feb 2008 14:00:59 -0800 (PST), sip.a...@gmail.com wrote:

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

[sip.a...@gmail.com]

On Feb 29, 11:28 pm, "Doug Harrison [MVP]" <d...@mvps.org> wrote:

> On Fri, 29 Feb 2008 14:00:59 -0800 (PST), sip.addr...@gmail.com wrote:
> >> 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...

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.

[Lynn McGuire]

On 10/11/2013 7:49 PM, newb...@gmail.com wrote:
> суббота, 1 марта 2008 г., 8:23:32 UTC+10 пользователь Doug Harrison [MVP] написал:

> 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