httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@gonzo.ben.algroup.co.uk>
Subject Re: C++ components?
Date Wed, 24 Jul 1996 09:09:37 GMT
Robert S. Thau wrote:
> 
>   I'd be interested to know about these things:
> 
>   1. Would anyone object if I C++-proofed Apache? This would probably not be
>   much more than the odd extern "C" in the headers.
> 
> There are also probably namespace collisions crawling around which
> you'd have to resolve.  I'm not sure how *much* of this there is, but
> there's some.

I've been told since I posted that the only namespace problem is "pool".

> 
>   4. Do any of you actually like C++?
> 
> Well, I'll toss in a dissenting vote on this one.  I've seen too many
> people get lost in a web of gotchas with C++.  The main problem with
> it is that it has all sorts of machinery which *looks* elegant,
> simple, and neat, but drags you into a tarpit when you actually try to
> use it.  "Smart pointers", for instance, seem like a neat idea, until
> you're trapped on the downward spiral of proxy classes and the like
> which you have to define in order to actually build and use them.

I'm not sure what you mean by smart pointers, but I'm guessing that you mean
some kind of wrapper for a pointer that hides tricks like double indirection
and link counting, right? I've actually implemented this and it wasn't too bad,
IMO, and that was before templates, too. The hairiest bit was deferring the
deletion of objects that removed the last link to themselves ;-)

> 
> Likewise, the language doesn't provide any automated storage
> management of its own, but provides tools for *you* to do it, if you
> choose.  Of course, if you do, then what you find out is that actually
> making these things work robustly is very, very hard, and is best left
> to the implementors of the language runtime.

Well ... I'm not sure I'd agree with this. It is certainly a damn sight easier
in C++ than it is in C. Interfacing C++ to the pool stuff would be trivial,
though getting the destructors called when the pool is destroyed might be
harder (if we actually want to - it would be the logical way to do the
cleanup routines).

>  (At this point, someone
> may pipe up to say that garbage collection has overhead.  Well, yeah,
> it does.  However, malloc()/free(), and schemes built upon it, also
> have overhead --- often more, in fact, than a well-implemented GC.
> See, for instance, http://www.geodesic.com --- when their GC for C++
> is linked to an unmodified X server, it gets faster, measured by
> x11perf).
> 
> One of the things that makes these deficiencies come up so often, of
> course, is the failure of the language itself to supply an adequate
> library of container types (something that STL may help to rectify,
> though it isn't to everybody's taste, and was still missing basics
> like hash tables last time I looked), but I'm not at all sure that
> covers everything.

No hash tables? Yuk. Anyway, I still haven't got round to looking at STL but
its on the list...

> 
>   6. Would there be any interest in creating a completely C++ Apache?
> 
> Well, see above.  I can see wanting to use a better language than C,
> but if you want to find one, then I can easily imagine better ones
> than C++ as well, and would probably choose another (Java is, at this
> point, a very interesting candidate, but so are Python, Modula-3.

I'm not so sure about these alternatives, but a strong argument against them
is the reduction of the "out-of-the-box experience" that C/C++ gives us. This
may change, of course.

> What I'd *really* like is a decent, high-performance implementation of
> SML, but the current implementations have an unfortunately high
> performance hint.  I'm hoping that when (if!)  CMU produces a
> production-quality version of their type-directed research compiler,
> this will improve...).

OK, I'll bite. What's SML?

Cheers,

Ben.

> 
> rst

-- 
Ben Laurie                  Phone: +44 (181) 994 6435
Freelance Consultant and    Fax:   +44 (181) 994 6472
Technical Director          Email: ben@algroup.co.uk
A.L. Digital Ltd,           URL: http://www.algroup.co.uk
London, England.            Apache Group member (http://www.apache.org)

Mime
View raw message