Thread: Woo hoo ... a whole new set of compiler headaches!! :)
================== Date: Fri, 22 Apr 2005 00:15:31 -0700 From: Mark Mitchell <mark@codesourcery.com> To: gcc-announce@gcc.gnu.org, gcc@gcc.gnu.org Subject: GCC 4.0.0 has been released GCC 4.0.0 has been released. This release is a major release, containing (among many other features) new optimization infrastructure that enables GCC to perform more high-level optimizations that has been possible in the past. A more complete list of changes is at: http://gcc.gnu.org/gcc-4.0/changes.html This release is available from the FTP servers listed here: http://www.gnu.org/order/ftp.html The release is in the gcc/gcc-4.0.0 subdirectory. As usual, a vast number of people contributed to this release -- far too many to thank by name! -- Mark Mitchell CodeSourcery, LLC mark@codesourcery.com (916) 791-8304 ==================== ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
> -----Original Message----- > From: Marc G. Fournier [mailto:scrappy@postgresql.org] > Sent: Friday, April 22, 2005 8:56 AM > To: pgsql-hackers@postgresql.org > Subject: [HACKERS] Woo hoo ... a whole new set of compiler headaches!! > :) > > GCC 4.0.0 has been released. > [...] I think that's great news! If the code is written in a conforming way, I don't see why a new release would be a cause for headaches. And if new compiler releases *are* a cause for headaches, it doesn't give me great confidence in the codebase. __ David B. Held Software Engineer/Array Services Group 200 14th Ave. East, Sartell, MN 56377 320.534.3637 320.253.7800 800.752.8129
On Fri, 22 Apr 2005, Dave Held wrote: >> -----Original Message----- >> From: Marc G. Fournier [mailto:scrappy@postgresql.org] >> Sent: Friday, April 22, 2005 8:56 AM >> To: pgsql-hackers@postgresql.org >> Subject: [HACKERS] Woo hoo ... a whole new set of compiler headaches!! >> :) >> >> GCC 4.0.0 has been released. >> [...] > > I think that's great news! If the code is written in a conforming way, > I don't see why a new release would be a cause for headaches. And if > new compiler releases *are* a cause for headaches, it doesn't give me > great confidence in the codebase. Actually, what I'm more "worried" about is the optimizations added to 4.x ... I know, for instance, that with FreeBSD's kernel, for the longest time you couldn't use the higher optimizations in 3.x, since it would cause "unexpected results" ... With GCC 4.x, there are new optimizations, and a while new set of "unknowns" that we're going to possibly get bug reports for ... and, it *is* a .0 major release for GCC, so there are bound to be bugs in their optimizer also, and I know there are some that will see "the latest and greatest", install it and come flying at us when its possible that its a bug in the newer GCC itself ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
"Marc G. Fournier" <scrappy@postgresql.org> writes:
> With GCC 4.x, there are new optimizations, and a while new set of
> "unknowns" that we're going to possibly get bug reports for ... and, it
> *is* a .0 major release for GCC, so there are bound to be bugs in their
> optimizer also, and I know there are some that will see "the latest and
> greatest", install it and come flying at us when its possible that its a
> bug in the newer GCC itself ...
FWIW, Red Hat has been using gcc 4 for Fedora Core 4 builds for some
time, so I know that PG (8.0.* that is) builds and passes regression
tests on all seven RH-supported architectures. I have not yet dared
to look at what warning messages gcc4 may spit out though ;-) ...
I have heard that it's a great deal pickier than earlier releases.
[ As a comparison point: the recent gcc and glibc updates in FC4 did
break MySQL. ]
regards, tom lane
> -----Original Message----- > From: Marc G. Fournier [mailto:scrappy@postgresql.org] > Sent: Friday, April 22, 2005 9:46 AM > To: Dave Held > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Woo hoo ... a whole new set of compiler > headaches!! :) > > [...] > With GCC 4.x, there are new optimizations, and a while new set > of "unknowns" that we're going to possibly get bug reports for > ... and, it *is* a .0 major release for GCC, Yeah, I agree that the first version of a major release can be a bit hairy. > so there are bound to be bugs in their optimizer also, Well that's like saying there were bound to be bugs in postgres 8.0 ;> > and I know there are some that will see "the latest and > greatest", install it and come flying at us when its possible > that its a bug in the newer GCC itself ... So just make the build system detect the version number and compile with -O0 or -O1 for gcc >= 4.0. ;> Anyway, that's what I thought the regression tests are for. Or is the development team unlikely to do any builds against 4.x for a while? __ David B. Held Software Engineer/Array Services Group 200 14th Ave. East, Sartell, MN 56377 320.534.3637 320.253.7800 800.752.8129
On Fri, 22 Apr 2005, Dave Held wrote: >> -----Original Message----- >> From: Marc G. Fournier [mailto:scrappy@postgresql.org] >> Sent: Friday, April 22, 2005 9:46 AM >> To: Dave Held >> Cc: pgsql-hackers@postgresql.org >> Subject: Re: [HACKERS] Woo hoo ... a whole new set of compiler >> headaches!! :) >> >> [...] >> With GCC 4.x, there are new optimizations, and a while new set >> of "unknowns" that we're going to possibly get bug reports for >> ... and, it *is* a .0 major release for GCC, > > Yeah, I agree that the first version of a major release can be a > bit hairy. > >> so there are bound to be bugs in their optimizer also, > > Well that's like saying there were bound to be bugs in postgres > 8.0 ;> There were, else we wouldn't have released 8.0.1 :) > So just make the build system detect the version number and compile with > -O0 or -O1 for gcc >= 4.0. ;> Anyway, that's what I thought the > regression tests are for. Or is the development team unlikely to do any > builds against 4.x for a while? See Tom's posting ... they (redhat) have apparently been playing with 4.x for awhile now, and all looks good ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Fri, Apr 22, 2005 at 11:46:04AM -0300, Marc G. Fournier wrote: > Actually, what I'm more "worried" about is the optimizations added to 4.x > ... I know, for instance, that with FreeBSD's kernel, for the longest time > you couldn't use the higher optimizations in 3.x, since it would cause > "unexpected results" ... For a long time, the Linux kernel was meant to be compiled with specific versions of GCC, because some assembly code was written in such a way that the specific bugs in that compiler version made it write the exact code they needed. So a new GCC release would fix the bugs, therefore breaking Linux; they had to create new, specially crafted buggy code to account for the bugs in the new compiler ;-) I think nowadays those issues are pretty much settled. (Not sure if you can compile the Linux kernel with GCC 4 anyway.) Maybe this was the issue with the FreeBSD kernel as well, I don't know. I wonder if this new GCC release could allow us to examine the strict aliasing issue again. -- Alvaro Herrera (<alvherre[@]dcc.uchile.cl>) "Amanece. (Ignacio Reyes)El Cerro San Cristóbal me mira, cínicamente, con ojosde virgen"
> -----Original Message----- > From: Marc G. Fournier [mailto:scrappy@postgresql.org] > Sent: Friday, April 22, 2005 10:17 AM > To: Dave Held > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Woo hoo ... a whole new set of compiler > headaches!! :) > > [...] > See Tom's posting ... they (redhat) have apparently been > playing with 4.x for awhile now, and all looks good ... Yeah, that's good news too, though it definitely helps that Postgres is written in C. Most of the conformance improvements are in the C++ front-end and the C++ Standard Library. Still no export though. I personally believe that projects should move to C++ when possible, but I understand that there is still a perception that C is fundamentally faster. __ David B. Held Software Engineer/Array Services Group 200 14th Ave. East, Sartell, MN 56377 320.534.3637 320.253.7800 800.752.8129
"Dave Held" <dave.held@arrayservicesgrp.com> writes:
> Yeah, that's good news too, though it definitely helps that
> Postgres is written in C. Most of the conformance improvements
> are in the C++ front-end and the C++ Standard Library. Still
> no export though. I personally believe that projects should
> move to C++ when possible, but I understand that there is still
> a perception that C is fundamentally faster.
I dunno about "fundamentally faster", but "fundamentally more stable"
I'd agree with. C++ has never recovered from being a moving target
for so long. For a project with any serious ambitions of portability,
it's a pretty risky choice.
regards, tom lane
> > I think that's great news! If the code is written in a conforming way, > I don't see why a new release would be a cause for headaches. And if > new compiler releases *are* a cause for headaches, it doesn't give me > great confidence in the codebase. Uhmmm that isn't always true. The switch from 2.x to 3.x was fairly painful. Standards can change and do often. Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: Friday, April 22, 2005 10:56 AM > To: Dave Held > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Woo hoo ... a whole new set of compiler > headaches!! :) > > [...] > I dunno about "fundamentally faster", but "fundamentally more stable" > I'd agree with. C++ has never recovered from being a moving target > for so long. For a project with any serious ambitions of portability, > it's a pretty risky choice. That depends on what features you choose to use. Certainly if you incorporate the latest template metaprogramming techniques, you will run into some portability issues. But you could easily move to C++ purely for the increased type checking without using all of the advanced features and get portability on the same par as C. If you don't believe me, check out the Boost libraries at www.boost.org. Most of the changes to C++ since C++98 have been additions to the Standard Library. The language changes have been mostly concerned with defining tricky corner cases that most programmers don't touch. It's actually very straightforward to write standard C++ and get a reliable build on all the major platforms. The only people who really concern themselves with defect reports and the kinds of issues you see on the standardization mailing lists are library designers and implementors who are creating state-of-the- art libraries and intentionally pushing the language to its limits. There's lots of good reasons to move to C++, even if the codebase did not take advantage of all the OOP or GP features available. You have better type checking, C++-style casts, which are safer if used correctly, inline functions, etc. Of course, taking advantage of your basic OOP features like data hiding and RAII would be a big bonus for a relatively small change. Then, of course, you have the controversial issue of exceptions. I personally think exceptions are a superior way to handle error conditions in most cases, but a lot of programmers are slow to come to that way of thinking. And because the vast majority of C programs are also correct C++ programs, it really wouldn't be that much effort to port the code. It would even be possible to do it piecemeal, building some modules in C++ and exposing a C interface to the rest of the codebase. Besides the functional advantages I briefly listed, I also find C++ to be more readable because you can avoid a lot of ugly casts, and other types of expressions have a more elegant syntax in C++. I would even be willing to translate a file or two into C++ to illustrate the difference, if that would be worthwhile. __ David B. Held Software Engineer/Array Services Group 200 14th Ave. East, Sartell, MN 56377 320.534.3637 320.253.7800 800.752.8129
On Fri, Apr 22, 2005 at 11:56:13AM -0400, Tom Lane wrote: > "Dave Held" <dave.held@arrayservicesgrp.com> writes: > > Yeah, that's good news too, though it definitely helps that > > Postgres is written in C. Most of the conformance improvements > > are in the C++ front-end and the C++ Standard Library. Still > > no export though. I personally believe that projects should > > move to C++ when possible, but I understand that there is still > > a perception that C is fundamentally faster. > > I dunno about "fundamentally faster", but "fundamentally more stable" > I'd agree with. C++ has never recovered from being a moving target > for so long. For a project with any serious ambitions of portability, > it's a pretty risky choice. Why don't we rewrite Postgres in D? http://www.digitalmars.com/d/ :-D -- Alvaro Herrera (<alvherre[@]dcc.uchile.cl>) "Pensar que el espectro que vemos es ilusorio no lo despoja de espanto, sólo le suma el nuevo terror de la locura" (Perelandra, CSLewis)
> -----Original Message----- > From: Joshua D. Drake [mailto:jd@commandprompt.com] > Sent: Friday, April 22, 2005 11:42 AM > To: Dave Held > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Woo hoo ... a whole new set of compiler > headaches!! :) > > [...] > Uhmmm that isn't always true. The switch from 2.x to 3.x was fairly > painful. Standards can change and do often. That depends on how you define "often". I wouldn't call 10 years from C89 to C99 or C++98 to "C++0x" (7 years and counting) "often". The majority of change from 2.x to 3.x, at least on the C++ side of things, had to do with moving into conformance with a standard that had been around for quite a while. Now that GCC is doing pretty well w.r.t. conformance, I don't see any major upheavals for a while. I'm sure the new optimizer changes will introduce some issues to deal with, but on a source code level I don't see why Postgres would have to work around them. __ David B. Held Software Engineer/Array Services Group 200 14th Ave. East, Sartell, MN 56377 320.534.3637 320.253.7800 800.752.8129
> -----Original Message----- > From: Alvaro Herrera [mailto:alvherre@dcc.uchile.cl] > Sent: Friday, April 22, 2005 12:06 PM > To: Tom Lane > Cc: Dave Held; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Woo hoo ... a whole new set of compiler > headaches!! :) > > [...] > Why don't we rewrite Postgres in D? > > http://www.digitalmars.com/d/ > > :-D I see the smiley, but moving to C++ isn't just about switching to the latest fad language. First of all, you would literally have to rewrite it to use D. There would probably need to be very little work to make the Postgres codebase a conforming set of C++ programs (mostly renaming variables/types named 'class', 'virtual', 'bool', etc.). Second, you can find a decent C++ compiler on virtually every platform that has a C compiler. Third, C++ offers real advantages in type safety, exception handling, resource management, and even performance. Even doing something as simple as writing a stored procedure in C is somewhat awkward because of all the boilerplate casting that must be done. I'm fairly certain that most of the macros in the stored procedure interface could go away if a C++ API were created. __ David B. Held Software Engineer/Array Services Group 200 14th Ave. East, Sartell, MN 56377 320.534.3637 320.253.7800 800.752.8129
Dave Held wrote: >>-----Original Message----- >>From: Alvaro Herrera [mailto:alvherre@dcc.uchile.cl] >>Sent: Friday, April 22, 2005 12:06 PM >>To: Tom Lane >>Cc: Dave Held; pgsql-hackers@postgresql.org >>Subject: Re: [HACKERS] Woo hoo ... a whole new set of compiler >>headaches!! :) >> >>[...] >>Why don't we rewrite Postgres in D? >> >>http://www.digitalmars.com/d/ >> >>:-D >> >> > >I see the smiley, but moving to C++ isn't just about switching >to the latest fad language. > No, it's about moving to the fad language about 2 generations back ... >First of all, you would literally >have to rewrite it to use D. There would probably need to be >very little work to make the Postgres codebase a conforming set >of C++ programs (mostly renaming variables/types named 'class', >'virtual', 'bool', etc.). Second, you can find a decent C++ >compiler on virtually every platform that has a C compiler. >Third, C++ offers real advantages in type safety, exception >handling, resource management, and even performance. > > Unless you did a major rewrite it's hard to see any great advantages. There are over 600,000 lines of code in Postgres by my rough count. The potential rewrite effort is enormous. A thorough job would probably consume a release cycle just on its own. Also, "virtually every platform" isn't good enough - we have a number of oddballs in our supported list, and it would have to include at least those. >Even doing something as simple as writing a stored procedure >in C is somewhat awkward because of all the boilerplate casting >that must be done. I'm fairly certain that most of the macros >in the stored procedure interface could go away if a C++ API >were created. > > > On the downside, some of us (including me) have much more experience in and ease with writing C than C++. I could certainly do it - I write plenty of Java, so OO isn't a closed book to me, far from it - but ramping up in it would take me at least some effort. I bet I'm not alone in that. So this would not be cost-free - very far from it. cheers andrew
"Dave Held" <dave.held@arrayservicesgrp.com> writes:
> [ much snipped... ]
> And because the vast majority of C programs are also correct C++
> programs, it really wouldn't be that much effort to port the code.
And not much reward, either. To actually get benefit commensurate
with the risks involved, we'd need to do some wholesale revisions
of internal APIs and coding practices. It might not qualify as a
complete rewrite, but it'd be dang close.
Personally I think the costs would far exceed the benefits.
regards, tom lane
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: Friday, April 22, 2005 1:22 PM > To: Dave Held > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Woo hoo ... a whole new set of compiler > headaches!! :) > > [...] > And not much reward, either. To actually get benefit commensurate > with the risks involved, Then we are certainly measuring risk differently, because my assessment is that it would not need to offer anything more than very modest benefits to justify the risk. It's not like rewriting the codebase in Java. It's not even close. > we'd need to do some wholesale revisions of internal APIs and > coding practices. No you wouldn't. You could make incremental revisions that offer a very gentle learning curve to C++. My suggestion is to convert the codebase iteratively, taking only small sure steps at each iteration. The internal APIs would evolve, not be overturned and replaced. And the coding practices encouraged by C++ generally lead to safer and more readable code, but would still not prevent people from writing idiomatic C within C++ if they really wanted/needed to (except where features have been converted to C++, of course). > It might not qualify as a complete rewrite, but it'd be dang close. It would only be a complete rewrite if you wanted to take it that far. Otherwise, it would be many small modifications each of which can offer an independent dimension of benefit that can be weighed and judged on its own. > Personally I think the costs would far exceed the benefits. The costs would be fairly minor, as most of the developers would not necessarily be responsible for converting the codebase, only following the new rules as they are introduced over time (and even then, many of the rules could be ignored anyway, like using C++ casts instead of C casts, or using constants instead of macros). Only the people who are comfortable and proficient with C++ would need to invest the time to make sure that upgrades to the codebase proceed in an orderly manner. __ David B. Held Software Engineer/Array Services Group 200 14th Ave. East, Sartell, MN 56377 320.534.3637 320.253.7800 800.752.8129
Dave Held wrote: > > we'd need to do some wholesale revisions of internal APIs and > > coding practices. > > No you wouldn't. You could make incremental revisions that offer a > very gentle learning curve to C++. My suggestion is to convert the > codebase iteratively, taking only small sure steps at each iteration. > The internal APIs would evolve, not be overturned and replaced. And > the coding practices encouraged by C++ generally lead to safer and > more readable code, but would still not prevent people from writing > idiomatic C within C++ if they really wanted/needed to (except where > features have been converted to C++, of course). I think there are some features we could use in C++. As a simple example, "//" for comments. 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. -- 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
> -----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
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. ;) > > I don't think you do recall correctly - it's in C99 (ratified in 2001) AFAIK. [more arguments for C++ snipped] I recall saying something like this when we were being urged to replace CVS with SubVersion/Arch/SomethingElse but I'll say it again - this decision should be made by the people who contribute the most. All the rest (including my contribution) is just noise, IMHO. cheers andrew
> -----Original Message----- > From: Andrew Dunstan [mailto:andrew@dunslane.net] > Sent: Friday, April 22, 2005 3:49 PM > To: Dave Held > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Woo hoo ... a whole new set of compiler > headaches!! :) > > [...] > I recall saying something like this when we were being urged > to replace CVS with SubVersion/Arch/SomethingElse but I'll say > it again - this decision should be made by the people who > contribute the most. All the rest (including my contribution) > is just noise, IMHO. Well, I think it goes without saying that such a decision will ultimately be made by the core developers. But to say that nobody should *suggest* changes seems a bit odd to me. I mean, people suggest changes to the design of Postgres almost daily, and some of them aren't even coders. But if nobody outside of the core developers suggests changes, that kind of takes some of the "open" out of "open source". True, the source would still be open, but there's a subtlety in the name that is similar to the "free" in "free software". That's not to say that any given suggestion is worthy of serious consideration; but to say that any suggestion that doesn't come from the core is just "noise" to my ear doesn't sound any different than Redmond saying any suggestion that doesn't come from 1 Microsoft Way is just "noise". As an aside, I don't think that switching to SVN is a half bad idea either. ;> __ David B. Held Software Engineer/Array Services Group 200 14th Ave. East, Sartell, MN 56377 320.534.3637 320.253.7800 800.752.8129
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
Dave Held wrote: >>-----Original Message----- >>From: Andrew Dunstan [mailto:andrew@dunslane.net] >>Sent: Friday, April 22, 2005 3:49 PM >>To: Dave Held >>Cc: pgsql-hackers@postgresql.org >>Subject: Re: [HACKERS] Woo hoo ... a whole new set of compiler >>headaches!! :) >> >>[...] >>I recall saying something like this when we were being urged >>to replace CVS with SubVersion/Arch/SomethingElse but I'll say >>it again - this decision should be made by the people who >>contribute the most. All the rest (including my contribution) >>is just noise, IMHO. >> >> > >Well, I think it goes without saying that such a decision will >ultimately be made by the core developers. But to say that nobody >should *suggest* changes seems a bit odd to me. I mean, people >suggest changes to the design of Postgres almost daily, and some >of them aren't even coders. But if nobody outside of the core >developers suggests changes, that kind of takes some of the "open" >out of "open source". True, the source would still be open, but >there's a subtlety in the name that is similar to the "free" in >"free software". That's not to say that any given suggestion >is worthy of serious consideration; but to say that any suggestion >that doesn't come from the core is just "noise" to my ear doesn't >sound any different than Redmond saying any suggestion that doesn't >come from 1 Microsoft Way is just "noise". > > > > I didn't mean people can't or shouldn't make suggestions, just that beyond a certain point advocacy seems unnecessary. I suspect most people here are already well aware of the advantages and disadvantages of C++. Apologies if I have offended you. cheers andrew
> -----Original Message----- > From: Andrew Dunstan [mailto:andrew@dunslane.net] > Sent: Friday, April 22, 2005 4:29 PM > To: Dave Held > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Woo hoo ... a whole new set of compiler > headaches!! :) > > [...] > I didn't mean people can't or shouldn't make suggestions, just > that beyond a certain point advocacy seems unnecessary. Fair enough. > I suspect most people here are already well aware of the > advantages and disadvantages of C++. That's where we disagree. In my experience, most C++ programmers know C, but most C programmers only know C++ through second-hand knowledge. And this community has already professed a fairly thorough commitment to C. I also don't find the rebuttals to the arguments for migration to be particularly compelling. In this case, I wouldn't even ask the core developers to do all the work. I would volunteer to do a lot of the grunt work in making the code base valid C++ (and I suspect several others would as well), and doing the other updates to make the code more idiomatic C++. I would only ask them to play along when the style shifts. > Apologies if I have offended you. No offense taken. __ David B. Held Software Engineer/Array Services Group 200 14th Ave. East, Sartell, MN 56377 320.534.3637 320.253.7800 800.752.8129
"Dave Held" <dave.held@arrayservicesgrp.com> writes:
>> I suspect most people here are already well aware of the
>> advantages and disadvantages of C++.
> That's where we disagree. In my experience, most C++ programmers
> know C, but most C programmers only know C++ through second-hand
> knowledge. And this community has already professed a fairly
> thorough commitment to C.
FWIW, I was doing development in C++ full-time for most of the 90's.
So it's not like I'm not reasonably familiar with the benefits.
And yeah, if we were starting from scratch I'd probably say C++ is
a good choice. But the price of getting there from here is higher
than the value of being there, IMHO.
regards, tom lane