Boost logo

Boost :

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2005-12-23 01:11:06


Christopher Kohlhoff wrote:
> Hi Rene,
>
> --- Rene Rivera <grafik.list_at_[hidden]> wrote:
> <snip>
>
>>My original contention is a compatibility concern. I want to
>>be able to write a *single* program that for compatibility can
>>run on Linux 2.4 and above. In such a situation I need to
>>query the OS to find out the optimal (from my point of view
>>not Asios' POV) method and instantiate/use it. Hence I am
>>using more information than is available when Asio makes its
>>optimization choice.
>
> But if your use case is as you described before, where you only
> have one or a small number of sockets, then why not just compile
> for a Linux 2.4 target only?

Because this is a concern for everyone. I might be the only person
currently asking for this, but I won't be the last. I am raising these
issues for the general benefit of the Boost review. Someone has to think
about how the library addresses the full spectrum of needs, even if it
wasn't originally designed for it. The best designed libraries can
accommodate unknown uses. But if your position is that since it doesn't
allow for a certain, to my POV, reasonable modularity standard to just
"hack" around it, I'd have to say that my vote went from "no but I would
consider changing it". To a: "vehement no". I don't want to see
libraries in Boost that fail some basic abstraction uses.

But to make the selection of which method, epoll, select, etc., to use
more salient to you personally, I have a simple question for you if Asio
is accepted into Boost:

How do you expect to write tests for your library that cover *all* the
various methods supported in one platform?

PS. I know I'm probably getting on your nerves by now. But that's what
reviews are like ;-)

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk