into_rust() — скринкасты по Rust. Доступно видео с RustConf 2016.

Де-факто ABI, разные для разных компиляторов. Но, лучше чем ничего, согласен.

Это элемент Command-Query Separation Principle.

Типичный оопэшный костыль.

Кроме того, для task::split может быть определено предусловие (true == this->needs_split()).

Костыли - такие костыли. Возвращать-то он что в таком случае будет?

А то ведь и исходный пример можно переписать с использованием boost::optional или std::optional (из C++17)

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

Сигнатура метода Task::split вполне ясно говорит, что можно получить или не получить новую задачу. Пару методов needs_split и split нужно явно документировать

А откуда ты, интересно, узнал какова семантика needs_split и split, если тебе об этом никто специально не говорил?)

Де-факто ABI, разные для разных компиляторов.

CodeSourcery, Compaq, EDG, HP, IBM, Intel, Red Hat, and SGI

Но, лучше чем ничего, согласен.

Люблю такие заявления. Вместо прямого «был неправ, плохо знал матчасть» начинается «лучше, согласен».

узнал какова семантика needs_split и split, если тебе об этом никто специально не говорил?

И то правда. Поэтому в С++ я спокойно могу написать:

  auto child_task = task.split();
  child_task.sleep(10);

Ну что за вопросы? Из названий функций и из примера кода приблизительно понятно что они должны делать. Но компилятор об этом не знает.

Ну что за вопросы? Из названий функций и из примера кода приблизительно понятно что они должны делать

Из оригинального то понятно)

Был не прав, есть несколько разных стандартов С++ ABI. Один из них стандартнее других. Ок?

Из оригинального то понятно)

Из кода с Option понятно не меньше.

Мда, и откуда же там видно по какой причине split может не сработать?

SIGABRT тоже можно перехватить.

Хорошо, но в общем случае, паника в расте - это не abort.

откуда же там видно по какой причине split может не сработать?

Этого не видно и в оригинальном коде.

В C++ запросто можно использовать not_null<T> и не иметь проблем, которые есть в чистом C.

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

Дальше можно спекулировать «отсутствием свободы» или «тупы юзеры/кодеры всё равно всё сделают неправильно», но это (мне) малоинтересно.

Этого не видно и в оригинальном коде.

А вот это уже просто откровенное вранье.

В общем случае даже страшно себе представить как из раста работать с юниксовыми сигналами)

static по прежнему на свой страх и риск

Да ладно?

Можно и кальку с вашего решения сделать, c usize вместо итератора.

https://play.rust-lang.org/?gist=49e1c87c14b49b20a0ee919b37b30efa&version...

Различия прям кардинальнее некуда :) А уж по уровню безопасности так на порядки... :)))

Кстати, прошу заметить, у меня deque используется, там операции удаления из середины гораздо эффективнее, чем в векторе.

Ну и зачем нужна такая безопасность?

Без GC жизни нет?

Был не прав, есть несколько разных стандартов С++ ABI.

Наверное, я чего-то не знаю, но опубликованный стандарт - один. ABI MSVC++ не опубликован и меняется с версиями компилятора.

Один из них стандартнее других.

MS?

Но компилятор об этом не знает.

Внезапно это не его работа. Это вообще библиотека какая-то реализует свою модель многопоточности. Где-то это std::thread, где-то QThread. При чем тут компилятор? Он должен «покормить собак и ничего не трогать».

Костыли - такие костыли.

Ыксперты такие ыксперты.

Возвращать-то он что в таком случае будет?

Да хоть пустую задачу, которая сразу будет в состоянии completed. Или исключение бросать.

Проблема в том, что никто существующие интерфейсы переписывать не будет

Отучаемся говорить за всех. Кроме того, boost::optional уже давным-давно доступен для использования.

А откуда ты, интересно, узнал какова семантика needs_split и split, если тебе об этом никто специально не говорил?)

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

Пытался освоить язык и просто не понял его.

Просто из любопытства: осилил ли ты С++? Scala? Haskell? Racket?

Или только С/Python? Дело не в пренебрежении к последним, если что. Просто, очевидно, что лёгкость освоения у языков разная.

Различия прям кардинальнее некуда :)

Просили сделать всё то же самое, и хотите чтобы всё получилось по другому?

Я бы так сделал: https://play.rust-lang.org/?gist=2d041efba4e6ca55ef35bef7f01b6f64&version...

