Виртуальные функции в микроконтроллерах — темная сторона

Во первых, девиртуализация — это не выбрасывание неиспользуемых методов, а замена виртуального вызова на невиртуальный.
Сейчас девиртуализация в реальном проекте делается компилятором из большой тройки на должном уровне оптимизации, если граф вызовов не очень сложный, в реальном проекте это если создание объекта и вызов метода находятся в той же функции или во вложенной на один-два уровня. Кроме того, невозможно девиртуализировать вызовы объектов, которые приходят в компонент извне.
А чтобы повыбрасывать неиспользуемый код, надо глобально девиртулизовать все виртуальные вызовы, и уже у тех иерархий, у которых это удалось, удалять неиспользуемые методы. На сегодняшний день компиляторы могут делать такое только в тривиальных случаях.

Типобезопасная работа с регистрами без оверхеда на С++17: value-based метапрограммирование

Тогда запакованный тип — уже параметр шаблона

template <typename T>
constexpr void foor(T value)
{
    using type = std::type_identity_t<T>;  
}

constexpr auto foo = []<typename T>(T value) // C++ 20
{
    using type = std::type_identity_t<T>;  
};

Типобезопасная работа с регистрами без оверхеда на С++17: value-based метапрограммирование

Я, честно говоря, бегло посмотрел, но макрос TYPE() можно заменить на

template <auto Value>
using type_t = typename decltype(Value)::type;

а макрос MAKE_TRAITS_WITH_MASK() на

template <typename Enum>
constexpr std::size_t mask = [](auto a) -> std::size_t
{ // здесь ошибка компиляции, но можно поставить дефолтное значение, если есть хорошее
    static_assert(!std::is_same_v<decltype(a), decltype(a)>);
    return 0;
}(Enum{})
;

template <typename Enum>
struct enum_traits
{
    static constexpr std::size_t mask = ::mask<Enum>;    
};

template <typename Enum>
constexpr enum_traits<Enum> enum_traits_value{};

enum class xx {};

template <> constexpr std::size_t mask<xx> = 0b110;

https://godbolt.org/z/ddRCxc

История микропроцессора и персонального компьютера: 1947-1974 годы

Бесполезный факт. Сооснователем компании Burroughs был дедушка Билла Берроуза, который написал Naked Lunch и прочие интересные книжки. Начинала компания с торговли арифмометрами.

Итоги: 9 главных технологических прорывов 2019 года

Я не большой знаток Rust, но читал, что одним из идеологических отличий от Rust является то, что концепция ownership распространяется на группу объектов. Возможно, это позволит сделать двусвязный список без unsafe кода.

Итоги: 9 главных технологических прорывов 2019 года

Ну, собственно, там тёмная история с Microsoft и IBM, учитывая, что NT линейку они разрабатывали совместно. Возможно, IBM намекнул регулятор — ребята, у вас и так всего дохрена, оставьте этот кусок бизнеса в покое.

CLion 2019.3 уже здесь! Повышенное быстродействие редактора и самые долгожданные новые возможности

youtrack.jetbrains.com/issue/RSCPP-28514

C++ vtables. Часть 1 (basics + multiple Inheritance)

Реализация виртуального наследования отличается, а обычное более-менее похоже.

CLion 2019.3 уже здесь! Повышенное быстродействие редактора и самые долгожданные новые возможности

Для немодифицированных файлов доступно готовое AST, что должно повысить скорость парсинга на порядок, определение циклических импортов.
Но даже самая начальная поддержка должна обрабатывать директивы module, import, export.

CLion 2019.3 уже здесь! Повышенное быстродействие редактора и самые долгожданные новые возможности

Да, а вот ещё хотел спросить. Поддержка модулей планируется, и если да, то когда её ориентировочно ждать?

CLion 2019.3 уже здесь! Повышенное быстродействие редактора и самые долгожданные новые возможности

Мне, честно говоря, показалось, что такие ошибки вы правите по остаточному принципу. Ок, я буду интенсивнее открывать тикеты.

