[опрос][c++] как часто вы пользуетесь protected полями и зачем?

всегда, а чего им наружу торчать

А почему тогда не private? Я protected поля кажется вообще никогда не использовал.

интересует почему не private хотя я головой понимаю почему. Сомнения в том что никто кроме с++ это не умеет и жаба кодеры сильно не плачут

а если нужен доступ при наследовании?

Почти никогда. Только если удобно non-virtual interface сделать. То есть, когда какая-то часть метода, который хочется сделать виртуальной одинакова для всех потомков.

А так я вообще за налог на наследование.

А ещё лучше Pimpl

> а если нужен доступ при наследовании?

Значит неправильная декомпозиция.

> и жаба кодеры сильно не плачут
Наверное, потому что в жабке тоже есть protected ;) Хотя это немножко другое

Всегда. Private использую очень редко. Исхожу из того, что наследнику нужно давать полную власть над родителем.

Очень редко. Где-то было не очень хорошее высказывание Страуструпа о proteced, типа зря такое замутил.

> А почему тогда не private?

protected более гибкий - позволяет выкрутится в случае чего, часто бывает ситуация, когда в библиотеке чего-то нет, чтоб сделать самому - надо получить какой-нибудь указатель, например, а хрен - все в private, разработчикам пишешь - они соглашаются, но дел у него много, так и висит тикет

ага вижу. спасибо.

> Значит неправильная декомпозиция.
А если сознательный шаг с целью оптимизации (сказывающейся на бенчмарках)?

Очень редко. Только тогда, когда приходил к осознанию того, что наследнику может понадобится конкретное поле. А так - все private.

да. Но мне хотелось бы знать про сайд эффекты вроде неявных ошибок и переусложнения архетектуры.

Почти никогда. В большинстве ситуаций protected - это все равно, что «немножко беременна».

> да. Но мне хотелось бы знать про сайд эффекты вроде неявных ошибок и переусложнения архетектуры.

никакой разницы с private - private нужен только для явного запрещения копирования, например, и пр. «трюков», остальное - это задолбленное в голову обезьян предубеждение, что раз вы тупые - ограничивайте себя сами

А чо тогда protected, а не public? :D

> А чо тогда protected, а не public? :D

чтоб не было желания лезть напрямую - компилятор даст по-рукам

все минусы public-полей сохраняются для protected'ов, только вертикально, а не горизонтально по иерархии

> чтоб не было желания лезть напрямую - компилятор даст по-рукам

Да брось, попытки отбить желание - и есть самое настоящее «задолбленное в голову обезьян предубеждение, что раз вы тупые - ограничивайте себя сами» :D

aho, хреновый у тебя подход. Класс получается не защищенным от вмешательства извне, что есть нарушение инкапсуляции.

> Да брось, попытки отбить желание - и есть самое настоящее «задолбленное в голову обезьян предубеждение, что раз вы тупые - ограничивайте себя сами» :D

нет - это часть «документирования» кода, точно так же как const, например, т.е. обозначение - что эти данные часть внутренней реализации

> нет - это часть «документирования» кода

Как же так, почему при наследовании «документация» должна не работать?

> aho, хреновый у тебя подход. Класс получается не защищенным от вмешательства извне, что есть нарушение инкапсуляции.

да - я выше уже писал зачем это надо, в реальном мире действительно хорошие программы и библиотеки «ложили» на подобные правила, т.к. они только мешают, но да - помогают организовывать толпу вчерашних студней

> Как же так, почему при наследовании «документация» должна не работать?

потому-что, внезапно, пользоваться полями родительского класса - это нормально

class SomeClass {
.......
protected:
  void inc () {
    i_++;
  }

private:
  int i_;
}

И тут кто-то делает финт ушами:

class MySomeClass : public SomeClass {
.......
protected:
  void inc () {
    i_--;
  }

private:
  int i_;
}

А от i_ зависит куча всего. Ы?

Пример утрированный, но, надеюсь, поймешь.

Редко. Protected-функции — чуть чаще.

> А от i_ зависит куча всего. Ы?

