Subject: Re: Why We Should Use the STL (fwd)
From: sam th (sam@uchicago.edu)
Date: Sun Jun 04 2000 - 21:30:38 CDT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun, 4 Jun 2000, Paul Rohr wrote:
> >2c. I am resistant to a veto because I am sympathetic to the issue.
>
> I'm not.
>
> The choice to use C++ **at all** wasn't easy, because it reduced the chances
> that we'll get significant code contributions from the very large population
> of C-only coders out there. For example, the large mass of GNOME developers
> stays out of our codebase entirely. This is not a Good Thing.
>
Well, we do have GNOME developers around (as I'm sure you
know). Obviously, there's Joaquin, but Dom Lachowicz posts occasionally
and I've even seen Havoc post. That said, the language bigotry shown by
many members of the open source community (try reading the linux-kernel
posts about esr's new config system - which is in python) is one of our
less intelligent aspects. C++ makes our XP development much easier (as
you pointed our in your presentation) and is the right tool for the
job. It is not our fault that some people can't accept that. Any they
shouldn't be able to force us to use sub-optimal tools.
> Sure, very experienced C++ coders will want to make use of more advanced
> features of the language, but every one of those features we add makes it
> *harder* for other folks to read and expand our code.
>
> As it is, I feel that we're very lucky each time that folks like Martin have
> chosen to surmount our *existing* C++ obstacles so that they can make
> significant contributions to our code.
>
Well, I don't count as a 'very experienced C++ coder' (or a very
experienced coder at all) but I don't think that this would prevent other
people from working with our code. In fact, no one even has to know that
UT_Vector is implemented using the STL. Currently, I suspect no one looks
at the UT_Vector code anyway, they just use it. This won't change if the
implementation changes (I seem to remember this being a much-touted
benifit of OOP).
> >As a practical matter, I can raise only two real objections:
> >
> >1. Support for vendor compilers still matters, at least to me.
> >Does anyone know if the QNX compiler can handle templates
> >properly? What about BeOS? Solaris?
Well, according to STLport, they work fine with SunPro 4.0+. Additonally,
Sun bundles the STL with their complier. Be distributes CodeWarrior as
their default development tool. QNX ships Watcom, also supported by
STLport.
>
> What about Amiga? What about various experimental GUI prototypes currently
> being developed that you and I have never heard of?
>
> I've used this line as a sig occasionally:
>
> "The world only needs one word processor -- AbiWord"
>
Amen.
> The fact that we're Open Source, and we've done our XP job so well, means
> that we have a very real chance that 10 or 20 years from now, it absolutely
> won't matter how obscure your platform of choice is -- you can run a
> full-strength modern word processor on it.
>
> As an example, consider the die-hard Amiga community. It's a dedicated,
> passionate community, but I'm not sure it's large enough to sustain a
> compiler-development team which tracks all the ins and outs of the evolving
> C++ standard.
>
Well, you've motivated me to go read the developer stuff on the Amiga
website. To quote:
"Of course C is also provided via the GNU compiler but this simply
compiles source down into VP Code anyway."
VP Code is their glorified assembly language (which they want people to
program in). So unless they rip the C++ front end out of GCC, the Amiga
will support the STL.
> If those folks really want to exchange content with everyone else, they
> "just" have to port AbiWord. Sure it's work, but it only has to be done
> once.
>
> However, every time we choose a more modern technology feature as a
> pre-requisite for AbiWord development, we risk obsoleting communities that
> aren't firmly in the mainstream.
>
Despite what some of the people on Slashdot think, AFAIK there are no real
C++ compilers without template support. In 10 or 20 years, platforms
without such support will be in museums (unless C++ is too).
> >2. I still don't see how a switch to STL helps us achieve the
> >kinds of major user-visible improvements which we still need in
> >order to reach a version 1.0.
>
> This the the bottom line, right?
>
> For any advanced language feature, I'd prefer to see a *huge* win in some
> critical area which can't readily be accomplished in some other way.
>
If I wasn't in the process of moving (and of not studing for my final, in
C++ programming of all things :-) I would already have the UT_Vector part
done. It really won't be much work.
sam th
sam@uchicago.edu
http://sam.rh.uchicago.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE5OxDQt+kM0Mq9M/wRAkZ5AJsGupdO0/y9jZa5D4EVPRO/HgXImgCg3Ncz
blqdMjKYgFGZUypqIzIYYIA=
=k0uY
-----END PGP SIGNATURE-----
This archive was generated by hypermail 2b25 : Sun Jun 04 2000 - 21:30:44 CDT