AndrewVK,
> ПК> Недавно на работе ребята полтора дня искали ошибку. Нашли: не вызывался Dispose. Кажется, для одного из членов класса. Finalize был абсолютно бесполезен, т.к. в этом Dispose объект должен был удалять себя из некоего реестра. Т.к. этого не происходило, ссылка на него жила (в реестре), и Finalize, очевидно, никогда не мог быть вызван.
> WeekReference спасет ваших отцов русской демократии
Речь не о том, как "вылечить" (это вполне несложно, когда ошибка локализована), а о том, что проблемы с забытым вызовом Dispose существуют, и доставляют вполне реальные неприятности.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
>> WeekReference спасет ваших отцов русской демократии
ПК>Речь не о том, как "вылечить" (это вполне несложно, когда ошибка локализована), а о том, что проблемы с забытым вызовом Dispose существуют, и доставляют вполне реальные неприятности.
А с чего ты решил что я предлагаю способ вылечить? Отнюдь, я просто намекаю на способ избежать подобных проблем. Всевозможные кеши и прочие реестры с негарантированным освобождением в GC средах должны реализовываться на базе слабых ссылок. Двойка с минусом вашему архитектору за такое решение.
Здравствуйте, Павел Кузнецов, Вы писали:
>> Привыкай к терминологии В нете интерфейс это отдельная сущность, а не абстрактный класс, как в плюсах. Поэтому класс не наследует интерфейс, а реализует
ПК>Это в C#.
Это в .NET.
ПК>В C++/CLI взаимозаменяемо используют "наследует" и "реализует". Более того, в C++/CLI интерфейс CLI называется интерфейсным классом
Кривая терминология, что я еще могу сказать. Наверное это очередное проявление того шовинизма, который явно был виден в той цитатке кого то из C++/CLI Team, что ты недавно приводил. Интересно, Саттер себя подобным же образом ведет?
ПК>здесь в качестве T может быть как ref class, так и interface class (а в будущем — и просто class), и все время мучиться выговаривая "базовый ref класс или реализуемый интерфейс" никакой выгоды, по-моему, не дает. А в будущем еще и придется все эти места поправить, добавив "или класс". В общем, я пока не вижу большого смысла в постоянном подчеркивании различия между наследованием от ref class, interface class и class.
А в CLR (именно в CLR, а не в C#) понятия интерфейса кардинально отличаются от понятия класса с кучей вытекающих из этого последствий. И то что C++/CLI замазывает это отличие говорит отнюдь не в его пользу.
>> Теперь касательно сути — ни в 1.1 ни в 2.0 IEnumerable от IDisposable не наследуется.
ПК>Не расширяет?
Я уже сказал — интерфейсы между собой наследуются. Неужели не заметил? Твоя ирония выглядит несколько некрасиво.
ПК>Видимо, ошибочка в примере вышла. С другой стороны, для сути совершенно неважно, какой именно интерфейс был бы приведен в качестве примера — это не суть, а несущественная деталь.
AndrewVK,
>>> Привыкай к терминологии В нете интерфейс это отдельная сущность, а не абстрактный класс, как в плюсах. Поэтому класс не наследует интерфейс, а реализует
> ПК>Это в C#.
> Это в .NET.
Ну, если уж говорить о терминологии, то не в .Net, а в CLI.
> ПК>В C++/CLI взаимозаменяемо используют "наследует" и "реализует". Более того, в C++/CLI интерфейс CLI называется интерфейсным классом
> Кривая терминология, что я еще могу сказать.
Это эмоции. Вероятно, было бы полезно напомнить, что часть C++/CLI, относящаяся к CLI — еще не весь язык, она должна органично стыковаться с частью, общей с ISO C++. Соответственно, нужны какие-то общие термины, обозначающие общую часть наследования классов и реализации интерфейсов. Я даже пример привел, где это существенно. По-моему, лучше рассматривать use cases (конкретные примеры, где различие важно или, наоборот, мешает), чем вовлекать эмоции ("кривая терминология", "шовинизм") и религию ("в CLR/CLI/.Net это именно так").
> ПК> здесь в качестве T может быть как ref class, так и interface class (а в будущем — и просто class), и все время мучиться выговаривая "базовый ref класс или реализуемый интерфейс" никакой выгоды, по-моему, не дает. А в будущем еще и придется все эти места поправить, добавив "или класс". В общем, я пока не вижу большого смысла в постоянном подчеркивании различия между наследованием от ref class, interface class и class.
> А в CLR (именно в CLR, а не в C#) <...>
Если уж начали цепляться к терминологии, то, снова-таки, CLI, а не CLR.
> ПК> Видимо, ошибочка в примере вышла. С другой стороны, для сути совершенно неважно, какой именно интерфейс был бы приведен в качестве примера — это не суть, а несущественная деталь.
>
Ну, пожалуй, в таком духе мне далее по этому поводу общаться неинтересно.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Cyberax, Вы писали:
C>А давайте ее чуть-чуть перепишем:
Давай. Куда тебе прислать код? Завтра вернешь переисанным. И пожалуйства без разных внешних библиотек, а то из-за твоих правок не охота получать гемаррой в виде их поиска и подключения.
C>У меня тут наверняка куча ошибок,
Даже не сомневаюсь. Как минимум нет обработки ошибкок, что превращает в общем-то неважную операцию в потенциальный вылет всей прграммы. Именно по этому я не побегу вставлять и отлаживать твой код. Этот код живет не на его правильности или достоинствах С++. Он живет на том, что сотни программеров проползли его на брюхе.
C> но если нормально писать на C>современном С++, то код будет выглядеть примерно как у меня.
Можно... уметь... красивые слова. Я вам тут суровую действительность привел. И подругому я не удиел. Только в приерах на форумах.
Хотя о чем говорить. Борцы за "чистые руки и холодное сердце" тоже нихрена не знают как должен выглядить грамотно написанный код. А код должен был бы выглядеть вотк как-то так:
if (Clipboard.ContainsText())
this.SelectedText = Clipboard.GetText();
Это кстати, почти рабочий C#-код. Замени this на имя тексбокса из ВыньФормсов и вставь его в кнопку, и уверен, что он заработает.
Так что понятия о декомпозиции и инкапсуляции не имеют не только те простые смертные что пишут код для Синтилы и других проектов, но и те кто поет песни про кривые руки.
ЗЫ
Кстати, даже беглый взгляд говорит, что исходный алгоритм угрохан к чертям. Работать твой код не будет точно. Добланные кулхацкеры писавшие синтилу для "оптимизации" хрянят текст перемежая символ текста с символом формата. Ты же на это забил решив сэкономить место. В итоге полностью угробил код. А до разумног решения произвести декомпозицию и выделить сущьности так и не допер.
Так что после такой оптимизации мне бедному прийдется еще ночь не спать, чтобы заствить это работать. И тогда я или просто откачу старую версию из сорс-контрола, или со злости перепишу это все к чертовой матери на нашрпе без этого гемороя.
По всей видимости если уж не на Шрапе, то на МС++ точно переписывать прийдется. Так как хочется чтобы небыло проблемы при запуске в 64-бытных дотнетных приложениях. А если будут зацепки на платформу, то ничего не выйдет.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>См. выделенное выше. Это еще не вошло в билд, который есть у тебя. Но спецификация еще может измениться. И не раз
Ясно. Работать будешь тоже на спецификации? Уже вторая бэта на носу. А они продукт до альфы не довели. Это уже не смешно.
Тут же проблема концептуальная. И заплатками ее не выличить. Не могут они запретить вызывать диспоз и приводить ссылку к указателю на интерфейс. Иначе нарушаются концепции. Так что это я в общем-то стебаюсь над твоей верой в лучшее.
Я тут попробовал рельно поработать на C++/CLI и могу с уверенностью сказать, что разумные люди это дело ни для чего большего чем для переноса/интеропа использовать его не будут.
С++-ный код компилируется более менее сносно. Но как только речь доходит до написания дотнетгого кода, то наступает базац. Комплит ворд и подсказки не работают. С перекрытием имен полный абзац. Избавиться от зависимости от платформы не удается. В общем, задница на ровном месте. И рядом Шарп без единой подобной проблемы. "Да на хрен мне все ваши шаблоны при таком геморе?" — скажет разумный программист и будет прав.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Речь не о том, как "вылечить" (это вполне несложно, когда ошибка локализована), а о том, что проблемы с забытым вызовом Dispose существуют, и доставляют вполне реальные неприятности.
Речь о том, что ты переворачивашь все с точностью на оборот. Ошибки подобного рода в Шарпе редкость и ловятся они в лет (если конечно человек притендует на среднее знание дотнета). А вот плюсовый код подобный Синтиловскому встречается сплошь и рядом и ошибки вызванные тем, что какой-то долболом использовал memcpy для копирования строк и не удосужился написать "len * sazeof(char)", а еще лучше вынести это дерьмо в отдельную функцию, встречается сплошь и рядом. И искать такие ошибки (проходы по памяти) ой как не просто. Тут ошибки уже приходится чуять.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 пишет:
> C>А давайте ее чуть-чуть перепишем: > Давай. Куда тебе прислать код? Завтра вернешь переисанным.
Насчет "завтра" не обещаю (времени — почти 0), но к следующей неделе
сделаю. mailto:cyberax@elewise.com
> И пожалуйства без разных внешних библиотек, а то из-за твоих правок не > охота получать гемаррой в виде их поиска и подключения.
Ага, а ты напиши программу на .NET без использования .NET-фреймворка. Идет?
> C>У меня тут наверняка куча ошибок, > Даже не сомневаюсь. Как минимум нет обработки ошибкок, что превращает > в общем-то неважную операцию в потенциальный вылет всей прграммы.
Есть. У меня ошибки вызовут исключение, которое будет _корректно_
обработано и выпущено дальше из метода.
> Хотя о чем говорить. Борцы за "чистые руки и холодное сердце" тоже > нихрена не знают как должен выглядить грамотно написанный код. А код > должен был бы выглядеть вотк как-то так: > >if (Clipboard.ContainsText()) > this.SelectedText = Clipboard.GetText(); > > > Это кстати, почти рабочий C#-код. Замени this на имя тексбокса из > ВыньФормсов и вставь его в кнопку, и уверен, что он заработает.
Ага. А для Ansi/Unicode-версий он работает? Примерно так выглядел бы и
код на С++, если не надо было бы думать о преобразованиях кодировок и т.п.
> Кстати, даже беглый взгляд говорит, что исходный алгоритм угрохан к > чертям. Работать твой код не будет точно. Добланные кулхацкеры > писавшие синтилу для "оптимизации" хрянят текст перемежая символ > текста с символом формата. Ты же на это забил решив сэкономить место. > В итоге полностью угробил код. А до разумног решения произвести > декомпозицию и выделить сущьности так и не допер.
Я понял что они там хотели сделать, и написал код, который вроде бы
должен работать. То что остальная кривизна кода не даст ему работать —
не показатель.
> Так что после такой оптимизации мне бедному прийдется еще ночь не > спать, чтобы заствить это работать. И тогда я или просто откачу старую > версию из сорс-контрола, или со злости перепишу это все к чертовой > матери на нашрпе без этого гемороя.
Я точно так же пару раз нафиг переписывал индусский код на Java. И что?
VladD2,
> ПК> Речь не о том, как "вылечить" (это вполне несложно, когда ошибка локализована), а о том, что проблемы с забытым вызовом Dispose существуют, и доставляют вполне реальные неприятности.
> Речь о том, что ты переворачивашь все с точностью на оборот. Ошибки подобного рода в Шарпе редкость и ловятся они в лет (если конечно человек притендует на среднее знание дотнета).
Ага. И нарушения инвариантов классов при исключениях из-за отсутствия поддержки транзакций тоже ловятся влет. Щаз Первое ловится более-менее влет только если ты знаешь, какой конкретно Dispose не вызывается. А если на Dispose завязана логика, а не только ресурсы, то все намного хуже, т.к. программа просто ведет себя неправильно. Где — Типа стрельбы по памяти, только без падений программы.
> А вот плюсовый код подобный Синтиловскому встречается сплошь и рядом <...>
Мы это уже обсуждали: мне интересно, что дает язык хорошему программисту, а не как он защищает от происков программистов плохих, т.к. мне больше нравится работать с первыми. Т.е. примеры сколь угодно плохого кода можешь мне не приводить — я их не читаю.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
> ПК>См. выделенное выше. Это еще не вошло в билд, который есть у тебя. Но спецификация еще может измениться. И не раз
> Ясно. Работать будешь тоже на спецификации?
Только что общался с разработчиками. Если не получится их убедить, что есть валидные use cases для прямого использования IDisposable и Dispose() в C++/CLI (пока, похоже, не получается), то в релизе будет именно так, как сейчас в спецификации.
> Я тут попробовал рельно поработать на C++/CLI и могу с уверенностью сказать, что разумные люди это дело ни для чего большего чем для переноса/интеропа использовать его не будут.
Интересно, интересно...
> С++-ный код компилируется более менее сносно. Но как только речь доходит до написания дотнетгого кода, то наступает базац. Комплит ворд и подсказки не работают. <...>
А... Опять про "интеллисенс"? Не интересно. Пол-работы, сам знаешь кому, не показывают. Следующий
> Избавиться от зависимости от платформы не удается.
Не вижу, чем в этом отношении C++/CLI отличается от C#.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Cyberax, Вы писали:
C>Ага, а ты напиши программу на .NET без использования .NET-фреймворка. Идет?
Идет. Сколько денег заплатишь?
C>Есть. У меня ошибки вызовут исключение, которое будет _корректно_ C>обработано и выпущено дальше из метода.
Кем? Не нужно придумывать.
C>Ага. А для Ansi/Unicode-версий он работает?
Да. Инкапсуляция, знаете ли.
C> Примерно так выглядел бы и C>код на С++, если не надо было бы думать о преобразованиях кодировок и т.п.
И что тебе помешало сделать его нормальным?
C>Я понял что они там хотели сделать, и написал код, который вроде бы C>должен работать. То что остальная кривизна кода не даст ему работать — C>не показатель.
Очень даже показатель. Показатель реальной картины. А вот рассказы о корректном программировании в большинстве случаев только в форумах и останутся.
C>Я точно так же пару раз нафиг переписывал индусский код на Java. И что?
То что на яве ты хотя бы не поймашь проход по памяти. Да и память не потеряшь. Нассчитана она на неидельных прграммистов.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>А... Опять про "интеллисенс"? Не интересно. Пол-работы, сам знаешь кому, не показывают. Следующий
Да он родимый. Без него производительность снижается на два пордка. Передай господам разработчикам, что если интилисенс будет глючить так же в релизе, то их продуктом кроме фанатов никто больше пользоваться не будет.
Если им нужны тестовые примеры, то могу прислать переведенный мною под МС++ синтиловский код.
>> Избавиться от зависимости от платформы не удается.
ПК>Не вижу, чем в этом отношении C++/CLI отличается от C#.
Тем что их в нем нет! Все связи с анменеджед-миром явно описаны в виде DllImport. А в МС++ даже нет возможности выбрать платформу "Any CPU".
Ихние же библиотеки вроде Авалона отказываются запускаться в 64-битном фрэйворке только потому, что в них есть С++-ный код.
Перенос чисто Шарповского приложения невызвает никаких пробелм. Нужно только заменить int/uint на IntPtr (если такие имеются). А если есть С++-ный код, то нужно создавать два вида сборок (32/64) и подгружать их по условию. Все это трах на ровном месте. Никаких реальных ограничений нет. Это кривизна реализации МС++ и выбранных в нем подходов.
Что стоит только то, что такой код:
public ref class Scintilla : public Control
{
protected:
property virtual TCreateParams ^ CreateParams
{
TCreateParams ^ get()
{
TCreateParams ^ prms = CreateParams;
prms->ClassName = "Scintilla";
return prms;
}
}
VladD2 пишет:
> C>Ага, а ты напиши программу на .NET без использования > .NET-фреймворка. Идет? > Идет. Сколько денег заплатишь?
Столько же, сколько ты заплатишь мне за программу на С++, работающую без
сторонних библиотек.
> C>Есть. У меня ошибки вызовут исключение, которое будет _корректно_ > C>обработано и выпущено дальше из метода. > Кем? Не нужно придумывать.
ON_BLOCK_EXIT вызовет нужные деструкторы, а вызывающий должен обработать
вылетевшие исключения.
> C>Ага. А для Ansi/Unicode-версий он работает? > Да. Инкапсуляция, знаете ли.
Нет, в C# просто все строки уникодные
> C> Примерно так выглядел бы и > C>код на С++, если не надо было бы думать о преобразованиях кодировок > и т.п. > И что тебе помешало сделать его нормальным?
Я пытался перевести код "близко к тексту", не особо вникая в его смысл.
> C>Я понял что они там хотели сделать, и написал код, который вроде бы > C>должен работать. То что остальная кривизна кода не даст ему работать — > C>не показатель. > Очень даже показатель. Показатель реальной картины. А вот рассказы о > корректном программировании в большинстве случаев только в форумах и > останутся.
Почему же, я вот нормальный код пишу
> C>Я точно так же пару раз нафиг переписывал индусский код на Java. И что? > То что на яве ты хотя бы не поймашь проход по памяти. Да и память не > потеряшь. Нассчитана она на неидельных прграммистов.
Агащаз. Встречались индусы, которые очень любили статические переменные
(типа theLastError и errorVector). Утечек памяти было вагон.
Здравствуйте, Cyberax, Вы писали:
C>VladD2 пишет:
>> C>Ага, а ты напиши программу на .NET без использования >> .NET-фреймворка. Идет? >> Идет. Сколько денег заплатишь?
C>Столько же, сколько ты заплатишь мне за программу на С++, работающую без C>сторонних библиотек.
А сколько надо заплатить за то чтобы простой C++ работал с framework.
if(Request["importfile"] == "yes")
{
try
{
CreateMatchTable(Request["id"]);
stepSecond.Visible = true;
vewMain.Visible = false;
}
catch(Exception err)
{
String strSQL;
strSQL = "update tblImportFiles set Status = 'E' where File_ID = "+
Request["id"];
OleDbConnection objConnect = new OleDbConnection(
Functions.get_setting("ConnectionString","MISSING CONNECTION STRING"));
objConnect.Open();
OleDbCommand objCommand = new OleDbCommand(strSQL,objConnect);
objCommand.ExecuteNonQuery();
objConnect.Close();
msgPanel.InnerHtml = "An exception of type " + err.GetType() +
" was encountered while connecting to data file.";
}
}
У меня таких перлов из реальных проектов на C#, которые давали мне на "лечение", тонна. Это что-нибудь доказывает? Какая нахрен разница — какой язык. Пургу одинаково легко нести на любом ЯП.
Здравствуйте, AndrewVK, Вы писали:
AVK>Я тебе, как суровый практик, могу сказать: using хватает выше крыши. Не встречал еще ни одной реальной проблемы, связанной с забытым юзингом.
А у нас встречается периодически (кроме классов из фреймворка, у нас существует много хелперов, работающих на IDisposable). Не то чтобы это было фатально (обычно легко найти), но все-таки.
Типа стрельбы по памяти, только без падений программы.
