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

Но чем это лучше, обещания присобачить delete?

Тем, что он не забудет это сделать. Не говоря уж о читаемости кода. И вообще, в С++ бесполезно пытаться защитить криворукого кодера от выстрела себе в ногу. Он найдет еще 1000 и один способ это сделать. SP нужны не для этого, а просто потому что они удобны.

я предлагал контролировать SP не только delete, но и new.

И как ты предлагаешь запретить использование оператора new? Кому надо, тот все равно вызовет.

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

И как это коррелирует с вопросом о моем понимании формул О большого?

Потому и думаешь, что «если алгоритм хорош на больших N, то он плох на малых».

Я такого не думал, и не говорил. Видимо, ты приравнял выражение «как правило» к слову «всегда». Ну извини, ты не предупреждал, что у тебя плохо с русским языком.

Докажи, что массив должен быть _несортированным_, мне это не очевидно.

На входе он несортированный. Понимаешь, бывает, данные лежат не совсем в том формате, в котором тебе хочется, и приходится обрабатывать их как есть. А если уж и следует сортировать данный массив, то уж по более важному критерию, чем этот warnLevel.

это верно, но не доказана обязательность такого прохода.

Доказательство - пожалуйста: пусть мы можем выкинуть элемент под некоторым номером из перебора. Тогда в случае, когда он содержит единственное максимальное число, алгоритм отработает неправильно.

бред полный. Это относится только к обменной сортировке массива, да и то, лишь в случае, если у нас есть O(1) памяти. Не более.

Ок, приведи пример сортировки с меньшей сложностью.

когда N=1, то что у тебя «растёт»? Куда?

При увеличении N же.

Формула с O-большое не учитывает накладные расходы.

Ну и пусть не учитывает. Я ее и не использую для рассчета накладных расходов.

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

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

Почему-то постулируя то, что стандартная сортировка, написанная людьми поумнее нас с тобой, работает заведомо медленнее, чем твой велосипед.

_Стандартная_ ?! Это какая из них?

Но чем это лучше, обещания присобачить delete?

Тем, что он не забудет это сделать. Не говоря уж о читаемости кода. И вообще, в С++ бесполезно пытаться защитить криворукого кодера от выстрела себе в ногу. Он найдет еще 1000 и один способ это сделать. SP нужны не для этого, а просто потому что они удобны.

я предлагал контролировать SP не только delete, но и new.

И как ты предлагаешь запретить использование оператора new? Кому надо, тот все равно вызовет.

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

И как это коррелирует с вопросом о моем понимании формул О большого?

Потому и думаешь, что «если алгоритм хорош на больших N, то он плох на малых».

Я такого не думал, и не говорил. Видимо, ты приравнял выражение «как правило» к слову «всегда». Ну извини, ты не предупреждал, что у тебя плохо с русским языком.

Докажи, что массив должен быть _несортированным_, мне это не очевидно.

На входе он несортированный. Понимаешь, бывает, данные лежат не совсем в том формате, в котором тебе хочется, и приходится обрабатывать их как есть. А если уж и следует сортировать данный массив, то уж по более важному критерию, чем этот warnLevel.

это верно, но не доказана обязательность такого прохода.

Доказательство - пожалуйста: пусть мы можем выкинуть элемент под некоторым номером из перебора. Тогда в случае, когда он содержит единственное максимальное число, алгоритм отработает неправильно.

бред полный. Это относится только к обменной сортировке массива, да и то, лишь в случае, если у нас есть O(1) памяти. Не более.

Ок, приведи пример сортировки с меньшей сложностью.

когда N=1, то что у тебя «растёт»? Куда?

При увеличении N же.

Формула с O-большое не учитывает накладные расходы.

Ну и пусть не учитывает. Я ее и не использую для рассчета накладных расходов.

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

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

Почему-то постулируя то, что стандартная сортировка, написанная людьми поумнее нас с тобой, работает заведомо медленнее, чем твой велосипед.

_Стандартная_ ?! Это какая из них?