Subject: Re: [boost] [config] problem with sys/select.h on Linux/Unix
From: Iain K. Hanson (iain.hanson_at_[hidden])
Date: 2009-07-01 09:02:30
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
> Cheers, John.
> PS select.h appear to be pulled in via <cstddef> in
Thanks for the help.
-- "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>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk