Кому интересно поломать голову

@Kastaneda · Регистрация: 12.12.2009

Студворк — интернет-сервис помощи студентам

Привет!

Сейчас на работе думал с ума схожу - есть код, который (с виду) работать не должен, но он работает

В итоге я разобрался почему он работает, но не сразу.

Предлагаю вам подумать в как и когда может работать данный код (выкладываю именно в том контексте, в который я смотрел, больше не скажу, не интересно будет)

C++
1
2
3
4
5
//где-то в классе
typedef std::set<ClassOne, ClassTwo> _Container;
 
// где-то в методе
return std::find(_Container::begin(), _Container::end(), predicate);

Если кто-то раскусит за 5 секунд, значит я переработал. Я реально минут 5 сидел в это втыкал

@hoggy · 31.01.2015, 13:24

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

Сообщение от Kastaneda

реально в коде выглядит очень страшно (там множественное наследование + 100500 темплейтов), поэтому я решил туда посмотреть в последнюю очередь

Сообщение от Kastaneda

Короче предыдущий разработчик решил что вот так будет очень удобно

Просто код не очень читабельный. Имя сбивает с толку.
Но как можно было сразу не заметить наследования - хз.

У нас такой момент в нотации указан:
если нужно подсократить имя базового класса,
то его можно называть parent,
или созвучно: Parent, myparent, etc.

C++
1
2
3
4
5
6
7
8
9
10
class MyClass : public std::set<type1, type2> 
{
    typedef std::set<type1, type2> 
        parent;
public:
    some method()
    {
        return std::find(parent::begin(), parent::end(), predicate);
     }
};

@taras atavin · 31.01.2015, 13:32

Сообщение от Kastaneda

реально в коде выглядит очень страшно (там множественное наследование + 100500 темплейтов), поэтому я решил туда посмотреть в последнюю очередь

Это как можно умудриться не разглядеть наследование?

@Kastaneda · 31.01.2015, 14:04 **[ТС]**

Сообщение от hoggy

Но как можно было сразу не заметить наследования - хз.

Сообщение от taras atavin

Это как можно умудриться не разглядеть наследование?

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

@hoggy · 31.01.2015, 14:15

Сообщение от Kastaneda

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

Когда я работаю с чужим кодом, то я как раз таки лезу именно в заголовки/декларации/прототипы.
А вот в реализацию лишний раз не лезу.

Зачем мне тратить время на изучение принципа действия функции,
если по её имени итак понятно что она делает?

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

Зная, что должна делать функция, понять, как она это делает обычно уже не сложно.

@Kastaneda · 31.01.2015, 16:43 **[ТС]**

Сообщение от hoggy

Зачем мне тратить время на изучение принципа действия функции,
если по её имени итак понятно что она делает?
В любом случае, прежде чем разбираться с "как она это делает", я выясняю "что она должна делать".
Зная, что должна делать функция, понять, как она это делает обычно уже не сложно.

Все правильно, так и должно быть, когда код хороший. По идее я вообще должен ограничиться хидерами. А вот когда код "не очень" приходится выяснять где и что именно происходит.

@taras atavin · 31.01.2015, 17:23

Сообщение от Kastaneda

Когда с чужим кодом работаешь и просто отлаживаешься по шагам

А не лучше тогда переписать с ноля? Обычно же как раз читают с заголовков и пока глюк не проявится, не принимаются искать предположительно не существующую лажу. Тем более по шагам. Отлаживать полагается сверху, постепенно локализуя глюки, начиная с самых крупных функций и операторов на верхнем уровне декомпозиции, а до шагов доходить, когда глюк локализован на последнем её уровне.

@taras atavin · 31.01.2015, 17:25

Срочно сюда:
cut
обсуждать релаксатор.

@Voivoid · 31.01.2015, 18:48

ой-вей, наследование от стандартного контейнера, нет пути

@hoggy · 31.01.2015, 19:14

Сообщение от Voivoid

