В общем случае идея одна: грамотное проектирование — решение всх проблем, поэтому статья мне кажется неуместной и откровенно глупой, Вы уж простите. Все проблемы, которые вы перечислили не проблемы вовсе, если заранее думать как писать и использовать инструменты там, где их нужно использовать.
Ну тут я вообще не понял, в чем проблема-то? Не используйте их, если в данном месте они не нужны. С таким же успехом можно нагнать на что угодно, вот смотрите: "макросы нечитаемый отстой", попробуйте доказать, что это не так. Да и вообще, вы знаете инструмент удобнее, чем шаблоны для генерации кода? Я — нет. Потому что других механизмов нет, и это, отнюдь, не боль для программиста, если программист знат где их использовать, а главное умеет это делать.
Соглашусь с нечитаемостью, да, синтаксис морально устаревает и с развитием языка становится всё более громоздким, но это всё не бОльшая претензия, чем говорить, что в Java очень длинные имена классов.
Кроме того, есть такая замечательная штука как концепты в С++20, если вас не устраивают шаблоны, посмотрите на них.
Виртуальные функции
Вот этот отрывок информации меня просто сразил. То есть Вы говорите, что вот, у нас в C++ должны быть только интерфейсы, что мы против полиморфного поведения, мы отрицаем добрую часть работы "Банды четырех?", все механизмы vtable — отстой, а stl с их basic_classname неправы и добавляют боли программистам (сюда же и поголовные шаблоны в stl)? Какая глупость.
Резюмирую: мне данная статья кажется некомпетентной. Всё Вами перечисленное — проблемы проектирования и неумения применять инструменты языка.
A(const std::string& s, AbstractParser&), к примеру?
А если использовать специфики С++ с так Вами ругаемыми шаблонами, то можно получить ещё более выразительный код, который, к тому же, будет эффективнее.
Имхо, Vim — секта.
Сам пользуюсь vim на постоянной основе с плагинами типа ycm, nerdtree, clang-tiny и форматтер, и это безумно удобная вещь, да, но не когда у тебя есть возможность использовать нормальную IDE.
К тому же странно, в статье нет сравнений (внятных), кроме «ну, в виме быстрее». Нет, не быстрее, большие проекты в нем писать не удобно зная даже все шорткаты. Зато очень удобно писать embedded, когда нет возможности использовать IDE нормально, а проекты вписываются в пару десятков файлов.
А итог такой: часто админите, пишите embedded, нет GUI или нужно просто быстро отредактировать конфиг? — vim с плагинами — ваш выбор. Но когда речь идёт о разработке больших проектов, выбирайте IDE, их придумали не просто так. А для vim-оводов, хорош вовлекать людей в секту.
Если к коду приложить cmake в связке с vcpkg, то вряд ли процесс займет дольше, чем 10 минут.
Кроме того, уже над просто грамотно составленным проектом уже вряд ли придётся прыгать с бубном.
Насколько я понял. Теперь мы не привязаны к классу-родителю, нам достаточно иметь определенные методы. Наверное, это имеет смысл, правда тут я его не увидел.
Ну, а вообще, должно быстрее работать, компайл тайм, все дела.
В общем случае идея одна: грамотное проектирование — решение всх проблем, поэтому статья мне кажется неуместной и откровенно глупой, Вы уж простите. Все проблемы, которые вы перечислили не проблемы вовсе, если заранее думать как писать и использовать инструменты там, где их нужно использовать.
В смысле деструктор не вызовется? Как это? https://isocpp.org/wiki/faq/exceptions#ctor-exceptions, да и вообще, Вам, наверное, стоит почитать про RAII.
Ну тут я вообще не понял, в чем проблема-то? Не используйте их, если в данном месте они не нужны. С таким же успехом можно нагнать на что угодно, вот смотрите: "макросы нечитаемый отстой", попробуйте доказать, что это не так. Да и вообще, вы знаете инструмент удобнее, чем шаблоны для генерации кода? Я — нет. Потому что других механизмов нет, и это, отнюдь, не боль для программиста, если программист знат где их использовать, а главное умеет это делать.
Соглашусь с нечитаемостью, да, синтаксис морально устаревает и с развитием языка становится всё более громоздким, но это всё не бОльшая претензия, чем говорить, что в Java очень длинные имена классов.
Кроме того, есть такая замечательная штука как концепты в С++20, если вас не устраивают шаблоны, посмотрите на них.
Вот этот отрывок информации меня просто сразил. То есть Вы говорите, что вот, у нас в C++ должны быть только интерфейсы, что мы против полиморфного поведения, мы отрицаем добрую часть работы "Банды четырех?", все механизмы vtable — отстой, а stl с их basic_classname неправы и добавляют боли программистам (сюда же и поголовные шаблоны в stl)? Какая глупость.
Резюмирую: мне данная статья кажется некомпетентной. Всё Вами перечисленное — проблемы проектирования и неумения применять инструменты языка.
А вариант использования Command отбрасывается?
A(const std::string& s, AbstractParser&), к примеру?
А если использовать специфики С++ с так Вами ругаемыми шаблонами, то можно получить ещё более выразительный код, который, к тому же, будет эффективнее.
template<typename Parser> A(const std::string& s);
Имхо, Vim — секта.
Сам пользуюсь vim на постоянной основе с плагинами типа ycm, nerdtree, clang-tiny и форматтер, и это безумно удобная вещь, да, но не когда у тебя есть возможность использовать нормальную IDE.
К тому же странно, в статье нет сравнений (внятных), кроме «ну, в виме быстрее». Нет, не быстрее, большие проекты в нем писать не удобно зная даже все шорткаты. Зато очень удобно писать embedded, когда нет возможности использовать IDE нормально, а проекты вписываются в пару десятков файлов.
А итог такой: часто админите, пишите embedded, нет GUI или нужно просто быстро отредактировать конфиг? — vim с плагинами — ваш выбор. Но когда речь идёт о разработке больших проектов, выбирайте IDE, их придумали не просто так. А для vim-оводов, хорош вовлекать людей в секту.
Если к коду приложить cmake в связке с vcpkg, то вряд ли процесс займет дольше, чем 10 минут.
Кроме того, уже над просто грамотно составленным проектом уже вряд ли придётся прыгать с бубном.
Насколько я понял. Теперь мы не привязаны к классу-родителю, нам достаточно иметь определенные методы. Наверное, это имеет смысл, правда тут я его не увидел.
Ну, а вообще, должно быстрее работать, компайл тайм, все дела.
Можно пойти дальше — нарисовать кубики клеймом.