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: