Здравствуйте, Павел Кузнецов, Вы писали:
ПК>VladD2,
>> ПК> Да-да-да. Конечно. Using просто так ввели, для развлечения.
>> Так его впролне хватает. Те кто как следует попробовал еще никто не жаловался.
ПК>Его может хватать только в пределах метода. Плюс, ответственность за его написание перемещается на пользователя класса. Нет уж, спасибо.
Я же говорю... для тех кто попробовал. К теоретикам это не относится.
У нас вообще забавный спор получается. Я пробовал и плюсы и дотнет. Ты же пробовал тольк плюсы. В общем, спор с теоретиками поедания устриц получается. На слово ты мне не веришь. Проверять не хочешь. Но постоянно озвучивашь разные бредовые мифы. Спроси у тех кто реально использует дотнет в своей пратктике и они ответят тебе, что нет проблоем озвучиваемых в этих мифах.
Ладно, попробую объяснить.
1. Так с ресурсами просто используется другая иделогия. Ресурсы просто не держутся открытыми в классах. Нужная информация попросу считывается в память, а ресурс отпускается. Ну, и так как память больше не ресурс, то и проблем нет. Для того чтобы жить было проще, например, при работе с БД используются пулы соеденений. При этом на время транзации получается динамическое соеденение которое обрабатывается в using-е. По выходу из using-а соеденение возвращается в пул. Файлы читаются в память, и т.д., и т.п.
2. Врешних ресурсов (ОС и т.п.) не так-то много. И следить за ними намного проще чем за памятью. Утечка ресурса может быть только временной, так как ЖЦ рано или поздно подберет их. Причем скорее всего рано (при сборе нулевого поколения). Таким образом утечка не приводящая к блокировке ресурса вообще мало кого волнуют. А утички приводящие к блокировкам становятся очень быстро заметны и моментально устраняются.
В общем, если ты не хочешь пробовать, то прийдется тебе поврить на слово. Управление ресурсами в дотнете неимоверно проще по сравнению с анменеджед С++. Я как бы написал немало плюсового кода управляющего ресурсами и занаю что говорю. После некоторого привыкания понимашь, что эта проблема имела такое значение в С++ потому, что реально являлась гемороем. В дотнете же геморроя не испытывашь, и со временем начинашь забывать про нее.
ПК>Я тебя понял. Мне такие языки не интересны.
То есть, ты никогда не ошибашся и все твои сотрудники тоже? В проекте рядом стобой работают одни гуру? Проблему эту ты поднимашь потому что для тебя она проблемой не является, но ты знаешь о великих муках дотнетчиков. Так?
ПК> Мне более интересен подход, который принуждает программиста исправлять свои ошибки, а не маскирует их.
С++ никогда ничему никого не принуждал. Не нужно этого пафоса. Впрочем точно так же как дотнет не маскирует ошибки. Не нужно повторять одни и те же мифы.
ПК> Да, лучшая диагностика времени исполнения, чем в C++, не помешала бы. Но без попыток "сглаживать негативные последствия".
Это очень неверное суждение. Похоже, что ты почему-то считашь, что сглаживание == маскирование. И наоборот не сглаживание != маскирование. Но это не так. Сглаживание означает, что небрежно написанный код не будет приводить к серьезным отложеным проблемам (насколько это возможно), как то утечки ресурсов или памяти. Потреянный хэндл в С++ это потеренный хэндл. Даже если ресурс при этом не блокируется, ты все равно теряешь его до конца программы. В дотнете же подобная небрежность просто удленняет время жизни этого хэндла. Это не так же хорошо как если бы он был освобожден сразу, но все же лучше чем полная утрата. На диагностику ошибок это никак не влияет, а стало быть не может служить источником проблем.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Глеб, все очень здорово.
Только посылки у тебя не те к сожалению.
Первым был "не курица или яйцо", а человек который это придумал.
Как это компилируется в .NET или в Java или в JavaScript меня как пользователя этих языков должно интересовать слабо если честно.
Меня интересует "зачем?" я хочу понять философский смысл поведения return в try/catch/finally.
Как я понимаю суть проблемы : protected blocks catch and finally выполняются
как локальные процедуры, т.е.
catch(something) это фактически локальная процедура
void catch(something) {...}
Аналогично finally это void finally() {...}
Т.е. возвращаемое значение из них подавляется.
Поведение в такой модели мне понятно.
Но опять же не понятно — зачем?
Ну напиши в специфимкации что return — это return и finally не выполнится — и гори оно огнем.Не надо устраивать пляски с бубном. Пусть компайлер ворнинги выдает если надо. Так честнее в разы чем дурить народ — "да, деструкторов у нас нет, но вы можете легко смоделировать их поведение".
GZ>Ндас. Я начинаю все больше понимать Влада с его фанатским отношением к спецификации C#....
Спецификации JavaScript и С# утверждались одним и тем же комитетом — ECMA. Так что делаем выводы...
VladD2,
>>> ПК> Да-да-да. Конечно. Using просто так ввели, для развлечения.
>>> Так его впролне хватает. Те кто как следует попробовал еще никто не жаловался.
> ПК>Его может хватать только в пределах метода. Плюс, ответственность за его написание перемещается на пользователя класса. Нет уж, спасибо.
> Я же говорю... для тех кто попробовал. К теоретикам это не относится.
Его в принципе не может хватать ни для чего, выходящего за пределы метода, т.к. его так нельзя использовать.
> У нас вообще забавный спор получается. Я пробовал и плюсы и дотнет.
У нас с тобой очень разный подход к программированию, для нас важны разные вещи, поэтому я не думаю, что твой опыт использования C++ хоть как-то релевантен.
> Ладно, попробую объяснить. > 1. Так с ресурсами просто используется другая иделогия. Ресурсы просто не держутся открытыми в классах.
У нас с тобой разные понятия того, что такое ресурсы. Для меня это далеко не только и не столько внешние ресурсы и ресурсы операционной системы. Почти все, что требует освобождения, для меня ресурс. Скажем, если от события клиент должен отписываться, то для меня само понятие установленной подписки — ресурс. Это означает, что функция, устанавливающая подобное соединение, в идеале будет возвращать объект, при разрушении которого соединение будет разорвано. И т.п. Для тебя, насколько я понял, это ресурсом не является. Соответственно, да, с ресурсами в твоем понимании у тебя проблем, может, и нет. В моем — очень даже.
> ПК> Я тебя понял. Мне такие языки не интересны.
> То есть, ты никогда не ошибашся и все твои сотрудники тоже?
Ошибаюсь. Поэтому предпочитаю языки со средствами, позволяющими мне добавлять максимум своих проверок, часто проверяющих какие-то аспекты логики программы, а не только и не столько пользоваться готовыми, которые о логике программы не знают.
> Проблему эту ты поднимашь потому что для тебя она проблемой не является, но ты знаешь о великих муках дотнетчиков. Так?
Я говорил о том, чего мне не хватает в C#. .Net здесь не при чем.
> Сглаживание означает, что небрежно написанный код не будет приводить к серьезным отложеным проблемам (насколько это возможно), <...>
Еще раз: мне мало интересны улучшения языка, направленные на уменьшение последствий небрежного написания кода (хотя приятным бонусом они безусловно являются). Намного интересней для меня возможности языка, направленные на увеличение возможностей, доступных тем, кто пишет аккуратно. Пока что в C# я для себя таких возможностей по сравнению с C++ нашел очень мало. И, если не ошибаюсь, все из них доступны из C++/CLI, буде у меня возникнет желание писать под .Net.
Соответственно, по доброй воле переходить на C# ради уменьшения "опасностей" я не собираюсь, т.к. насколько я вижу для меня это означает уменьшение выразительных возможностей языка по сравнению с тем, что есть сейчас (C++).
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, GlebZ, Вы писали:
CS>Как это компилируется в .NET или в Java или в JavaScript меня как пользователя этих языков должно интересовать слабо если честно.
Почему? Со всеми этими наворотами мы начали забывать что работает с дискретными копьютерами, то что в байте 8 бит, то что процессоры бывают 8-16-32-64 битными. Мы стали забывать что и как у нас работает. А это ведь палка о двух концах. С одной стороны это освобождает голову от лишнего. С другой стороны, если припрет сделать высокопроизводительный алгоритм, не будет хватать знаний. Не очень понимаю как может программист на С не понимать принципы функционирования процессора. Не очень понимаю как программист на C# не знает принципы работы MSIL. Хотя я многого не очень понимаю. Почему-то многие программисты знают как работают маршрутизаторы в интернете, хотя это им и на фиг не нужно, но не знают как работает программа на более низком уровне. Почему-то в БД понимание функционирования самой базы и индексов считается в достаточной мере важно, но почему это не присутсвует в языках.
CS>Меня интересует "зачем?" я хочу понять философский смысл поведения return в try/catch/finally.
Филосовский смысл такой же, как остутсвие детерменированных деструкторов или множественного наследования экземпляров. Невозможность сделать по выбранной технологии.
CS>Как я понимаю суть проблемы : protected blocks catch and finally выполняются
как локальные процедуры.
Почти да. Только вход в процедуру прямым jump, и такой же выход из нее. При исключении в стек закатывается полный путь со всеми вызываемыми финализаторами и до блок типа catch(видов catch несколько) до которого пройдет выполнение. Дальше, при выходе из блока нужно выполнить только, pop eax, jmp eax. То есть, корректные вызовы напрямую. При попадании в блок, стек должен находится в нормальной форме чтобы можно было работать с локальными переменными.
CS>Поведение в такой модели мне понятно. CS>Но опять же не понятно — зачем?
Попробуй сказать, что должна делать finally при попадании туда с помощью throw на команде return.
CS> Спецификации JavaScript и С# утверждались одним и тем же комитетом — ECMA. Так что делаем выводы...
Но писали их разные команды. А писать и принимать — очень разные вещи.
Здравствуйте, GlebZ, Вы писали:
GZ>Почему-то в БД понимание функционирования самой базы и индексов считается в достаточной мере важно, но почему это не присутсвует в языках.
Потому что возможный оверхед разный. Из-за незнания архитектуры процессора обычно теряется 20-30%, ну пусть 100%. А из-за незнания принципов работы реляционных хранилищ и В+ деревьев легко можно потерять сотни и тысячи процентов.
Здравствуйте, McSeem2, Вы писали:
AR>>Правде, причем здесь буква "М", я не понимаю.
MS>Я тоже не знаю. Это был Copy/Paste из книжки http://www.ega-math.narod.ru/Singh/
Глюки перевода.
В немецком оригинале было "полное титулование": Professor Em. Landau — Заслуженный профессор Ландау. Сглючили, наверное, еще при переводе с немецкого на английский...
Все, что здесь сказано, может и будет использоваться против меня...
Здравствуйте, VladD2, Вы писали:
A>>Дальнейший разбор вообще не имеет смысла. VD>В чем по-твоему ошибка?
В смеси C общения с файлами (FILE *) и С++ работы со строками (оператор <<)
A>>Уже здесь ошибка и её надо исправлять, а не дальше глядеть. VD>Понимаеш ли. Это кусок окда из очень заслуженного продукта. И те кто его писали как минимум опыт имеют не меньше чем у тебя.
Ну культуры программирования у меня явно больше
A>>Большая проблема Си++ это то, что при некоторой возможности писать на нём хорошо, мало что в нём этому способствует. VD>Согласен. Я это формулирю так. Кодирование на С++ при "правильном" подходе выливается в соблюдение моря паттернов и учету кучи мелких деталей не имеющих отношения к основной задаче.
Согласен. Только ты утверждаешь, что это очень сильно отвлекает, а я считаю, что вовсе и не сильно и не сказать, чтоб очень уж отвлекало.
A>>Ты подумай, какая либа самая главная? CRT == C Run-Time. Короче имеем все плоды обратной совместимости. VD>CRT — это библиотека С. И грязи я в ней не вижу. Продукт спроектирован по всем канонам С.
Да, но используется в Си++. Сам вот код привёл. А оно там надо? ИМХО совсем эта библиотека там не нужна, не говоря уже о возможности забыть fclose(dest);
Здравствуйте, adontz, Вы писали:
A>Да, но используется в Си++. Сам вот код привёл. А оно там надо? ИМХО совсем эта библиотека там не нужна, не говоря уже о возможности забыть fclose(dest);
Не надо. Но то что есть в С++ штатно лично у меня вызывает рвотное чувство. Возможно та же фигня и у товарищей. Я бы наверно наклепал бы свою обертку, а они решили что и так сойдет.
В общем, это пример реального кода. Можно сто раз сказать, что так не бывает, но ничего от этого не изменится. И это еще успешный и более менее качественный проект. А что творится в закрытом коде некоторых коммерческих продуктов приходитс догадываться только по их глюкам.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, adontz, Вы писали:
A>>Да, но используется в Си++. Сам вот код привёл. А оно там надо? ИМХО совсем эта библиотека там не нужна, не говоря уже о возможности забыть fclose(dest);
VD>Не надо.
Ну вот и ладушки
VD>В общем, это пример реального кода. Можно сто раз сказать, что так не бывает, но ничего от этого не изменится.
Так я как раз знаю что такое бывает! Просто не надо потом говорить, что это проблема Си++ кода!!! Си++ красивое слово которое круто звучит, но многие этот язык не знают! Я знаю "плюсовика", который себя считает очень крутым, а на деле понятия не имеет, что такое шаблон.
Здравствуйте, VladD2, Вы писали:
VD>В общем, если ты не хочешь пробовать, то прийдется тебе поврить на слово. Управление ресурсами в дотнете неимоверно проще по сравнению с анменеджед С++. Я как бы написал немало плюсового кода управляющего ресурсами и занаю что говорю. После некоторого привыкания понимашь, что эта проблема имела такое значение в С++ потому, что реально являлась гемороем. В дотнете же геморроя не испытывашь, и со временем начинашь забывать про нее.
Ага... Вот и я про нее забыл... и словил утечку при использовании внешнего компонента которому по логике IDisposable нужен как рыбке зонтик... Причем всплыло это через довольно продолжительное время после того как я это место отладил и забыл. (а если бы я не поленился и сделал кэширование сразу то сидела бы до сих пор и не извесно нашлась бы или нет... причем текла исключительно память...) Пришлось ставить тулзу которая ищет утечки памяти в .NET...
В С++ этого бы не произошло просто по тому что там все на АВТОМАТИЧЕСКИХ деструкторах которые вызывает КОМПИЛЯТОР. И я всегда помню что за ресурсами нужно следить. Хотя не совсем так эта память активизируется только тогда когда приходится работать с неким сишным интерфейсом. И засыпает сразу после того как написан врапер.
ЗЫ Кстати как я делал кэширование это отдельная история... там где в С++ я бы написал одно слово const в C# пришлось поплясать с бубном... (нужно было гарантировать что клиентский код не испортит кэш)
ЗЗЫ Хотя C# почти всегда доволько приятный язык но... "почти" портит впечатление
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Ага... Вот и я про нее забыл... и словил утечку при использовании внешнего компонента которому по логике IDisposable нужен как рыбке зонтик...
Дык. Ероектирование никто не отменял. Память больше не ресрурс, но ресурсы все таки пока встречаются. Для них по прежнему нужно делать обертки.
Кстати, открою один сикрет. В C# 2.0 можно делать обертки с нулевым оверхэдом. Орлы из команды Шарпа разрешили использовать паттерн Dispose без интерфейса. Если создать структуру и обосзвать у нее метод
void Dispose() { }
то будучи подставленной в using она способна выполнять обязанности "обертки". Так я в R#-е написал обертку для востановления контекста для сообщений об ошибках:
using (ErrorContext x = new ErrorContext(_errors, attrIplInfo))
{
...
using (ErrorContext x = new ErrorContext(_errors, xxx))
{
...
}
...
}
WH>ЗЗЫ Хотя C# почти всегда доволько приятный язык но... "почти" портит впечатление
Ну, идиал он всегда недостижим.
ЗЫ
Однако лесно слышать подобные слова от столь преданного плюсам человека. Думаю, если ты попрограммируешь на Шарпе еще с годик, то твое мнение и вовсе станит положительным.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Дык. Ероектирование никто не отменял. Память больше не ресрурс, но ресурсы все таки пока встречаются. Для них по прежнему нужно делать обертки.
Дык эта компонента только с памятью и работала... Ни к каким ресурсам ей обращатся незачем... вот я даже и не подумал что у нее может быть реализован IDisposable И хоть бы кто варнинг выдал
VD>Кстати, открою один сикрет. В C# 2.0 можно делать обертки с нулевым оверхэдом. Орлы из команды Шарпа разрешили использовать паттерн Dispose без интерфейса. Если создать структуру и обосзвать у нее метод
Забавно.
Я тоже открою один секрет. Если ссылатся на обект не нужно то можно писать так
using( new ErrorContext( 2 ) )
{
using( new ErrorContext( 1 ) )
{
}
}
Не знаю как там со стандартом но работает.
VD>Ну, идиал он всегда недостижим.
Во во...
VD>Однако лесно слышать подобные слова от столь преданного плюсам человека.
Преданого??? Как только появится что-то перекравыющие С++ по возможностям то С++ сразу пойдет лесом. VD>Думаю, если ты попрограммируешь на Шарпе еще с годик, то твое мнение и вовсе станит положительным.
Не думаю.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Дык эта компонента только с памятью и работала...
"Компонет". "Компонента" — это из области математики.
WH> Ни к каким ресурсам ей обращатся незачем... вот я даже и не подумал что у нее может быть реализован IDisposable И хоть бы кто варнинг выдал
Он был анменеджед? Если, да, то понятно что к нему нужен диспоз. Тогда вина лежит на том, что создал для него обертку. Если бы он просто реализовал в ней финалайзер (деструктор), то проблем бы с утечкой не возникло.
WH>Не знаю как там со стандартом но работает.
Законно. Юсинг описан так:
using-statement:
using ( resource-acquisition ) embedded-statement
resource-acquisition:
local-variable-declaration
expression
Так что можно даже присваивать переменную внутри юсинга. Надо быть только осторожным с присвоением вэлью-типов. Они же ведь при этом копруются.
VD>>Однако лесно слышать подобные слова от столь преданного плюсам человека. WH>Преданого??? Как только появится что-то перекравыющие С++ по возможностям то С++ сразу пойдет лесом.
Ну, вот судя по тому, что C# лесом не пошел я и делаю кое-какие выводы. По себе знаю, что если люди ломают привычки, значит это не просто так.
VD>>Думаю, если ты попрограммируешь на Шарпе еще с годик, то твое мнение и вовсе станит положительным. WH>Не думаю.
А я почти уверен.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ну, вот судя по тому, что C# лесом не пошел я и делаю кое-какие выводы. По себе знаю, что если люди ломают привычки, значит это не просто так.
Ага... просто надо было ГУЙ лабать... А ВинФормс всетки поудобний МФЦ будет.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
WH>>Ага... просто надо было ГУЙ лабать... А ВинФормс всетки поудобний МФЦ будет. AVK>Но не то чтобы особенно сильно
Для человека который никогда не писал ГУЙ?
[offtop]
Приличный грид у которого в ячейках могут быть комбобоксы не подскажешь? А то меня стандартный уже достал комбобоксы я к нему прикрутил но все както криво работает, а разбиратся времени нет.
[/offtop]
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>>>Ага... просто надо было ГУЙ лабать... А ВинФормс всетки поудобний МФЦ будет. AVK>>Но не то чтобы особенно сильно WH>Для человека который никогда не писал ГУЙ?
Это ты про меня что ли? Или про себя?
WH>[offtop] WH>Приличный грид у которого в ячейках могут быть комбобоксы не подскажешь? А то меня стандартный уже достал комбобоксы я к нему прикрутил но все както криво работает, а разбиратся времени нет. WH>[/offtop]
Я как то гридами не увлекался. Есть какой то грид на codeproject бесплатный + платные гриды от основных поставщиков компонентов.
К теоретикам это не относится.
На слово ты мне не веришь. Проверять не хочешь. Но постоянно озвучивашь разные бредовые мифы. Спроси у тех кто реально использует дотнет в своей пратктике и они ответят тебе, что нет проблоем озвучиваемых в этих мифах.
но работает.
