From: David Abrahams (abrahams_at_[hidden])
Date: 2000-10-18 13:20:06
----- Original Message -----
From: "William Kempf" <sirwillard_at_[hidden]>
> Then would it not be more appropriate to develop those missing areas
> in pure C++ code?
> I really don't intend to criticize here, because the library is
> vastly important and useful to some people (I don't know python yet,
> so I'm not one of them, but I'm not letting my lack of knowledge here
> cloud what I'm saying). However, I thought one of the major goals of
> Boost was to develop C++ libraries that through evolution and use
> might be considered with the next language standard? If I'm right
> about that goal, py_cpp doesn't fit with Boost.
I hope my counterargument from previous emails covers this.
> It's not possible
> for the standard to address multiple languages or gaurantee proper
> interaction between them, even if that's possible to do in the real
> world. For instance, extern "C" is the closest thing we have to
> something like this in the standard today, and all it does is
> gaurantee no name mangling. It's up to vendors to define what else
> this linkage might mean (i.e. parameter passing rules, etc.). As
> pointed out on comp.std.c++ recently, it doesn't gaurantee that any
> given C compiler can link object code from any given C++ compiler
> generated with extern "C" linkage. In practice we know this works,
> because OS vendors give specifications about all of this that
> compiler vendors (voluntarily) follow. But those specifications are
> (rightfully) external to any language standard.
It isn't an issue of rightfulness, it is an issue of practicality. We could
have written language into the standard that defines the concept of a
platform, requires it to define 'C' a linkage convention, then declares that
extern "C" is compatible with that. It's a lot more work to do that, though,
and be sure you're getting it right.
> So long as the library is complete at time of submission then I agree
> that just because there's further extensions planned is not a reason
> to delay submission. I hope to use a similar tactic with the Boost
> thread library, submitting a core set of features that will allow
> developers to expand into more complex concepts.
Then we have to define "complete". Py_cpp was complete in that it was useful
and relatively bug-free upon submission. There were also a lot of obvious
enhancements waiting to be made.
> > > I thought the idea was to include a library and then over time
> > > through usage what interfaces of code might require modification.
> > >
> > > It seems like once in Boost this library might still undergo
> > > changes on a weekly basis. Perhaps I'm wrong on this, but previous
> > > comments and added features during the review period have slightly
> > > concerned me.
> > Is the concern that rapid improvements to a single library might
> cost boost
> > some credibility?
> I'd say that's a concern, but it doesn't lead to concluding that a
> library not be included just because extensions are planned. What's
> important is that the extensions are carefully thought out and go
> through a seperate review period.
That is /not/ part of the boost protocol as I understand it (though I notice
the online documentation gets very fuzzy at this point). Once it is
accepted, changes to a library do not undergo the same formal review
process. Maybe we should change that, but IMO it might impede progress.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk