Здравствуйте, 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>>Нет, в 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) и вёлся рефакторинг стандартной библиотеки. С вполне понятными последствиями в виде постоянно ломающегося кода.
Здравствуйте, 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>Хватало для вычислительных задач. Сегодня он мало применим.
Насколько я помню свою работу у подрядчиков для ВПК, нормально применим во всяких исследовательско-изыскательских и прочих ОКР.
Для тех вычислительных задач указатели вообще не нужны.
(не говоря уже об излишнем type erasure, в виде приведения к object'у)