Мне кажется, вы не заметили заключительное предложение:

Если у кого-то не хватает опыта писать именно на C++, то да, Rust поможет.

Давайте еще раз обозначу свою точку зрения, дабы не возникало спекуляций и разночтений:

• писать на C или в стиле C слишком опасно;
• C++ давным давно располагает средствами для упрощения себе жизни (в кои-то веки эти средства начали централизовано собирать под крышу GSL, а так у каждого они были свои). И с годами C++ становится еще безопаснее;
• Rust, что не удивительно, предлагает еще больше безопасности, чем C++;
• но плата за безопасность Rust-а — это необходимость писать на совсем другом языке, выбросив, по сути, предшествующие C++ные наработки. Где-то эта цена может быть приемлема (если есть возможность делать проекты с нуля), где-то нет;
• мой интерес состоит в том, чтобы понять, когда Rust перейдет из категории многообещающего молодого инструмента в категорию более-менее широко используемого стабильного инструмента. И перейдет ли вообще.

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

Просили сделать всё то же самое, и хотите чтобы всё получилось по другому?

Вообще-то я просил не вас :)

Но раз вы взялись, то я указал на несколько моментов, которые сильно отличают два наших варианта.

Я бы так сделал: https://play.rust-lang.org/?gist=2d041efba4e6ca55ef35bef7f01b6f64&version...

Ну отличие только в задействовании паттерн-матчинга вместо пары if-ов. Пример-то был призван продемонстрировать то, что используется только интерфейс контейнера, без погружения в потроха, т.е. без нарушения инкапсуляции. Ваше решение здесь в принципе ничем не отличается. Те же самые два вложенных цикла.

И кроме того, метод state, который может сказать, что задача завершилась, а может так же взять и разделить задачу на части (даже когда мы не хотим этого делать по тем или иным причинам) — это, мягко говоря, спорное решение.

А вот это уже просто откровенное вранье.

«Потому, что так надо» - это не причина. Вернее, причина, но её ценность в деле самодокументирования - околонулевая.

Ыксперты такие ыксперты.

Аргументация - такая аргументация.

И да, насчёт костылей я погорячился, такое может быть удобно в ряде случаев, например, когда у query «говорящее» название или когда command модифицирует объект без возврата значения. Впрочем, в таких случаях ADT тоже не помешают.

Да хоть пустую задачу, которая сразу будет в состоянии completed.

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

Или исключение бросать.

Ещё куда не шло, но тогда кроме заботы о, собственно, проверке needs_split придётся озаботиться ловлей исключения.

Отучаемся говорить за всех.

Видимо, я говорил за тебя, ибо

boost::optional уже давным-давно доступен для использования.

но в твоём сферическом АПИ тасков его и близко нет.

И кроме того, метод state, который может сказать, что задача завершилась...

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

новые проекты предпочитают начинать на других языках

Из последнего: 1. Гугл начал операционку делать, основанную на LK embedded kernel на Си. https://en.wikipedia.org/wiki/Google_Fuchsia 2. Новую интересную ось представили на днях на С++ : http://www.includeos.org/

Более того, популярные и известные проекты на Расте забрасываются своими авторами:

Glium - биндинги в OpenGl. Одна из причин - автор накосячил с проектированием, проще переписать. https://users.rust-lang.org/t/glium-post-mortem/7063/1

Zinc.rs - разработка на Расте под ембед. Среди причин: код стал слишком сложный для поддержки, проблемы с кросс-компиляцией https://users.rust-lang.org/t/zinc-mini-post-mortem/7079

Менять во время обхода - завязываться на реализацию (ничего не сломается) => нарушение инкапсуляции

А если эта гарантия в документации прописана?

Вы можете не верить, но С++ доживает свой век... новые проекты предпочитают начинать на других языках.

Это совершенно точно не так. Правда не знаю хорошо ли это или нет.

И да, насчёт костылей я погорячился

Т.е. делать вбросы на счет костылей — это нормально, а в уровне аргументации виноват я. Неплохо так устроились.

но в твоём сферическом АПИ тасков его и близко нет.

А он там и не нужен. Есть needs_split, который, например, говорит, что задача слишком «жирная» и ее можно попробовать порезать на кусочки. И есть split, который задачу на кусочки режет.

