|
Boost : |
From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-01-22 16:06:00
At 08:29 AM 1/22/2002, dmoore99atwork wrote:
>> I do have a couple of questions for other people who have spent
>time thinking on this problem...
>
>I forgot one!
>
>5. In the requirements document, it is suggested that since platform
>header files for socket APIs are notorious for poor macro practices
>like redefining "send", etc., that these headers should never be
>included by any Boost socket headers that are a part of the public
>interface. I understand the rationale, but...
I wrote that, and it might be too strong. It could have said something
like if you include a platform specific header with damaging macros, do so
in a way (#undef or whatever) that the danger does not propagate into user
code. But one problem is what happens when the header changes.
Some of these headers really do have macros with names like "send" - that
isn't an exaggeration!
> Wrapper classes for
>in_addr and sockaddr_in would need to use heap allocation for their
>wrapped structures. Is this worth it? I'm leaning towards "yes", as
>the heap allocation doesn't seem to be anything to be afraid of,
>except perhaps in busy servers....
I'm inclined to thing that even on the busiest server the cost of dynamic
allocation would so low as to be nonexistent compared to the rest of what a
sockets library does.
In any event, your interface design should not require inclusion of
platform headers. That should be an implementation decision left up to the
implementor, not something required by the interface.
--Beman
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk