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

@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, можно закрытое наследование; писать правда всё равно больше, чем при открытом (и надо будет дописывать при изменении интерфейса адаптируемого класса), но и ненужных при этом свойств открытого наследования тоже нет.

Новые блоги и статьи Все статьи Все блоги /
[golang] Конкурентный fetcher с ограничением максимального количества одновременных HTTP запросов. alhaos 10.06.2026 Задача Реализовать конкурентный fetcher с ограничением максимального количества одновременных HTTP запросов. Сигнатура func Fetch(urls string, maxConcurrent int) Result Пример urls :=. . .	[golang] Состояние гонки (race condition) alhaos 10.06.2026 Состояние гонки (race condition) Состояние гонки (Race Condition) — это ошибка, возникающая при одновременном доступе нескольких горутин к одним и тем же данным без должной синхронизации. При этом. . .	Взрослые отношения, и почему они не получаются kumehtar 09.06.2026 Когда в детстве ребёнок не получает от родителей чего-то важного, он лишается не просто приятных переживаний, а основы для формирования определённых внутренних качеств и навыков. Если ребёнок не. . .	[golang] Worker Pool alhaos 09.06.2026 Worker Pool Worker Pool — паттерн конкурентной обработки задач в Go. Суть: фиксированное количество горутин-воркеров читают задачи из общего канала и пишут результаты в общий канал результатов. . . .
[golang] Pipeline alhaos 08.06.2026 Pipeline Pipeline — паттерн конкурентной обработки данных в Go. Суть: данные проходят через цепочку независимых стадий, каждая из которых работает в своей горутине и общается с соседями через. . .	Свет внутри себя kumehtar 07.06.2026 Пусть это будет здесь lIs4oanZS9Y	Программа для com-порта Uhbif79 05.06.2026 Всем привет, давно хотел изучить Qt, начинал, бросал, потом снова начинал. И сейчас вот смог написать свою первую программу. До этого имел опыт программирования микроконтроллеров, писал прошивки на. . .	Транскрипция 55-минутного видео через Whisper: WhisperDesktop облажался, спас Google Colab[ anaschu 01.06.2026 Понадобилось получить текст из свежезагруженного видео на YouTube. Казалось бы, задача на пять минут. Заняла полтора часа. Делюсь опытом — может кому пригодится последовательность решений. . . .

@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