Hi, On Wed, 2009-07-01 at 11:16 +0100, John Maddock wrote:
It doesn't: at least not deliberately, my guess it's included by something else like <unistd.h> which we really do need.
Thanks for the reply, but unistd.h is not the culprit either directly or indirectly. Two possible candidates are sys/time.h and sys/types.h. Are either of these used directly or indirectly in boost config?
Nope, just unistd.h limits.h and stdint.h as far as I can tell.
stdint.h pulls in sys/types.h
Other boost libs document their dependencies. It would be useful if boost config documented the headers it includes, particularly as the C headers pollute the global namespace.
Do you have any thoughts on a work around? It is awkward trying to write a library intended for submission to boost and not being able to use either config or the unit test framework.
OK here's the thing, it looks to me as though that header is very likely to be included even if it's by the users own code based on what you're saying?
If so, then it's going to be important for you code and these system headers to happily live together, can you give an indication of what you're trying to do?
I am trying to write a sockets library and the general admonishment has been to avoid macro infested system headers. Given time to think about it overnight, I have come to the same conclusion as you. That I am going to have to live with at least some these system headers. sys/types.h defines size_t which is pretty fundamental ;-). I guess I'll have to just undef the macros I need to exclude.
Cheers, John.
PS select.h appear to be pulled in via <cstddef> in select_stdlib_config.hpp.
Thanks for the help. Regards /ikh -- "I disapprove of what you say, but I will defend to the death your right to say it," Evelyn Beatrice Hall who wrote under the pseudonym S.G. Tallentyre in a biography of Voltaire. #include <std_disclaimer>