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

-----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 ojos de 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

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers-
owner@postgresql.org] On Behalf Of Andrew Dunstan
Sent: Friday, April 22, 2005 10:46 AM
To: Dave Held
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Woo hoo ... a whole new set of compiler

headaches!!

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 ...

Language wars are about as much fun as operating system wars.
C and C++ are both nice languages.

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.

You could use C++ as "a better C" with very little effort (but there are
C++ keywords sprinkled here and there, so it would be a good month of
work for somebody).

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.

There is a C++ compiler for everything you can think of and most things
you can't think of. That's not really a problem.

The real problem is that the development team is a team of C
programmers, not C++ programmers. That is the reason that a change
makes no sense at all.

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.

This is the crux of the matter. You will certainly not be alone here.
I (personally) prefer C++ to C, but I am comfortable in either language.
However, if you have a team of 100 C programmers and a huge C project,
it is a terrible mistake to ask them to use C++.

So this would not be cost-free - very far from it.

Here, we clearly agree. As a project scales larger and larger the
benefits of C++ loom greater and greater. When your project consists of
millions of lines of code, then C++ is a much better choice. But I
don't think PostgreSQL is going to scale to titanic size any time soon.
If it were, I would suggest the conversion, no matter how painful.

cheers

andrew

---------------------------(end of

broadcast)---------------------------

"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: Dann Corbit [mailto:DCorbit@connx.com]
Sent: Friday, April 22, 2005 1:08 PM
To: Andrew Dunstan; Dave Held
Cc: pgsql-hackers@postgresql.org
Subject: RE: [HACKERS] Woo hoo ... a whole new set of compiler
headaches!!

From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers-
owner@postgresql.org] On Behalf Of Andrew Dunstan

Dave Held wrote:

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 ...

Except that C++ is hardly a "fad language". Most estimates place
the top 3 languages by number of programmers as C++, Java, and C,
with C++ and Java switching positions, and C lagging behind by a
decent margin. And it's been this way for quite a while.

Language wars are about as much fun as operating system wars.
C and C++ are both nice languages.

My intent was not to start a language jihad. I don't think C is a
bad language. I just think C++ is better.

[...]
Unless you did a major rewrite it's hard to see any great
advantages.

