Re: C++ bindings for POSIX [was Non-blocking I/O]

From: tom.widmer_at_[hidden]
Date: 2001-03-07 14:56:59

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 12:09 PM 3/7/2001 +0000, tom.widmer_at_c... wrote:
> 
>  >What we need if for some people to form a new standards body to come
>  >up with a new standard for, say, a C++ binding of POSIX,
> 
> Standards bodies standardize existing practice.  They are not suited for 
> doing things like figuring out a C++ binding for POSIX.

True. That's what boost is for! Or is that what, e.g., AT&T is for? :)

> 
> 
>  > that is
>  >easily ported to any platform that supports a C POSIX binding and a
>  >ISO compliant C++ compiler. Ideally, a Win32 port would be possible.
>  >All the realtime POSIX extensions would be designed in from the
>  >start, though not required (especially since I use a realtime OS :)
>  >
>  >Perhaps this what a group of the boost people could be doing, rather
>  >than working relatively independently on a hotch potch of reasonably
>  >portable libraries?
> 
> Well, why don't you make a proposal?  

haha, but I see your point.

> What is needed is leadership and high-level design skills.  Just how do you 
> take low-level C functions and turn them into C++ classes?  The approach 
> has to be generic enough that you can explain it to others on your 
> team.  The results don't have to be perfect, but should look like C++ 
> rather than C.

This is exactly what I'm suggesting (and no doubt others have - I don't read many boost posts) - in the boost group we have many of the top C++ gurus, and presumably a fair amount of POSIX knowledge (anyone on the POSIX standards committee?).

But I am realising that this problem is very, very difficult, so these various independent forays into different regions of POSIX/OS dependent components are perhaps a vital precursor to anyone being able to make the proposal that you are talking about. The top level of the design relies on what is possible and practical at the bottom and, more importantly, what is *known* to be possible and practical at the bottom. 

It's just frustrating that this will take so long (every one's a volunteer anyway, so have limited time to give to boost). By the time all these separate libraries are complete some geniuses (and I mean uber-geniuses, e.g. BS/AK) could have designed the whole thing and farmed out the implementation, which might be half done (but hopefully not half-baked!). But I doubt anyone is clever enough to design a *good* POSIX binding right now, without this intermediate experimental step involving a number of peer reviewed approaches and designs - new idioms are still being discovered/created that would be helpful in the final design and implementation.

Some might say that the C++ standard came too soon, before the difference that advanced template meta-programming could have made to the STL was known (the STL was a last minute addition in any case), and before the excellent effect that certain minor language changes would have made (e.g. built in type_traits, and some kind of generic iterator into the members of a class to allow automatic serialisation).

But as you say:
"The results don't have to be perfect, but should look like C++ 
> rather than C." 

Another problem is that the common tools/compilers are still not mature enough for the kind of code that some of the implementation might require.

Perhaps when the current wave of libraries is complete and the designs evaluated, some geniuses (as opposed to uber-geniuses) would like to make the proposal? By then we should be able to rely on reasonable template support from the major compilers (MSVC 8/gcc 3?).

I'll tail off my rambling now I think...

Tom