А какая вообще связь между безопасностью и GC? GC имитирует систему с бесконечной памятью и больше ничего не делает. Возможны, теоретически, любые комбинации с GC/без GC и опасно/беозпасно.
Здравствуйте, Sharowarsheg, Вы писали:
S>И тогда это будет совершенно безопасно
Простите, что встреваю, но у меня уже глаз дергается от настолько вольного использования этого слова =/ Не будет "совершенно безопасно". Будет "типо-безопасно", в лучшем случае. До "совершенно" там еще как до луны
Здравствуйте, Sharowarsheg, Вы писали:
S>GC имитирует систему с бесконечной памятью и больше ничего не делает.
Как следствие, существенно упрощает прикладной код. А эти ребята ИМХО перемудрили. Я с бОльшим удовольствием к доброму старому C (без плюсов) вернулся бы. Ковырял как раз на днях сорцы кое-какие — и глядя на до байта и до такта вылизанный код, резко вспомнил всю попаболь, которую испытывал, переходя на всю эту managed-муть.
Здравствуйте, dimgel, Вы писали:
S>>GC имитирует систему с бесконечной памятью и больше ничего не делает. D>Как следствие, существенно упрощает прикладной код. А эти ребята ИМХО перемудрили.
Нет, в Rust как раз оптимум. Я недавно переписал свой проект с С++ на Rust — получилось очень красиво.
Здравствуйте, Sharowarsheg, Вы писали:
S>Не обязательно. Например, можно требовать, чтобы вся память была или статическая или в стеке. Или просто статическая. И типизированная. И тогда это будет совершенно безопасно — все переменные известны на этапе компиляции.
Можно, но ничего сильно интересного написать так не получится.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sharowarsheg, Вы писали:
S>>А какая вообще связь между безопасностью и GC? GC имитирует систему с бесконечной памятью и больше ничего не делает. Возможны, теоретически, любые комбинации с GC/без GC и опасно/беозпасно. C>Если нет GC, то память нужно освобождать руками (с той или иной степенью автоматизации). А это небезопасно в современных распространённых языках без GC.
В C++, используя только смартпоинтеры+RAII (без обычных поинтеров, адресной арифметики и unsafe cast) можно получить гарантии, фактически без ручного управления памятью и фактически без GC.
Здравствуйте, VladD2, Вы писали:
C>>Нет, в Rust как раз оптимум. Я недавно переписал свой проект с С++ на Rust — получилось очень красиво. VD>Насколько сложно возиться с их таймлайами на практике?
Немного многословно получается везде аннотации ставить, изменения в языке скоро это упростят. Сама концепция С++-нику сразу же понятна, многие так примерно уже и писали многие годы.
Понятно, что для чего-нибудь типа вебсайта или учётной программы — смысла во всём этом нет.
VD>Были ли в проекте графы или другие сильно связанные структур которые невозможно разместить в стеке? Если были, то каков их процент? И насколько с ними пришлось повозиться?
Проект очень хорошо лёг на обычные иерархические функциональные структуры. Немногие места, где нужно было делать кольцевые ссылки, прекрасно решились с помощью явных RWArc.
Изначально я пробовал писать в Erlang'овском стиле, где разделяемые данные представлены "серверами", с которыми идёт работа через каналы сообщений. Но потом оказалось, что это не особо нужный оверхед (в плане кода) и проще делать обычные методы, использующие явную блокировку.
В итоге, небезопасный код получился только в FFI-обёртке для libcurl, что вполне ожидаемо. Когда начинал писать, ещё не было нормального родного HTTP-клиента для Rust, возможно эту часть перепишу.
VD>Результат и оригинал можно увидеть?
Немножно устаревший оригинал: https://github.com/moleculo/extreme-s3 , новый результат выложу чуть позже.
В общем, прекрасный язык для системного кода, который должен работать с минимумом внешних зависимостей и интероперировать с C/C++. Сильная типизация и нормальные generic'и помогают писать без тонны юнит-тестов для проверки типов (что сильно достаёт в Python). Синтаксис очень простой, особенно после выкидывания из языка магических значков типа @.
Есть зачатки поддержки нормального autocompletion'а: https://github.com/phildawes/racer Так как разбор языка делается просто, то в будущем поддержка со стороны инструментов типа JetBrains или Eclipse должна делаться без особых проблем.
Из недостатков — сейчас пока очень сильно эволюционирует система исключений. Изначально язык планировался более Erlang-like и fail'ы были ограничены границами задач, но сейчас задачи становятся менее центральными. Будет интересно посмотреть до чего доэволюционируют, так как сейчас исключения бесполезны.
Ну и ещё я начинал делать в тот момент, когда в язык вводились DST (Dynamically Sized Types) и вёлся рефакторинг стандартной библиотеки. С вполне понятными последствиями в виде постоянно ломающегося кода.
Здравствуйте, gandjustas, Вы писали:
C>>Поможет от большинства проблем, так как язык заставляет использовать блокировку для доступа к разделяемым данным. G>Блокировка это далеко не всегда хорошо. Например есть разделяемый dictionary. При конкурентном доступе что блокировать? G>Если весь dictionary, то это ударит по быстродействию. Если нужны частичные Reader-Writer Lock, то как поможет язык?
Очевидно, с помощью RW-блокировок: http://winningraceconditions.blogspot.com/2012/09/rust-4-typesafe-shared-mutable-state.html
G>>>Владение есть и в C++ — unique_ptr и move. C>>В С++ нет borrow checker'а. G>Приведи пример чтоли, где разница. http://smallcultfollowing.com/babysteps/blog/2013/06/11/data-parallelism-in-rust/
Здравствуйте, Cyberax, Вы писали:
S>>А какая вообще связь между безопасностью и GC? GC имитирует систему с бесконечной памятью и больше ничего не делает. Возможны, теоретически, любые комбинации с GC/без GC и опасно/беозпасно. C>Если нет GC, то память нужно освобождать руками (с той или иной степенью автоматизации). А это небезопасно в современных распространённых языках без GC.
Не обязательно. Например, можно требовать, чтобы вся память была или статическая или в стеке. Или просто статическая. И типизированная. И тогда это будет совершенно безопасно — все переменные известны на этапе компиляции.
Здравствуйте, dimgel, Вы писали:
D>Здравствуйте, AlexRK, Вы писали:
s22>>>Почитал и понял, что мало кто готов на таком писать.....
ARK>>С чего вы взяли выделенное?
D>Шо, ваще никто?!
Здравствуйте, Иван Дубров, Вы писали:
S>>А какая вообще связь между безопасностью и GC? GC имитирует систему с бесконечной памятью и больше ничего не делает. Возможны, теоретически, любые комбинации с GC/без GC и опасно/беозпасно.
ИД>Ещё система с GC гарантирует отсутсвие ссылок на "освобождённые" куски памяти и на случайные объекты.
Да нет, в общем-то. Напиши unsafe() и гарантии кончаются.
Здравствуйте, Sharowarsheg, Вы писали:
ИД>>Ещё система с GC гарантирует отсутсвие ссылок на "освобождённые" куски памяти и на случайные объекты.
S>Да нет, в общем-то. Напиши unsafe() и гарантии кончаются.
Ну это никак не противоречит тому, что я сказал. Не пиши unsafe -- будут гарантии. Без GC утверждение превратится в "не освобождай память -- будут гарантии", что довольно сильно сужает тип решаемых задач.
G>В C++, используя только смартпоинтеры+RAII (без обычных поинтеров, адресной арифметики и unsafe cast) можно получить гарантии, фактически без ручного управления памятью и фактически без GC.
Смарт-пойнтеры это простейший ref-counting GC. И, кстати, с ними можно нарваться на почти все недостатки GC.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Я именно это и сказал. "Как до Луны" — это общепринятое сокращение от "как до Луны на тракторе", вообще-то.
Я лишь дополнил, что это относится в том числе и к "безопасным языкам с GC", а не только к C++ с верификатором обеспечивающим отсутствие растерла памяти.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, D. Mon, Вы писали:
DM>>Однако что мозилловцы, что гуглохромовцы пришли к осознанию, что в реальности это не работает. Одни вон Rust стали изобретать, другие мигрировать на GC.
EP>Для каких задач? Случайно не interop?
Да по сути ни для каких. Потому что Firefox периодически падает, а для Windows каждый месяц закрывают уязвимости. Можно это, конечно, назвать "работает" (и по факту оно действительно бОльшую часть времени работает, вот сейчас я пишу из Firefox, например), но люди хотят идти дальше.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Я про "другие мигрировать на GC"
В Хроме (да и не только в хроме) — есть разные кучи объектов — V8 (JS) и DOM. Все они — бывает так — что изрядно ссылаются друг на друга, и по сути через прокси, с тем или иным способом пиннинга с обоих сторон. В итоге можно создавать ситуации, в которых память гарантированно не будет высвобождаться GC V8 и/или DOM. Кроме того сам код рендера изрядно страдает переусложнением. Поэтому появилось мнение, что переход на новый GC, а так же соединение этих куч — даст более хороший результат. Попутно обещают не только улучшить производительность, но и сделать код стабильнее/безопаснее. Это вкратце. Я что-то мог уже подзабыть, поэтому если интересно можно поискать что-то начиная отсюда http://www.chromium.org/blink/blink-gc и по ключевому слову oilpan. По моему где-то была презентация.
Здравствуйте, gandjustas, Вы писали:
G>thread safety не достигается одной концепцией владения. Владение лишь позволяет избавится от "случайных" гонок. Но когда данные разделяемые владение не поможет.
Поможет от большинства проблем, так как язык заставляет использовать блокировку для доступа к разделяемым данным.
G>Владение есть и в C++ — unique_ptr и move.
В С++ нет borrow checker'а.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>thread safety не достигается одной концепцией владения. Владение лишь позволяет избавится от "случайных" гонок. Но когда данные разделяемые владение не поможет. C>Поможет от большинства проблем, так как язык заставляет использовать блокировку для доступа к разделяемым данным.
Блокировка это далеко не всегда хорошо. Например есть разделяемый dictionary. При конкурентном доступе что блокировать?
Если весь dictionary, то это ударит по быстродействию. Если нужны частичные Reader-Writer Lock, то как поможет язык?
G>>Владение есть и в C++ — unique_ptr и move. C>В С++ нет borrow checker'а.
Приведи пример чтоли, где разница.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Выше было заявлено, что 'GC гарантирует отсутсвие ссылок на "освобождённые" куски памяти и на случайные объекты.' EP>Я же привёл пример, который показывает что для ресурсов гарантии намного слабее (при необходимости prompt finalization).
Так про это и разговора не было.
EP>А вот как реализовать нечто подобное на C#? Где тут ставить using'и?
Action<object> make_clojure(FileStream f)
{
return x => f.Write(x);
}
Action<object> fire(FileStream f)
{
var f = make_clojure(f);
f("continuing");
return f;
}
void Main()
{
using (var f = new FileStream("log.txt"))
{
f("starting");
var log = fire(f);
log("Elbereth");
log(42);
}
}
Вообще, за эквилибристику с ресурсами надо вырывать все, что можно.
Ибо нечитаемый говнокод.
EP>Через "неопределённое поведение" ISO даёт полную волю реализациям на самодеятельность. EP>Конкретные реализации вполне имеют право определять это поведение как им захочется. Это может быть хоть то же самое исключение, а может даже диагностика в compile-time (для некоторых случаев) — что определённо лучше чем runtime исключение.
Прошу прощения, но это полная ерунда. Чистое натягивание совы на глобус.
Вы видели в природе ПО, которое написано в расчете на исключения в случае неопределенного поведения?
Существуют ли такие компиляторы вообще?
Если фантазировать, то можно много чего нафантазировать. Например, что язык C# не допускает ошибок переполнения. Просто компилятор такой пока не написан, но написать его можно.
Здравствуйте, Sharowarsheg, Вы писали:
S>А какая вообще связь между безопасностью и GC? GC имитирует систему с бесконечной памятью и больше ничего не делает. Возможны, теоретически, любые комбинации с GC/без GC и опасно/беозпасно.
Если нет GC, то память нужно освобождать руками (с той или иной степенью автоматизации). А это небезопасно в современных распространённых языках без GC.
Здравствуйте, Sharowarsheg, Вы писали:
S>А какая вообще связь между безопасностью и GC? GC имитирует систему с бесконечной памятью и больше ничего не делает. Возможны, теоретически, любые комбинации с GC/без GC и опасно/беозпасно.
Ещё система с GC гарантирует отсутсвие ссылок на "освобождённые" куски памяти и на случайные объекты.
Здравствуйте, Иван Дубров, Вы писали:
ИД>>>Ещё система с GC гарантирует отсутсвие ссылок на "освобождённые" куски памяти и на случайные объекты. S>>Да нет, в общем-то. Напиши unsafe() и гарантии кончаются.
ИД>Ну это никак не противоречит тому, что я сказал. Не пиши unsafe -- будут гарантии.
Это ты в кучу смешал опять GC и гарантии. Не пиши unsafe — гарантии будут, но они будут независимо от того, есть ли GC или нет.
Равно как если GC есть, всё равно можно написать unsafe, и тогда будет GC, но без гарантий.
Система с GC гарантирует отсутствие ссылок на всякий мусор (это если unsafe не писать), но, скажем, система вообще без ссылок гарантрует отсутствие ссылок на всякий мусор уж точно не хуже. На фортране, кстати, я пару лет решал всякие задачки численные, и ссылками не пользовался вообще. Я даже не уверен до сих пор, есть ли в фортране вообще понятие указателя. Так вот, вполне естественно, ни разу ни одной проблемы с памятью — безо всякого GC.
ИД> Без GC утверждение превратится в "не освобождай память -- будут гарантии", что довольно сильно сужает тип решаемых задач.
Здравствуйте, Sharowarsheg, Вы писали:
ИД>>Ну это никак не противоречит тому, что я сказал. Не пиши unsafe -- будут гарантии.
S>Это ты в кучу смешал опять GC и гарантии. Не пиши unsafe — гарантии будут, но они будут независимо от того, есть ли GC или нет.
Нет, не независимо. Если в C коде есть, скажем, free, то потенциально может возникнуть ситуация, когда ссылка будет указывать на мусор. С GC такое невозможно (ну, с ограничениями, что нет unsafe, и.т.д).
S>Равно как если GC есть, всё равно можно написать unsafe, и тогда будет GC, но без гарантий.
Это да.
S>Система с GC гарантирует отсутствие ссылок на всякий мусор (это если unsafe не писать), но, скажем, система вообще без ссылок гарантрует отсутствие ссылок на всякий мусор уж точно не хуже.
Да, но опять же, класс решаемых задач сильно сужается (или стоимость растёт).
ИД>> Без GC утверждение превратится в "не освобождай память -- будут гарантии", что довольно сильно сужает тип решаемых задач.
S>Сужает или нет, это совершенно второе дело.
Если это второе дело, то воробще непонятно, как можно обсуждать какие-либо свойства языков или платформ. Для пустого множества задач, всё будет хорошо независимо от языка.
Короче, я не очень понимаю, с чем тут можно спорить. Грубо говоря, с позиции математики, для некоторого класса задач для систем с GC можно статически доказать, что не будет обращений по битым указателям, без GC, в общем случае, -- нельзя.
Здравствуйте, Cyberax, Вы писали:
S>>Не обязательно. Например, можно требовать, чтобы вся память была или статическая или в стеке. Или просто статическая. И типизированная. И тогда это будет совершенно безопасно — все переменные известны на этапе компиляции. C>Можно, но ничего сильно интересного написать так не получится.
Ну, фортран 77 был не так уж плох. Этюдов, конечно, не попишешь, но для работы хватало.
Здравствуйте, dimgel, Вы писали:
D>Я с бОльшим удовольствием к доброму старому C (без плюсов) вернулся бы. Ковырял как раз на днях сорцы кое-какие — и глядя на до байта и до такта вылизанный код,
Heartbleed и прочее байтогрызиков ничему не учит, я смотрю...
S>>Это ты в кучу смешал опять GC и гарантии. Не пиши unsafe — гарантии будут, но они будут независимо от того, есть ли GC или нет.
ИД>Нет, не независимо. Если в C коде
А почему именно C код? Возьми, скажем, бейсик-код, или фортран-код.
ИД>есть,скажем, free,
нету
ИД>то потенциально может возникнуть ситуация, когда ссылка будет указывать на мусор. С GC такое невозможно (ну, с ограничениями, что нет unsafe, и.т.д).
и с фортраном невозможно, с ограничением, что это F77.
ИД>>> Без GC утверждение превратится в "не освобождай память -- будут гарантии", что довольно сильно сужает тип решаемых задач.
S>>Сужает или нет, это совершенно второе дело.
ИД>Если это второе дело, то воробще непонятно, как можно обсуждать какие-либо свойства языков или платформ.
Ну как, тетрис написать достаточно и на луну слетать тоже можно без указателей.
Здравствуйте, -n1l-, Вы писали:
N>Здравствуйте, Don Reba, Вы писали:
DR>>В кои-то веки рад переводу, ибо оригинал ужасающе неграмотен.
N>Примеры неграмотности можно?
Style. "Pitfalls, of which the user should be aware."
> These aren’t problems with Rust but rather differences from what people are commonly familiar with, restrictions that may seem arduous at first but ultimately give you more power, at a small cost.
"From that, with which people are commonly familiar."
Unnecessary comma before "at a small cost."
Switch from third person to first person.
> The version of Rust latest confirmed to work for this post is Rust 0.12.
"The latest version of Rust."
> If anything has broken with it, please contact me.
"If anything is broken with it" or "if anything has become broken since then."
> You might write it like this which follows, for example, a way that works fine.
Missed comma before "which." Run-on sentence. Terrible phrasing.
"You might write it like the following example, which works fine."
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Cyberax, Вы писали:
C>>Здравствуйте, Sharowarsheg, Вы писали:
S>>>А какая вообще связь между безопасностью и GC? GC имитирует систему с бесконечной памятью и больше ничего не делает. Возможны, теоретически, любые комбинации с GC/без GC и опасно/беозпасно. C>>Если нет GC, то память нужно освобождать руками (с той или иной степенью автоматизации). А это небезопасно в современных распространённых языках без GC.
G>В C++, используя только смартпоинтеры+RAII (без обычных поинтеров, адресной арифметики и unsafe cast) можно получить гарантии, фактически без ручного управления памятью и фактически без GC.
Здравствуйте, kochetkov.vladimir, Вы писали:
S>>И тогда это будет совершенно безопасно KV>Простите, что встреваю, но у меня уже глаз дергается от настолько вольного использования этого слова =/ Не будет "совершенно безопасно". Будет "типо-безопасно", в лучшем случае. До "совершенно" там еще как до луны
При формальной трактовке "совершенно безопасно" недоступно для любых языков полных по Тьюрингу
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Sharowarsheg, Вы писали:
S>>И тогда это будет совершенно безопасно
KV>Простите, что встреваю, но у меня уже глаз дергается от настолько вольного использования этого слова =/ Не будет "совершенно безопасно". Будет "типо-безопасно", в лучшем случае. До "совершенно" там еще как до луны
Совершенно безопасно в смысле "если захочется, то можно сделать не хуже, чем в С#"
Здравствуйте, s22, Вы писали:
G>>В C++, используя только смартпоинтеры+RAII (без обычных поинтеров, адресной арифметики и unsafe cast) можно получить гарантии, фактически без ручного управления памятью и фактически без GC.
s22>В многопоточном режиме?
Да, стандартные смартпоинтеры потокобезопасны, как утверждает МСДН.
От состояния гонок в коде приложения ни смартпоинтеры, ни GC не спасает.
Здравствуйте, hi_octane, Вы писали:
G>>В C++, используя только смартпоинтеры+RAII (без обычных поинтеров, адресной арифметики и unsafe cast) можно получить гарантии, фактически без ручного управления памятью и фактически без GC. _>Смарт-пойнтеры это простейший ref-counting GC. И, кстати, с ними можно нарваться на почти все недостатки GC.
Это философский вопрос — считать смартпоинтеры GC или нет.
Но сути не меняет. Можно в языке C++ выделить safe подмножество, хотя в самом языке нет никакого GC.
И в других языка, без встроенного GC, можно выделить Safe подмножество с помощью конструкций, аналогичных смартпоинтерам.
Здравствуйте, gandjustas, Вы писали:
G>Это философский вопрос — считать смартпоинтеры GC или нет.
Страуструп, их отец, прямым текстом говорит, что это "a form of garbage collection".
G>Но сути не меняет. Можно в языке C++ выделить safe подмножество, хотя в самом языке нет никакого GC.
Однако что мозилловцы, что гуглохромовцы пришли к осознанию, что в реальности это не работает. Одни вон Rust стали изобретать, другие мигрировать на GC.
Здравствуйте, D. Mon, Вы писали:
DM>Однако что мозилловцы, что гуглохромовцы пришли к осознанию, что в реальности это не работает. Одни вон Rust стали изобретать, другие мигрировать на GC.
Здравствуйте, D. Mon, Вы писали:
G>>Но сути не меняет. Можно в языке C++ выделить safe подмножество, хотя в самом языке нет никакого GC. DM>Однако что мозилловцы, что гуглохромовцы пришли к осознанию, что в реальности это не работает. Одни вон Rust стали изобретать, другие мигрировать на GC.
В реальности куча других причин, кроме type-safety и memory-safety.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
DM>>Однако что мозилловцы, что гуглохромовцы пришли к осознанию, что в реальности это не работает. Одни вон Rust стали изобретать, другие мигрировать на GC. EP>Для каких задач? Случайно не interop?
Для каких задач делают Rust? Вы действительно это хотели спросить, на форуме, в 2014 году?
Здравствуйте, D. Mon, Вы писали:
DM>>>Однако что мозилловцы, что гуглохромовцы пришли к осознанию, что в реальности это не работает. Одни вон Rust стали изобретать, другие мигрировать на GC. EP>>Для каких задач? Случайно не interop? DM>Для каких задач делают Rust? Вы действительно это хотели спросить, на форуме, в 2014 году?
Здравствуйте, gandjustas, Вы писали:
DM>>Однако что мозилловцы, что гуглохромовцы пришли к осознанию, что в реальности это не работает. Одни вон Rust стали изобретать, другие мигрировать на GC. G>В реальности куча других причин, кроме type-safety и memory-safety.
Ещё есть thread safety, который Rust тоже помогает решать за счёт концепции владения.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
DM>>>Однако что мозилловцы, что гуглохромовцы пришли к осознанию, что в реальности это не работает. Одни вон Rust стали изобретать, другие мигрировать на GC. G>>В реальности куча других причин, кроме type-safety и memory-safety. C>Ещё есть thread safety, который Rust тоже помогает решать за счёт концепции владения.
thread safety не достигается одной концепцией владения. Владение лишь позволяет избавится от "случайных" гонок. Но когда данные разделяемые владение не поможет.
Владение есть и в C++ — unique_ptr и move.
В C# оно не сильно нужно, потому что большой упор на immutable, в базовой библиотеке куча thread-safe коллекций и примитивов синхронизации.
Здравствуйте, fddima, Вы писали:
EP>>Я про "другие мигрировать на GC" F> В Хроме (да и не только в хроме) — есть разные кучи объектов — V8 (JS) и DOM.
То есть то, о чём я и говорил — для interoperability.
F>Я что-то мог уже подзабыть, поэтому если интересно можно поискать что-то начиная отсюда http://www.chromium.org/blink/blink-gc и по ключевому слову oilpan. По моему где-то была презентация.
Тут кто-то уже давал ссылку на статью по теме. Там, насколько я помню, GC используется только для interop'а, а не для всего приложения, хотя могу и ошибаться.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>Я про "другие мигрировать на GC" F>> В Хроме (да и не только в хроме) — есть разные кучи объектов — V8 (JS) и DOM. EP>То есть то, о чём я и говорил — для interoperability.
Ну пока всё же в большей мере речь идет о переписывании Blink на Oilpan. Интеграция с V8 и Dart назвать интеропом — честно говоря язык не повернется так его назвать, в виду своей плотности.
Здравствуйте, s22, Вы писали:
s22>Почитал и понял, что мало кто готов на таком писать..... s22>Жутко как то.... s22>может просто непривычно?
s22>http://habrahabr.ru/post/240617/
Возьми Objective C. На нём написаны миллионы приложений, как для мака, там и для айдевайсов. Всё управление памятью там на счётчиках ссылок. И ничего, жить можно.
EP>Всего лишь для некоторых примитивных семейств объектов
Скрытый текст
EP>
EP>using System;
EP>using System.IO;
EP>public class Test
EP>{
EP> public delegate void fireworks();
EP> public static fireworks make_closure(FileStream fs)
EP> {
EP> return () => fs.Read(new byte[10], 0, 10);
EP> }
EP> public static fireworks fire()
EP> {
EP> using (var fs = File.Open("file", FileMode.Open))
EP> {
EP> return make_closure(fs);
EP> }
EP> }
EP> public static void Main()
EP> {
EP> fire()(); // System.ObjectDisposedException
EP> }
EP>}
EP>
Интересно чем именно вызваны эти смайлики. Я конечно могу строить предположения:
* "Ха-ха, да у меня всего один файл на всю программу, остальные ресурсы это память!"
* "Ха, тут using вообще не нужен, да и prompt finalization туда же!"
* "Ну и что что тут ссылка на disposed объект, главное что в production вылетит ObjectDisposedException."
Но всё же интересны исходные мысли по этому поводу.
Здравствуйте, AlexRK, Вы писали:
EP>>* "Ну и что что тут ссылка на disposed объект, главное что в production вылетит ObjectDisposedException." ARK>Вот это, ясное дело.
Выше было заявлено, что 'GC гарантирует отсутсвие ссылок на "освобождённые" куски памяти и на случайные объекты.'
Я же привёл пример, который показывает что для ресурсов гарантии намного слабее (при необходимости prompt finalization).
Тот же ref counting даёт куда больше:
auto make_closure = [](auto f)
{
return [=](auto x)
{
*f << "logging: " << x << endl;
};
};
auto fire = []
{
auto f = make_shared<ofstream>("log.txt");
*f << "starting" << endl;
auto result = make_closure(f);
*f << "continuing" << endl;
return result;
};
int main()
{
{
auto log = fire();
log("Elbereth");
log(42);
} // file is closed here
}
А вот как реализовать нечто подобное на C#? Где тут ставить using'и?
ARK>Неопределенное поведение ни при каком раскладе не лучше, чем ObjectDisposedException.
Через "неопределённое поведение" ISO даёт полную волю реализациям на самодеятельность.
Конкретные реализации вполне имеют право определять это поведение как им захочется. Это может быть хоть то же самое исключение, а может даже диагностика в compile-time (для некоторых случаев) — что определённо лучше чем runtime исключение.
Здравствуйте, dimgel, Вы писали:
D>...Я с бОльшим удовольствием к доброму старому C (без плюсов) вернулся бы. Ковырял как раз на днях сорцы кое-какие — и глядя на до байта и до такта вылизанный код, резко вспомнил всю попаболь, которую испытывал, переходя на всю эту managed-муть.
При всем моем к тебе уважении — не верю. И знаешь почему? Прочти свою подпись под сообщением.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sharowarsheg, Вы писали:
S>Не обязательно. Например, можно требовать, чтобы вся память была или статическая или в стеке. Или просто статическая. И типизированная. И тогда это будет совершенно безопасно — все переменные известны на этапе компиляции.
Я из таких языков знаю только Фортнар доисторических версий. И что-то никто на нем писать не хочет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Нет, в Rust как раз оптимум. Я недавно переписал свой проект с С++ на Rust — получилось очень красиво.
Насколько сложно возиться с их таймлайами на практике?
Были ли в проекте графы или другие сильно связанные структур которые невозможно разместить в стеке? Если были, то каков их процент? И насколько с ними пришлось повозиться?
Результат и оригинал можно увидеть?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hi_octane, Вы писали:
_>Смарт-пойнтеры это простейший ref-counting GC. И, кстати, с ними можно нарваться на почти все недостатки GC.
Вообще-то их сейчас несколько видов есть. Ты говоришь о том что официально называют shared. А еще есть unique и просто уничтожающий объект при выходе из области видимости смарт-поинтера.
К автоматическому управлению памятью, к которой относится GC, это все не относится. Это автоматизация управления памятью. Но не полная автоматика. Это примерно как называть автоматическим управлением автомобилем систему круиз-контроля (пусть и адаптивную) или парк-асистент. Да, жизнь упрощает, но водителя не заменяют. Так же и смартпоинтеры они упрощают жизнь, повышают уровень, но головную боль управления памятью не снимают с программиста.
Не будет никто в С++ использовать подсчет-ссылок для 100% объектов. Напротив, в С++ 80% объектов живет в стеке. Массовый подсчет-ссылок приведет к тому, что управляемые среды начнут таким программам на С++ давать огромную фору.
При этом одну из проблем GC подсчет ссылок решает. Подсчет ссылок размазывает оверхэд по всему коду предотвращая паузы GC. Но, при этом, он привносит другие проблемы вроде фрагментации памяти и циклических ссылок.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandjustas, Вы писали:
G>Да, стандартные смартпоинтеры потокобезопасны, как утверждает МСДН.
Это дополнительные тормоза куда большие чем от GC, вообще-то.
G>От состояния гонок в коде приложения ни смартпоинтеры, ни GC не спасает.
Ну, кое что придумать можно. Достаточно выделять память для разных потоков в разных пулах GC и запретить использование объектов созданных в одном потоке из другого. Для общения между потоками нужно использовать специальный обменный пул GC, а объекты помещать в очереди потоков. Короче, модель акторов с отдельным обменным хипом, как в Сингулярити.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AlexRK, Вы писали:
EP>>Выше было заявлено, что 'GC гарантирует отсутсвие ссылок на "освобождённые" куски памяти и на случайные объекты.' EP>>Я же привёл пример, который показывает что для ресурсов гарантии намного слабее (при необходимости prompt finalization). ARK>Так про это и разговора не было.
Разговор про безопасность, и про то как managed языки помогают управлять временем жизни объектов.
Я показываю пример, что для произвольных ресурсов не очень-то и помогает.
А внезапный вылет исключения (например ObjectDisposedException, при ошибке в управлении ресурсами) — согласно OWASP вполне себе vulnerability (1, 2)
EP>>А вот как реализовать нечто подобное на C#? Где тут ставить using'и? ARK>
ARK>...
ARK>void Main()
ARK>{
ARK> using (var f = new FileStream("log.txt"))
ARK> {
ARK> f("starting");
ARK> var log = fire(f);
ARK> log("Elbereth");
ARK> log(42);
ARK> }
ARK>}
ARK>
Так это же совершенно другой код — тут Main знает о FileStream, и даже сам создаёт его (не говоря уже об излишнем type erasure, в виде приведения к object'у)
ARK>Вообще, за эквилибристику с ресурсами надо вырывать все, что можно.
Это такие guidelines на C#, да?
Впрочем ничего удивительного — using'и не везде можно поставить (см. пример выше), добавление ресурса вглубь иерархии/композиции заставляет вручную менять весь код транзитивно зависящий от класса в который добавляет ресурс. Немудрено допустить ошибку
ARK>Ибо нечитаемый говнокод.
Почему же нечитаемый? Ну ok, вот сокращённый пример, но это рояли не играет:
auto make_logger = [](auto file)
{
ofstream f(file);
return [f = move(f)](auto x) mutable
{
f << "logging: " << x << endl;
};
};
int main()
{
auto log = make_logger("log.txt");
log("Elbereth");
log(42);
}
ARK>Прошу прощения, но это полная ерунда. Чистое натягивание совы на глобус. ARK>Вы видели в природе ПО, которое написано в расчете на исключения в случае неопределенного поведения?
Библиотека Bloomberg — BSL (BDE Standard Library), позволяет задавать действие при обнаружении UB (в более общем смысле — нарушение precondition) — это может быть, например, исключение, abort, или полностью игнорирование проверки (для производительности) ибо как ни крути — нарушение precondition это баг.
То есть эдакое опциональное defensive programming.
ARK>Существуют ли такие компиляторы вообще?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
DM>>Однако что мозилловцы, что гуглохромовцы пришли к осознанию, что в реальности это не работает. Одни вон Rust стали изобретать, другие мигрировать на GC.
EP>Для каких задач? Случайно не interop?
"Другие" для DOM-а Хрома и для JS. Наелись смартпоинтеров до отвращения и поняли, что это не айс.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandjustas, Вы писали:
G>Можно в языке C++ выделить safe подмножество, хотя в самом языке нет никакого GC.
Нельзя, так как в любом месте можно тупо поместить ссылку в не то место или забыть что-то сделать. Автоматика подразумевает единые правила которые нельзя нарушить случайно. А С++ держится на соглашениях и осторожности программистов.
G>И в других языка, без встроенного GC, можно выделить Safe подмножество с помощью конструкций, аналогичных смартпоинтерам.
Для этого в такие языки нужно ввести какие-топ средства недопущения опасных действий. Например, такие как в Rust. Никакими смартпоинтерами это не делается, иначе бы языки типа Раста просто не были бы нужны.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Ещё есть thread safety, который Rust тоже помогает решать за счёт концепции владения.
Проблема в том, что в Rust владением (временем жизни, если точнее) нужно управлять вручную. Компилятор позволяет контролировать, что поинтер не будет в молоко указывать, но за счет кучи ограничений и ручного управления временем жизни объектов.
Плюс для разделяемых объектов в Rust используется подсчет ссылок. Что, как бы, само по себе чревато.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Разговор про безопасность, и про то как managed языки помогают управлять временем жизни объектов.
Для самого часто используемого ресурса — безусловно помогают.
EP>Я показываю пример, что для произвольных ресурсов не очень-то и помогает.
Ну да.
EP>А внезапный вылет исключения (например ObjectDisposedException, при ошибке в управлении ресурсами) — согласно OWASP вполне себе vulnerability
Vulnerability vulnerability рознь, я так думаю.
Mission-critical системы это одно, а какой-нибудь игровой серверок — другое. На последнем безусловно лучше исключение (которое стопанет какой-нибудь игровой агент, который тут же будет перезапущен), чем UB (которое проявится неизвестно где и когда).
EP>Так это же совершенно другой код — тут Main знает о FileStream, и даже сам создаёт его (не говоря уже об излишнем type erasure, в виде приведения к object'у)
Понятное дело, что другой.
EP>Впрочем ничего удивительного — using'и не везде можно поставить (см. пример выше), добавление ресурса вглубь иерархии/композиции заставляет вручную менять весь код транзитивно зависящий от класса в который добавляет ресурс. Немудрено допустить ошибку
Юзинги в C# реализованы кривовато, это да. Но GC вроде как не позиционировался, как средство от всех бед.
ARK>>Вы видели в природе ПО, которое написано в расчете на исключения в случае неопределенного поведения?
EP>Библиотека Bloomberg — BSL (BDE Standard Library), позволяет задавать действие при обнаружении UB (в более общем смысле — нарушение precondition) — это может быть, например, исключение, abort, или полностью игнорирование проверки (для производительности) ибо как ни крути — нарушение precondition это баг. EP>То есть эдакое опциональное defensive programming.
А каким образом библиотека узнает об UB?
ARK>>Существуют ли такие компиляторы вообще? EP>Например memory sanitizer у Clang, да и вообще подобных утилит много.
Это наверное все же подобие статического анализа, а не замена UB исключениями. То бишь это средства для устранения UB (и наверняка они не устраняют все, совершенно уверен в этом). А речь у нас тут шла о справедливости утверждения, что UB лучше исключения быть не может.
Здравствуйте, AlexRK, Вы писали:
EP>>Разговор про безопасность, и про то как managed языки помогают управлять временем жизни объектов. ARK>Для самого часто используемого ресурса — безусловно помогают.
Согласен. Не на 100%, но помогают.
EP>>А внезапный вылет исключения (например ObjectDisposedException, при ошибке в управлении ресурсами) — согласно OWASP вполне себе vulnerability ARK>Vulnerability vulnerability рознь, я так думаю. ARK>Mission-critical системы это одно, а какой-нибудь игровой серверок — другое. На последнем безусловно лучше исключение (которое стопанет какой-нибудь игровой агент, который тут же будет перезапущен), чем UB (которое проявится неизвестно где и когда).
Да, но здесь вопрос-то в другом — как в этом случае получить prompt finalization, без ObjectDisposedException, и без полностью ручного управления ресурсом.
EP>>Впрочем ничего удивительного — using'и не везде можно поставить (см. пример выше), добавление ресурса вглубь иерархии/композиции заставляет вручную менять весь код транзитивно зависящий от класса в который добавляет ресурс. Немудрено допустить ошибку ARK>Юзинги в C# реализованы кривовато, это да. Но GC вроде как не позиционировался, как средство от всех бед.
Тут скорее не к GC вопрос, а к управляемым языкам. Отчасти облегчив управление памятью, они практически ничем не помогли с управлением остальными ресурсами.
ARK>>>Вы видели в природе ПО, которое написано в расчете на исключения в случае неопределенного поведения? EP>>Библиотека Bloomberg — BSL (BDE Standard Library), позволяет задавать действие при обнаружении UB (в более общем смысле — нарушение precondition) — это может быть, например, исключение, abort, или полностью игнорирование проверки (для производительности) ибо как ни крути — нарушение precondition это баг. EP>>То есть эдакое опциональное defensive programming. ARK>А каким образом библиотека узнает об UB?
Это грубо говоря assert'ы расставляемые программистом компонента вручную. Он видит, что при нарушении одного из precondition следующем шагом будет UB, и даёт возможность решить что делать в таком случае.
И вообще говоря, нарушение precondition это UB в любом языке. Причём обнаружить все такие нарушения невозможно в общем случае.
ARK>>>Существуют ли такие компиляторы вообще? EP>>Например memory sanitizer у Clang, да и вообще подобных утилит много. ARK>Это наверное все же подобие статического анализа, а не замена UB исключениями.
Там большинство утилит динамические (инструментация и т.п.), а не статические. Очевидно что при желании можно бросить исключение в пользовательский код (при обнаружении UB).
В некоторых из этих утилит, статический анализ используется для уменьшения нагрузки от инструментации, в тех случаях где очевидно что UB нет.
ARK>То бишь это средства для устранения UB (и наверняка они не устраняют все, совершенно уверен в этом). А речь у нас тут шла о справедливости утверждения, что UB лучше исключения быть не может.
Мой поинт в том, что UB это "here be dragons" только до тех пор, пока мы читаем абстрактную спецификацию. В конкретных же реализациях обработка UB может быть реализована лучше чем то, что предоставляют исключения.
Здравствуйте, VladD2, Вы писали:
EP>>А вот как реализовать нечто подобное на C#? Где тут ставить using'и? VD>А зачем подобное на нем реализовывать?
Хочется увидеть как можно сочетать лямбды с prompt управлением ресурсами (для которого разработчики языка предлагают using'и), эдакий аналог upwards funarg problem.
А вообще интересно какие ещё есть проблемы с управлением ресурсами.
Например другая проблема — добавление ресурса вглубь иерархии/композиции заставляет вручную менять весь код транзитивно зависящий от класса в который добавляется ресурс. На Nemerle эту проблему уже пытались решить
Здравствуйте, VladD2, Вы писали:
C>>Ещё есть thread safety, который Rust тоже помогает решать за счёт концепции владения. VD>Проблема в том, что в Rust владением (временем жизни, если точнее) нужно управлять вручную. Компилятор позволяет контролировать, что поинтер не будет в молоко указывать, но за счет кучи ограничений и ручного управления временем жизни объектов.
Оно не то чтобы ручное (нигде автоматического уничтожения объектов не нужно), но ограниченное.
Как я уже сказал, ограниченность даёт неожиданный плюс в виде того, что управление владением помогает с конкурентным кодом — автоматически проверяемыми инвариантами "только владелец может менять данные" и "может быть только один владелец одновременно".
VD>Плюс для разделяемых объектов в Rust используется подсчет ссылок. Что, как бы, само по себе чревато.
Планируется возможность добавить нормальный точный GC. Библиотеки проектируются с учётом на это.
Меня скорее печалит, что при текущем дизайне Rust невозможно автоматически сделать модель Erlang'а с множеством независимых GC, по одному для каждой задачи.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Хочется увидеть как можно сочетать лямбды с prompt управлением ресурсами (для которого разработчики языка предлагают using'и), эдакий аналог upwards funarg problem.
А зачем их сочетать?
Как бы, если ты не идиот, то будешь искать способ не сделать глупость, а не наоборот.
Стратегии эти известны:
1. Работать с неуправляемыми ресурсами внутри одной области видимости (using).
2. Читать данные залпом в память.
3. Использовать пулы ресурсов возвращающие коротко-живущие хэндлеры (которые можно в using-ах локально использовать). Вот эти хрени могут внутри и подсчет ссылок использовать и другие техники.
4. Хранить ресурс который нужно долго держать открытым в другом диспоузебл-объекте (например, в форме).
На десктопах, где памяти завались проще не заморачиваться и использовать п. 2.
EP>А вообще интересно какие ещё есть проблемы с управлением ресурсами.
Да нет их на практике. В С++ они есть только потому, что ресурсом является любой динамически занятый кусок памяти.
Если я пишу код работающий с файлом я просто буду читать его содержимое в цикле внутри using-а, а уже обработку вынесу в функции. Время их работы будет вложено в using.
Если файл априори небольшой (например, код), я его тупо весь считаю в память одним АПИ-вызовом.
Если это соединение с БД, то буду использовать пулы подключений.
Если мне нужно писать в сокет из формы при вводе данных, то положу его в поле формы и закрою его в финалайзере формы и на событие закрытия.
EP>Например другая проблема — добавление ресурса вглубь иерархии/композиции заставляет вручную менять весь код транзитивно зависящий от класса в который добавляется ресурс. На Nemerle эту проблему уже пытались решить
Здравствуйте, Cyberax, Вы писали:
C>Немного многословно получается везде аннотации ставить, изменения в языке скоро это упростят.
Вроде как уже упростили. Там сейчас остались только:
1. Универсальные указатели на что угодно (как в плюсах).
2. Лайфтаймы позволяющие возвращать указатели через стек и гарантировать их корректность во внешней функции.
3. "Боксинг" — объекты размещенные в куче с семантикой еденичного владения.
4. Разделяемые объекты размещаемые в куче и живущие на подсчете ссылок.
Ты на старом синтаксисе писал?
C>Сама концепция С++-нику сразу же понятна, многие так примерно уже и писали многие годы.
Концепции то понятно, но мне вот со стороны показалось, что даже для С++-ника получается слишком много приседаний. Хотя контроль компилятора и все такое... Без практики это оценить сложно.
C>Понятно, что для чего-нибудь типа вебсайта или учётной программы — смысла во всём этом нет.
Можно подумать, что для остального софта можно и гвозди микроскопом забивать.
VD>>Результат и оригинал можно увидеть? C>Немножно устаревший оригинал: https://github.com/moleculo/extreme-s3 , новый результат выложу чуть позже.
ОК, будет интересно посмотреть.
C>В общем, прекрасный язык для системного кода, который должен работать с минимумом внешних зависимостей и интероперировать с C/C++. Сильная типизация и нормальные generic'и помогают писать без тонны юнит-тестов для проверки типов (что сильно достаёт в Python). Синтаксис очень простой, особенно после выкидывания из языка магических значков типа @.
Так какой синтаксис ты использовал, новый или старый?
И что если сравнивать не со скриптами, а с дотнетом или явой?
C>Есть зачатки поддержки нормального autocompletion'а: https://github.com/phildawes/racer Так как разбор языка делается просто, то в будущем поддержка со стороны инструментов типа JetBrains или Eclipse должна делаться без особых проблем.
Да, в этом плане проблем не будет.
C>Из недостатков — сейчас пока очень сильно эволюционирует система исключений. Изначально язык планировался более Erlang-like и fail'ы были ограничены границами задач, но сейчас задачи становятся менее центральными. Будет интересно посмотреть до чего доэволюционируют, так как сейчас исключения бесполезны.
Да, уж. Дизайн там явно в самом разгаре.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Оно не то чтобы ручное (нигде автоматического уничтожения объектов не нужно), но ограниченное.
Ну, как бы free — нет, но ведь эти лайтаймы нужно явно в функциях описывать. Функцию заранее нужно планировать так, чтобы ее результат можно было бы во вне вернуть. Ну, и зависимость возвращаемого значения от времени жизни параметров как бы выглядит не очень автоматическим решением. Все же с GC все в разы проще.
C>Как я уже сказал, ограниченность даёт неожиданный плюс в виде того, что управление владением помогает с конкурентным кодом — автоматически проверяемыми инвариантами "только владелец может менять данные" и "может быть только один владелец одновременно".
Это скорее фича тип с единичным владением. Там же кроме него и подсчет ссылок, и просто указатели. Но, согласен, что объект с единичным владением для общения между потоками удобен, как и неизменяемые объекты.
VD>>Плюс для разделяемых объектов в Rust используется подсчет ссылок. Что, как бы, само по себе чревато. C>Планируется возможность добавить нормальный точный GC. Библиотеки проектируются с учётом на это.
Что-то как-то верится с трудом. Они слишком вольно ссылки на объекты в параметры передают. Такие ссылки поплывут при компактизации кучи. Вряд ли они смогут все указатели подправить в стеке.
C>Меня скорее печалит, что при текущем дизайне Rust невозможно автоматически сделать модель Erlang'а с множеством независимых GC, по одному для каждой задачи.
Почему нет?
По хипу на поток плюс один обменный (для объектов используемых в качестве сообщений). Именно так сделано в Сингулярити.
Думаю, большей проблемой будут указатели.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
EP>>Хочется увидеть как можно сочетать лямбды с prompt управлением ресурсами (для которого разработчики языка предлагают using'и), эдакий аналог upwards funarg problem. VD>А зачем их сочетать?
Лямбда это по сути обычный объект, для которого есть специальный синтаксис создания. Если в примере выше заменить лямбду на обычный объект, и сделать его IDisposable — то using можно будет поставить (хотя фактически вручную).
То что using не работает для лямбды — это асимметрия/недостаток.
VD>Как бы, если ты не идиот, то будешь искать способ не сделать глупость, а не наоборот.
И в чём же глупость? В том что в C# это нормально сделать нельзя? Ок, будем списывать каждый недочёт языка, на глупость желания разработчика
Тебе не хватает макросов в C#? "если ты не идиот, то будешь искать способ не сделать глупость, а не наоборот."!
VD>Стратегии эти известны: VD>1. Работать с неуправляемыми ресурсами внутри одной области видимости (using).
1. эта область может зависеть от внешних runtime условий, и если пытаться перекрыть все возможные варианты, то для многих частных случаев эта область будет избыточно большой.
2. эту область придётся выводить вручную.
3. передавая ресурс куда-то вниз — нет гарантии что кто-то не продлит его время использования за пределы using scope.
VD>2. Читать данные залпом в память.
1. А если файл большого размера?
2. Не всегда нужно именно "читать", иногда достаточно просто сделать memory mapping. Предлагаешь перегонять MemoryMappedFile в массив для обхода недостатка языка?
3. В обсуждаемом примере вообще запись, а не чтение.
VD>3. Использовать пулы ресурсов возвращающие коротко-живущие хэндлеры (которые можно в using-ах локально использовать). Вот эти хрени могут внутри и подсчет ссылок использовать и другие техники.
И как это поможет для обсуждаемого примера? Кто будет держать ресурс живым в то время пока лямбда не вызывается?
Или как хотя бы ты вернёшь из функции такой хэндл? Где там using ставить? Выводить время жизни хэндла вручную?
VD>4. Хранить ресурс который нужно долго держать открытым в другом диспоузебл-объекте (например, в форме).
Это вариация 1.
VD>На десктопах, где памяти завались проще не заморачиваться и использовать п. 2.
Если у тебя на всю программу один файл .n, в несколько десятков килобайт — то можно и так
EP>>А вообще интересно какие ещё есть проблемы с управлением ресурсами. VD>Да нет их на практике. В С++ они есть только потому, что ресурсом является любой динамически занятый кусок памяти.
И есть соответствующее решение, причём оно подходит для любых ресурсов.
И если для памяти оно действительно менее автоматизированное чем GC, то для остальных ресурсов по факту более, в сравнении с мейнстрим управляемыми языками. Что приведённый пример как раз и показывает
VD>Если это соединение с БД, то буду использовать пулы подключений.
Время жизни одного соединения из пула чем будет контролироваться?
EP>>Например другая проблема — добавление ресурса вглубь иерархии/композиции заставляет вручную менять весь код транзитивно зависящий от класса в который добавляется ресурс. На Nemerle эту проблему уже пытались решить
Это blub аргумент.
Вот по ссылке человек решая реальную задачу наткнулся на эту проблему, и даже макрос для её частичного решения соорудил, а ты всё говоришь что проблема надуманна.
VD>Не знаю что там отчасти,
Там говорится, что автоматически генерируется только для классов с IDisposable. Вот есть не-IDisposable класс с несколькими не-IDisposable полями. После небольшого изменения, какой-то объект из глубин композиции стал IDisposable, что транзитивно сделало IDisposable и поле нашего объекта.
Описываемое решение не говорит о том как нужно распространять это транзитивное заражение IDisposable — вручную?
Или те же using'и для вновь заражённых объектов кто будет проставлять?
VD>но я подобной фигней тоже занимался
. Но исключительно в повествовательно-спортивном интересе. На практике я этого дела не использовал ни разу.
У тебя ещё примитивней чем по ссылке — там хотя бы атрибут вручную ставить не нужно:
В итоге всё выродилось до полностью автоматической реализации IDisposable, без всяких аттрибутов вообще. Ориентиром было наличие самого интерфейса IDisposable. Т.е. если класс заявлял что он IDisposable, но не давал самописной реализации своего Dispose, то создавалась реализация "по-умолчанию" для всех приватных и протектед полей. Оказалось удобно и надёжно, писанины меньше, меньше места для ошибок.
Здравствуйте, VladD2, Вы писали:
C>>Оно не то чтобы ручное (нигде автоматического уничтожения объектов не нужно), но ограниченное. VD>Ну, как бы free — нет, но ведь эти лайтаймы нужно явно в функциях описывать. Функцию заранее нужно планировать так, чтобы ее результат можно было бы во вне вернуть.
Это совсем не доставляет проблем, особенно учитывая move-oriented присваивание.
VD>Ну, и зависимость возвращаемого значения от времени жизни параметров как бы выглядит не очень автоматическим решением. Все же с GC все в разы проще.
Проще, но вызывает жёсткую зависимость от GC. Для системного языка это не очень хорошая идея.
C>>Как я уже сказал, ограниченность даёт неожиданный плюс в виде того, что управление владением помогает с конкурентным кодом — автоматически проверяемыми инвариантами "только владелец может менять данные" и "может быть только один владелец одновременно". VD>Это скорее фича тип с единичным владением.
Это основная фича всего языка, вокруг неё всё строится.
VD>Там же кроме него и подсчет ссылок, и просто указатели. Но, согласен, что объект с единичным владением для общения между потоками удобен, как и неизменяемые объекты.
"Коробки" (объекты) со счётчики ссылок требуют или иммутабельности или явных блокировок. Так что тут тоже всё ОК — иммутабельные объекты можно безопасно между потоками передавать, и мутировать, пока на них гарантированно только одна ссылка есть.
C>>Планируется возможность добавить нормальный точный GC. Библиотеки проектируются с учётом на это. VD>Что-то как-то верится с трудом. Они слишком вольно ссылки на объекты в параметры передают. Такие ссылки поплывут при компактизации кучи. Вряд ли они смогут все указатели подправить в стеке.
В самом Rust нет никаких проблем со ссылками — в любом месте кода можно построить граф используемых переменных. Собственно, поддержка этого есть в исходнике компилятора.
Основная проблема будет, как обычно, с FFI. Сейчас пока он используется практически только для unmanaged-структур.
C>>Меня скорее печалит, что при текущем дизайне Rust невозможно автоматически сделать модель Erlang'а с множеством независимых GC, по одному для каждой задачи. VD>Почему нет?
Мутируемые объекты можно разделять между потоками с помощью RWArc и другими способами.
Здравствуйте, VladD2, Вы писали:
C>>Немного многословно получается везде аннотации ставить, изменения в языке скоро это упростят. VD>Вроде как уже упростили. Там сейчас остались только:
Пока нет: https://github.com/rust-lang/rfcs/blob/master/text/0141-lifetime-elision.md
C>>Сама концепция С++-нику сразу же понятна, многие так примерно уже и писали многие годы. VD>Концепции то понятно, но мне вот со стороны показалось, что даже для С++-ника получается слишком много приседаний. Хотя контроль компилятора и все такое... Без практики это оценить сложно.
Синтаксис непривычен немного.
C>>Понятно, что для чего-нибудь типа вебсайта или учётной программы — смысла во всём этом нет. VD>Можно подумать, что для остального софта можно и гвозди микроскопом забивать.
Rust делается всё же для достаточно узкой цели — языка, на котором можно написать операционку или библиотеку типа libz, которую будут использовать клиенты на любом языке.
C/C++. Сильная типизация и нормальные generic'и помогают писать без тонны юнит-тестов для проверки типов (что сильно достаёт в Python). Синтаксис очень простой, особенно после выкидывания из языка магических значков типа @. VD>Так какой синтаксис ты использовал, новый или старый?
Новый.
VD>И что если сравнивать не со скриптами, а с дотнетом или явой?
Я бы сказал, что на Scala/Kotlin/C# всё же проще. Хотя безопасная работа с данными мне всё же очень понравилась.
C>>Из недостатков — сейчас пока очень сильно эволюционирует система исключений. Изначально язык планировался более Erlang-like и fail'ы были ограничены границами задач, но сейчас задачи становятся менее центральными. Будет интересно посмотреть до чего доэволюционируют, так как сейчас исключения бесполезны. VD>Да, уж. Дизайн там явно в самом разгаре.
Я бы сказал, что на 90% завершено для версии 1.0
Что мне очень нравится, дизайн делается в результате feedback'а от реального использования. Так что теоретически красивые фичи типа сегментированного стека выбросили как непрактичные, а не оказались с ними в финальном релизе.
Здравствуйте, VladD2, Вы писали:
S>>Ну, фортран 77 был не так уж плох. Этюдов, конечно, не попишешь, но для работы хватало.
VD>Хватало для вычислительных задач. Сегодня он мало применим.
Насколько я помню свою работу у подрядчиков для ВПК, нормально применим во всяких исследовательско-изыскательских и прочих ОКР.
Для тех вычислительных задач указатели вообще не нужны.
Здравствуйте, Cyberax, Вы писали:
C>Из недостатков — сейчас пока очень сильно эволюционирует система исключений. Изначально язык планировался более Erlang-like и fail'ы были ограничены границами задач, но сейчас задачи становятся менее центральными. Будет интересно посмотреть до чего доэволюционируют, так как сейчас исключения бесполезны.
А эта эволюция видна на примере чего-то?
Вряд ли в язык будет тащиться тяжелый рантайм для исключений.
Здравствуйте, AlexRK, Вы писали:
C>>Из недостатков — сейчас пока очень сильно эволюционирует система исключений. Изначально язык планировался более Erlang-like и fail'ы были ограничены границами задач, но сейчас задачи становятся менее центральными. Будет интересно посмотреть до чего доэволюционируют, так как сейчас исключения бесполезны. ARK>А эта эволюция видна на примере чего-то?
Пока обсуждают: https://github.com/rust-lang/rfcs/pull/243
ARK>Вряд ли в язык будет тащиться тяжелый рантайм для исключений.
Тяжёлого рантайма для исключений точно не нужно, DWARF-исключения делаются без сильно дополнительных телодвижений.
