Re: [GENERAL] C++ port of Postgres
От | Andres Freund |
---|---|
Тема | Re: [GENERAL] C++ port of Postgres |
Дата | |
Msg-id | 20160816205518.yesjo6w2t6os3kvu@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [GENERAL] C++ port of Postgres (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: [GENERAL] C++ port of Postgres
|
Список | pgsql-hackers |
On 2016-08-16 13:40:06 -0700, Peter Geoghegan wrote: > On Tue, Aug 16, 2016 at 1:29 PM, Peter Geoghegan <pg@heroku.com> wrote: > > 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. > > Actually, come to think of it, I guess this is wrong. The problem with > what I say here is that longjmp() and setjmp() are incompatible with > the stack unwinding used by C++ destructors in general (exceptions are > another issue). I think that the practical implication of that is that > we can never use any C++ feature that hides the complexity of resource > management, unless and until elog() is reimplemented to not use > longjmp() and setjmp(). FWIW, IIRC that's not true for gcc/glibc, because they IIRC use common codepaths. But obviously that's not all-encompassing enough to rely on that.
В списке pgsql-hackers по дате отправления: