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

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@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
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
> 

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