CLion 2019.3 уже здесь! Повышенное быстродействие редактора и самые долгожданные новые возможности

Перегрузки да, там перечисляются кандидаты, и почему каждый не подошёл. А я имею ввиду вот что:

#include <string>
#include <concepts>

template <typename T>
concept int_addable = 
   std::integral<T> &&
   requires (T const &t) { { t + t } -> T; }
;

template <int_addable T>
void foo(T &t) {}

int main()
{
  foo(std::string{});   
}

хотелось бы сообщения:

 concept int_addable isn't satisfied for function foo() // это есть
because the clause std::integral<T> isn't satisfied for type std::basic_string<char, std::char_traits<char>> // а этого нет

CLion 2019.3 уже здесь! Повышенное быстродействие редактора и самые долгожданные новые возможности

Для сложных выражений в static_assert() есть удобный popup, где можно посмотреть, чему равно или какого типа подвыражение, неплохо бы такую же функциональность для концептов. Сейчас там всё ограничивается красным подчёркиванием и фразой concept isn't satisfied.

Ещё интересно автодополнение как в clangd для членов, методов и подтипов.

Ну и, конечно, всё ещё есть не критичный, но существенный процент ошибок вообще, а в выражениях с концептами этот процент значительно выше.

Производительность Resharper C++ удалось подтянуть, по сравнению с ранними версиями. Сейчас, на мой взгляд, она на удовлетворительном уровне.

CLion 2019.3 уже здесь! Повышенное быстродействие редактора и самые долгожданные новые возможности

Это плохо

CLion 2019.3 уже здесь! Повышенное быстродействие редактора и самые долгожданные новые возможности

А там будет code completion для концептов?

CLion 2019.3 уже здесь! Повышенное быстродействие редактора и самые долгожданные новые возможности

А с Resharper C++ как обстоят дела?

«Современный» C++: сеанс плача с причитаниями

Случайно наткнулся на некропост и захотел ответить. Например, Visual Studio страшно замедлилась после того как .NET команда протолкнула переписывание IDE на .NET, а потом пришлось долго оптимизировать её производительность.

Усложнение C++ неизбежно. И не только C++

Очень мало примеров переписывания софта и очень много поддержки старого кода и портирования. И чем больше проект, тем чаще выбирается второй и третий варианты.

Усложнение C++ неизбежно. И не только C++

И в этом контексте в долгосрочном плане я не вижу как Си вдруг становится особняком. Для меня становится очевидным что однажды и он родимый будет вытеснен,

Когда-нибудь, разумеется, C будет вытеснен. Вопрос только когда, как и кем.

И попытки аргументировать уникальность случая ценой перехода звучат очень натянуто.

Ну мы же не просто теоретизируем. Очень мало примеров переписывания софта и очень много поддержки старого кода и портирования.

Переход от печатных книг, газет и журналов к их цифровым аналогам пока еще далеко не завершен, но ведь тенденция не вызывает сомнений.

Смена языка — это не настолько радикальное изменение. На выходе будет точно такой же бинарный файл. Возможно, за счёт улучшения языка исчезнут некоторые классы ошибок, но и сегодняшнее положение дел считается приемлемым. Прирост производительности кодера составит ну, максимум, в два раза. Вот если язык будет настолько мощен, что прирост составит 10 или 100 раз, тогда — да, это радикальное изменение.

Усложнение C++ неизбежно. И не только C++

Почему в случае с переходом на новый язык программирования мы должны переписывать весь старый код? а не просто написать новый и лучший и выкинуть старье? Зачем нам старые приложения? Их место как и печатных машинок на свалке и в музеях или в коллекциях энтузиастов.

Очень давно, когда железо стоило дороже софта, так и делали. Но в районе C ситуация изменилась на противоположную, софт стал дороже железа. А главное, не просто дороже, а его невозможно переписать за секунду, сколько денег не вкладывай. И получается дилемма — портировать старый софт или ждать 10 лет, пока будет написан новый. Что выберет бизнес?