1 | |||||||
С++ идиомы31.07.2016, 19:20. Показов 115239. Ответов 34
Метки нет (Все метки)
Перевод статей 1 и 2. Будет постепенно обновляться. Желающие внести вклад могут писать в ЛС.
Переведенные идиомы: self-assignment in an assignment operator Scope Guard Shrink-to-fit Checked delete Pointer To Implementation Получение адреса(ака взятие адреса aka Address-of) nullptr Iterator Pair Coercion by Member Template
14
|
31.07.2016, 19:20 | |
Ответы с готовыми решениями:
34
С++ идиомы - обсуждение Как и какие идиомы и паттерны можно (и лучше) применять? Идиомы программирования Английские идиомы: как правильно перевести in its own right? Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |
фрилансер
5826 / 5346 / 1097
Регистрация: 11.10.2019
Сообщений: 14,284
|
||||||
14.03.2021, 21:21 | 21 | |||||
JeyCi,
1
|
19409 / 10028 / 2443
Регистрация: 30.01.2014
Сообщений: 17,678
|
|
16.03.2021, 14:56 | 22 |
Потому что именно это в его названии и заложено.
Вообще я убежден, что CRTP должен быть элементом дизайна, а не оптимизации. Нет никакого смысла вводить его только ради оптимизации. Должны быть более фундаментальные причины.
1
|
19409 / 10028 / 2443
Регистрация: 30.01.2014
Сообщений: 17,678
|
|
16.03.2021, 15:44 | 23 |
JeyCi, я вам тут прикрепил pdf-ку со статьей из журнала C++ Report от 95 года по CRTP. Думаю полезно будет ознакомиться для полного понимания.
2
|
Любитель чаепитий
|
|
16.03.2021, 16:36 | 24 |
Не по теме:
Кликните здесь для просмотра всего текста
Код
anon@DESKTOP:/mnt/d/Projects/tmp$ valgrind --leak-check=full ./a.out ==75== Memcheck, a memory error detector ==75== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==75== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==75== Command: ./a.out ==75== ==75== error calling PR_SET_PTRACER, vgdb might block 4 12.56 8 ==75== ==75== HEAP SUMMARY: ==75== in use at exit: 56 bytes in 3 blocks ==75== total heap usage: 11 allocs, 8 frees, 73,384 bytes allocated ==75== ==75== 16 bytes in 1 blocks are definitely lost in loss record 1 of 3 ==75== at 0x4C3217F: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==75== by 0x109189: main (crtp_leak.cpp:63) ==75== ==75== 16 bytes in 1 blocks are definitely lost in loss record 2 of 3 ==75== at 0x4C3217F: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==75== by 0x1091A7: main (crtp_leak.cpp:64) ==75== ==75== 24 bytes in 1 blocks are definitely lost in loss record 3 of 3 ==75== at 0x4C3217F: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==75== by 0x1091C5: main (crtp_leak.cpp:65) ==75== ==75== LEAK SUMMARY: ==75== definitely lost: 56 bytes in 3 blocks ==75== indirectly lost: 0 bytes in 0 blocks ==75== possibly lost: 0 bytes in 0 blocks ==75== still reachable: 0 bytes in 0 blocks ==75== suppressed: 0 bytes in 0 blocks ==75== ==75== For counts of detected and suppressed errors, rerun with: -v ==75== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
1
|
329 / 149 / 33
Регистрация: 29.06.2019
Сообщений: 1,429
|
|
16.03.2021, 20:20 | 25 |
DrOffset, спасибо... начинаю понимать, как создаётся язык (что и есть цель ООП по сравнению с процедурным пр-ем), паттерны и Finite State Machine ... - прямо откровения от автора ... интересные... особенно понравилась фраза
Pros: 1) шаблон генерит функции для потомков авоматически, чтобы их не писать во всех потомках - в классическом варианте 2) по расширенной версии с базовым классом... использование перекрёстного приведения (своеобразный dynamic-cast) вообще, интересный трюк - наследоваться от базового и от template'ового... - наверно, даже таким способом и страховку от "алмаза смерти" можно изобрести?... не пробовала ещё... только вот получить наследника второй очереди - с этим наследуемым виртуальным clone(), задаваемым в шаблоне, чтобы не прописывать его во всех наследниках, - уже вроде не получится .... Добавлено через 6 минут P.S. значит new от строк 63-65 надо потом delete.. т.е. они, вероятно, не от-move-ились в unique_ptr, а, наверно, от-copy-лись... простите за выражения
0
|
GbaLog-
|
17.03.2021, 07:09
#26
|
0
|
JeyCi
|
17.03.2021, 07:31
#27
|
0
|
Алексей1153
|
17.03.2021, 07:31
#28
|
Не по теме: JeyCi, утечка там вот тут: Код
std::unique_ptr<AbstractShape> clone() const override { return std::make_unique<Derived> //создаётся НОВЫЙ объект обёртки (static_cast<Derived const&>(*this));//в конструктор передаётся КОПИЯ *this - снаружи this не удалится сам, так как создан new }
0
|
329 / 149 / 33
Регистрация: 29.06.2019
Сообщений: 1,429
|
|
18.03.2021, 08:57 | 29 |
? вижу только одну возможную фундаментальную причину - не дублировать код в потомках (чтобы было легче сопровождать) и - вторую - не отдавать полиморфизм на откуп run-time'у (для скорости)... имхо
p.s. для меня могут быть только 4 фундаментальные причины: - для увеличения скорости, - для минимизации памяти, - для минимизации писанины, - для того, чтобы не потерять что-нибудь (что приводит к memory leaks)... разве есть ещё какие-то более фундаментальные причины, например для использования CRTP?..
0
|
19409 / 10028 / 2443
Регистрация: 30.01.2014
Сообщений: 17,678
|
|
18.03.2021, 09:16 | 30 |
Обычно там, где действительно нужен runtime-полиморфизм, никак не получится его заменить на compile-time.
Я говорил только про выбор CRTP в качестве решения для замены runtime-полиморфизма. И суть моих слов в том, что дизайн должен быть основным критерием, а не производительность. В смысле, что производительность - это следствие, а не первопричина.
0
|
329 / 149 / 33
Регистрация: 29.06.2019
Сообщений: 1,429
|
|
18.03.2021, 13:07 | 31 |
ну в общем, да, - если по логике нужны будут разные реализации от одного интерфейса... то CRTP расширенный очень даже хорош (хоть некоторые и пеняют на "читаемость и отлаживаемость кода" по сравнению с использованием обычных Абстрактных классов )...
спасибо за view: performance <-design-> optimization (& 1<->3)
0
|
Avazart
|
18.03.2021, 15:45
#32
|
Не по теме: Да хорош тему засерать и тролиху кормить.
0
|
329 / 149 / 33
Регистрация: 29.06.2019
Сообщений: 1,429
|
|
23.03.2021, 18:40 | 33 |
вот читаю книгу из #25 - так речь о CRTP-фабрике в главе 13 - там и примеры с clone()... а сам CRTP в главе 8 описывается... а wiki, наверно, вырвали кусок и этот clone() не заменили на любую более вразумительную функцию...
только сейчас поняла, почему clone() - рудимент от фабрики - может быть любая др. функция...
0
|
329 / 149 / 33
Регистрация: 29.06.2019
Сообщений: 1,429
|
|
18.05.2021, 19:55 | 34 |
да, с CRTP-фабрикой, - примером с wiki, - я всё-таки поспешила...
всё-таки смысл статического полиморфизма (в данном случае) - Lazy: CRTP... === - полагаю, желание/потребность подрядить ленивые вычисления/методы и может стать фундаментальным аргументом в пользу выбора CRTP (иных пока не вижу)... только я пока не выбирала ленивые методы... как бы не вижу в них преимуществ... разве что по памяти (чтобы функции-члены не инстанцировались в случае, если вдруг потом могут и не понадобится)... имхо Добавлено через 4 минуты p.s. вероятно, для подмешивания этот трюк в основном используется... так же
0
|
329 / 149 / 33
Регистрация: 29.06.2019
Сообщений: 1,429
|
||||||
19.05.2021, 10:42 | 35 | |||||
оставлю работающий код (с линка - просто там нарезки) для ситуации подмешивания нескольких Базовых классов Кликните здесь для просмотра всего текста
- всё-таки доп. уровень косвенности в CRTP через друзей может помочь и избежать "Алмаза смерти" (подробнее здесь - смысл friend в подмешивании)... === и так же (по последнему линку) - это попытка избавиться от большого количества static_cast'ов при реализации CRTP-паттерна, которая как раз и заключается в выносе всех static_cast'ов на верх. уровень иерархии, а чтобы оттуда не получить ромбовидного наследования - использование template'а, принимающего параметром тоже template (а не конкретный type) в общем, CRTP, конечно, вариант, когда все типы известны на этапе компиляции, - для статического полиморфизма... но всё-таки глубокие иерархии всё равно не стоит делать... а диспетчеризация через visit и variant в std даёт нужное и без иерархий... появление std::variant -- всё-таки большой шаг вперёд был в std... имхо
0
|
19.05.2021, 10:42 | |