Problem when defining my own string.h
in [Visual C]
|
Prev: error C2065: 'PROTECTED_DACL_SECURITY_INFORMATION' : undeclared identifier
Next: Warnings about deprecated / insecure function usage
From: Doug Harrison [MVP] on 29 Feb 2008 13:01 On Fri, 29 Feb 2008 08:21:53 -0800 (PST), sip.address(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
From: sip.address on 29 Feb 2008 15:13 On Feb 29, 7:01 pm, "Doug Harrison [MVP]" <d...(a)mvps.org> wrote: > On Fri, 29 Feb 2008 08:21:53 -0800 (PST), sip.addr...(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. 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; }
From: sip.address on 29 Feb 2008 16:05 On Feb 29, 9:13 pm, sip.addr...(a)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..
From: Doug Harrison [MVP] on 29 Feb 2008 16:31 On Fri, 29 Feb 2008 12:13:48 -0800 (PST), sip.address(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 >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; >} 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. -- Doug Harrison Visual C++ MVP
From: David Wilkinson on 29 Feb 2008 16:46
sip.address(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 |