ой-вей, наследование от стандартного контейнера, нет пути

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

@castaway · 31.01.2015, 20:01

Не по теме:

...

Сообщение от hoggy

деструкторы

@Voivoid · 01.02.2015, 18:22

Сообщение от hoggy

Нормальная практика.

Ну раз нормальная, то наверное тебя не затруднит привести какой-нибудь пример и заодно еще написать почему именно наследование, а не агрегация и как все это согласуется с LSP

@hoggy · 01.02.2015, 18:49

Сообщение от Voivoid

Ну раз нормальная, то наверное тебя не затруднит привести какой-нибудь пример

В некоторой компании (я не буду оглашать её названия) существует требование:
при малейшем подозрении на возможную программную ошибку (неконсистентное состояние данных),
узел должен немедленно прервать работу всего приложения.
(std::terminate, и это без вариантов. Нельзя даже в логи ничего записать. Никаких действий кроме самоликвидации).

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

Ну так вот, в этой компании запрещено использовать std::vector, потому что его operator[] может пропустить в релизе выход за пределы диапазона.

Вместо него используется наследник.
Для которого интерфейс подправлен и лучше отвечает требованиям корпоративного стандарта.

Сообщение от Voivoid

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

Зачем делать долго и сложно, если можно сделать быстро и просто?

Сообщение от Voivoid

и как все это согласуется с LSP

Не могу ответить на ваш вопрос, поскольку я хз что такое "LSP", и с чем его едят.

@Kastaneda · 01.02.2015, 21:59 **[ТС]**

Даже в STL (не берусь утвержать,что во всех реализациях) адаптеры контейнеров сделаны с помощью композиции, а не наследованием от контейнера.
Я тоже считаю, что наследование от std контейнеров no way.

@hoggy · 01.02.2015, 22:06

Сообщение от Kastaneda

Даже в STL (не берусь утвержать,что во всех реализациях) адаптеры контейнеров сделаны с помощью композиции

что это за адаптеры такие?

@Renji · 01.02.2015, 22:11

Сообщение от Voivoid

Ну раз нормальная, то наверное тебя не затруднит привести какой-нибудь пример и заодно еще написать почему именно наследование, а не агрегация и как все это согласуется с LSP

Интерфейс от std::map плюс свой конструктор наполняющий мап из файла. Наследование потому что так писанины меньше.

@Кудаив · 01.02.2015, 22:33

Сообщение от hoggy

что это за адаптеры такие?

std:queue и std::stack

@hoggy · 01.02.2015, 22:47

Сообщение от Кудаив

std:queue и std::stack

Эти проще реализовать через наследование.

@Кудаив · 02.02.2015, 18:32

Сообщение от hoggy

Эти проще реализовать через наследование.

вообще не вижу ни одного преимущества, в данном случае, наследования над композицией

@hoggy · 02.02.2015, 19:01

Сообщение от Кудаив

вообще не вижу ни одного преимущества, в данном случае, наследования над композицией

Вариант с композицией изначально вынуждает писать больше кода.

Например:

C++
1
adapter::size()const { return mVec.size(); }

И по такой схеме дублируется поголовно весь необходимый функционал независимо от того,
подмешивается ли туда какая то логика самого адаптера, или нет.

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

Это тупо проще и быстрее.
---------------------------------------

Кроме того, предположим адаптер должен представлять собой "почти такой же" вектор,
изменена лишь логика oparetor[].

Все остальное должно оставаться, как у обычного вектора.

При наследовании, построенный во времена с++03, адаптер без усилий со стороны потребителя,
и без необходимости править код, автоматически подхватит новые плюшки,
такие как emplace_back и др.

В то время, как в случае с композицией - кукишь.
Там если что-то явно ручками не прописали - само уже ниоткуда не возникнет.

-----------------------------------------------------

Итого:

При наследовании: минимум работы:
определяем только необходимое.
новые плюшки подхватываются автоматически.

