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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Slowness of extended protocol
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Wait events monitoring future development