There doesn't need to be great advantages. Just enough to justify
the effort. Take casts, for instance: C uses a single syntax for
all types of cast. C++ breaks casting down into static_casts<>
(for upcasting to a type for which the opposite cast would be an
implicit conversion), dynamic_cast<> (for polymorphic types, which
don't exist in the C++ sense in the Postgres codebase, by definition),
const_cast<> (for casting away constness, or adding it), and
reinterpret_cast<> (for dangerous bit twiddling where you'd better
know the exact layout for each platform). Probably most of the
casts in the Postgres codebase would be converted to static_cast<>.
And if the types were upgraded over time, many of those casts could
probably go away. The dangerous casts would remain marked as
reinterpret_cast<>, and that would serve to highlight the portions
of the code that are probably platform-dependent and that probably
need inspection when porting to a new platform.

While the benefits of using the C++-style casts would only be
maximized if they were used everywhere, you still get incremental
benefit from converting them a few at a time.

Consider inline functions. In C, you have to implement them as
macros, which eliminates your type safety. In C++, you can get
both type safety and performance. Take a concrete example: qsort().
In C, you must pass a function pointer to use this function, and
that function pointer gets dereferenced every time qsort() needs to
do a comparison. That's a lot of overhead that is eliminated in
C++'s sort() function, which accepts a comparison functor that
can and often does get inlined.

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.

You could use C++ as "a better C" with very little effort
(but there are C++ keywords sprinkled here and there, so it
would be a good month of work for somebody).

My point exactly. It's *not* a task that has to be tackled all
at once. Once you have a total C++ codebase, converting it into
a C++ style can be done quite incrementally, with benefits
accruing with each update.

[...]

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.

This is the crux of the matter. You will certainly not be alone
here. I (personally) prefer C++ to C, but I am comfortable in
either language. However, if you have a team of 100 C programmers
and a huge C project, it is a terrible mistake to ask them to use
C++.

I disagree. The C programmers could learn C++ rules one at a time.
The first rule would simply to be to not use C++ keywords as
identifiers. That is really the minimum necessary to write C style
code in a C++ program. The next might be to replace macro constants
with const ints. The next might be to replace C-style casts with
C++-style. There is really no need to throw the whole book at
the developer community all at once. It might take a year or two
to get the codebase into idiomatic C++, but the developers would
have learned C++ quite easily without really noticing it. I would
certainly not suggest something radical like replacing hand-rolled
containers with standard library equivalents. *That's* the kind of
rewrite that should give any coder nightmares.

Even OOP-style encapsulation could be done incrementally. You take
a few fields of some struct, make them private, add accessor
functions, and update the references. You don't have to hide all
the data all at once. I know, because I've upgraded lots of C
code to C++, and it's not nearly as hard as the typical C
programmer thinks it is. To make it all idiomatic C++ would
certainly require a large effort. But you don't need purely
idiomatic C++ to gain most of the benefits of the language.

So this would not be cost-free - very far from it.

Here, we clearly agree. As a project scales larger and larger the
benefits of C++ loom greater and greater. When your project
consists of millions of lines of code, then C++ is a much better
choice. But I don't think PostgreSQL is going to scale to titanic
size any time soon. If it were, I would suggest the conversion, no
matter how painful.

And this is where we disagree. I think C++ offers tangible benefits
at all scales. The cost is not free, but contrary to what most people
think, it doesn't have to be paid all at once. It can be paid in
very small installments, and further change can even be more or less
abandoned if the team felt that it wasn't returning on the investment.
There really is no other language path that offers that kind of
gradual transition.

__
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: 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, Pennsylvania 19073

-----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, Pennsylvania 19073

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

Dave Held wrote:

Consider inline functions. In C, you have to implement them as
macros

No -- inline functions are in C99, and of course there have been GCC
extensions with similar (but not identical) semantics for many years.

-Neil

On Sat, Apr 23, 2005 at 11:58:44AM +1000, Neil Conway wrote:

Dave Held wrote:

Consider inline functions. In C, you have to implement them as
macros

No -- inline functions are in C99, and of course there have been GCC
extensions with similar (but not identical) semantics for many years.

We have plenty of very ugly macros anyway. See fastgetattr(),
HeapKeyTest(), HeapTupleSatisfies(), HeapTupleHeaderSetXmax and friends,
Assert() and friends.

I'm not saying that we could get rid of them with C++ ... just that we
have ugly macros for which type checking seems to be ... primitive.

Anyway I think the prize for weird strangeness in macro usage would go
to PG_TRY and friends.

--
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
"Industry suffers from the managerial dogma that for the sake of stability
and continuity, the company should be independent of the competence of
individual employees." (E. Dijkstra)

Alvaro Herrera wrote:

We have plenty of very ugly macros anyway. See fastgetattr(),
HeapKeyTest(), HeapTupleSatisfies(), HeapTupleHeaderSetXmax and friends,
Assert() and friends.

I don't think Assert() is too bad, but I agree some of the others are a
bit ugly. In some places where we would like to use a macro but don't
want to doubly-evaluate macro arguments, we define the function with
"static inline" in a header file when using GCC, and include a normal
function definition in a source file otherwise (see list_length() in
pg_list.h / list.c for example). Needless to say, this is even uglier :)

An alternative would be to define inline functions in headers using
"static __inline". When using GCC (or other compilers that implement
sane "static inline" semantics per C99, such as icc), __inline would
expand to "inline"; otherwise it would expand to the empty string.
Compilers that don't implement "static inline" would include multiple
copies of the function definition, which would bloat the object code (if
a compiler doesn't implement "static", it is a good bet that it also
doesn't implement the unit-at-a-time analysis required to elide unused
static function definitions). So I'm not really sure that this is a win
overall.

-Neil