Boost logo

Boost :

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-10-18 13:02:57

I've now got some time to respond to some of the questions about
appropriateness for boost...

----- Original Message -----
From: "Moore, Paul" <paul.moore_at_[hidden]>

> From: David Abrahams [mailto:abrahams_at_[hidden]]
> > 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 certainly goes into uncharted territory for us. I asked the
> > question many months ago when I posted the first versions of
> > what I had done, but the group was silent on the topic.
> I recall the posting. I don't think I (personally) understood the
> implications of what you were saying at the time. Sorry. I see your point
> that inter-language libraries are a valuable resource, and I take the
> that just because this is the first does not mean it is inappropriate.
> FWIW, my view is that the "official" Boost libraries should be an
> of the C++ standard library, in principle. That is, platform-independent
> code which provides useful functionality for people coding applications in
> C++.

Well, py_cpp certainly fits that bill. Python is probably more portable, by
any reasonable measure, than C++ itself.

> In a similar manner to the C++ standard libraries, I see value in
> a standardised interface for certain highly generic OS-dependent
> (like the iostreams facility). This should be handled with care and
> restraint, so as not to rely on features which may not be available on all
> platforms (I know some platforms don't even have a concept of IO - there
> to be a balance here). An example of this is the thread stuff. While a
> generic threading library would be nice, we have to focus on the
> and "cross-platform" aspects (and the consequent "minimal" aspect) -
> otherwise we end up just picking one OS's approach and porting it to those
> platforms we care about.

IMO we have an opportunity to do things in boost that we can't do easily in
the standard. When considering a new library for the standard, these two
obstacles (among others) arise:
1. What about platforms that don't support that feature? Can we really
require the library to contain that component?
2. Where's the proof-of-concept?

They feed into each other in a viscious cycle. Nobody bothers to make an
implementation that could be considered for the standard because they know
we wouldn't be able to make a C++ compiler for some currently supported
platforms. These problems are part of the reason we don't currently have
thread support. Boost gives us the opportunity to deal with #2 until the
language lawyers figure out how to appropriately broaden the scope of the

> In this context, inter-language libraries are fraught with issues. We end
> inadvertantly taking sides in language wars ("why does Boost support
> but not Perl/TCL/Ruby/Lua/...?"). We are also tied into other software's
> versioning issues (does py_cpp interface to Python 1.5, 1.6 or 2.0?).

I agree with another poster that py_cpp can begin to provide a generic
framework for interfacing with other dynamic languages. I also believe that
inter-language interface is going to be one of those areas into which it
will be important to broaden the scope of C++, eventually.

> > One of the reasons I thought it might be a good thing to
> > include at boost is that Python's standard library still covers
> > a vast number of useful areas that std + boost do not.
> I'm not sure what you are implying in this. Can I write a sockets program
> C++ with py_cpp and Python? I assume that the resulting program would rely
> on Python, and hence would not compile into a single distributable EXE?
> of this is bad in itself, but it reflects back to the "is this appropriate
> territory" question again.

We haven't dealt with packaging issues with any other libraries at boost;
I'm not sure why it should be a more important issue in this case. (?)

> > I'm not sure that a library's review should be considered
> > premature just because there is lots of room for
> > expansion/improvement. In this case, one of the points of the
> > review would be to get a feeling for which of the new features
> > is most desired by potential users.
> Agreed. I strongly believe that we should get things into the official
> distribution "as soon as they are ready". Stability has to be a part of
> that, but also relevant are portability to as many compilers/OSes as
> possible, usefulness, completeness of documentation, ...
> Rejecting one library because it is likely to change, when we accept
> which doesn't run on half the C++ compilers out there, and another which
> barely documented, is unreasonable. Once a library is accepted, it will
> more users, and so there will inevitably be pressure to change things.
> is not a bad thing.
> Also, review (and subsequent acceptance) imply a commitment to developing
> and improving the library. Having a large number of libraries permanently
> "under construction" but never complete is more damaging to Boost's
> credibility than having released libraries undergo (controlled) change
> be.

All of these sound right to me.

> It's about the change from development to support. Support doesn't mean
> stagnation, but it does mean a focus on not breaking compatibility for
> existing users.

/What/ is about the change from development to support?

> > Is the concern that rapid improvements to a single library
> > might cost boost some credibility?
> It's an issue, but no more so than the others I mentioned. Even the
> library changed between versions of the draft. The key thing has to be a
> visible stable goal, and progress towards it. OTOH, if a library is
> "alpha quality", then it should wait a while before acceptance.


> > 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 decision, so 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 appropriate or inappropriate for boost.
> Agreed. Clarifying this issue is very important. In my view, it affects
> just py_cpp, but also the threading discussions and probably other areas
> well (there was some talk of GUI libraries a long while ago).
> As a general principle, I would argue that the basic benchmark would be
> we imagine this library being accepted into a future version of the
> standard?" On that test, I'd say that py_cpp would fail (and threads is
> borderline). But this needs clarifying and tightening up before it is a
> reasonable guide. (Assuming that the group agrees with me).

It really depends whether you think that the general scope of the C++
standard will be limited for all time to generalized computational jobs and
basic i/o. I believe that for C++ to survive and thrive, it will need to
have a vastly expanded library, that begins to cover the same kind of
territory as Java's or Python's library (see Why
do people decide to build their GUIs in web browsers with
HTML/Java/JavaScript instead of C++ these days? There are lots of reasons,
but the fact that there's no standard, portable C++ GUI is one of them.

Just to prove that inter-language binding isn't too far afield, I'd like to
point out that there is already a subgroup of the C++ committee working on a
standardized SQL binding. Herb Sutter is leading the group.


Boost list run by bdawes at, gregod at, cpdaniel at, john at