Здравствуйте, D. Mon, Вы писали:
DM>один из разработчиков интеловского компилятора рассказывал, что если в функции есть какая-то работа с исключениями, то многие оптимизации для нее сразу выключаются.
Не осилили интеловские разработчики исключения, бывает.
Здравствуйте, AlexRK, Вы писали:
ARK>Не обязательно городить подсчет ссылок, можно как в Rust — уникальные указатели и контроль за ними. С точки зрения надежности и скорости — самый лучший вариант.
В Расте, как раз, подсчет ссылок. Уникальные указатели можно в любой язык/рантайм встроить. Но это не общий механизм. Все равно нужно иметь возможность раделяемого владения ссылками. И тут есть только три варианта:
1. GC.
2. Подсчет ссылок.
3. Ручное управление памятью.
Мне кажется GC + уникальные указатели лучше чем подсчет ссылок и уникальные указатели.
ARK>Исключения — очень спорная вещь. Разговоры о "пользе" исключений — однобокий взгляд. Минусов у исключений не меньше, чем плюсов.
Все минусы упираются в ручное управление памятью. В управляемых средах с исключениями проблем нет. Не надо выдумывать.
ARK>К счастью, есть люди, которые это понимают, поэтому Rust и Swift именно такие, какие есть.
Осталось только понять не заблуждаются ли эти люди. Вот Гугль в Хроме выбрал GC. И Хром выглядит вполне себе конкурентноспособно. А вот Раст выглядит довольно странно (мягко говоря).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, s22, Вы писали:
s22>в инете много про это.... s22>часто компиляторы не инлайнят код, если во вложенной функции есть вызов исключения.
Это проблемы не исключений, а С++ и его компиляторов. И не смотря на эти проблемы С++ считается одним из самых "быстрых" языков (т.е. его компиляторы порождают самый быстрый код).
Вряд ли у разработчиков новых языков главным требованием является превзойти С++ по скорости генерируемого кода.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В Расте, как раз, подсчет ссылок. Уникальные указатели можно в любой язык/рантайм встроить. Но это не общий механизм. Все равно нужно иметь возможность раделяемого владения ссылками.
На мой взгляд, разделяемые ссылки нужны редко. И как раз уникальные ссылки в Расте являются главным типом ссылок, а ARC там — сбоку припеку.
ARK>>Исключения — очень спорная вещь. Разговоры о "пользе" исключений — однобокий взгляд. Минусов у исключений не меньше, чем плюсов. VD>Все минусы упираются в ручное управление памятью. В управляемых средах с исключениями проблем нет. Не надо выдумывать.
Да нет, главные проблемы исключений — совсем не из-за ручного управления памятью. Про них я здесь уже писал.
И в управляемых средах все проблемы исключений тоже присутствуют в полной мере.
Здравствуйте, AlexRK, Вы писали:
ARK>На мой взгляд, разделяемые ссылки нужны редко. И как раз уникальные ссылки в Расте являются главным типом ссылок, а ARC там — сбоку припеку.
Ну, так какие проблемы то тогда? Раз разделяемые ссылки это редкость (хотя я не понимаю как без них делать иерархии объектов вроде HTML DOM), то GC будет идеальным дополнением к ним, так как на малых объемах GC рулит неимоверно. А вот ARC ваш нужен только тем кто GC не осилил.
ARK>Да нет, главные проблемы исключений — совсем не из-за ручного управления памятью. Про них я здесь уже писал. ARK>И в управляемых средах все проблемы исключений тоже присутствуют в полной мере.
Ты много писал, но внятно ничего не сказал. Давай, опиши нам здесь проблемы которые вызывают исключения в языках с GC. Думаю, ты начнешь вилять и не приведешь ни одного аргумента, потому что их нет в природе.
Мой аргумент очень прост. В С++ проблемы с исключением возникают из-за необходимости раскрутки стека. Почти любой объект в С++ обладает деструктором. При раскрутке стека нужно вызвать деструкторы. 99% объектов с деструктора занимаются освобождением памяти, а не каких-то других ресуросв. В языках с GC такой проблемы нет. Объекты контролируются GC. Банальный сдвиг указателя стека убивает ссылки на них и следовательно виртуально освобождает ссылки на объекты. Конструкции try/finally редки и несложно (без заметного оверхэда) реализуются. Инлайнингу это никак не препятствует.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ты много писал, но внятно ничего не сказал. Давай, опиши нам здесь проблемы которые вызывают исключения в языках с GC. Думаю, ты начнешь вилять и не приведешь ни одного аргумента, потому что их нет в природе.
Главное я вроде как сказал: вылет исключения нарушает инварианты программы, ответственность за поддержку которых ложится на программиста. Чего тут непонятного или невнятного — Именно поэтому исключения не используются нигде в mission-critical софте.
Кроме того, много аргументов было приведено в ссылках, которые я давал выше и которые вы, видимо, читать не стали. Например:
Really easy:
— Recognizing that error-code-based code is badly-written.
— Recognizing the difference between bad error-code-based code and not-bad error-code-based code.
Hard:
— Recognizing that error-code-base code is not badly-written.
Really hard:
— Recognizing that exception-based code is badly-written.
— Recognizing that exception-based code is not badly-written.
— Recognizing the difference between bad exception-based code and not-bad exception-based code.
По-моему, абсолютно верное наблюдение.
Мои аргументы в основном о качестве и поддерживаемости кода, а вы смотрите только с технической стороны — раз можно написать using, значит все хорошо. Не написал? ССЗБ, вон из профессии, исключения это не проблема! А другим потом говнокод разгребать приходится.
Здравствуйте, hi_octane, Вы писали:
_>Из маргинальных языков радует редко упоминаемый тут Nim — компилируемый, статически типизированный, есть какой-то GC с некоторыми настройками, есть исключения, есть макросы но (пока?) без квази-цитат и есть шаблоны (квази-цитаты без макросов?), есть целых 3 перегрузки оператора '.', memory regions, декларируется автоматический решатель/доказатель того что программы работают на непересекающихся данных (имхо это грамотнее чем вводить кучу видов указателей), замыкания, yield, возвращаемые значения lvalue (зачем? пока не разобрался...), и куча других интересностей. Но развивается медленно. Часть синтаксиса как будто содрана с Nemerle — не думаю что до квадратных скобок в Generics можно самому додуматься
Кстати, очень интересный язык. Как раз прочёл сегодня статейку про него http://habrahabr.ru/post/258119/. Странно, что на rsnd часто обсуждался D и Rust (как замена C++), и ни разу не упоминался Nim. В то время как он умеет даже компилироваться в C++ код, имея при этом множество синтаксических вкусностей.
Здравствуйте, alex_public, Вы писали:
_>Кстати, очень интересный язык. Как раз прочёл сегодня статейку про него http://habrahabr.ru/post/258119/. Странно, что на rsnd часто обсуждался D и Rust (как замена C++), и ни разу не упоминался Nim. В то время как он умеет даже компилироваться в C++ код, имея при этом множество синтаксических вкусностей.
Прочел статью. Не увидел в Nim ничего интересного... Ну обсыпали Ц сахаром слегка, не более того. Не вижу ни цельной концепции, ни каких-то новых фич. Да еще эти отступы.
Здравствуйте, AlexRK, Вы писали:
ARK>Могу. Главный минус: исключения оставляют программу в несогласованном состоянии, с разрушенными инвариантами, и формально проконтролировать этот момент нельзя. Теоретически могло бы помочь STM, но у него свой неустранимый минус — не работает с IO.
Исключения могут оставить программу в несогласованном состоянии, с разрушенными инвариантам, и формально проконтролировать этот момент нельзя. То же самое относится и ко всем остальным операторам языка.
Здравствуйте, mrTwister, Вы писали:
ARK>>Ну, это ошибки другого рода. Грамотно написанное API не позволит _пользователю_ этого API забыть проверку. T>В яве тоже пытались заставлять обрабатывать исключения — не взлетело. И с кодами ошибок не взлетит.
Уже давным-давно взлетело. Целые классы приложений не пишутся с применением исключений. Ядра ОС, например.
Здравствуйте, mrTwister, Вы писали:
ARK>>Могу. Главный минус: исключения оставляют программу в несогласованном состоянии, с разрушенными инвариантами, и формально проконтролировать этот момент нельзя. Теоретически могло бы помочь STM, но у него свой неустранимый минус — не работает с IO.
T>Исключения могут оставить программу в несогласованном состоянии, с разрушенными инвариантам, и формально проконтролировать этот момент нельзя. То же самое относится и ко всем остальным операторам языка.
Бинарное "могут — не могут"? Смешно. Все тьюринг-полные языки одинаково удобны и одинаково надежны?
Исключения позволяют достичь негативного эффекта с гораздо большей вероятностью, чем остальные операторы. Просто потому, что их в коде вообще не видно.
Здравствуйте, AlexRK, Вы писали:
ARK>Главное я вроде как сказал: вылет исключения нарушает инварианты программы, ответственность за поддержку которых ложится на программиста.
А тебе ответили, что ты заблуждаешься. Приведи код на Шарпе или Яве доказывающий твое заявление.
ARK>Чего тут непонятного
Ничего. Ты что-то там ляпнул, а все должны тебе верить на слово? Я пишу на дотнете с его появления, т.е. 13 лет. Никаких таких проблем ни разу не видел.
ARK>Именно поэтому исключения не используются нигде в mission-critical софте.
Вот это ваше "mission-critical" — это что-то не дертерминированное граничащее с понтами. Давай примеры в студию и опиши что в них не так.
ARK>Кроме того, много аргументов было приведено в ссылках, которые я давал выше и которые вы, видимо, читать не стали.
Куча трепа без единого доказательства? А мне это не интересно. Ты что-то утверждаешь, будь добр обосновать.
ARK>Например: ARK>Really easy:... ARK>Hard:... ARK>Really hard:... ARK>По-моему, абсолютно верное наблюдение.
А, по-моему, чушь какая-то. И без каких либо доказательств или объяснений. Похоже автор этих строк просто не понимает зачем нужны исключения.
Результаты использования кодов возврата мы можем наблюдать в коде COM-серверов. Практически стандартным явлением в которых является просто никакая обработка ошибок. Люди просто халтурят и получается полная задница. Отладка становится тяжелой. Найти концы очень не просто. В то же время исключения позволяют находить место проблемы элементарно. Включи перехват и получи нужную точку в программе в отладчике.
ARK>Мои аргументы в основном о качестве и поддерживаемости кода, а вы смотрите только с технической стороны — раз можно написать using, значит все хорошо. Не написал? ССЗБ, вон из профессии, исключения это не проблема! А другим потом говнокод разгребать приходится.
Нет у тебя никаких аргументов. Показывай некачественный код. Объясняй его причины. Будем смотреть. Подозреваю, что ты так же не понимаешь стратегию использования исключений.
Код с исключениями объективно чище. В нем просто нет никакого болерплэйта. Обработка может ставиться там где это нужно. Протаскивать что-то руками нет нужны. Если что никто не запрещает реализовывать отдельные куски кода и на кодах возврата. Исключения этому никак не противоречат. Более того, если возврат ошибки/диагностики является частью логики, то реализовывать ее на исключениях просто не верно. Исключения это средство не обращать внимания на нештатные ситуации, а не крутой goto.
Кроме того очень хочется увидеть пример разломанных исключениями инвариантов в управляемом коде.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
_>Кстати, очень интересный язык. Как раз прочёл сегодня статейку про него http://habrahabr.ru/post/258119/. Странно, что на rsnd часто обсуждался D и Rust (как замена C++), и ни разу не упоминался Nim. В то время как он умеет даже компилироваться в C++ код, имея при этом множество синтаксических вкусностей.
Здравствуйте, alex_public, Вы писали:
_>>Nim _>Кстати, очень интересный язык. Как раз прочёл сегодня статейку про него http://habrahabr.ru/post/258119/. Странно, что на rsnd часто обсуждался D и Rust (как замена C++), и ни разу не упоминался Nim. В то время как он умеет даже компилироваться в C++ код, имея при этом множество синтаксических вкусностей.
От всех, кто пробовал с ним играться, я пока слышал (читал) лишь одно — все очень сырое и половина не работает (еще на уровне компилятора). Потенциально он может и интересный (хотя мне противен чисто синтаксически), но пока неюзабелен.
Здравствуйте, hi_octane, Вы писали:
> Часть синтаксиса как будто содрана с Nemerle — не думаю что до квадратных скобок в Generics можно самому додуматься
Здравствуйте, VladD2, Вы писали:
ARK>>Главное я вроде как сказал: вылет исключения нарушает инварианты программы, ответственность за поддержку которых ложится на программиста. VD>А тебе ответили, что ты заблуждаешься. Приведи код на Шарпе или Яве доказывающий твое заявление. VD>Кроме того очень хочется увидеть пример разломанных исключениями инвариантов в управляемом коде.
Ну вот примитивный пример:
class Test
{
private MyItem[] _myArray;
protected abstract void ProcessInternal(MyItem item);
public void Process()
{
foreach (var item in _myArray)
{
ProcessInternal(item); // throws Exception
}
// здесь _myArray оказался в неизвестно каком состоянии
}
VD>Результаты использования кодов возврата мы можем наблюдать в коде COM-серверов. Практически стандартным явлением в которых является просто никакая обработка ошибок. Люди просто халтурят и получается полная задница. Отладка становится тяжелой. Найти концы очень не просто. В то же время исключения позволяют находить место проблемы элементарно. Включи перехват и получи нужную точку в программе в отладчике.
Обычные коды ошибок действительно обладают этим недостатком. Но возврат в стиле Rust — нет.
Именно поэтому исключения не используются нигде в mission-critical софте.
