Re: [boost] Re: py_cpp

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?

Someday, maybe.

> 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
> establish
> > > through usage what interfaces of code might require modification.
> > >
> > > It seems like once in Boost this library might still undergo
> significant
> > > 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.

-Dave