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

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

Новые блоги и статьи Все статьи Все блоги /
Оказывается, Unreal Engine позволяет качество на порядки выше, чем было в Lineedge Etyuhibosecyu 05.07.2026 Жаль, конечно, что я не узнал об этом, пока Lineedge существовала, а то бы Noname2331 написал, что волки превращаются в пиксельную кашу, а я бы его попросил скачать какую-нибудь бриллиантовую или Pro. . .	Doom для терминала без стрельбы и монстров. 3D Raycasting на ascii. dcc0 05.07.2026 Попросил нейронную сеть deepai. org написать рейкастинг 3D с библиотекой ncurses для Linux. Чтобы можно было ходить на стрелочки. Чтобы стены были отрисованы символами. Справилась. Первый вариант. . .	Установка статуса документа по условию Maks 05.07.2026 Алгоритм из решения ниже реализован на нетиповом документе "НарядПутевка" разработанного в КА2. Задача: в табличной части "Материалы" документа при записи автоматически устанавливать статус. . .	Сезонность и суточность закисления почв anaschu 04.07.2026 200 часов это все равно моловато. Есть ситуации, но нестандартные, когда смена происходит за 5 лет. Но обычно это 50 лет и более. Наверное, закисление почвы происходит сезонно в средней. . .
В чем ценность человеческого опыта в глобальном смысле? kumehtar 03.07.2026 Возможно, ценность человека не в том, что он однажды достигает мудрости, а в том, что он становится носителем карты пути. Он знает не только истину, но и последовательность внутренних изменений,. . .	интеграция AnyLogic с самописным REST API и переход на Odoo anaschu 03.07.2026 Успешная интеграция AnyLogic с самописным REST API и переход на промышленную Odoo WMS Сегодня проделал огромный путь от простой симуляции физических процессов до построения полноценной. . .	Поиск всех путей на ориентированном графе. Linux dcc0 02.07.2026 Переработка старого кода из моей статьи. Через несколько переработок от PHP кода к C89 (надеюсь, 89). Но довольно запутанно получилось. Код для Linux. Но если убрать time и то, что с ним. . .	Сам себя обучал rest api anaschu 02.07.2026 Педагогический лайфхак: Почему чистый REST API для ученика намного круче, чем готовые библиотеки Когда мы отказались от капризного JAR-файла AnyLogic и переписали код на стандартный HttpClient,. . .

@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