Rewrite it in Rust - что бы ещё переписать?

Итераторы на раст и так равноценны сишным циклам там, где применимы. /thread

Ну и? Ты допустил ошибку в одном месте — в одном месте и исправишь.

Реализуй это прямой индексацией и исправлять придется везде, куда накопипастил.

Ну и? Ты допустил ошибку в одном месте — в одном месте и исправишь.

Ну да. И для индексов, и для итераторов.

Реализуй это прямой индексацией и исправлять придется везде, куда накопипастил.

Во-первых с чего это, если ошибка не связана с индексацией. Во-вторых накопипастил что? Цикл 0..len в одну строку? Или я чего-то в этой жизни не понимаю, или реально существуют люди, у которых есть проблемы, о которых я даже не догадывался. Покажите мне уже, блин, как можно было накосячить в данном случае с индексами. Вот надо заполнить массив от 0 и по возрастающей, где и что может пойти не так? А если речь идет о более сложных случаях, так я сразу писал, что согласен, что для них итераторы добро, пони и радуга.

Насколько я могу судить, абстракция контейнера редко пишется для одного единственного случая :)

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

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

У меня уже готов второй вариант с расшаренными items (правда выглядит пока страшно, надо со свежей головой будет пересмотреть, слишком много слоев получилось), а это таки уже ситуация, которую можно встретить в реальной жизни. Плюс как пример можно графы привести - ходить по нодам и удалять то, что не надо. Ну и не уесть, а показать, что придираться можно к чему угодно. К слову я до сих в легкой растеренности от того, что вот это:

for i in 0..current.len() {
    current[i] = i as i32;
}

люди оказываются могут написать неправильно и напутать тут с индексами. Ладно еще в примере с массивом, который я показывал (и который на Rust никто не сделал), там более сложная логика, не все ее поняли, но тут.

только если во время итерации контейнер поменялся

Чего без unsafe'а он никак не сможет сделать.

А что тут с индексами не так? Я тоже не понимаю.

Ну почему: с Rc оно даже скомпилируется, но в рантайме по рукам настучит

Моя модификация не требует ни дополнительных аллокаций, ни перемещения больше чем одного элемента за раз, ни работы с кучей.

Тот пример, внезапно, тоже ничего из этого не требует. Просто потому, что всё лежит на стеке и отлично инлайнится компилятором.

С Arc<RefCell<...>>? Ну так-то да, правда программа запаникует раньше, чем ей получится что-либо изменить.
Вообще, ситуация, когда что-то одно может изменяться из двух мест одновременно — эталоннейший говнокод (и заодно один из трудноотлаживамых багов).

tailgunner, который настолько не знает Rust, что даже простые вещи считает «космического масщтаба заявлениями»

Космического масштаба заявление было сделано тобой здесь: Rewrite it in Rust - что бы ещё переписать? (комментарий) - о том, что класс ошибок «выход за пределы массива» при использовании итераторов в Rust не устранен, а проигнорирован. Но дальше, вместо того, чтобы продемонстрировать выход за границу на итераторах, ты начал демонстрировать, что в них можно запутаться. Хотя с эти никто и не спорил.

А что тут с индексами не так?

«Не так» здесь то, что предлагается переписывать проход итератором на проход индексом: Rewrite it in Rust - что бы ещё переписать? (комментарий)

Космического масштаба заявление было сделано тобой здесь: Rewrite it in Rust - что бы ещё переписать? (комментарий) - о том, что класс ошибок «выход за пределы массива» при использовании итераторов в Rust не устранен, а проигнорирован

Нет, это ты так захотел прочитать, а я писал про то, что если взяли не то, то и положили не то. Разницу видишь?

я писал про то, что если взяли не то, то и положили не то.

Это пустая банальность даже для тебя. А то, что ты писал, находится по ссылке, которую я указал.

«Не так» здесь то, что предлагается переписывать проход итератором на проход индексом:

В простых случаях и для чисто системного языка, да, предлагается. Rust таким не является, внедрение его в базовую систему того же Linux или любой другой ОС не планируется (песочницы вроде Redox имеют право на жизнь, но я писал почему не будут востребованы), потому конкретно на нем можно писать как угодно. И для прикладного софта абстракции - добро, спорить не буду, и уже писал об этом.

