Re: C++ (was: parser)

[Predrag Balorda <balorda@bigfoot.com>]

> > >And no, religious wars will not be tolerated, only constructive
> > >comments please.
> >
> > But you have not presented anything but religious arguments for
> > rewriting OpenLDAP in C++.  You, in effect, have said C++ is
> > righteous and C is evil.   Guess I must be a pagan.
> 
> Some points that may be useful:
> 
>         - C++ has come a long way. I rejected C++ four years ago as being to
> messy and not well implemented enough. However, the STL (standard C++
> library) is available and in pretty good shape. Furthermore, the language
> has been pretty stable for a while now, with no new features. egcs performs
> really well, over a wide range of architectures and applications.
> 
> The advent of the STL means that many useful objects are available, with
> optimized implementations. For example, the string object is very useful
> while still being lightweight.
> 
>         - C++ lends itself very well for applications like LDAP. Most
> objects can be tought to clean up after themselves. Objects can even cache
> themselves is smart ways. This saves tremendously on bookkeeping tasks which
> now seem to be an important part of the OpenLDAP source
> 
>         - Abstraction would be very useful to support multiple backends
> transparently. No nasty function tables to maintain.
> 
> Converting to C++ however isn't an incremental process. To benefit, lots of
> things have to be redesigned en reimplemented. This might scare of existing
> developers.
> 
> I need to shutdown my OpenLDAP servers every week because they exhaust my
> virtual memory..
> 
> Programmers hate doing cleanup, C++ facilitates this task enormously.

Again, I am being misunderstood by Kurt there. I didn't present a
"religious" argument and sure as hell haven't said C is evil.
I have said that LDAP hierarchy, such as it is, could easily be
represented with classes (or a single class for that matter).
Also, nodes can do operations for/on themselves, they would have their
own properties (ok structs in C cover that) and member functions (C
can't cover that) which is much more convenient and elegant.
When you asked why not another language, I really didn't think anyone on
our devel list would like a notion of implementing an LDAP server in
Java for example, but I would be up for it any day. I guess I was wrong
there. By saying "C++" I'm not trying to make a case for a specific
language, but instead trying to assert an object oriented approach,
which language we choose is irrelevant at this stage.

Performance is becoming less important with every new cpu churned out by
the big guys. Correctness of implementation and stability should always
be paramount. But having said that new compilers now days tend to
produce fast code anyway and notion of having to code in assembler just
to speed up a critical loop is gone. At least in UNIX world...

The point about not going for Java though is that maybe it still is a
bit early for going down that route and I don't think we would be taken
seriously (performance or otherwise) by the rest of the world.

But as I said..just a thought, nothing else...

Pele