Re: Mostly Harmless: Welcoming our C++ friends

Tom Lane wrote:
> Kurt Harriman <harriman(at)acm(dot)org> writes:
>> However, probably an easier alternative would be to have
>> just one buildfarm machine do a nightly build configured
>> with the --enable-cplusplus option.

> There is no such option, and won't be.

Yours is the first comment anyone has posted to the list
regarding my proposed c++configure patch, and it sounds
alarmingly definite.

May I ask you to elaborate? Have you more to say on the
subject?

>> This would build one file - main.c - as C++ (necessary
>> because on some platforms the main() function needs to be
>> C++ to ensure the C++ runtime library is initialized).
>
> Useless, since main.c doesn't include any large number of headers,

main.c directly or indirectly includes these 71 headers:
access/attnum.h access/genam.h access/heapam.h
access/htup.h access/rmgr.h access/sdir.h
access/skey.h access/tupdesc.h access/tupmacs.h
access/xlog.h access/xlogdefs.h bootstrap/bootstrap.h
c.h catalog/genbki.h catalog/pg_am.h
catalog/pg_attribute.h catalog/pg_class.h catalog/pg_index.h
executor/execdesc.h executor/tuptable.h fmgr.h
lib/stringinfo.h nodes/bitmapset.h nodes/execnodes.h
nodes/nodes.h nodes/params.h nodes/parsenodes.h
nodes/pg_list.h nodes/plannodes.h nodes/primnodes.h
nodes/tidbitmap.h nodes/value.h pg_config.h
pg_config_manual.h pg_config_os.h pgtime.h
port.h postgres.h postgres_ext.h
postmaster/postmaster.h rewrite/prs2lock.h storage/backendid.h
storage/block.h storage/buf.h storage/bufpage.h
storage/item.h storage/itemid.h storage/itemptr.h
storage/lock.h storage/lwlock.h storage/off.h
storage/relfilenode.h storage/shmem.h tcop/dest.h
tcop/tcopprot.h utils/array.h utils/elog.h
utils/errcodes.h utils/guc.h utils/help_config.h
utils/hsearch.h utils/int8.h utils/palloc.h
utils/pg_crc.h utils/pg_locale.h utils/ps_status.h
utils/rel.h utils/relcache.h utils/snapshot.h
utils/timestamp.h utils/tuplestore.h

> and in particular there is no reason for it to include the headers
> that are critical to function libraries.

Extra #includes could be added to main.c just for the purpose of
getting them C++-syntax-checked. Or, a few more .c files could be
chosen to expand the set of C++-syntax-checked headers. For
instance, xml.c pulls in spi.h and 96 other headers. 66 of them
overlap with main.c; but these 31 are new:
access/xact.h catalog/namespace.h catalog/pg_language.h
catalog/pg_proc.h catalog/pg_type.h commands/dbcommands.h
executor/execdefs.h executor/executor.h executor/spi.h
lib/dllist.h libpq/pqformat.h mb/pg_wchar.h
miscadmin.h nodes/memnodes.h nodes/nodeFuncs.h
nodes/relation.h tcop/pquery.h tcop/utility.h
utils/builtins.h utils/catcache.h utils/date.h
utils/datetime.h utils/datum.h utils/lsyscache.h
utils/memutils.h utils/plancache.h utils/portal.h
utils/resowner.h utils/syscache.h utils/tzparser.h
utils/xml.h
funcapi.h is still missing. One file that includes it is
pl_exec.c, which pulls in 8 more headers not already listed:
access/transam.h commands/trigger.h executor/spi_priv.h
funcapi.h parser/scansup.h plpgsql.h
utils/snapmgr.h utils/typcache.h
So C++-compiling just a few source files is sufficient to syntax
check a useful subset of header files including those which are
most important for add-on development.

However, the above approach has a couple of obvious caveats:

:( It doesn't give C++ users a precise specification of exactly
which header files they may rely upon from release to release.

:( From time to time, C++ programmers will probably come along
asking for even more header files to be sanitized.

The alternative which you have suggested, using pgcompinclude,
could solve these caveats by enforcing C++ safety upon every
PostgreSQL header file. And it would not require any more .c
files beyond main.c to be kept C++-clean.

http://archives.postgresql.org/pgsql-patches/2007-07/msg00056.php

I'll get started on the pgcompinclude thing.

Regards,
... kurt