Здравствуйте, k.o., Вы писали:

KO>Здравствуйте, Galiulin Rishat Faimovich, Вы писали:

GRF>>Здравствуйте, k.o., Вы писали:

KO>>>Здравствуйте, Galiulin Rishat Faimovich, Вы писали:

KO>>>>>>>Попробуйте повторить этот пример используя ваш specification.hpp.

GRF>>>>Вроде теперь ваш пример работает

KO>>>Зато, теперь не работает добавление константности:

GRF>>А для каких целей нужно будет добавление константности если полностью перейти на in, in_out, out нотацию?
GRF>>Как я понимаю in параметр должен гарантировать толко неизменность передаваемого внешнего для функции параметра.

KO>Многие (я в том числе) предпочитают обеспечивать, также, неизменяемость входных параметров внутри самой функции (см., например, "Совершенный Код" 2-е издание, изд. Питер, с. 173). Вы сами-то здесь

Автор: Galiulin Rishat Faimovich
Дата: 14.09.11

зачем заменили 'int* bar_in' на 'const int* const bar_in'? То, что в некоторых случаях их всё-таки имеет смысл делать изменяемыми, всего лишь, показывает ограниченность модели in/in_out/out (или, если хотите, системы типов C++). В принципе, всё это прекрасно решается введением соглашений об именовании параметров (например, добавлением префиксов in, inOut, out к именам параметров) и code review, но, в этом случае нет никакого смысла и в дополнительных обёртках, таких как ваши.

Ваши доводы, а также доводы MasterZiv: здесь

Автор: MasterZiv
Дата: 15.09.11

и здесь

Автор: MasterZiv
Дата: 18.09.11

, убедили и меня и коллег полностью отказаться от введения как IN, IN-OUT и OUT define-ов (они не контролируются компилятором и следовательно могут ввести в заблуждение), так и in, in_out и out шаблонов (они вводят сильные ограничения) и перейти на стандартную модель.