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