Это пустая банальность даже для тебя. А то, что ты писал, находится по ссылке, которую я указал.

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

что там где в индексах выход за границу

Это смотря как вывернутся.

let mut i = 0;
while i < p.len() {
    println!("{} {}", i, p.at(i));
    i += 1;
}

Можно в итераторе кешировать размер, и получить такой же выход за границы.

Если контейнер меняется при проходе по нему, а не по просьбе программиста, то ССЗБ. Проблема в at, а не в индексе или итераторе.

Это смотря как вывернутся.
Можно в итераторе кешировать размер, и получить такой же выход за границы.

Согласен.

И для прикладного софта абстракции - добро, спорить не буду

Системный софт отличается от прикладного только жесткостью требований по низкому потреблению ресурсов и предсказуемости. Если комбинация язык+компилятор обеспечивает нулевую стоимость абстракций (а в Rust этого можно добиться), абстракции являются добром и для системного языка. Более того, абстракция итерации в полный рост используется в ядре Linux.

Системный софт отличается от прикладного только жесткостью требований по низкому потреблению ресурсов и предсказуемости.

В целом да, но не только. К примеру, стандартная библиотека Rust или C++ не подойдет в роли базовой, если только это не ОС чисто на С++ и Rust. Да и для библиотек общего пользования в целом не подойдут Rust и C++. Тут абстракции надо резать по максимуму. Плюс если дать людям возможность писать разными способами, то они этим будут пользоваться. Возьмем задачу с заполнением массива. Ее можно решить через for, while, рекурсию, итераторы. Предположим мы выбрали итераторы, но и тут кто-то возьмет for_each, кто-то enumerate, а кто-то windows. В то время как в С или Go (хоть он тоже не замена С) практически гарантированно будет цикл for. И за этим циклом точно не будет что-то там перегружено и подправлено. И все используемые типы очевидны.

Более того, абстракция итерации в полный рост используется в ядре Linux.

Речь идет про for each? Если да, то это скорее сахар, а не абстракция, т.к. по факту это тот же цикл от и до прямо в месте вызова и без дополнительных типов/функций. Или это о другом?

хайп про то, что программы на rust с неправильной работой с памятью не компилируются

Системный софт отличается от прикладного только жесткостью требований по низкому потреблению ресурсов и предсказуемости.

В целом да, но не только

Только.

стандартная библиотека Rust или C++ не подойдет в роли базовой, если только это не ОС чисто на С++ и Rust.

Стандартная библиотека Си тоже.

абстракция итерации в полный рост используется в ядре Linux.

Речь идет про for each?

Грепни iterator в исходниках ядра.

Зачем ты путаешь падения программы и ошибки работы с памятью?

Не надо тащить rust в web! Вы его тоже убьете.

rust - это переусложненный C с синтаксисом хуже перла, чего ему в вебе делать? Впрочем, главная задача rust (и функциональщины) - это отсасывать альтернативно мыслящих и просто школьников из мейстрима (чтобы они не мешали разработчикам, ориентированным на решение практических задач и велосипедили в других местах), поэтому в веб он, таки, доберется.

у тех, кто не боится Rust, будет свой инструмент.

rust он не для написания инструментов, он вообще не для программирования. Он для того, чтобы любители решать головоломки были отдельно, а решатели практических задач отдельно (чтобы велосипедисты не мешали разработчикам).

Но начинать новый проект на C++ в 2017-м можете только вы.

А на чем же нужно начинать новый проект в 2017-м?

Пока ни кому не удалось сделать «простой» C.

Тут все сильно зависит от понимания того, что значит «простой». Если простой в освоении, то такого, скорее всего, вообще невозможно придумать. Потому что для решения широкого круга задач нужны разные инструменты и их нужно объединить в одном языке. Если простой в использовании, то C++ достаточно простой для решения широкого круга задач на большом числе архитектур. Конечно простым в использовании C++ становиться, когда его освоишь достаточно хорошо.

А вот это уже хороший вопрос. Для прикладного/системного софта выбор довольно ограничен:

