Re: Woo hoo ... a whole new set of compiler headaches!! :) - Mailing list pgsql-hackers

From Dave Held
Subject Re: Woo hoo ... a whole new set of compiler headaches!! :)
Date
Msg-id 49E94D0CFCD4DB43AFBA928DDD20C8F9026184D3@asg002.asg.local
Whole thread Raw
In response to Woo hoo ... a whole new set of compiler headaches!! :)  ("Marc G. Fournier" <scrappy@postgresql.org>)
Responses Re: Woo hoo ... a whole new set of compiler headaches!!
Re: Woo hoo ... a whole new set of compiler headaches!! :)
List pgsql-hackers
> -----Original Message-----
> From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
> Sent: Friday, April 22, 2005 1:59 PM
> To: Dave Held
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Woo hoo ... a whole new set of compiler
> headaches!! :)
>
> [...]
> I think there are some features we could use in C++.  As a simple
> example, "//" for comments.

Actually, the C committee deemed that to be such a useful style that
they added it as early as C89, if I recall correctly. ;)

> Howevrer, C++ is a far larger language than C, and I am concerned
> we would be unable to control which features of C++ got into our
> code and which did not, leading to a slower, overly complex, uneven
> hunk of code.

I don't know why you would be unable to control features of the
language any less than you control adding features to the database.
Aren't all patches reviewed?  As long as the reviewers know what the
current standards are, there shouldn't be any surprises.  If the
reviewers don't recognize the code, they shouldn't approve the patch.
As far as slower, there is always an "abstraction penalty" of some
sort.  That is the price of code safety.  However, C++ is one of the
few languages that explicitly attempts to bring this cost as close to
zero as theoretically and practically possible, and in most cases, it
does very well.  The C++ committee has published a performance report
that should be interesting reading for those who think that C++ is a
slow language:

www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1396.pdf

As far as complex, C++ is necessarily more complex than C.  The
question is whether that additional complexity is justified by the
benefits it brings.  For the basic OOP features of C++, I think I
could make a pretty solid case.  For the generic/meta-programming
features of C++, I could make a very solid case for a new project,
but not necessarily for Postgres.  Can you write overly complex C++
code?  By all means.  Are a bunch of C programmers who are taking
in C++ a little at a time likely to write overly complex C++ code?
Not the least bit likely.

As I've said before, there are actually many opportunities for C++
to provide performance advantages over C.  Const correctness combined
with an optimizing compiler that performs const propagation can
give you both strong type safety and higher performance for statically
analyzable code.  Inlined functions and function objects can give all
kinds of opportunities for speed enhancement.  And templates can
significantly reduce source code size when used correctly.  That
translates directly to easier readability and maintainability, though
that isn't something I would push onto Postgres until all the simpler
features had been exploited first.  And there's plenty of those to
exploit.

Encapsulation would allow developers to define and enforce invariants
for data types that is checked at the language level.  While that
can be emulated in C, doing so to the same extent as what is available
naturally in C++ would lead to significantly bloated code.  Greater
type safety leads to more correct code.  It leads to easier to read
and easier to write code, because with enforced invariants, you know
what to expect and what not to expect from various operations.  When
everything is public, you are at the mercy of the entire codebase,
and 600k lines is a lot of code to wade through.

The reason that C->C++ is such a smart conversion is exactly because
you don't have to do things in big hunks.  You don't have to convert
wholesale to a different language paradigm.  You can take tightly
prescribed steps, and stop at any point along the way.

__
David B. Held
Software Engineer/Array Services Group
200 14th Ave. East,  Sartell, MN 56377
320.534.3637 320.253.7800 800.752.8129


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Bitmap scans vs. the statistics views
Next
From: Jan Wieck
Date:
Subject: Re: Bitmap scans vs. the statistics views