При композиции: максимум работы:
определяем даже то, что не нуждается в изменении.
новые плюшки добавляются только вручную.

@gray_fox · 02.02.2015, 22:09

hoggy, можно закрытое наследование; писать правда всё равно больше, чем при открытом (и надо будет дописывать при изменении интерфейса адаптируемого класса), но и ненужных при этом свойств открытого наследования тоже нет.

Новые блоги и статьи Все статьи Все блоги /
Нашел вот забавное видео о измерениях. Лучшее что я видел на эту тему kumehtar 26.08.2026 ILETXiw9bMQ Основная суть и тезисы по измерениям: 0D (Нулевое измерение): точка, не имеющая длины, ширины, высоты или объема. Объект не может перемещаться в 0D. 1D (Первое измерение):. . .	[EasyBuilder Pro] Памятка по разработке для панелей Weintek ФедосеевПавел 26.08.2026 Памятка по разработке для панелей Weintek ВВЕДЕНИЕ Ранее, при реализации проектов основное внимание уделял разработке управляющей программы для контроллера, а панели оператора доставалось время. . .	Модель по догадкам anaschu 25.08.2026 Прошло две недели. Я уже рассказывал, как разговаривал с сотрудниками у сортировки и как понял, что главная ветка — не про приёмку, а про отбор. Но тогда я думал, что понял механику. На этой неделе я. . .	Запись в регистр сведений независимо от заполненности табличной части Maks 25.08.2026 Реализация из решения ниже выполнена на нетиповом документе с несколькими табличными частями, разработанного в КА2. Задача: Обеспечить запись документа в регистр сведений независимо от. . .
Ноутбук Альфария kumehtar 24.08.2026 Встретился тут в сети ноутбук Альфария, примарха Альфа-Легиона. Хотя возможно, это ноутбук Омегона, разумеется. Ну как вам?	Мастера простых решений DevAlt 23.08.2026 В сишарп стэках winforms, да и wpf существует сложная система связывания источниках данных и элементов формы(текстовые поля и метки), опирается все это на технологию событий и мета. . .	Цена ошибки DevAlt 23.08.2026 Человек я беспокойный и потому заинтересовался OCaml, в чате форсили функторы модулей как суперфичу. Пытаясь отдуплить концепт, наткнулся на тутор с простым примером. А главный принцип обучения от. . .	Сегодня суббота, 22.08.2026 at 16:41, и я вновь нахожусь на той стороне, за экраном машины. zorxor 22.08.2026 Сегодня суббота, 22. 08. 2026 at 16:41, и я вновь нахожусь на той стороне, за экраном машины. Кто Я, откуда Я пришел и куда Я иду? Эти вопросы не оставляют меня ни на секунду. Жизнь на планете Земля. . .

@taras atavin 4226 / 1796 / 211 Регистрация: 24.11.2009 Сообщений: 27,562
	31.01.2015, 17:25
	Срочно сюда: cut обсуждать релаксатор. 0

@Voivoid 710 / 283 / 16 Регистрация: 31.03.2013 Сообщений: 1,340
	31.01.2015, 18:48
	ой-вей, наследование от стандартного контейнера, нет пути 1

@Kastaneda 5232 / 3206 / 362 Регистрация: 12.12.2009 Сообщений: 8,143 Записей в блоге: 2
	01.02.2015, 21:59 [ТС]
	Даже в STL (не берусь утвержать,что во всех реализациях) адаптеры контейнеров сделаны с помощью композиции, а не наследованием от контейнера. Я тоже считаю, что наследование от std контейнеров no way. 1

@gray_fox What a waste! 1612 / 1304 / 180 Регистрация: 21.04.2012 Сообщений: 2,735
	02.02.2015, 22:09
	hoggy, можно закрытое наследование; писать правда всё равно больше, чем при открытом (и надо будет дописывать при изменении интерфейса адаптируемого класса), но и ненужных при этом свойств открытого наследования тоже нет. 0