• C - говно мамонта
• C++ - слишком сложный, затраты превышают результат
• Rust - сырой, слишком низкоуровневый для GUI
• D - мёртв, зато умеет GC, что удобно для GUI
• Java - не для десктопа
• C# - полу-проприетарщина для винды
• Swift - няшка, но только для macOS
• Go - язык для одноклеточных
• веб-стек - GUI средствами разметки текста (HTML)

Что-то забыл?

C++ намного сложнее Rust, так что не подходит.

Libreoffice Writer же

«Падает» - это в данном случае не сегфолт какой-нибудь, а я говорю языку, что не хочу обрабатывать ошибку, которая может возникнуть в определённых ситуациях, и программа тогда вольна прекратить работу.

D - мёртв, зато умеет GC, что удобно для GUI

Знатный аналитик. GC как раз противопоказан для гуйни. Или ты думал что в 2017 все продолжают писать гуи на C/C++ из вредности? Раст мог бы ворваться, но его делают сектанты без связи с реальностью. Swift - наиболее адекватный язык из современных, согласен, но ябблы как всегда делают хорошо лишь для себя любимых.

в веб он, таки, доберется.

Не думаю. Вот есть пример: скала. В веб она таки добралась на волне хайпа, но не задалось там. Все потому что сложность инструмента не адекватна предметной области. Ведь что есть веб? Обертка к БД по сути, ну и много (очень много) интерфейса. Ну и в какой пень там пляски с типами или указателями? Конечно, сектанты и на хаскеле делают веб, но это такое... В общем, кроме сектантов этим пользоваться никто не захочет.

ок, есть ещё деление на ноль и другие приключения шурика.

а если рассматривать как «падение» всё, что не exit code = 0, то варианты бесчисленны.

Или ты думал что в 2017 все продолжают писать гуи на C/C++ из вредности?

На C/C++ GUI пишут только под линь, ибо только два тулкита доступно.

На винде - C#, на macOS - swift, obj-c.

Так что проблема не в GC, а в легаси.

Только.

Нет.

Стандартная библиотека Си тоже.

Собрал пустой файл на Rust (только main) без дебажной инфы. Смотрю objdump - полно функций из libc используется, pthread и пр. я в счет даже беру, именно libc. Ну а то, что стандартная библиотека С обычно используется опосредованно, так это логично, каждый язык уже наворачивает свои абстракции в своей стандартной библиотеке. Возможно потому libc и такая ограниченная - нет смысла переусложнять.

Грепни iterator в исходниках ядра.

Вот, например:

struct fib_trie_iter {
	struct seq_net_private p;
	struct fib_table *tb;
	struct key_vector *tnode;
	unsigned int index;
	unsigned int depth;
};

static struct key_vector *fib_trie_get_next(struct fib_trie_iter *iter)
{
	unsigned long cindex = iter->index;
	struct key_vector *pn = iter->tnode;
	t_key pkey;

	pr_debug("get_next iter={node=%p index=%d depth=%d}\n",
		 iter->tnode, iter->index, iter->depth);

