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: sip.address on 29 Feb 2008 16:59 > >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.. > >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; > > > 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.
From: sip.address on 29 Feb 2008 17:00 > 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
From: Doug Harrison [MVP] on 29 Feb 2008 17:11 On Fri, 29 Feb 2008 13:59:04 -0800 (PST), sip.address(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 Visual C++ MVP
From: Doug Harrison [MVP] on 29 Feb 2008 17:23 On Fri, 29 Feb 2008 16:46:04 -0500, David Wilkinson <no-reply(a)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. -- Doug Harrison Visual C++ MVP
From: David Wilkinson on 29 Feb 2008 17:27
sip.address(a)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. sip: Portability? You mean forward or backward slash? Forward slash always works for me (I only use VC and various Unix/Linux compilers). -- David Wilkinson Visual C++ MVP |