Re: [GENERAL] C++ port of Postgres
От | Peter Geoghegan |
---|---|
Тема | Re: [GENERAL] C++ port of Postgres |
Дата | |
Msg-id | CAM3SWZSu+++ZvHdHst71fSKdLON5GMo-2L_Lk2mN5QvBmuBNBg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [GENERAL] C++ port of Postgres (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [GENERAL] C++ port of Postgres
|
Список | pgsql-hackers |
On Tue, Aug 16, 2016 at 9:59 AM, Tom Lane <tgl@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
В списке pgsql-hackers по дате отправления: