Здравствуйте, Evgeny.Panasyuk, Вы писали:
DM>>Однако что мозилловцы, что гуглохромовцы пришли к осознанию, что в реальности это не работает. Одни вон Rust стали изобретать, другие мигрировать на GC. EP>Для каких задач? Случайно не interop?
Для каких задач делают Rust? Вы действительно это хотели спросить, на форуме, в 2014 году?
Здравствуйте, D. Mon, Вы писали:
DM>>>Однако что мозилловцы, что гуглохромовцы пришли к осознанию, что в реальности это не работает. Одни вон Rust стали изобретать, другие мигрировать на GC. EP>>Для каких задач? Случайно не interop? DM>Для каких задач делают Rust? Вы действительно это хотели спросить, на форуме, в 2014 году?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Я про "другие мигрировать на GC"
В Хроме (да и не только в хроме) — есть разные кучи объектов — V8 (JS) и DOM. Все они — бывает так — что изрядно ссылаются друг на друга, и по сути через прокси, с тем или иным способом пиннинга с обоих сторон. В итоге можно создавать ситуации, в которых память гарантированно не будет высвобождаться GC V8 и/или DOM. Кроме того сам код рендера изрядно страдает переусложнением. Поэтому появилось мнение, что переход на новый GC, а так же соединение этих куч — даст более хороший результат. Попутно обещают не только улучшить производительность, но и сделать код стабильнее/безопаснее. Это вкратце. Я что-то мог уже подзабыть, поэтому если интересно можно поискать что-то начиная отсюда http://www.chromium.org/blink/blink-gc и по ключевому слову oilpan. По моему где-то была презентация.
Здравствуйте, 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'а, а не для всего приложения, хотя могу и ошибаться.
Здравствуйте, 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'а.
Приведи пример чтоли, где разница.
Здравствуйте, 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/
Здравствуйте, 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 исключение.
Здравствуйте, 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# не допускает ошибок переполнения. Просто компилятор такой пока не написан, но написать его можно.
Здравствуйте, dimgel, Вы писали:
D>...Я с бОльшим удовольствием к доброму старому C (без плюсов) вернулся бы. Ковырял как раз на днях сорцы кое-какие — и глядя на до байта и до такта вылизанный код, резко вспомнил всю попаболь, которую испытывал, переходя на всю эту managed-муть.
При всем моем к тебе уважении — не верю. И знаешь почему? Прочти свою подпись под сообщением.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sharowarsheg, Вы писали:
S>Не обязательно. Например, можно требовать, чтобы вся память была или статическая или в стеке. Или просто статическая. И типизированная. И тогда это будет совершенно безопасно — все переменные известны на этапе компиляции.
Я из таких языков знаю только Фортнар доисторических версий. И что-то никто на нем писать не хочет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Нет, в Rust как раз оптимум. Я недавно переписал свой проект с С++ на Rust — получилось очень красиво.
Насколько сложно возиться с их таймлайами на практике?
Были ли в проекте графы или другие сильно связанные структур которые невозможно разместить в стеке? Если были, то каков их процент? И насколько с ними пришлось повозиться?
Результат и оригинал можно увидеть?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