и ни одной строки комментария об этом факте? ну так тут и private не поможет

Тьфу ты, блин. :) Что-то перемудрил с примером. Он неверен, посыпаю голову пеплом.

Просто часто методы завязаны друг на друге и вызов одного метода напрямую, а не из другого может привести к неожиданным последствиям. Вот, что я хотел сказать.

> потому-что, внезапно, пользоваться полями родительского класса - это нормально

А неродительского - ненормально? :D Приехали.

C++ не язык а попса чего только стоят десятистраничные темы по обсуждению какой нить хрени из него порой я его ненавижу приходится на нем писать только из за того что шаблоны можно заставить генерировать нужный код ну и деструкторы пожалуй еще

> А неродительского - ненормально? :D Приехали.

нет - по одной простой причине, когда мы пользуемся полем из класса Widget например, мы не знаем, как это скажется на реальном объекте Button, в Button же мы имеем на руках нужные знания и документацию

На самом деле разницы никакой нет. Наследованию очень часто предпочитают композицию.

> На самом деле разницы никакой нет. Наследованию очень часто предпочитают композицию.

вобщем мне лень спорить, хоть я сам и начал :) как кому удобней - пусть так и пишет

(ушел)

приходится на нем писать только из за того что шаблоны можно заставить генерировать нужный код

генерь из чего-то другого, в чём проблема-то?

> генерь из чего-то другого, в чём проблема-то?

Проблема - прицепиться к существующим с/с++ интерфейсам. Компилятор код этих интерфейсов парсит и подставляет как надо в шаблоны. Из кодогенератора на перле/питоне такое проделать очень тяжело.

> C++ не язык а попса чего только стоят десятистраничные темы по обсуждению какой нить хрени из него порой я его ненавижу приходится на нем писать только из за того что шаблоны можно заставить генерировать нужный код ну и деструкторы пожалуй еще

В каком классе?

Проблема - прицепиться к существующим с/с++ интерфейсам

у Objective-C как-то получается же

очень тяжело

если генерить C++ - да, если C - уже проще; если какой-нибудь вербозный язык уровня Java или Ada - совсем хорошо. впрочем, это уже философия

> если C - уже проще

Кончено проще, но все равно не просто.

Корректно распарсить прототип C-функции (узнать количество и типы аргументов, наличие и тип возвращаемого значения), со всеми этими указателями, модификаторами const и тд - уже нетривиальная задача. А если прототипы нужных функций перемешаны с кодом, дейфанами, и тд - то проще сразу застрелиться.

s/дейфанами/дефайнами/

> Корректно распарсить прототип C-функции (узнать количество и типы аргументов, наличие и тип возвращаемого значения), со всеми этими указателями, модификаторами const и тд - уже нетривиальная задача.

все уже сделано за нас:

http://www.antlr.org/grammar/list

кстати с antrl и кодогенерация тривиально пишется

protected — это то дерево, из которого делают костыли.

Абсолютно всегда, когда не нужен явный private.

> как часто вы пользуетесь protected полями и зачем?

Как только - так сразу. По дефолту либо паблик, либо приват. При наследовании бывает у предков можно полезное позаимствовать, а засирать интерфейс с внешним миром не хочется. Умников, вещающих про правильную и неправильную декомпозицию не слушайте, они наследованием, похоже, вообще не пользуются.

> вообще не пользуются

Не умеют пользоваться. //fixed

«Значит неправильные бенчмарки». У него оч. выгодная позиция))) На любой аргумент можно ответить в духе «значит пчолы неправильные, совсем неправильные!»

>C++ не язык а попса чего только стоят десятистраничные темы по обсуждению какой нить хрени из него порой я его ненавижу приходится на нем писать только из за того что шаблоны можно заставить генерировать нужный код ну и деструкторы пожалуй еще

мой парсер русского языка подвис на несколько минут

> а засирать интерфейс с внешним миром не хочется

внешнему миру вообще лучше отдавать только функции, интерфейсы и фабрики, а не «засирать»(с) публичные хедеры деталями реализации