Пользователь, если хочет побыстрее обработать жирные задачи, может дергать needs_split. И, если находит жирную и имеет вычислительные ресурсы, то может дернуть split.

Пример с boost/std::optional был показан «для коллекции», мол, не только в Rust-е есть Optional<Box<>>.

А вот и еще свежее: http://www.opennet.ru/opennews/art.shtml?num=45285 Причем внутрях там вполне себе современный C++.

Этот метод state - вообще порнография какая-то. Либо он сообщает состояние, либо меняет его, причём что именно он сделает неизвестно. Предыдущий вариант со split_if_needed был куда лучше, только назвать его надо было правильно, а не прикидываться, что работаешь с неизмененным интерфейсом.

Вы можете не верить, но С++ доживает свой век

Настало время офигительных историй.

Люблю такие заявления. Вместо прямого «был неправ, плохо знал матчасть» начинается «лучше, согласен».

Так ведь этот стандарт существует параллельно стандарту С++. И комитет может принять такие изменения, которые заставят поломать сложившиеся соглашения. Разве нет?

в уровне аргументации виноват я

Именно. Я позволил себе излишнюю эмоциональность, но на личности не переходил.

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

Почему тогда было не назвать метод, например, too_fat? Сомневаюсь, что тогда возникли бы какие-то вопросы.

Просто в коде вида

if (нужно_сделать()) {
    сделай();
}

подход с query/command выглядит несколько костыльно.

В общем случае даже страшно себе представить как из раста работать с юниксовыми сигналами)

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

Но какое это имеет отношение к панике?

Я позволил себе излишнюю эмоциональность

Вы себе явно хотите позволять больше, чем другим.

Почему тогда было не назвать метод, например, too_fat?

Т.е. разделение на query/command внезапно перестало быть ООП-ным костылем? Претензии уже только к имени query-метода?

Если у кого-то не хватает опыта писать именно на C++, то да, Rust поможет.

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

В остальном же, мы более-менее сходимся во мнении, разве что я (что, наверное, очевидно) более положительно отношусь к расту.

Не думаю, что в плане освоения (более-менее нормального) раст сильно проще.

Я не говорил, что Rust-проще. Речь про то, что Rust заставит обращать внимания на вещи, которые в C++ можно пустить на самотек и отгрести проблем. Т.е. в C++нужна самодисциплина и опыт (подкрепленная чем-то вроде clang-analyzer или coverity). А в Rust-е придется удовлетворять компилятор.

Тем не менее, C++ позволяет писать вполне безопасный код.

Т.е. разделение на query/command внезапно перестало быть ООП-ным костылем?

Когда ты вместо рассказа про безграничную пользу query-методов перешёл на личности, а я снизил толщину до:

«такое может быть удобно в ряде случаев, например, когда у query «говорящее» название или когда command модифицирует объект без возврата значения.»

и

«Просто в коде вида if (нужно_сделать()) сделай(); подход с query/command выглядит несколько костыльно.»

Впрочем, учитывая частоту, с которой я встречаю приведённый код, первоначальное заявление видится мне не столь далёким от истины.

Тем не менее, C++ позволяет писать вполне безопасный код.

С тоже, но далеко не каждого плюсовика заставишь на нём писать.

Это же LOR, тут все ходы записаны: www.linux.org.ru/add_comment.jsp?topic=12923462&replyto=12930391

Вы начали раскидывать костыли еще до того, как я успел что-либо сказать в ваш адрес.

Ну вот как на C сделать аналог not_null<T>?

автор накосячил с проектированием, проще переписать.

Ну, если почитать пост мортем, то автор надеялся создать универсальную обёртку, что невозможно, учитывая различия реализаций и косяки драйверов opengl. Пичалька, но rust здесь не причём.

Тем не менее, C++ позволяет писать вполне безопасный код.

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

Вы начали раскидывать костыли еще до того, как я успел что-либо сказать в ваш адрес.

Я закончил их раскидывать до того, как ты привёл к ним контраргументы.

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

Несколько, видимо, как раз потому, что с общим случаем проблемы.

Но какое это имеет отношение к панике?

Это имеет отношение именно к сигналам и к вот этому вот RFC (который «и ныне там»): https://github.com/rust-lang/rfcs/issues/1368

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

Нет, речь не про это. C++ позволяет делать это так же легко, а C - нет.