Re: const correctness

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: const correctness
Дата
Msg-id 4EBA81BB0200002500042C13@gw.wicourts.gov
обсуждение исходный текст
Ответ на Re: const correctness  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: const correctness  (Robert Haas <robertmhaas@gmail.com>)
Re: const correctness  (Thomas Munro <munro@ip9.org>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> wrote:

> If it doesn't uglify the code, there aren't any negatives.  I'm
> just saying we may not be able to get very far before we run up
> against that issue.  For example, in the OP, Thomas wrote:
>
> 7.  I made a list_head_const function, which can be used used to
>     get a pointer to the head cell when you have a pointer to
>     const List; I needed that so I could make foreach_const and
>     forboth_const; they were needed to be able to make
>     list_member, _equalList and various other list-visiting
>     functions work with const List objects.
>
> So that's already duplicating list_head, foreach, and forboth.

OK, I failed to pick up on that properly.  With that stripped out,
you get the attached patch, which does nothing but add "const" to
661 lines.  It still applies cleanly, builds with no warnings, and
passes regression tests.

It is a bit disappointing that without creating two flavors of the
list_head function and the foreach and forboth macros, there are a
number of functions which aren't intended to modify their inputs
which can't be declared with const parameters; but unless there is
some demonstrable performance benefit from those changes, I agree
that the argument for having the two flavors is thin.

-Kevin


Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dimitri Fontaine
Дата:
Сообщение: Adding Node support in outfuncs.c and readfuncs.c
Следующее
От: Dimitri Fontaine
Дата:
Сообщение: Re: a modest improvement to get_object_address()