Напоминает «Здесь играем, здесь не играем, здесь рыбу заворачивали» — вот вам класс, только половина входящих туда глаголов — исключения, и спрягаются по-своему.
Сервер на Rust, там нет классического ООП с наследованием.
Общий комментарий — а всегда ли надо делать "классическое" ООП?
Если требуется просто динамический полиморфизм — хватает одноуровневой иерархии "интерфейс/трейт-реализация". Это ещё не ООП.
Ну а если требуется сложная многоуровневая иерархия… я бы подумал как свести к одноуровневому случаю. Пока не видел ни разу, чтобы многоуровневые иерархии были реально удобны.
Ооо, в винде багов тоже вагон. Например, у меня на рабочем ноуте Skype for на*Business умудрился начисто убить микрофонный вход через джек и через встроенную вебку. Работает только то что USB.
А Минт 17 у меня на личном ноуте счастливо живёт и прекрасно работает уже года три, безболезненно пережив дамп-перенос на SSD и случайно «запоротые» права на часть системных файлов.
Объясните мне одну вещь. Почему так трудно добавить маленький ROM в микруху с полным образом прошивки и каким-либо способом принудительно залить этот образ (вместе с NVRAM) в основное пространство? Псевдо-экономия? Желание рубить бабло на сервисе случайно убитых ноутов?
Да я как бы про них в курсе. Меня смущает ситуация, когда стандартная библиотека построена таким образом, что для решения созданных ею проблем требуется или писать кучу бойлерплейта, или втаскивать стороннюю библиотеку в несколько раз большего объёма. Что не всегда возможно. И никаких изменений уже лет 20 в этом направлении. ranges-v3 может и поменяют ситуацию, но последний раз когда я в них лазил, я не нашёл адапторов, аналогичных бустовским.
Ведь вы никогда мне не скажете и не покажете — где я не прав, в чём я не прав, что и почему мне нужно смотреть. Вы где-то прочитали тезис, но не можете его аргументировать, и именно поэтому как только у вас возникают проблемы — вы пытаетесь снять с себя ответственность.
По существу у вас возражения есть?
Это не более чем манипуляции. Компилятор компилирует код с unsafe? Компилирует. На это финиш.
Вы таки не понимаете, почему и для чего это сделано. Вы не понимаете, что системный язык вообще без прямой работы с памятью — не системный язык.
Это очень хорошо, когда вы не можете ничего ответить и пытаетесь делегировать эту обязанность на какие-то ссылки. Ведь я же говорю не с ссылка, а с вами.
Но для начала неплохо бы владеть предметом. А для этого надо немножко почитать.
И опять — ответов нет. К чему и что следует из этой ссылки, к чему вы её спастили и какие мои слова она опровергает — неясно. Недостаточно просто кинуть ссылку — надо связать её с контекстом и вывести следствие. У вас нет ни того, ни другого.
Эта ссылка была дана вам чтобы показать, что в С++ реализация итератора сводится далеко не к одному перегруженному оператору "++". Даже для простого InputIterator.
Категории итераторов — это расширение функционала и не более того. Если вы в расте взяли и определили, что у нас итератора есть InputIterator, то руководствуйтесь и в С++ такой же логикой. InputIterator такой же итератор — всё остальное — сверху.
В Rust нет категорий итераторов в понимании С++.
Вот опять непонятно что и непонятно к чему. Я сразу же указал, что евангелисты раста часто путают безопасность уровня языка и безопасность уровня программиста, это же касается не только безопасности.
Я даже не знаю, что на это ответить. "Безопасность уровня программиста" это как? Не давать программисту нажимать неправильные кнопки? Rust даёт определённые средства отлова и устранения определённых классов ошибок. И даёт средства локально отключать некоторые из этих ограничений — если того требует задача.
Даже предположим, что отличия есть( на самом деле тут уже подлог, ведь в С++ ссылки — это конструкции языка, а в расте — просто обёртки и сравнивать их некорректно. Я могу сделать какую угодно обёртку и назвать её ссылкой), то что из этого следует?
Эта фраза чётко говорит о том, что вы не понимаете, что такое ссылки в Rust. Уважьте, перейдите по ссылкам и прочтите.
Вы понимаете, что нельзя просто так взять и сказать «разница есть». Ведь смысл не в разнице, а в том, что из неё следует. И это следствие вы не вывели.
Смысл в разнице, т.к. из неё следует тот самый вывод. А разница в том, что в С++ ссылка не может быть перемещена и переназначена — что делает её применение сильно ограниченным. Что в Rust ссылка может менять указуемый объект, может быть перемещена и может свободно храниться в поле структуры, не "пригвождая" структуру к одному месту. И что не может пережить объект, на который указывает.
Вот и тут то же самое. Вам указали на то, что сравнивать голые указатели в С++ и ссылки в расте — некорректно. Вы поплыли в сторону «они различаются» — различаются, дальше что?
Как раз корректно. Ссылки в Rust несут ту же нагрузку, что и в С++ — и в дополнение бОльшую часть нагрузки указателей.
В целом, разговор защёл в тупик. Вы не приводите аргументов, только игнорируете либо отрицаете мои.
"Я бежала пять миль чтобы сказать вам как вы мне безразличны"
Я бы может ответил вам на ваши тезисы. Но судя по тому, как вы их подаёте, вы банально не владеете вопросом, уж простите за столь грубый пассаж. Чтобы ответить на всё это, мне пришлось бы цитировать вам главы из документации, где всё это объяснено. Держите ссылки:
никакой компилятор ничего не гарантирует и ни к чему, о чём говорилось — не имеет( это было проигнорировано), никакой компилятор ни по каким «рукам» не даст.
Гарантии выражаются в отказе компилировать код, в котором они нарушаются. Этого недостаточно?
Это всё обычная лапша и обёртки, которые есть везде, с одной лишь разницей — разделение языка на unsafe/safe, но из этого так же ничего не следует.
Изучите вопрос. Ссылки выше в комментарии.
Итератор — это интерфейс, а реализация никакого отношения к итератору не имеет. И сложность абсолютно не зависит от интерфейса. Хочешь ++ — сделай ++ в крестах, если оптимальный интерфейс реализовать не можешь. И это сложность именно оптимальности, а не крестов.
И какой бы код ты не показывай — везде ответ один «это неправильный код», при этом мы сразу же забываем о том, что «компилятор должен бить по руками» и «гарантии».
В этом топике речь если шла, то о неидиоматичном коде. И вы, кстати, ни одного примера кода не привели.
Мы берём ссылки и сравниваем их с указателями, будто бы в крестах ссылок нет. Мы сравниваем то, что удобно нам, игнорируя то, что неудобно.
Вы не могли бы развить тему по поводу thread? Когда я имел дело с Lua — coroutine/thread были моделью stackful "продолжений". При resume происходило переключение стека и выполнение участка кода до следующего yield или завершения. Но никакого планировщика не было и в помине. Т.е. выглядело как непрозрачный вызов функции. Если же Corona SDK добавляет планировщик — неясно, как происходит ожидание асинхронного результата.
В Rust точно так же есть свобода написать свою реализацию.
Не совсем понимаю вас, в чём проблема либо держать счётчик знаков и добавлять конец строки на каждом 80-м, либо просто искать позицию 80-го символа.
Разыменовывать указатели (не ссылки а именно указатели)
Вызывать unsafe функции, в т.ч. FFI
Реализовывать для типов unsafe трейты
Менять статические переменные
Нас будет интересовать в основном №1 и немножко №2, из-за операций над указателями и transmute.
Всё не совсем так, а вернее совсем не так.
А я могу сказать, что примерно так и есть. В С++ вы не можете статически гарантировать, что указатель не указывает "в молоко". Вы не можете гарантировать, что ещё жива стуктура, на которую он указывает. Имеющиеся там ссылки из-за неперемещаемости почти неюзабельны как поля структур. Так что в С++ указатели — повсеместное средство.
Все эти рассуждения сводятся к одному — мы сравниваем несравнимые вещи. Мы сравниваем кейсы с указателями, которые в расте точно так же требуют указателей, именно поэтому в stdlib через строчку unsafe.
Угу. Только потом эти указатели не будут торчать наружу. В этом отличие и есть.
По количеству — https://github.com/rust-lang/rust/search?utf8=%E2%9C%93&q=unsafe&type=
1068 вхождений просто слова. На весь проект. Натыкался где-то, что реальных использований около 200-250, но ссылку к сожалению привести не могу.
В конечном итоге раст ничем не отличается от того же stl, где никакие указатели не нужны. Единственная разница в том, что в C++ писать unsafe не надо, а в расте надо.
Отличается, причём сильно. Почитайте, какие доп. гарантии дают ссылки Rust по сравнению с его же указателями.
Есть какие-то рассуждение на тему того, что «а unsafe видно лучше», но кем лучше и почему — не сообщается. Чем его лучше видно, нежели new — неясно. Все рассуждения про «new может быть где-то спрятан» — правильно, так же как и unsafe.
Таки лучше видно, не поверите. Если у меня творится какая-то ахинея с памятью — я точно знаю, что искать. Банально глобальным поиском по проекту.
В конечном итоге раст — это просто набор обёрток, которые можно реализовать где угодно и они реализованы на С++. Никакой разницы нет. Единственная разница в том, что нужно писать unsafe — на этом разница заканчивается.
В конечном итоге они оба транслируются в ассемблер, которому на все эти новомодные штучки наплевать — он байты перекладывает. Разница есть. Либо вы прилагаете дополнительные усилия, пишете обёртки, доп. проверки, призываете статические чекеры чтобы не отстрелить себе ногу. Либо вы пишете дополнительный код, чтобы какие-то ограничения локально отменить.
Все рассуждения о том, что unsafe что-то там — не работают. Такие же рассуждения были о том, что «мы заставляем всех проверять ошибки», но почему-то добавили unwrap() и теперь весь код — это unwrap() через unwrap() и где всё эти рассуждения? А нигде. Никому они не интересны. Остались на уровне гайдлайнов, как и в С++.
Покажите мне код б-м серьёзного проекта, в котором повсюду применяется unwrap. В гайдлайнах чёрным по белому написано, что unwrap при неудаче грохнет поток. Что что частенько означает "грохнет процесс".
Ничего из этого намеренно сделано не было, никакой явности нет. Никто и никогда не расскажет о том, чем код в unsafe более явный, нежели С++. Как максимум всякие субъективные рассуждения на тему «мне так нравится», но каждый своё болото хвалит и никаких объективных предпосылок к этому нет.
Вот этот пассаж вообще не понял. Выше уже написал, что конкретно делает ансэйф.
Чего длиннее и почему — никто не расскажет и не покажет.
Ну да, для этого надо почитать код какого-нибудь контейнера на Rust и С++. Мой личный опыт — на С++, чтобы сделать всё правильно, писанины сильно больше.
В зачаточном состоянии она на расте — без unsafe ничего не напишешь.
Попробуйте написать итератор над любой нетривиальной структурй данных. С поддержкой всех нужных категорий. И сравните с как правило одним или двумя методами, которые надо реализовать для итератора на Rust. Я именно об этом.
Да, можно накастылить семантику указателя через ссылку + option, как это сделал автор, да и кто угодно сделает. Только есть нюансы — указатель хранит состояние бесплатно, а option платно. Привет оверхед по памяти 50-100% на ноду. Естественно, что в хелвордах это мало кому интересно, но это интересно за рамками оных.
Что это такое, какие тут есть проблемы — не знаю ни я, ни, скорее всего, все остальные.
Тогда зачем вообще комментируете эту часть? Если вы хотели пояснений — написали бы "Поясните". А не "Я не знаю, значит никто не знает, значит никому не нужно".
Нет, это т.н. "конструкторы типов". Грубый аналог из С++
Один из примеров использования — те самые монады. Есть более конкретные примеры, но сходу не вспомню.
Сервер на Rust, там нет классического ООП с наследованием.
Общий комментарий — а всегда ли надо делать "классическое" ООП?
Если требуется просто динамический полиморфизм — хватает одноуровневой иерархии "интерфейс/трейт-реализация". Это ещё не ООП.
Ну а если требуется сложная многоуровневая иерархия… я бы подумал как свести к одноуровневому случаю. Пока не видел ни разу, чтобы многоуровневые иерархии были реально удобны.
Как по мне — это ничего не меняет. Просто в Java будет почти всегда использоваться 2 вызова метода — и вам таки придётся изучать контекст.
Можно через кастомные типы много где сделать. Вопрос в том, что мало кто заморачивается.
А Минт 17 у меня на личном ноуте счастливо живёт и прекрасно работает уже года три, безболезненно пережив дамп-перенос на SSD и случайно «запоротые» права на часть системных файлов.
А можете кинуть ссылку, почему Firefox "никогда не будет поддерживать" этот тег? Или это вендорское MS-style расширение от Google?
Да я как бы про них в курсе. Меня смущает ситуация, когда стандартная библиотека построена таким образом, что для решения созданных ею проблем требуется или писать кучу бойлерплейта, или втаскивать стороннюю библиотеку в несколько раз большего объёма. Что не всегда возможно. И никаких изменений уже лет 20 в этом направлении. ranges-v3 может и поменяют ситуацию, но последний раз когда я в них лазил, я не нашёл адапторов, аналогичных бустовским.
Тут я пожалуй слукавил, что проблема только в std::basic_string
Там несколько проблем, связанных конкретно с С++:
<locale>и всего, что связано с нимиПо существу у вас возражения есть?
Вы таки не понимаете, почему и для чего это сделано. Вы не понимаете, что системный язык вообще без прямой работы с памятью — не системный язык.
Но для начала неплохо бы владеть предметом. А для этого надо немножко почитать.
Эта ссылка была дана вам чтобы показать, что в С++ реализация итератора сводится далеко не к одному перегруженному оператору "++". Даже для простого InputIterator.
В Rust нет категорий итераторов в понимании С++.
Я даже не знаю, что на это ответить. "Безопасность уровня программиста" это как? Не давать программисту нажимать неправильные кнопки? Rust даёт определённые средства отлова и устранения определённых классов ошибок. И даёт средства локально отключать некоторые из этих ограничений — если того требует задача.
Эта фраза чётко говорит о том, что вы не понимаете, что такое ссылки в Rust. Уважьте, перейдите по ссылкам и прочтите.
Смысл в разнице, т.к. из неё следует тот самый вывод. А разница в том, что в С++ ссылка не может быть перемещена и переназначена — что делает её применение сильно ограниченным. Что в Rust ссылка может менять указуемый объект, может быть перемещена и может свободно храниться в поле структуры, не "пригвождая" структуру к одному месту. И что не может пережить объект, на который указывает.
Как раз корректно. Ссылки в Rust несут ту же нагрузку, что и в С++ — и в дополнение бОльшую часть нагрузки указателей.
В целом, разговор защёл в тупик. Вы не приводите аргументов, только игнорируете либо отрицаете мои.
Засим откланиваюсь.
"Я бежала пять миль чтобы сказать вам как вы мне безразличны"
Я бы может ответил вам на ваши тезисы. Но судя по тому, как вы их подаёте, вы банально не владеете вопросом, уж простите за столь грубый пассаж. Чтобы ответить на всё это, мне пришлось бы цитировать вам главы из документации, где всё это объяснено. Держите ссылки:
Пара комментариев:
Гарантии выражаются в отказе компилировать код, в котором они нарушаются. Этого недостаточно?
Изучите вопрос. Ссылки выше в комментарии.
http://en.cppreference.com/w/cpp/iterator
Просвещайтесь.
В этом топике речь если шла, то о неидиоматичном коде. И вы, кстати, ни одного примера кода не привели.
http://en.cppreference.com/w/cpp/language/reference
Почитайте, чем отличается.
Вы не могли бы развить тему по поводу thread? Когда я имел дело с Lua — coroutine/thread были моделью stackful "продолжений". При resume происходило переключение стека и выполнение участка кода до следующего yield или завершения. Но никакого планировщика не было и в помине. Т.е. выглядело как непрозрачный вызов функции. Если же Corona SDK добавляет планировщик — неясно, как происходит ожидание асинхронного результата.
Выдержка по ссылке:
Два момента — двойственный тип результата и нестыкованность с итераторами. Но принципиально решаемо и, думаю, будет решаться.
Мне кажется, или вы сами себе противоречите?
Или вопрос в том, что вам нужно работать нативно с не-UTF кодировкой?
C-строки: https://doc.rust-lang.org/std/ffi/struct.CString.html, https://doc.rust-lang.org/std/ffi/struct.CStr.html
OS-строки: https://doc.rust-lang.org/std/ffi/struct.OsString.html, https://doc.rust-lang.org/std/ffi/struct.OsStr.html
Посмотрите, есть ли там то, что вам нужно.
В Rust точно так же есть свобода написать свою реализацию.
Не совсем понимаю вас, в чём проблема либо держать счётчик знаков и добавлять конец строки на каждом 80-м, либо просто искать позицию 80-го символа.
Вы интересный. Вам всё непонятно и неизвестно.
Для начала — что может Rust unsafe:
Нас будет интересовать в основном №1 и немножко №2, из-за операций над указателями и transmute.
А я могу сказать, что примерно так и есть. В С++ вы не можете статически гарантировать, что указатель не указывает "в молоко". Вы не можете гарантировать, что ещё жива стуктура, на которую он указывает. Имеющиеся там ссылки из-за неперемещаемости почти неюзабельны как поля структур. Так что в С++ указатели — повсеместное средство.
Угу. Только потом эти указатели не будут торчать наружу. В этом отличие и есть.
По количеству — https://github.com/rust-lang/rust/search?utf8=%E2%9C%93&q=unsafe&type=
1068 вхождений просто слова. На весь проект. Натыкался где-то, что реальных использований около 200-250, но ссылку к сожалению привести не могу.
Отличается, причём сильно. Почитайте, какие доп. гарантии дают ссылки Rust по сравнению с его же указателями.
Таки лучше видно, не поверите. Если у меня творится какая-то ахинея с памятью — я точно знаю, что искать. Банально глобальным поиском по проекту.
В конечном итоге они оба транслируются в ассемблер, которому на все эти новомодные штучки наплевать — он байты перекладывает. Разница есть. Либо вы прилагаете дополнительные усилия, пишете обёртки, доп. проверки, призываете статические чекеры чтобы не отстрелить себе ногу. Либо вы пишете дополнительный код, чтобы какие-то ограничения локально отменить.
Покажите мне код б-м серьёзного проекта, в котором повсюду применяется unwrap. В гайдлайнах чёрным по белому написано, что unwrap при неудаче грохнет поток. Что что частенько означает "грохнет процесс".
Вот этот пассаж вообще не понял. Выше уже написал, что конкретно делает ансэйф.
Ну да, для этого надо почитать код какого-нибудь контейнера на Rust и С++. Мой личный опыт — на С++, чтобы сделать всё правильно, писанины сильно больше.
Попробуйте написать итератор над любой нетривиальной структурй данных. С поддержкой всех нужных категорий. И сравните с как правило одним или двумя методами, которые надо реализовать для итератора на Rust. Я именно об этом.
Оптимизировано.
https://github.com/rust-lang/rust/blob/master/src/libcore/nonzero.rs
И да, известные мне реализации optional для С++ такую оптимизацию не поддерживают. Чем option+reference лучше голого указателя — отдельная тема.
Тогда зачем вообще комментируете эту часть? Если вы хотели пояснений — написали бы "Поясните". А не "Я не знаю, значит никто не знает, значит никому не нужно".