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

А если посмотреть талмуд, то она делает совсем другое - генерирует исключение #BR — BOUND Range Exceeded. Время её выполнения, надо полагать, Вы дадите в ответе на моё сообщение?

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

Я их просто не использую. Если в большинстве случаев профессионалу хватает обычного C, то и шаблоны не нужны. Чем и пользуюсь. Но от C++ структур/классов не откажусь.

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

Когда классы проникают в ЛОГИКУ работы прогаммы (в какой-нибудь основной цикл приложения/потока/сервера tcp) - это очень и очень плохо. Нужно от такого избавляться!!! Вынуждает использовать всякие inversion of control (и прочую лабуду), как следствие - логика работы программы разбросана по нескольким разным модулям и работать с таким кодом становится невозможно.

> А ещё часто бывает доработка на месте, когда ты не знаешь, что нужно дописать...

Хе, вот тут у тебя проблема в компетенции или у проекта вообще. Вот тебе варианты:
- Заглянул в доку и прочитал что нужно
- Поставил breakpoint и посмотрел что нужно

Ну а если ситуация "мне бекенд что-то должен ответить, но хз что..." то это проблема явно не компилятора.

Тривиальные опечатки исправляются тривиально.
А нетривиальные - покрываются тестами (напр. ты не ту переменную на вход послал и оно все скомпилилось)
Плюс этот пример вообще не в тему - инкрементальная компиляция решает 99% таких ситуаций.

Это абсолютно несвязанные задачи. Любой код должен решать поставленную задачу и делать это корректно, иначе это какой-то говнокoд.
Если компилятор смог оптимизировать без твоей работы - это только плюс.

> никто никогда в своём уме не будет об этом думать раньше времени

Неправда. Ты всегда должен заранее оценивать сложность тех или иных алгоритмов, по имеющимся данным подбирать структуры данных и тд.
То что в итоге что-то может быть не учтено - это да, но оставлять все на "а... потом профильну и исправлю" это бред.

  Функции остались ;-)

Настолько сложно что компилер с сделали в 4 функицях, C4 называется.

...очередную дыру в проекте.

Поясню к чему это спрашиваю:
Целое ядро линукса версии 1.0.0 содержало 176250 строк кода.
Версии 5.11 - 30.34 миллионов строк вообще и из них около 14% само ядро, 60% - дрова. Т.е. "чистое ядро" - больше 4 млн. строк кода.
Не задумывались ли вы что это не погромисты деградировали, а кодовая база стала настолько, что охватить ее взглядом не может практически никто, даже при мелком дроблении на проекты, подпроекты и тд?
И чтобы хоть как-то заставить это работать приходится делать фреймворки, уровни абстраций и тд?

Лукавит дедуля

using namespace std;

int main()
{
    int notArray[] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
    int* pointer = notArray;
    cout<<"not array size: "<<sizeof(notArray)<<endl<<"pointer size: "<<sizeof(pointer)<<endl;

    return 0;
}



not array size: 40
pointer size: 8

Если [] указатель, то почему он такой большой?