httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Tatarinov <tatar...@prairie.NoDak.edu>
Subject Re: 2.0: process model design
Date Sun, 23 Nov 1997 03:14:42 GMT
Alexei Kosut wrote:
> 
> On Sat, 22 Nov 1997, Igor Tatarinov wrote:
> 
> > How about doing 2.0 in C++? Many things would be so much nicer then.
> 
> We've discussed this. I have nothing against C++, but I think there are
> several reasons that we should stick with C (in no particular order):
> 
> 1) C++ compilers are much harder to come by than C compilers on a given
>    platform. Nearly any Unix system will have a C compiler available, with
>    mostly working ANSI C libraries. Most Unices will not have C++
>    compilers by default, and if they do, they are often broken. If we
>    moved to C++, we'd have to require that those using it download a C++
>    compiler (gcc, most likely), and possibly some C++ library (now that
>    there is finally an ISO C++ standard, this might become easier).
> 
>    Apache wants to run and support as many OSes as possible, out of the
>    box. C++ makes this much harder to do.

I can argue against that. Most users do not probably need the source 
code. so binary execs would be enough.
 
> 2) Apache is written in C. Regardless of what we keep talking about,
>    Apache 2.0 will not be a ground-up rewrite. 
> 
>    If we moved to C++, Apache would have to be rewritten completely to be
>    object-oriented, or there's really no point. And that would involve a
>    lot more work than we're really prepared to give it, I think.

I can agree with that.
 
>    In addition, I suspect many Apache developers (myself included) are not
>    as familiar with C++ as they are with C. Because Apache is a volunteer
>    organization, and we have to training budget, this may be a good enough
>    reason to stick with C.

If this is true, I withdraw my idea. It's well known that to reap the 
benefits of OOP one has to spend much more time in design than in the 
traditional approach. Of course, experience helps a lot here.
 
> That being said, I think the code should be made more C++-friendly. By
> that I mean it should compile with a C++ compiler, which it does not now
> (namespace problems). The header files should contain extern "C"
> declarations and the like, etc... And it is my plan that, when I finally
> get around to writing up my spec for the Apache 2.0 module API, it will be
> C++-saavy, so that you can write modules in C++, and pretend you are
> dealing with objects (though you aren't, really).

I am not sure it's really worth it. Those who want to modify Apache
will probably use a C compiler anyway. Other users can download 
binaries.

igor

Mime
View raw message