On Tue, Aug 16, 2016 at 9:59 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I think this might have advantages purely from the standpoint of new > compilers possibly offering useful warnings we don't get now. But > if we only go this far, I'm pretty dubious that it really helps people > to develop extensions in C++. Almost invariably, if you ask *why* they > want to do that, you'll get an answer involving C++ libraries that are > not going to play very nice with our error handling or memory management > conventions.
FWIW, it's not uncommon to opt-out of C++ exceptions entirely, for various reasons. For example, the Google C++ style guide forbids it (if only for historical reasons), as does the GCC style guide (since GCC was a C program until several years ago [1]). Sometimes, these third party libraries that mandate the use of exceptions do indeed create significant headaches for Postgres, compatibility-wise, but that isn't a given. IMV, it would be useful to use C++ classes (and even template classes) for a small number of data structures, while still largely adhering to earlier practices (this is what GCC did). Specifically, a few modules such as StringInfo, could be made to follow the RAII/scope bound resource management usefully, which doesn't seem incompatible with memory contexts. However, this doesn't seem terribly exciting to me. [1] https://lwn.net/Articles/542457/ -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
