История изменений

Не обязательно ничего забывать, это лишь твои какие-то фантазии. Особенно не обязательно делать это сразу. Это если у кого-то в красном углу вместо Спаса висит книжка Страуструпа, то тогда да. А если своей головой думают, то необязательно. Дали инструмент, дали описание - дальше сам решай, что и как с ним делать. Если джун и страшно, то тогда читай книжку Страуструпа. Но я не думаю, что в перечисленных мной хотя бы тех трёх проектах кто-то настолько пуглив, чтобы спасаться только молитвами из молитвенника.

Я говорил про поэтапность перехода, которая критична для больших монолитных проектов. Она достижима. Это основное.

Т.е., если C++ лучше C, то в любом нормальном крупном проекте должны выполнить такой план:

1. формально переходим на сборку проекта компилятором C++, отрабатывая список несоответствий. Код по сути остаётся весь тот же, просто собираем грабли и ставим их зубами вверх, чтобы не наступить

2. по мере возможности, надобности и желания внедряем «смену стиля мышления» в новых модулях, или рефакторим. Если для конкретного модуля (в организационном смысле слова «модуль») не нужно ничего менять, то пусть остаётся на Си.

При этом монолит не нужно дробить. Там, где важна эффективность, раздробить на микросервисы, как это сейчас модно, не всегда возможно, т.к. эффективность скажет «прощай».

Именно такой план снижает риски и делает переход возможным. Но почему-то в перечисленных мной проектах так делать не стали. Значит, C++ не так уж лучше С.

Не обязательно ничего забывать, это лишь твои какие-то фантазии. Особенно не обязательно делать это сразу. Это если у кого-то в красном углу вместо Спаса висит книжка Страуструпа, то тогда да. А если своей головой думают, то необязательно. Дали инструмент, дали описание - дальше сам решай, что и как с ним делать. Если джун и страшно, то тогда читай книжку Страуструпа. Но я не думаю, что в перечисленных мной хотя бы тех трёх проектах кто-то настолько пуглив, чтобы спасаться только молитвами из молитвенника.

Я говорил про поэтапность перехода, которая критична для больших монолитных проектов. Она достижима. Это основное.

Т.е., если C++ лучше C, то в любом нормальном крупном проекте должны выполнить такой план:

1. переходим на C++, отрабатывая список несоответствий. Код по сути остаётся весь тот же, просто собираем грабли и ставим их зубами вверх, чтобы не наступить

2. по мере возможности, надобности и желания внедряем «смену стиля мышления» в новых модулях, или рефакторим. Если для конкретного модуля (в организационном смысле слова «модуль») не нужно ничего менять, то пусть остаётся на Си.

При этом монолит не нужно дробить. Там, где важна эффективность, раздробить на микросервисы, как это сейчас модно, не всегда возможно, т.к. эффективность скажет «прощай».

Именно такой план снижает риски и делает переход возможным. Но почему-то в перечисленных мной проектах так делать не стали. Значит, C++ не так уж лучше С.

Не обязательно ничего забывать, это лишь твои какие-то фантазии. Особенно не обязательно делать это сразу. Это если у кого-то в красном углу вместо Спаса висит книжка Страуструпа, то тогда да. А если своей головой думают, то необязательно. Дали инструмент, дали описание - дальше сам решай, что и как с ним делать. Если джун и страшно, то тогда читай книжку Страуструпа. Но я не думаю, что в перечисленных мной хотя бы тех трёх проектах кто-то настолько пуглив, чтобы спасаться только молитвами из молитвенника.

Я говорил про поэтапность перехода, которая критична для больших монолитных проектов. Она достижима. Это основное.

Т.е., если C++ лучше C, то в любом нормальном крупном проекте должны выполнить такой план:

1. переходим на C++, отрабатывая список несоответствий. Код по сути остаётся весь тот же, просто собираем грабли и ставим их зубами вверх, чтобы не наступить

2. по мере возможности, надобности и желания внедряем «смену стиля мышления» в новых модулях, или рефакторим.

При этом монолит не нужно дробить. Там, где важна эффективность, раздробить на микросервисы, как это сейчас модно, не всегда возможно, т.к. эффективность скажет «прощай».

Именно такой план снижает риски и делает переход возможным. Но почему-то в перечисленных мной проектах так делать не стали. Значит, C++ не так уж лучше С.

Не обязательно ничего забывать, это лишь твои какие-то фантазии. Особенно не обязательно делать это сразу.

Я говорил про поэтапность перехода, которая критична для больших монолитных проектов. Она достижима. Это основное.

Т.е., если C++ лучше C, то в любом нормальном крупном проекте должны выполнить такой план:

1. переходим на C++, отрабатывая список несоответствий. Код по сути остаётся весь тот же, просто собираем грабли и ставим их зубами вверх, чтобы не наступить

2. по мере возможности, надобности и желания внедряем «смену стиля мышления» в новых модулях, или рефакторим.

При этом монолит не нужно дробить. Там, где важна эффективность, раздробить на микросервисы, как это сейчас модно, не всегда возможно, т.к. эффективность скажет «прощай».

Именно такой план снижает риски и делает переход возможным. Но почему-то в перечисленных мной проектах так делать не стали. Значит, C++ не так уж лучше С.