А зачем? QObject'ы Qt в общем случае отличаются только тем, что удалять их правильнее через deleteLater. Ну так какие проблемы передать этот deleteLater прямо в QSharedPointer?
как раз таки с поддержкой времени жизни долгоживущих объектов проблем нет — их можно либо через raii создавать/удалять, либо (самый простой вариант) выделять на стеке в main. В самых неудобных случаях делаются синглтоны/мультитоны. А вот всякие нетривиальные, «недолгоживущие» и всем потребные сущности без shared_ptr тяжеловато мониторить.
вот только из-за того, что в лямбде захвачен некопируемый объект, сама лямбда тоже становится некопируемой. И в std::function, например, её уже не засунешь.
вы меня совершенно не поняли, я про совершенно другой сценарий. static_assert'ом можно проверить, считается результат constexpr функции на этапе компиляции или же нет.
все STL контейнеры позволяют использовать свой аллокатор памяти. new/delete переопределяются глобально. Пользуясь constexpr можно реализовывать всякие compile-time префикс функции. Проблемы на ровном месте придумываете.
std::vector как раз и удваивает, скорее всего, другие контейнеры тоже. Рекоммендую не забывать про std::vector::reserve, хотя в рамках объемов оперативной памяти более 40 реаллокаций не сэкономишь
ну так суть шаблонов в том, чтобы получить оптимальный байткод для каждого из возможных вариантов использования. Справляются с этим компиляторы или нет к комитету стандартизации отношения не имеет.
constexpr не является жестким требованием для функции. Подадим на вход compile-time значение и она посчитается на этапе компиляции. Подадим на вход runtime значение и получим обычную функцию. В сложных сценариях работы компилятор может не понять, что на самом деле на входе функции константа, и посчитать её runtime-значением. Отличить один сценарий от второго можно либо просматривая asm-выхлоп, либо пользуясь static-assert'ом
тогда уж заменяй на uint_fast32_t.
И не забывай проверять constexpr через static_assert. А то маловато смысла писать constexpr там, где на вход функции подается не-constexpr значение
constexpr во-первых является конструкцией с++, а не си, а во-вторых, несет несколько иной смысл. Вместо constexpr функции/переменной компилятор сразу подставляет посчитанное на этапе компиляции значение (если его можно посчитать на этапе компиляции). А const просто означает, что переменную нельзя поменять.
так ведь ничего же не мешает сделать три модели (для поля, а также левой и верхней шапок), которые будут обращаться к одним и тем же данным. При этом логика моделей шапок будет одинакова с точностью до транспонирования.
это если:
а. человек — профессионал, который гарантированно не допустит ошибку, не пропустит возможность оптимизации и отлично знает особенности архитектуры
в. существует достаточное количество выделенных на проект часов, чтобы писать его на асме, под каждую отдельно взятую целевую платформу и архитектуру.
со временем менеджеры поймут, что как девять женщин не родят ребенка за месяц, так и не получится сэкономить на программистах, «освоивших с++ за 21 день». Что рефакторинг может быть экономически обоснован, и чтобы «добавить фичу А» может потребоваться в 20 раз больше времени, чем на «добавить фичу Б», даже если они формулируются похожим образом.
И не забывай проверять constexpr через static_assert. А то маловато смысла писать constexpr там, где на вход функции подается не-constexpr значение
а. человек — профессионал, который гарантированно не допустит ошибку, не пропустит возможность оптимизации и отлично знает особенности архитектуры
в. существует достаточное количество выделенных на проект часов, чтобы писать его на асме, под каждую отдельно взятую целевую платформу и архитектуру.