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

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

Новые блоги и статьи Все статьи Все блоги /
Access VikBal 11.12.2025 Помогите пожалуйста !! Как объединить 2 одинаковые БД Access с разными данными.	Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro	Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .	Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .
Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .	Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .	Мысли в слух kumehtar 18.11.2025 Кстати, совсем недавно имел разговор на тему медитаций с людьми. И обнаружил, что они вообще не понимают что такое медитация и зачем она нужна. Самые базовые вещи. Для них это - когда просто люди. . .	Создание Single Page Application на фреймах krapotkin 16.11.2025 Статья исключительно для начинающих. Подходы оригинальностью не блещут. В век Веб все очень привыкли к дизайну Single-Page-Application . Быстренько разберем подход "на фреймах". Мы делаем одну. . .	Фото: Daniel Greenwood kumehtar 13.11.2025

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

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