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 17:28 On Fri, 29 Feb 2008 14:00:59 -0800 (PST), 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. 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 -- Doug Harrison Visual C++ MVP
From: sip.address on 29 Feb 2008 18:23
On Feb 29, 11:28 pm, "Doug Harrison [MVP]" <d...(a)mvps.org> wrote: > On Fri, 29 Feb 2008 14:00:59 -0800 (PST), sip.addr...(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. > > 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. |