Здравствуйте, T4r4sB, Вы писали:
TB>Ага, конечно, надо "просто помнить" кучу правил инвалидации итераторов. TB>А ещё очень круто, когда у тебя есть проект, в котором спокойно указатели используются в качестве ключей хеш-мапы, это наверное команда не осилила гайды. Проект называется LLVM, если что.
Здравствуйте, rollcoin, Вы писали:
R>Так там автор (ученик самого Столярова) не осилил ключ компилятора -O
Он не неосилил. Он его не хочет использовать:
> Мне кажется нерепрезентативен как раз оптимизированный код, но спасибо за предложение. Поясню почему оптимизированный код мне сравнивать кажется неверным решением:
> Прежде всего, он менее ясен, часто существенно менее ясен -- разобраться и понять, как исходный код стал полученным машинным становится сложно. Поэтому и разобраться в нём становится сложней, а значит и сравнивать.
> Кроме того, тогда вместо языков мы скорее сравниваем искусство оптимизации компиляторощиков -- чего мне тоже не хотелось бы.
> Наконец -- можно и включить оптимизации, результат изменится не принципиально -- код будет всё так же больше и всё так же медленней в случае Раста, особенно в случае Раста "эталонного".
Т.е. он несёт какую-то чушь и при этом, возможно, откровенно врёт, т.к. я смотрел генерируемый Rust-ом код на итераторах и он там был ровно такой же, какой сгенерируется из обычного C++-цикла. Я думаю, что если хорошо постараться со всякими фильтрами и мапами, то можно запутать оптимизатор, но типовой код вполне себе максимально эффективный.
Здравствуйте, T4r4sB, Вы писали:
TB>в С++ приходится держать в голове кучу правил "не обращаться по этому указателю после того, как уничтожен тот буфер".
Шта? Это С но не С++
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Вот есть dlang.org
его написали два крутых чувака из мира C|C++
Причем читая книгу Александреску понимаешь что ЯП разрабатывался
именно с учетом реалий (многопоточка, перформанс и в тоже время простота программирования),
о которых он прекрасно знает из практики.
Здравствуйте, T4r4sB, Вы писали:
TB>Ага, конечно, надо "просто помнить" кучу правил инвалидации итераторов.
А зачем их вообще помнить? Не храни итераторы за пределами текущей области видимости. Не удаляй объекты из коллекции в цикле. Если следовать этим двум простым принципам ты никогда не получишь проблемы с итераторами. Ситуация когда тебе эти два правила надо нарушить невероятно редкая (я реже чем раз в год сталкиваюсь), ну и если уж случилось такое — перечитать правила инвалидации итератора для конкретного контейнера дело 5-ти минут. Это вообще ничто по сравнению с усилиями на ублажение компилятора Rust.
TB>А ещё очень круто, когда у тебя есть проект, в котором спокойно указатели используются в качестве ключей хеш-мапы, это наверное команда не осилила гайды. Проект называется LLVM, если что.
Ну бывает, проект древний, с очень серьезными требованиями к скорости. Это всяко единичный случай.
KP>Честно говоря, до усрачки их. Причем ОС на D все дохлые, а на Rust пара вполне себе развивается.
да, возможно вы правы.
но я лишь хотел сказать, что и на ди и на обероне(причем реалтайм) ОС пишутся не смотря на наличие GC.
но при этом все же они намного проще синтаксически и семантически. т.е. если нужно выжать максимум из железа по-моему проще на сях это сделать.
раст я так понимаю привлекает молодежь падкая на рекламу. если же инженер уже знает си, то ему проще написать на нем. чем учить новый сложный яп.
Здравствуйте, vaa, Вы писали:
vaa>Сколько ОС на расте написано?
А нафига?
ОС это сугубо утилитарная штука, которая нафиг не нужна без аппликух под неё.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, vaa, Вы писали:
vaa>>Сколько ОС на расте написано? CC>А нафига? CC>ОС это сугубо утилитарная штука, которая нафиг не нужна без аппликух под неё.
Rust вроде бы системный? даже протолкнули в ядро линукса.
как раз непонятно, зачем писать прикладное по на нем, если ди или даже сишапр с ее ВМ уже достаточно шустры для этого?
смысл?
Здравствуйте, vaa, Вы писали:
vaa>но при этом все же они намного проще синтаксически и семантически. т.е. если нужно выжать максимум из железа по-моему проще на сях это сделать. vaa>раст я так понимаю привлекает молодежь падкая на рекламу. если же инженер уже знает си, то ему проще написать на нем. чем учить новый сложный яп.
Не знаю починили ли в Rust главную проблему — непредсказуемые паники, но на данный момент для серьезных задач (авиация, автомобилестроение, космос) он банально не подходит. Хотя я 100% уверен что с ним было бы спокойнее писать компоненты где требуются гарантии уровня DAL-B/A или ASIL-D. Там даже можно было бы пойти на ублажение компилятора ради увеличившийся безопасности решения. Но, увы и ах, его даже Глав Пингвин забанил, ожидать что Blackberry пропустит в QNX вообще не реально
Здравствуйте, CreatorCray, Вы писали:
vaa>>Сколько ОС на расте написано? CC>А нафига? CC>ОС это сугубо утилитарная штука, которая нафиг не нужна без аппликух под неё.
Не так давно была новость про работы над POSIX-совместимой ОС, которая позоляла запускать всего одно приложение и позицировалась она построения кластеров. Не могу сейчас найти детали, к сожалению. Но в целом идея потенциально хороша, ты убираешь все левые механизмы связанные с переключением задач и оставляешь минимум. Проще с аудитом, надежностью и т.д. Аппликухи — любой POSIX, в теории.
Здравствуйте, kaa.python, Вы писали:
KP>Не так давно была новость про работы над POSIX-совместимой ОС, которая позоляла запускать всего одно приложение
Тогда это не ОС, это runtime
KP>ты убираешь все левые механизмы связанные с переключением задач и оставляешь минимум.
Ну т.е. по сути это прошивка.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, kaa.python, Вы писали:
KP>Не знаю починили ли в Rust главную проблему — непредсказуемые паники
Паники ровно в той же степени непредсказуемы как std::abort или throw 1 в сторонних библиотеках. То есть, встретиться могут и да, нет механизма контроля (с оговорками), но обычно так делать не принято. Есть некоторое количество исключений вроде доступа по индексу. Против таких методов из стандартной библиотеки помогает (изкоробочный) линтер.
Ну и проблемой была не непредсказуемость, а отсутствие возможности обработать выделение памяти. Это "починили" добавив новые функции.
Здравствуйте, kaa.python, Вы писали:
KP>Не знаю починили ли в Rust главную проблему — непредсказуемые паники, но на данный момент для серьезных задач (авиация, автомобилестроение, космос) он банально не подходит. Хотя я 100% уверен что с ним было бы спокойнее писать компоненты где требуются гарантии уровня DAL-B/A или ASIL-D. Там даже можно было бы пойти на ублажение компилятора ради увеличившийся безопасности решения. Но, увы и ах, его даже Глав Пингвин забанил, ожидать что Blackberry пропустит в QNX вообще не реально
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, T4r4sB, Вы писали:
KP>Да если бы оно работало А то выходят монстры из портянок с Box/Rc/Arc/Cell которые надо хитро использовать в разных случаях что бы компилятор остался доволен, но они еще и до кучи херят гарантии времени компиляции, добавляют кучу боли, но не делают код безопаснее куда как более простого кода на C++.
А чем это отличается от unique_ptr/shared_ptr/atomic_shared_ptr ?
Здравствуйте, DarkEld3r, Вы писали:
DE>Паники ровно в той же степени непредсказуемы как std::abort или throw 1 в сторонних библиотеках. То есть, встретиться могут и да, нет механизма контроля (с оговорками), но обычно так делать не принято. Есть некоторое количество исключений вроде доступа по индексу. Против таких методов из стандартной библиотеки помогает (изкоробочный) линтер.
Паники отключаются? Критический код не может содержать исключений (паник и всего на них похожего) и динамического выделения памяти.
Не храни итераторы за пределами текущей области видимости. Не удаляй объекты из коллекции в цикле. Если следовать этим двум простым принципам ты никогда не получишь проблемы с итераторами. Ситуация когда тебе эти два правила надо нарушить невероятно редкая (я реже чем раз в год сталкиваюсь), ну и если уж случилось такое — перечитать правила инвалидации итератора для конкретного контейнера дело 5-ти минут. Это вообще ничто по сравнению с усилиями на ублажение компилятора Rust.
