excessive stab information

[Dave Korn]

----Original Message----
>From: Andy Chittenden
>Sent: 28 April 2005 17:26

>> .... I'd have said that the
>> published-interfaces
>> directory "foo" should be in the default search path so that published
>> interfaces are accessible everywhere; the users can #include "bar.h". 
>> And if someone wanted to create a private header file in some
>> source dir called
>> "bar.h", and was complaining that it would be overridden by
>> the published
>> "bar.h", well, that's just as much their fault as if they'd
>> tried to create
>> a private header file called "stdlib.h" and were complaining about the
>> system's one overriding their own.
> 
> but then if you have 1000s of published directories, then the include
> path becomes unwieldy and you need to change it for each new subsystem
> that gets published. It also means that there's a risk of clashes if
> someone's called their header file something generic - making sure that
> each header file in each subsystem is uniquely named across the whole
> system is unrealistic. By using a directory structure for the published
> headers, we keep the compiler's include path manageable, it makes the
> compiler find header files faster (ie it's not searching 1000s of
> directories) and we avoid name clashes between sub-systems.

  Well, what would make that manageable would be if all the published
directories lived under one path, and the individual #includes then
specified #include "relative-subdir/published_foo.h".  This is how most
libraries work: lib FOO publishes its header files in a subdir called FOO
under /include, and users of those libraries specify #include
"FOO/foo_interface.h".  No namespace pollution, because the subdir named
after the module keeps all the different modules' interfaces separate.  No
1000's of published directories in the include path, just the top-level
/include, with the include paths specified relative to that.  And no
difference between how the client of a library refers to its published
interface header and how the internal components of that library do so.

  Have I accounted for all your objections there?

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....