Re: Woo hoo ... a whole new set of compiler headaches!! :)

You make some good points below. I personally think C++ would be an
interesting change. It would bring additional functionality to the
language, but patch application would also have to filter C++ feature
additions along with the code changes themselves, and there is
variability in C++ compilers and the features they support.

It is really an cost/benefit judgement call.

---------------------------------------------------------------------------

Dave Held wrote:
> > -----Original Message-----
> > From: Bruce Momjian [mailto:pgman(at)candle(dot)pha(dot)pa(dot)us]
> > Sent: Friday, April 22, 2005 1:59 PM
> > To: Dave Held
> > Cc: pgsql-hackers(at)postgresql(dot)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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073