Re: Mostly Harmless: Welcoming our C++ friends - Mailing list pgsql-hackers

From Kurt Harriman
Subject Re: Mostly Harmless: Welcoming our C++ friends
Date
Msg-id 49438036.4040900@acm.org
Whole thread Raw
In response to Re: Mostly Harmless: Welcoming our C++ friends  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Mostly Harmless: Welcoming our C++ friends
List pgsql-hackers
Tom Lane wrote:
> Kurt Harriman <harriman@acm.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


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Sync Rep: First Thoughts on Code
Next
From: Peter Eisentraut
Date:
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)