Нужно ли указывать virtual для переопределенного метода в C++?

❌ Не нужно.

Сейчас объясню.

Иногда встречаю код по такому шаблону:

class Base 
{
public:
    virtual void func() { /* ... */ }
};

class Derived : public Base 
{
public:
    virtual void func() override { /* ... */ }
};

🔼 Здесь в классе-наследнике Derived у переопределенного метода func() повторно указан virtual.

Ничего криминального в этом нет, код корректно сработает. Но слово virtual здесь лишнее. Никакой смысловой нагрузки оно не несёт.

Когда-то давным-давно, когда в стандарте не было override, повторное указание virtual было оправдано. Просто так легче читать. Сразу видно, что метод виртуальный.

С появлением override необходимость в этом отпала. Слово virtual нужно указывать один раз в базовом классе метода. Вот так ⤵️

class Base 
{
public:
    virtual void func() { /* ... */ }
};

class Derived : public Base 
{
public:
    void func() override { /* ... */ }
};

—

Мало C++? Тогда можно вспомнить про литералы

А Филосо́ф - Без огурцов

У Крылова есть басня "Философ и огородник", где мужик-огородник сажает огурцы, а философ-огородник над ним смеется, мол, не по науке всё. Но пока философ читает книжки, думает, прикидывает и вымеряет, огородник - работает на земле. В итоге "у огородника взошло всё и поспело", "а философ - без огурцов".

🔽

Не знаю как вы, но я постоянно балансирую между "философом" и "огородником". Хочется посидеть, подумать как лучше, чтобы раз - и готово. Но опыт говорит: "Делай!"

Фишка в том, что разработка - это сложно. Редко получается учесть всё сразу. Да и получается ли вообще? Нет, позитивный сценарий возможен, если текущая задача очень похожа на какую-то из предыдущих. Но так бывает не всегда. А в инновациях - практически никогда. Поэтому приходится думать, планомерно превращаясь в "философа" и рискуя "огурцами".

Конечно, "философ" и "огородник" - это крайности. А в нашем интеллектуальном труде нужен баланс.

💡 Зная о своей склонности пофилософствовать, я стараюсь балансировать, придерживаясь цикла: "подумал - сделал - оценил". И чем короче цикл, тем лучше.

Да, после оценки будут коррекции. Да, какие-то идеи не прокатят. Да, из-за этого будет казаться, что если бы подольше подумал, то получше бы придумал... 🙄 Не придумал бы. Лучшая идея как раз и пришла в голову от того, что предыдущую ты уже попробовал и оценил.

Поэтому когда в очередной раз повиснете в мыслях над своей лучшей задачей, вспомните про "филосо́фа - без огурцов" и спокойно переходите к делу 😉

—

Текст басни оставил в комментах. Палец вверх тому, кто найдет строки про навязчивое желание переписать проект на новомодную технологию!

#КнижнаяПолка

Как не утонуть в правках. Git-стратегия для сложных задач с риском откатов

Ситуация: пилите большую фичу, написали много кода и вдруг замечаете, что сломали то, что час назад работало. Что случилось, почему? Открываете git diff, а там правки не за последний час, а за последний день... Где была допущена ошибка? Начинаем вспоминать, запускаем отладчик и забываем про текущую работу.

🔸 Как не доводить до такой ситуации?

Правильно - чаще коммитить. Но как коммитить то, что еще не готово? Коммит же должен быть завершенным!

Решение есть у нас: промежуточные коммиты.
Мы просто коммитим все, что хотим и когда хотим, а по окончании работ "схлопываем" промежуточные коммиты в один, используя interactive rebase.

Промежуточные коммиты оформляются с префиксом WIP (от Work In Progress), чтобы потом их не пропустить. В git log получается примерно так:

WIP: что-то сделал
WIP: еще что-то сделал
WIP: убрал кое-чего
WIP: зарефакторил то-то

🔸 Когда делать промежуточный коммит?

Я руководствуюсь общим правилом: если мой следующий шаг приведет к правкам незакоммиченного кода, я делаю промежуточный коммит. У меня должна быть возможность быстро понять, где допущена ошибка, и откатиться.

Обычно такие коммиты случаются:
- при фиксировании логически завершенных правок,
- перед любым рефакторингом,
- в конце дня.

А чтобы вам проще было разобраться с подходом, я записал небольшое практическое видео. На простом примере показал как промежуточные коммиты помогают локализовать ошибку и как потом "схлопнуть" эти коммиты в один через interactive rebase. Ссылки здесь ⤵️

📱 Смотреть на YouTube

📱 Смотреть во ВКонтакте

#Troubleshooting

YouTube Analyzer 5.0

Мы выпустили новую версию YouTube Analyzer - анализатора поисковой выдачи YouTube на Python / PySide6 (Qt).

Из интересного в коде по сравнению с предыдущей версией:

🔜 Добавлены рабочие пространства. Теперь можно открыть неограниченное количество пространств во вкладках и работать одновременно с поиском, трендами и пр. Под капотом стандартные QTabWidget.

🔜 Реализована система плагинирования. Разные типы рабочих вкладок могут быть загружены из плагинов. Например, сейчас так работает autocomplete_plugin.

🔜 Добавлена галерея превью (на скрине). Ютуб-менеджеры используют ее для выявления трендов в превью видео. Реализовано на QListView с включенным режимом QListView.ViewMode.IconMode.

—

YouTube Analyzer - это desktop-приложение, написанное на Python / PySide (Qt).
Его решения можно использовать как шаблон для своих приложений на Python / PySide или на C++ / Qt.