	while (!IS_TRIE(pn)) {
		while (cindex < child_length(pn)) {
			struct key_vector *n = get_child_rcu(pn, cindex++);

			if (!n)
				continue;
...

	/* record root node so further searches know we are done */
	iter->tnode = pn;
	iter->index = 0;

	return NULL;
}

Именно такое я имел в виду, когда говорил, что итераторы подходят для сложных случаев. А для простых в ядре прекрасно используется for, причем гораздо чаще. Так что все логично - простые вещи решаются просто, сложные упрощаются.

На винде - C#

На винде пишут на чем угодно, и C# там используется не так уж и часто, особенно для сложного софта, не смотря на многолетние усилия микрософта.

Так что проблема не в GC, а в легаси.

ObjC и Swift не имеют GC (хотя кое-кто поспорил бы), а счетчики не создают проблем с отложенными удалениями, паузами для работы GC и жором памяти «на всякий случай».

C# там используется не так уж и часто

Жду ссылку на аналитику.

ObjC и Swift не имеют GC

Swift пилили для мобилок, там особо не разгуляться. Хотя Google это не остановило.

Жду ссылку на аналитику

Так все просто, выбери набор софта - аудиоплеер, видеоплеер, файловый менеджер, мессенджер, браузер, морду к СУБД и пр., и посмотри на чем оно будет. В виндовсе кто на чем горазд на том и пишет. Даже свой скайп M$ переписала на JavaScript.

Почти весь новый софт на C#, старый на чём попало.

Почти весь новый софт на C#

Жду ссылку на аналитику (с). Шучу, может и так, хотя тот новый софт, что я тыкаю иногда в виртуалке, бывает все так же на чем попало. Разве что больше стало JS гуя, и если опять говорить про MS, то они же еще и VSCode на нем сделали. И офис частично в онлайн увели.

на С# только инсталляторы вижу и конфигураторы всякие для игрулек. Хотя венды у меня целый зоопарк.

// другой аноним.

Смотрю objdump - полно функций из libc используется, pthread и пр. я в счет даже беру, именно libc

И что? Весь системный интерфейс в Unix предоставляется через libc. Ты лучше расскажи о том, как в других языках используется стандартная библиотека Си - ну, это там, где fopen. fwrite, sprintf и прочая неумирающая классика вроде setbuf.

А сделать на Rust аналог libc более чем возможно (просто никому не нужно, когда есть готовые libc в ассортименте). Точно так же можно написать Rust без использования libc, но это тоже не сильно нужно по уже указанной причине.

Именно такое я имел в виду, когда говорил, что итераторы подходят для сложных случаев

Я не знаю, что ты имел в виду, но сказал ты: «простых случаях и для чисто системного языка». Сейчас, похоже, условие сокращено до «простых случаев». Еще немного поработать над тем, что именно является «сложным случаем», и мы получим, что итераторы следует использовать как можно чаще.

Мне для пакетной обработки же. Чтобы руками открывать и сохранять в текст, я AlReader в wine использую. А вот пару десятков файлов руками довольно нудно обрабатывать.

Ты лучше расскажи о том, как в других языках используется стандартная библиотека Си - ну, это там, где fopen. fwrite, sprintf и прочая неумирающая классика вроде setbuf.

Во-первых я уже писал, что в других языках логично и даже нужно делать более удобные обертки в их стандартных библиотеках, более того разница в типах обязывает это делать, нет смысла дергать fopen с char-поинтером, когда в языке используются свои строки. Но это не отменяет факта работы с libc. Во-вторых libc - это лишь малая часть от того, что обычно предлагается. В-третьих никто не запрещает использовать тот же fopen (с ограничениями упомянутыми выше):

http://php.net/manual/ru/function.fopen.php https://dlang.org/phobos/core_stdc_stdio.html http://support.sas.com/documentation/cdl/en/lrdict/64316/HTML/default/viewer.... https://www.gnu.org/software/guile-gnome/docs/glib/html/File-Utilities.html http://www.cplusplus.com/reference/cstdio/fopen/

А сделать на Rust аналог libc более чем возможно

Да много на чем можно сделать аналог libc через сишный ABI и без всего что есть в этих языках, кто ж спорит. Будет ли такая библиотека безопасной? Нет, только если сильно просадить производительность и заставить пользователей библиотеки отказаться от указателей и использовать обертки. Будет ли она удобней? Нет, потому-что все возможности Rust в интерфейсе не используются, будет тот же С, только в профиль. И придумать ничего лучше fopen и пр. классики (с) не выйдет. Потому я и думаю, что тут тоже есть возможность для переосмысливания и улучшения.

Я не знаю, что ты имел в виду, но сказал ты: «простых случаях и для чисто системного языка». Сейчас, похоже, условие сокращено до «простых случаев»

Нет, я уже потерял нить разговора (перечитывать лень), но С я считаю системным языком, потому именно в данном случае сокращения нет.

soffice --convert-to txt document.rtf

Надо будет попробовать, спасибо.

А, ну дак это легко. Скармливать ввод макроса в конструктор нумовского бигфлоат

Ну так ТС же написал

Что бы такое небольшое Переписать на Расте™ для начала?

Речь идет про for each? Если да, то это скорее сахар, а не абстракция, т.к. по факту это тот же цикл от и до прямо в месте вызова

посмотри для примера битовый форич - это ниразу не сахар

http://elixir.free-electrons.com/linux/v4.14.3/source/include/linux/bitops.h#L40

оптимизация для ARM

https://elixir.free-electrons.com/linux/v4.14.3/source/arch/arm/include/asm/b...

А я смотрю, ты любишь каламбуры.