> Стандарт. Плюс он написан так, что часть вещей просто UB, часть отдана
> на откуп реализатором компиляторов.
> Это всё нужно держать в голове при написании даже самого просто кода.А это бывает как-то по-другому?)) Оно UB не просто так, а потому что где-то напрямую зависит от работы конкретного процессора, а где-то - реально без разницы, как оно там внутри устроено, лишь бы результат был нужный. Если же конечный результат не соответствует ожиданиям - то это уже проблема конкретной реализации, а не стандарта. Т.е., иными словами - баг, или просто недоработка.
> И на это тратится время и внимание (которое тоже ресурс) программиста.
Программист для того и существует, чтобы тратить своё время именно на такие вещи.
> О, как самоуверенно.
> Ну или у нас тут человек, который не совершает ошибок.
> Или кто-то что-то недоговаривает.
Всё куда проще. Я в своё время тоже напрыгался с подобными вещами. А потом просто выработал для себя несколько простых правил, которые позволяют подобных ошибок избегать. В частности например, "пишешь delete - дважды проверь, что именно". Пока что работает. Иными словами, смысла в Rust нет никакого на мой взгляд, потому что всё, что преподносится, как его преимущество, в С++ достигается применением определённого стиля программирования. При этом всегда остаётся возможность поступить как-то иначе, если вдруг в этом возникнет необходимость.
> Вы ушли куда-то далеко. Мы говорим про инструкции самой программы.
А какая собственно разница, что там в инструкциях программы? Меня интересует, сколько и на что будет потрачено тактов процессора. Всё. Остальное - значения не имеет никакого.
> А как вы гарантируете что к этой переменной не будет обращения с
> другого потока?
> Дайте угадаю - вы просто все продумали и пришли к выводу что
> эта ситуация невозможна? (т.е. по факту "мамой клянусь!")
Нет, на такие вещи я не полагаюсь никогда. А вот на знание, как именно работает моя программа - да, полагаюсь. И не просто так, а протестировав предварительно все возможные варианты.
> А потом Сaptain "That should never happen" strikes! Again...
> и у нас очередная уязвимость из-за гонки.
Не знаю, возможно я что-то делаю не так, но мне ещё ни разу не удалось вызвать состояние гонки. Если только специально к этому не стремился)) Понятно, что всё бывает впервые. Ну так и в Rust наверняка повылазит много приколов когда (если) его начнут массово применять. Хотя лично я очень надеюсь, что до этого не дойдёт)) Иначе говоря, не существует никакой гарантии, кроме той, что дают ваши опыт и квалификация. Независимо от ЯП. Не ошибётесь в указателях или в синхронизации потоков - ошибётесь в другом месте.
> По всем четырем?? Надо же.
> Вот тогда вам еще одна stackoverflow.com/questions/71010294/different-results-between-clang-gcc-and-msvc-for-templated-constructor-in-base-c
Насчёт трёх - не разглядел, извините. Вы бы их хоть как-то разделили что ли. По существу же вопроса - ответ в последней вашей ссылке. Там собственно сказано, что описанное поведение - это баг MSVC. Который вроде бы даже исправили уже. Т.е. тут вопрос не к стандарту, а к его реализации, как и говорил. Остальное мне разбирать лень - наверняка там будет тоже самое.
> Вы же понимаете, что личный опыт так себе аргумент.
Да, понимаю. Но вы сознательно упускаете остальную часть моего ответа, а она немного меняет смысл сказанного. В частности, я говорил, что если вы видите UB, то ничто вам не мешает его обойти. Т.е. это совершенно не аргумент. Более того, свободность стандартов в части конкретных реализаций - это скорее плюс, чем минус. Потому что позволяет из нескольких выбрать наилучшую с точки зрения поставленных задач.
>> И речь опять таки изначально шла не про С, а про С++ - просьба не менять тему.
> Да, простите. С++ники тоже не сделали такой инструмент.
> Может потому что им нравится делать, а потом исправлять уязвимости (мозила и
> хром передают).
> А может потому что они не видят в этом проблемы.
> А может задача слишком сложная с теми вольностями что позволяют плюсы.
> Кто знает.
Я думаю - из-за "они не видят в этом проблемы". Потому что это действительно так. Как уже неоднократно написал - вопрос в квалификации программистов, а не в ЯП.
> А валится оно где попало и в рандомных местах. Потому что память
> в этот момент уже испортил кто-то другой просто выйдя за границы
> буфера. И какую именно память он попортит в след. раз никто
> угадать не может. А еще это повторяется отнюдь не всегда.
> Ну удачи, расчехляйте санитайзеры.
> Несмотря на то что сейчас я не с++ программист, мне доводилось исправлять
> такие баги. И больше не хочется))
Мне тоже доводилось. Грамотное применение дебагера чаще всего помогает))
Ну и для избежания дальнейшего непонимания - резюмирую свою позицию. Rust - это по факту чуть более высокий вид абстракции, что на мой взгляд не нужно совершенно. В ядре я имею ввиду (с чего собственно весь разговор начался). Для прикладных задач - да пожалуйста, пользуйтесь сколько угодно. Это ваше личное дело. Если получится что-то годное - лично я только за. Для себя же лично особого смысла в нём не вижу - меня не напрягает внимательно проверять свои delete (за пределы массива в С++ выйти - это ещё постараться надо). Напрягает же что Rust пихают усиленно везде, где только можно и нельзя, хотя на поверку все его расписываемые достоинства оказываются не такими уж и достоинствами. Потому что всё это легко достигается в других ЯП просто применением соответствующего стиля программирования. А вот недостатки вполне просматриваются - например отсутствие стандартизации или явно бОльшее количество инструкций как на этапе компиляции, так и на этапе исполнения. Пропихивание же говорит, что это кому-то надо. Зачем? Ну... Мы сегодня живём при капитализме. Пропихивают, значит кто-то увидел свой личный денежный интерес (на самом деле там чётко понятно, кто, что и зачем, но достоверных данных у меня нет, искать - лень, поэтому будем считать это моими домыслами). Если бы это было хоть как-то оправдано с технической точки зрения - я бы ещё понял. Но в нынешнем виде - извините, но нет.
