> Не передергивайте. Мы сравниваем потенциальные плюсы и минусы замены сишки на один
> из двух языков.
> Мы как раз не хотим попасть в каменный век из-за одного залетевшего
> дятла.Так не я передёргиваю, а вы. Речь шла о том, что в С++ большой объём документации. Или я вас неправильно понял? Тогда - поясняйте, что имеете ввиду.
> Нет, инструкции разные.
Интересно, каким образом. Или я чего-то не знаю о работе процессоров?))
> Просто чтобы добиться эквивалентного кода в с++ вы напр.
> должны присвоить переменной null после освобождения памяти, чтобы потом не
> сделать double free.
Зачем? Я просто ничего не буду присваивать. Совершенно сознательно. И, затем, совершенно сознательно не сделаю double free. Как раз сэкономив те самые такты процессора. Что на компиляции, что во время исполнения.
> То что вы так написали выше совсем не значит что инструкции одни
> и те же))
Ну т.е. один и тот же процессор способен выполнять... непредусмотренные изначально инструкции? О_о
> это рантайм сущность. В расте они тоже есть.
> Но вам ничего не мешает в с++ читать и писать с любого
> потока просто в переменную.
> Ну будет пару рейсов, делов-то.
> А раст это не позволит - будет ошибка компиляции, где вам прозрачно
> намекнут что "или ты ошибся, или используй соответствующие примитивы синхронизации"
Ну и? Где нужно, я совершенно сознательно использую std::atomic или std::mutex и иже с ними. При этом опять же совершенно сознательно, где нужно (а бывает и такое), для ускорения работы не буду использовать примитивы синхронизации. Зачем мне лишние проблемы с слишком "умным" компилятором и лишние нагромождения скомпилированных инструкций?
> Ну чего же вы так! Мне не сложно привести примеры))
> codeproject.com/Questions/5331052/Cplusplus-different-output-on-different-compilers
> learn.microsoft.com/en-us/answers/questions/119430/different-results-in-different-compilers-c
> stackoverflow.com/questions/5158014/why-do-different-c-compilers-give-different-results-for-this-code
> qna.habr.com/q/1320980
> ru.stackoverflow.com/questions/1508112/%D0%9F%D0%BE%D1%87%D0%B5%D0%BC%D1%83-%D1%80%D0%B5%D0%B7%D1%83%D0%BB%D1%8C%D1%82%D0%B0%D1%82-%D1%80%D0%B0%D0%B7%D0%BD%D1%8B%D0%B9-%D0%BF%D1%80%D0%B8-%D0%BE%D0%B4%D0%B8%D0%BD%D0%B0%D0%BA%D0%BE%D0%B2%D1%8B%D1%85-%D1%81%D1%82%D0%B0%D0%BD%D0%B4%D0%B0%D1%80%D1%82%D0%B0%D1%85-%D1%8F%D0%B7%D1%8B%D0%BA%D0%B0-%D0%A1
> и тыщщи их
По вашей ссылке - пустота.
> А всё потому, что в распрекрасный стандарт с++ напихали undefined behaviour и
> implementation defined behaviour.
Что-то я их там особо не видел, за исключением тех случаев, когда речь идёт о работе того, что напрямую завязано на особенности железа. Это раз. А два - собственно, в чём проблема то? Ну раз поведение не определено, значит нужно действовать по-другому. У меня за плечами уже не одна сотня тысяч строк кода на С++, и что-то каких-то особых проблем с этим я не видел. Т.е. - это очередная маркетинговая уловка, не более того.
> Насколько я знаю - нет.
> gccrs только разрабатывают и он еще не релизился.
> mrustc еще не релизился и это не generic compiler, а просто чтобы
> бустрапит раста.
> Ferrocene просто надстройка для rustc.
Ну... Я под Rust не писал и не собираюсь, так что вам виднее. Но gccrs на сколько я знаю, может и не готов для "повседневного" использования, но в принципе уже рабочий.
> Значит у сишников нет желания?))
Именно так. Любой ЯП - это просто инструмент. Как вы его используете, зависит полностью от вас. И речь опять таки изначально шла не про С, а про С++ - просьба не менять тему.
> Да, но проверка будет занимать напр. 1000 строк кода. И проверять сотни
> тысяч строк с одинаковым качеством.
> А теперь посади погромиста вычитывать 100к сорцов. Посмеемся))
А чего смеяться то? Можно и не вычитывать, а запустить и посмотреть - где валится. И работать уже по месту. Тем более, что тестировать всё равно надо, независимо от ЯП. Или вы валите всё в релиз без тестирования?))
