From: William Kempf (sirwillard_at_[hidden])
Date: 2000-10-17 08:53:04
--- In boost_at_[hidden], "David Abrahams" <abrahams_at_m...> wrote:
> ----- Original Message -----
> From: "Paul Baxter" <paul_baxter_at_i...>
> > Paul Moore wrote:
> > > I've been watching the py_cpp messages go past, and while I
> > to
> > > sound like I'm being negative for the sake of this, I wonder if
> > is
> > > really appropriate for Boost?
> > > Comments? I'm surprised that no-one else has said this - am I
> > > something fundamental from not having actually looked at py_cpp?
> For the record, I have never had a clear idea of whether py_cpp is
> appropriate for Boost - as the first inter-language library, it
> goes into uncharted territory for us. I asked the question many
> when I posted the first versions of what I had done, but the group
> silent on the topic.
> One of the reasons I thought it might be a good thing to include at
> that Python's standard library still covers a vast number of useful
> that std + boost do not.
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. 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.
> > I had thought much the same, but since it is already in for
> > thought the point was moot.
> > I also wonder whether it is too soon to review it (even if right
> > boost) since previous messages have alluded to further changes in
> > near future which sound a little more than problem fixing.
> I'm not sure that a library's review should be considered premature
> because there is lots of room for expansion/improvement. In this
> of the points of the review would be to get a feeling for which of
> features is most desired by potential users.
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.
> > 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
> 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.
> > Having said all that, I'm chiefly on the sidelines and people
> > are an excellent driving force behind Boost. I certainly don't
> > to take these comments personally and do appreciate what looks
> > very useful library for both the python and C++ communities.
> I'm not offended in the least, and am happy to leave that decision
up to the
> group at large. That said, I think it is important that if we
decide not to
> accept py_cpp, that we understand the criteria for making that
> we can make them part of boost policy. So far, the remarks I've
heard do not
> clearly state what it is that would cause py_cpp to be deemed
> inappropriate for boost.
I hope the reason I gave is valid here, though I'm making an
assumption about the goals of Boost.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk