Здравствуйте, Дарней, Вы писали:
ГВ>>Я бы не стал называть это поиском проблем. Скорее уж, попыткой избавиться от каких-то неприятностей, свойственных традиционным решениям. Д>Просто я прекрасно могу представить, какое количество проблем они приобретут взамен. И еще не факт, что применение C++ избавит их от старых. Д>C++ очень опасно применять для кода, который регулярно будет изменяться, особенно — если это серверный код.
Опасно реализовывать непродуманные и поспешные решения. Вот это — в самом деле опасно. А на каком языке — да какая разница! Если научился писать багоустойчивый код на C++, то большой разницы между кодированием сервера и "клиента" уже нет. А если нет, то...
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
VladD2,
> Неплохо было бы аргументировать этот набор ничем не обоснованных заявлений.
Гм... Читать умеем? Аргументация и/или примеры присутствуют. Если какие-то из аргументов полагаешь недостаточными, приводи контрпримеры, опровергай и т.п. Если есть какие-то конкретные положения, для которых аргументация отсутствует, указывай конкретно.
Posted via RSDN NNTP Server 1.9 delta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>VladD2,
>> Неплохо было бы аргументировать этот набор ничем не обоснованных заявлений.
ПК>Гм... Читать умеем?
Умеем. Остается выяснить умеем ли мы аргументировать.
ПК> Аргументация и/или примеры присутствуют. Если какие-то из аргументов полагаешь недостаточными, приводи контрпримеры, опровергай и т.п. Если есть какие-то конкретные положения, для которых аргументация отсутствует, указывай конкретно.
Довольно глупо переписывать половину твоих реплик.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК> Аргументация и/или примеры присутствуют. Если какие-то из аргументов полагаешь недостаточными, приводи контрпримеры, опровергай и т.п. Если есть какие-то конкретные положения, для которых аргументация отсутствует, указывай конкретно.
> Довольно глупо переписывать половину твоих реплик.
Ну, тогда остаемся в текущей ситуации. Я высказал ряд тезисов с некоторой аргументацией. Опровержения приведенных аргументов или хотя бы иллюстрации их недостаточности не последовало. Снабжать все подряд дополнительной аргументацией, без указанных действий с твоей стороны, я, естественно, не буду.
Posted via RSDN NNTP Server 1.9 delta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Что-то я не очень понимаю, как unsafe поможет в достижении перечисленных выше моментов...
Просто для всего, что ты перечисил, в C# есть аналог или что-то на замену. (ну за исключением генериков, которые еще недоступны для большинства)
А вот для тех (редких) случаев, когда производительности C# не хватает — для них и нужен unsafe
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Ну, тогда остаемся в текущей ситуации. Я высказал ряд тезисов с некоторой аргументацией. Опровержения приведенных аргументов или хотя бы иллюстрации их недостаточности не последовало. Снабжать все подряд дополнительной аргументацией, без указанных действий с твоей стороны, я, естественно, не буду.
Так, я чувствую мои просьбы ушли в пустоту. Ну сколько можно? Заканчивайте здесь разборки.
Дарней,
> ПК>Что-то я не очень понимаю, как unsafe поможет в достижении перечисленных выше моментов...
> Просто для всего, что ты перечисил, в C# есть аналог или что-то на замену.
Имхо, есть существенные отличия у предлагаемых "альтернатив"...
> шаблоны, позволяющие контролировать часть семантических ограничений во время компиляции, (generics не в счет)
"generics не в счет" не из-за того, что они "еще недоступны для большинства", а из-за их ограниченности
. Считать это положительным или отрицательным моментом — дело вкуса. Однако для тех, кому нужна функциональность "полных" шаблонов C++, generics адекватной заменой не являются.
> размещение объектов в стеке + деструкторы, что позволяет автоматизировать освобождение ресурсов
Снова-таки, "аналог" не вполне аналогичен. using решает проблему вызова освобождения ресурсов в случае исключений, но (!) перекладывает обязанность по слежению за этим на пользователей класса. Плюс, если в классе, ранее не требовавшем "специального" освобождения ресурсов, эти ресурсы таки появятся, старый код сломается. В случае использования деструкторов разработчик класса контролирует эти моменты прозрачно для пользователя. В общем, снова-таки, using кого-то, может, и устраивает, но полагать это адекватной заменой для всех пользователей...
> "свободные" функции
Этого вообще нет.
> А вот для тех (редких) случаев, когда производительности C# не хватает — для них и нужен unsafe
Производительность, конечно, иногда очень важна (и она тоже далеко не всегда достигается через unsafe, т.к. целый ряд вещей, связанных с производительностью, в C++ решается через шаблоны), но в данном случае для меня намного существеннее именно возможности языка, которые в случае C#, имхо, сильно ограничивают выразительные средства, доступные разработчикам библиотек.
Posted via RSDN NNTP Server 1.9 delta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Снова-таки, "аналог" не вполне аналогичен. using решает проблему вызова освобождения ресурсов в случае исключений, но (!) перекладывает обязанность по слежению за этим на пользователей класса. Плюс, если в классе, ранее не требовавшем "специального" освобождения ресурсов, эти ресурсы таки появятся, старый код сломается. В случае использования деструкторов разработчик класса контролирует эти моменты прозрачно для пользователя. В общем, снова-таки, using кого-то, может, и устраивает, но полагать это адекватной заменой для всех пользователей...
В текущем проекте, который уже 2 года живет, не было ни одного случая потери ресурсов из-за забытого using. Веришь?
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Производительность, конечно, иногда очень важна (и она тоже далеко не всегда достигается через unsafe, т.к. целый ряд вещей, связанных с производительностью, в C++ решается через шаблоны), но в данном случае для меня намного существеннее именно возможности языка, которые в случае C#, имхо, сильно ограничивают выразительные средства, доступные разработчикам библиотек.
Уж простит мнея АВК (как модератор), но отвечать "по делу" на этот набор поверхноссных суждений и догм нельзя. Паша мужик молодой, мы тоже не совсем старики. Поглядим что он запоет через 10 лет. А пока этот спор с теоритиками устрицаедения надо завязать.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>В текущем проекте, который уже 2 года живет, не было ни одного случая потери ресурсов из-за забытого using. Веришь?
Да плевать ему на практику тысяч человек. Его теори незыблемы. Пробовать на практике ему в лом. Мне кажется все эти разговоры бессмысленны. Это упертость принципиальна. Надо завершать этот бессмысленный разговор.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Вот еще достаточно интересное мнение по поводу некоторых трудностей при использовании языков со сборкой мусора для разработки игр.
Для не верующих Фом...
Вот ссылка на сравнение двух 3D-движков. Ogre — исходный движек писанный на С++. Axiom — C#-порт Ogre.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Вот еще достаточно интересное мнение по поводу некоторых трудностей при использовании языков со сборкой мусора для разработки игр.
. Считать это положительным или отрицательным моментом — дело вкуса. Однако для тех, кому нужна функциональность "полных" шаблонов C++, generics адекватной заменой не являются.
Я в курсе.. увы, C++ шаблоны — это инструмент "не для всех". Большинство кодеров при виде заворота в стиле Александреску приходит в тихий ужас и норовит забиться куда-нибудь в уголок. Невразумительные сообщения об ошибках в пару кб текста длиной — это тоже далеко не плюс. Я уж не говорю про проблемы с компиляторами и поддержкой стандарта языка.
надеюсь, R# эту проблему в конце концов решит :-D
ПК>Снова-таки, "аналог" не вполне аналогичен. using решает проблему вызова освобождения ресурсов в случае исключений, но (!) перекладывает обязанность по слежению за этим на пользователей класса. Плюс, если в классе, ранее не требовавшем "специального" освобождения ресурсов, эти ресурсы таки появятся, старый код сломается. В случае использования деструкторов разработчик класса контролирует эти моменты прозрачно для пользователя. В общем, снова-таки, using кого-то, может, и устраивает, но полагать это адекватной заменой для всех пользователей...
Можно рассматривать это и как плюс. Большое количество скрытой активности в деструкторах часто очень осложняет жизнь. Кстати говоря, выброс исключения из Dispose не может обрушить прогу — в отличие от C++
>> "свободные" функции ПК>Этого вообще нет.
Никто не мешает использовать вместо них статические функции-члены.
ПК>Производительность, конечно, иногда очень важна (и она тоже далеко не всегда достигается через unsafe, т.к. целый ряд вещей, связанных с производительностью, в C++ решается через шаблоны), но в данном случае для меня намного существеннее именно возможности языка, которые в случае C#, имхо, сильно ограничивают выразительные средства, доступные разработчикам библиотек.
Если так уж сильно приспичит, то можно написать наиболее критичную часть проги на MSIL или MC++
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Павел Кузнецов, Вы писали:
ПК>>Снова-таки, "аналог" не вполне аналогичен. using решает проблему вызова освобождения ресурсов в случае исключений, но (!) перекладывает обязанность по слежению за этим на пользователей класса. Плюс, если в классе, ранее не требовавшем "специального" освобождения ресурсов, эти ресурсы таки появятся, старый код сломается. В случае использования деструкторов разработчик класса контролирует эти моменты прозрачно для пользователя. В общем, снова-таки, using кого-то, может, и устраивает, но полагать это адекватной заменой для всех пользователей...
Д>Можно рассматривать это и как плюс. Большое количество скрытой активности в деструкторах часто очень осложняет жизнь. Кстати говоря, выброс исключения из Dispose не может обрушить прогу — в отличие от C++
Зато исключение в Dispose может оставить программу в неопределенном состоянии, и это явно хуже, чем "обрушить прогу". И кстати, не "обрушить", а вызвать terminate(), в котором ты волен произвести необходимые действия перед завершением (послать crash dump разработчику, например).
Здравствуйте, alexeiz, Вы писали:
A>Зато исключение в Dispose может оставить программу в неопределенном состоянии, и это явно хуже, чем "обрушить прогу"
А почему "в неопределенном состоянии"? Даже если один или несколько Dispose в пределах блока выбросит исключение, все остальные Dispose все равно будут вызваны. К сожалению, я не нашел данных, какое из этих исключений будет обработано
Или ты что-то другое имел в виду?
A>И кстати, не "обрушить", а вызвать terminate(), в котором ты волен произвести необходимые действия перед завершением (послать crash dump разработчику, например).
Программа перестанет работать, не сохранив своих данных, не завершив сеанс работы и т.п. Крэш дамп конечно поможет разработчикам, но юзеру от этого легче не станет
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, alexeiz, Вы писали:
A>>Зато исключение в Dispose может оставить программу в неопределенном состоянии, и это явно хуже, чем "обрушить прогу"
Д>А почему "в неопределенном состоянии"? Даже если один или несколько Dispose в пределах блока выбросит исключение, все остальные Dispose все равно будут вызваны. К сожалению, я не нашел данных, какое из этих исключений будет обработано Д>Или ты что-то другое имел в виду?
A>>И кстати, не "обрушить", а вызвать terminate(), в котором ты волен произвести необходимые действия перед завершением (послать crash dump разработчику, например).
Д>Программа перестанет работать, не сохранив своих данных, не завершив сеанс работы и т.п. Крэш дамп конечно поможет разработчикам, но юзеру от этого легче не станет
Твоё недоумение скорее всего вызвано непониманием причин, по которым C++ обязывает программу аварийно завершиться при выбросе исключения при обработке другого исключения (скорее всего, когда деструктор выбрасывает). Почитай об этом в clc++.moderated или comp.std.c++. Здесь я, так как у меня нет времени это досконально разъяснять, скажу лишь, что проблеммы при выбросе исключений из деструкторов и из Dispose имеют один и тот же характер. Одна из таких проблем — это выброс исключения при обработке другого исключения, и она может случится, как с выбрасывающими десрукторами, так и с выбрасывающими Dispose. Эта проблемма не имеет удовлетворительного разрешения в том смысле, что невозможно обработать такую ситуацию и продолжить выполнение программы нормальным образом. Что-нибудь обязательно будет сломано в состоянии программы, ты на это можешь наткнуться и сразу вылететь, а можешь совсем не заметить, а можешь и произвести какие-нибудь деструктивные действия (вроде разрушения файлов пользователя при попытке сохранить его данные, эдак подложив пользователю своеобразную свинью).
Далее, тот факт, что .NET в этом случае позволяет тебе продолжить выполниние программы как ни в чём не бывало, является лишь непризнанием данной проблеммы как таковой дизайнерами .NET'а. Параллели между Dispose и деструкторами C++ очевидны. C++/CLI даже ставит их во взаимно однозначное соответствие. Почему дизайнеры .NET'а ничего криминального не увидели в продолжении выполнения программы в этом случае, для меня загадка. Скорее всего это было технически возможно сделать, и они решили "почему бы и нет?" Ведь в .NET программа не упадет при обращении к памяти с нуленым адресом, не перезапишет за пределы массива, т.е не сделает ничего такого, на что вполне способен в такой ситуации "wicked" C++. Поэтому они решили сделать .NET "более надёжным" и в данном случае. Но они не увидели принципиального недетерминированного поведения, access violation и buffer overrun всего лишь частные случаи которого.
Параллели между Dispose() и деструкторами С++ очевидны, но это все-таки не одна и та же вещь.
Я не сомневаюсь, что в случае C++ выброс исключения во время раскрутки стека приводит к неопределенному поведению. Но приведет ли к неопределенному поведению в .NET — это еще не факт. Я не сомневаюсь, что архитекторами эта проблема обдумывалась (в отличие от некоторых других ) — судить можно хотя бы по приведенному выше факту. Как показал тест — сначала завершаются вызовы Dispose для всех объектов текущего блока, и только затем продолжается раскрутка стека. Происходит это независимо от того, было ли выброшено исключение одним из вызванных методов, или нет.
Единственная неопределенность в данном случае — это вопрос о том, какое из исключений будет обрабатываться далее — то, которое изначально привело к раскрутке стека, или одно из тех, которые возникли во время процесса раскрутки. Судя по результатам эксперимента — обрабатываться будет то, которое было выброшено последним. Это действительно не очень хорошо, т.к. информация о предыдущих исключениях теряется. Однако, неопределенного поведения здесь все-таки нет.
Поэтому мне хотелось бы получить или детальные пояснения, или точные ссылки на оные. Потому что перекапывать целый раздел Юзнета в поисках неких туманных подтверждений твоей правоты — на это времени у меня уж совершенно нет.
