Хочу узнать мнение народа о будущем С++/CLI. Просмотрел интервью Герба Саттера (гл. архитектор С++) с Channel 9 на MSDN. Я так понял, что С++ будет мощным языком для платформы .NET, безопасным и дающим больше возможностей при работе например с generics. Интересно, а он будет поддерживать стандарт С++ 98го года, т.е. просто добавят новые возможности для работы с .NET ?
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Kisloid пишет:
> Хочу узнать мнение народа о будущем С++/CLI. Просмотрел интервью Герба > Саттера (гл. архитектор С++) с Channel 9 на MSDN. Я так понял, что С++ > будет мощным языком для платформы .NET, безопасным и дающим больше > возможностей при работе например с generics. Интересно, а он будет > поддерживать стандарт С++ 98го года, т.е. просто добавят новые > возможности для работы с .NET ?
Это будет уже не С++, а нечто. Убрали самые важные компоненты языка:
автоматические объекты и детерминированные деструкторы.
C>Это будет уже не С++, а нечто. Убрали самые важные компоненты языка: C>автоматические объекты и детерминированные деструкторы.
А по-русски можно, пожалуйста? А то я в терминах не силен.
Здравствуйте, Cyberax, Вы писали:
C>Это будет уже не С++, а нечто. Убрали самые важные компоненты языка: C>автоматические объекты и детерминированные деструкторы.
Здравствуйте, ansi, Вы писали:
C>>Это будет уже не С++, а нечто. Убрали самые важные компоненты языка: C>>автоматические объекты и детерминированные деструкторы. A>А по-русски можно, пожалуйста? А то я в терминах не силен.
. Там как раз таки весь смысл в автоматических (стековых) переменных — создаете вы их сами, а уничтожаются они деструктором — причем как раз таки {b]детерминированно[/b] — грубо говоря, всегдя можно сказать когда и в какой последовательности будут уничтожены стековые объекты. В CLI же деструкторов нету (есть этот невменяемый Dispose, кажись) и все оюъекты (которые, к тому же, в общем случае, создаются в куче) убиваются GC — но уже нельзя сказать ни о последовательности их умерщвления, ни о том, когда они будут уничтожены.
Это и представляет большую проблему — к примеру, нельзя просто написать менеджед-wrapper анменеджед ресурсов — к примеру, класс File. Ведь по логике деструктор должон осмободить дескриптор (ну и файл закрыть) — ан нет. То есть закрыть то он закроет, но непонятно когда. Посему заметьте интерфейс IDisposable и конструкцию using.
Это просто пример для файла. А ведь есть еще соединения с БД, всякие объекты ядра/GDI...
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, igna, Вы писали:
I>Здравствуйте, Cyberax, Вы писали:
C>>Это будет уже не С++, а нечто. Убрали самые важные компоненты языка: C>>автоматические объекты и детерминированные деструкторы.
I>Разве?
I>http://msdn.microsoft.com/visualc/homepageheadlines/ecma/
Здравствуйте, nikogo, Вы писали:
N>А конкретнее можно?
18.11 Destructors and finalizers
Any native class or ref class can have a user-defined destructor. Such destructors are run at the times
specified by the C++ Standard:
• An Object of any type allocated on the stack is destroyed when that Object goes out of scope.
• An Object of any type allocated in static storage is destroyed during program termination. 10
• An Object that is allocated on the native heap using new, is destroyed when a delete is performed
on a pointer to that Object.
• An Object that is allocated on the CLI heap using gcnew, is destroyed when a delete is performed
on a handle to that Object.
• An Object that is a member of another Object is destroyed as part of the destruction of the enclosing 15
Object.
For the purposes of destruction, the native and CLI heaps are treated the same. The only difference between
the two heaps is the automation and timing of memory reclamation. In the case of the native heap, memory
is reclaimed manually at the same time as the delete, while in the case of the CLI heap, memory is
reclaimed automatically during garbage collection whether or not there was a delete. In addition, Objects 20
on the CLI heap are finalized, if a finalizer exists.
Any ref class can have a user-defined finalizer. The finalizer is run zero or more times by the garbage
collector, as specified by the CLI.
Здравствуйте, Kisloid, Вы писали:
K>Хочу узнать мнение народа о будущем С++/CLI. Просмотрел интервью Герба Саттера (гл. архитектор С++) с Channel 9 на MSDN. Я так понял, что С++ будет мощным языком для платформы .NET, безопасным и дающим больше возможностей при работе например с generics. Интересно, а он будет поддерживать стандарт С++ 98го года, т.е. просто добавят новые возможности для работы с .NET ?
Огромное будуйщее. Бизнес-приложения на нем не советую. С# значительно стройней, сохраняет нас от возможностей ошибиться убирая многие детали.
С++/CLI — более системное управление объектами в памяти, простота работы с unmanagement. Но обладает некоторым недостатком, его возможности намного превосходят стандарты CLS (соответсвенно, легко наткнутся на непереносимость модулей из другого языка, хотя и есть ). И он более сложен (введены различные типы ссылок и указателей).
По этому поводу был огромный флейм в котором я подредактировал свое мнение по поводу C++/CLI. Можно читать начиная с: здесь
Здравствуйте, GlebZ, Вы писали:
GZ>Огромное будуйщее. Бизнес-приложения на нем не советую. С# значительно стройней, сохраняет нас от возможностей ошибиться убирая многие детали. GZ>С++/CLI — более системное управление объектами в памяти, простота работы с unmanagement. Но обладает некоторым недостатком, его возможности намного превосходят стандарты CLS (соответсвенно, легко наткнутся на непереносимость модулей из другого языка, хотя и есть ). И он более сложен (введены различные типы ссылок и указателей).
, а просто перекрасили в соответствии с моделью CLI.
> A>А по-русски можно, пожалуйста? А то я в терминах не силен.
> В CLI же деструкторов нету (есть этот невменяемый Dispose, кажись) и все оюъекты (которые, к тому же, в общем случае, создаются в куче) убиваются GC — но уже нельзя сказать ни о последовательности их умерщвления, ни о том, когда они будут уничтожены.
Согласен. Однако это не означает, что какой-нибудь язык не может сделать так, чтобы невменяемый Dispose стал вполне вменяемым, связав его с деструкторами. Именно так и сделали в C++/CLI: там деструкторы ref классов связаны именно с Dispose, а не с Finalize, как это почему-то сделали в C#. И деструкторы, как и везде в C++, автоматически вызываются для локальных, глобальных переменных, членов классов и т.п. Поэтому, сохраняя принятые в C++ идиомы управления ресурсами (RAII), можно быть вполне уверенным в последовательности освобождения ресурсов в т.ч. и при программировании под CLI.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Kisloid, Вы писали:
K>Хочу узнать мнение народа о будущем С++/CLI. Просмотрел интервью Герба Саттера (гл. архитектор С++) с Channel 9 на MSDN. Я так понял, что С++ будет мощным языком для платформы .NET, безопасным и дающим больше возможностей при работе например с generics. Интересно, а он будет поддерживать стандарт С++ 98го года, т.е. просто добавят новые возможности для работы с .NET ?
Насколько мне известно к первому релизу полной поддержки дженериков не будет, так как констрэйны к ним пока еще не прикрутили.
И вообще складывается полное впечатление, что поддержика нового стиля явно пока недоработана.
Ну, а как язык. На МС++ тоже можно было писать дотнетные програмы. Но народ обычно предпочитал Шарп или Жлабэйсик.
Думаю новая версия МС++ будет востребована впервую очередь теми кто слишком сильно прикипели к С++ и не жалают расставаться с любимым языком. Таких не мало. Так что можно точно сказать, что он будет более востребован нежелни первая версия МС++.
Ну, а в тотальную гегемонию МС++ что-то не верится. Никаких реальных преимуществ перед Шарпом или ВБ в области создания чисто менеджед приложений у него не будет. А граматического мусора в коде будет призрядно. В купе с тем, что МС++ хуже интегрируется в разные средства автоматизации вроде IDE и MSBuild — это оттолкнет от него тех кто не был связан долгие годы с С++. Да и многие С++-ники в итоге перейдут на Шарп.
Ну, а где МС++ будет бесспорным лидером — это совершенно понятно. В области переноса С++-приложений под дотнет. Тут у него конкурентов нет. Ведь можно будет практически без переписывания откомпилировать обычное Виндвс-приложение на МС++ и получить возможность расширять приложения всеми средствами доступными в дотнете.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Это будет уже не С++, а нечто. Убрали самые важные компоненты языка: C>автоматические объекты и детерминированные деструкторы.
Не нужно придумывать. Ничего никуда не убрали. В язык встроили дополнительные средства для общения с управляемым миром.
Деструкторы же наоборот приделали даже к менеджед-обхектам.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Нахлобуч, Вы писали:
Н>Здравствуйте, ansi, Вы писали:
C>>>Это будет уже не С++, а нечто. Убрали самые важные компоненты языка: C>>>автоматические объекты и детерминированные деструкторы. A>>А по-русски можно, пожалуйста? А то я в терминах не силен.
Н>Посмотри Gdi Objects Selector
. Там как раз таки весь смысл в автоматических (стековых) переменных — создаете вы их сами, а уничтожаются они деструктором — причем как раз таки {b]детерминированно[/b] — грубо говоря, всегдя можно сказать когда и в какой последовательности будут уничтожены стековые объекты.
Да уж. Супер технология. И как живут GDI+ с Авалоном?...
Н>В CLI же деструкторов нету (есть этот невменяемый Dispose, кажись) и все оюъекты (которые, к тому же, в общем случае, создаются в куче) убиваются GC — но уже нельзя сказать ни о последовательности их умерщвления, ни о том, когда они будут уничтожены.
Трепач находка для шпионов. (с) Ну, или иногда лучше молчать чем говорить. (с)
Отличительной особенностью новой вресии МС++ (С++/CLI) о которой идет речь в этой ветке как раз является возможность эмуляции деструкторов у управляемых объектов реализующих IDispose. Возможность использовать деструкторы у С++-объектов была с самого начала. Так что прежде чем начинать строить обвинительные заключения нужно хотя бы немгожко разобраться в теме. В этом форуме, кстати, не раз поднимался этот вопрос.
Н>Это и представляет большую проблему — к примеру, нельзя просто написать менеджед-wrapper анменеджед ресурсов — к примеру, класс File.
Мля, не только можно, но и ненужно. Вернее бессмысленно, так как любой объект реализующий IDispose можно просто использовать как стэковую переменную. Правда класса "File" в природе не существуют, но классы вроде FileStream или StreamReader можно спокойно объявлять таким образом:
И по выходу из области видимости у streamReader будет автоматически вызван Dispose().
Н> Ведь по логике деструктор должон осмободить дескриптор (ну и файл закрыть) — ан не Н>т. То есть закрыть то он закроет, но непонятно когда. Посему заметьте интерфейс IDisposable и конструкцию using. Н>Это просто пример для файла. А ведь есть еще соединения с БД, всякие объекты ядра/GDI...
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Честно говоря, из этой спеки я не особо понял сементику вызова C>деструкторов и их отношение к финализаторам. Буду рад, если я ошибаюсь.
VladD2,
> Насколько мне известно к первому релизу полной поддержки дженериков не будет,
Что такое полная поддержка generics — вопрос спорный. Полагаю, что подразумевается поддержка всех возможностей, доступных из C#. В этом смысле можно сказать, что возможностей и больше, и меньше одновременно: часть возможностей отсутствует, но есть некоторые дополнительные.
> так как констрэйны к ним пока еще не прикрутили.
Interface constraints есть, нет constraints value class и new. Насколько необходимо первое — вопрос открытый; очень желательно — 100%, но при дополнительных возможностях C++/CLI, по идее без них прожить можно. Второе легко обеспечивается прямым использованием Activator. Так что, имхо, ничего страшного.
> Ну, а где МС++ будет бесспорным лидером — это совершенно понятно. В области переноса С++-приложений под дотнет.
Не только. Т.к. в управлении ресурсами C++/CLI (на сегодня) дает больше возможностей, чем любые другие языки под .Net, и т.к. в нем заметно больше выразительных возможностей в определенных моментах (шаблоны, управляемые ссылки и т.п.), то можно предположить, что также C++/CLI будет более удобным еще в ряде случаев, вне зависимости от взаимодействия с неуправляемым кодом.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Kisloid, Вы писали:
K>Здравствуйте, GlebZ, Вы писали:
GZ>>Огромное будуйщее. Бизнес-приложения на нем не советую. С# значительно стройней, сохраняет нас от возможностей ошибиться убирая многие детали. GZ>>С++/CLI — более системное управление объектами в памяти, простота работы с unmanagement. Но обладает некоторым недостатком, его возможности намного превосходят стандарты CLS (соответсвенно, легко наткнутся на непереносимость модулей из другого языка, хотя и есть ). И он более сложен (введены различные типы ссылок и указателей).
K>Слушай, а что это такое : здесь
или твое мнение изменилось, и если да то почему ?
Да. Просто я узнал C++/CLI поближе. Пришлось изменить свое мнение. Синтаксис значительно улучшен по сравнению MC++. Даже лучше сказать, полностью переделан.
Что касается переноса приложений с С++, то я все равно голосую за С#. Переводить под С++/CLI — все равно нужно достаточно много потрудиться (хотя и меньше чем в MC++). Система ссылок и указателей для менеджед не такая как в обычных C++. Язык с его множеством указателей и ссылок достаточно сложен. Перевод на C# не слишком более сложен, но после этого можно получить читабельную, и стройно выстроенную программу. Но что касается взаимодействия с unmanaged кодом и адресацией по всем объектам(особенно value) — показывает что для системных вещей взаимодействия с unmanaged и небольших программ в которых производительность должна быть выше обычного — конкурентов нет (разве что писать сразу на CLI ).
Еще, с первого раза, мне не удалось выявить сразу стройную систему, когда код является верифицируемым, и когда он не является верифицируемым. Можно это списать на раннюю бету, которая стоит у меня. Надеюсь в дальнейшем это будет четко описано в документации. Но это также говорит о сложности языка для бизнес-приложений. Бизнес-приложения должны строится на безопасном, простом для refactoring, языке.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>VladD2,
>> Насколько мне известно к первому релизу полной поддержки дженериков не будет,
ПК>Что такое полная поддержка generics — вопрос спорный.
Не, вопрос элементарный. Полная — это так что есть в Шарпе. Причем просто потому, что она для него и делалась. Это уже потом решили всунуть их всюду. Отсюда и неполная поддержка плюсами.
ПК>Interface constraints есть, нет constraints value class и new. Насколько необходимо первое — вопрос открытый; очень желательно — 100%, но при дополнительных возможностях C++/CLI, по идее без них прожить можно. Второе легко обеспечивается прямым использованием Activator. Так что, имхо, ничего страшного.
Причем тут активатор? Ты не можешь описать всех возможностей предоставляемых дженериками. А значит не сможешь описать некоторые из дженериков. Так что Activator прийдется пользоваться уже в других языках.
>> Ну, а где МС++ будет бесспорным лидером — это совершенно понятно. В области переноса С++-приложений под дотнет.
ПК>Не только. Т.к. в управлении ресурсами C++/CLI (на сегодня) дает больше возможностей, чем любые другие языки под .Net,
Продолжай верить в свои сказки дальше. Я уже устал говорить, что проблемы с управлением ресурсами возникают только в интеропе.
ПК> и т.к. в нем заметно больше выразительных возможностей
И чё все строем не ходят?
ПК> в определенных моментах (шаблоны, управляемые ссылки и т.п.), то можно предположить, что также C++/CLI будет более удобным еще в ряде случаев, вне зависимости от взаимодействия с неуправляемым кодом.
Ну, естественно. Если нужно будет числа подробить на максимальной скорости, то всегда можно будет на МС++ кусок кода пометить анменеджед. Но об этом я вроде говорил. Ты просто пропустил.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК> Что такое полная поддержка generics — вопрос спорный.
> Не, вопрос элементарный. Полная — это так что есть в Шарпе. Причем просто потому, что она для него и делалась.
Может, и так, но тот же C# поддерживает не все возможности generics.
> ПК> в управлении ресурсами C++/CLI (на сегодня) дает больше возможностей, чем любые другие языки под .Net,
> Продолжай верить в свои сказки дальше. Я уже устал говорить, что проблемы с управлением ресурсами возникают только в интеропе.
Не смешно. Даже если представить, что все целиком насквозь managed, как ты будешь закрывать сокет, соединение с базой данных или файл, о котором run-time понятия не имеет?
> Если нужно будет числа подробить на максимальной скорости, то всегда можно будет на МС++ кусок кода пометить анменеджед.
Речь далеко не только и не столько о дроблении чисел на максимальной скорости.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Не смешно. Даже если представить, что все целиком насквозь managed, как ты будешь закрывать сокет, соединение с базой данных или файл, о котором run-time понятия не имеет?
Я тебе, как суровый практик, могу сказать: using хватает выше крыши. Не встречал еще ни одной реальной проблемы, связанной с забытым юзингом.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Может, и так, но тот же C# поддерживает не все возможности generics.
Точно, Пашь. Причем когда специально для Шарпа придумывали джененики, то долго думали, как бы так извернуться, чтобы придумать для них такие возможности, чтобы в нем нельзя использовать было.
ПК>Не смешно.
За то про вайну.
ПК> Даже если представить, что все целиком насквозь managed,
И как такое предстваить?
ПК> как ты будешь закрывать сокет, соединение с базой данных или файл, о котором run-time понятия не имеет?
Я даже не знаю. Видимо буду тебе мылить. Я их поткрываю, а ты будешь дозакрывать.
Ну, действительно уже не смешно. Единственное с чем у меня в последнее время небыло проблем — это с закрытием чего бы то нибыло. Вот давича несколько файлов открывал и ты не поверишь... они сабаки как один закрылись, даже скучано как-то. А вот решил у одного из них стрибут поменять, вот тут действительно веселье настала. Ресурсты тыут не причем, но пол ночи убли. Под утро только понял, что какая-то скатина не умеет грамотно сообщения об ошибке писать. Я то грешным делом думал, что у меня руки кривые, а оказалось, что всего лишь на файле защиту поставили (только на чтение). Еще поприкалывало, то как FAT даты воспринимает. В общем, много веселого. Но вот с закрытием файлов что-то скучно. С сокетами та же хрень, только их еще открывать не приходится.
В Янусе вон целая туча соеденений с БД, и хоть бы раз от этого проблема возникла. С событиями и то их больше было.
ПК>Речь далеко не только и не столько о дроблении чисел на максимальной скорости.
Ну, дык. Осталось в этом убедить остальный. Пашь, ну, глянь не те же библиотеки к Лонгхорну. МС++ там имеется только в тех местах где идет суровый интероп. А это процентов 5 от силы. Остльное голимый шарп. Думаешь у них проблемы с С++-программистами?
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
AndrewVK,
> Я тебе, как суровый практик, могу сказать: using хватает выше крыши. Не встречал еще ни одной реальной проблемы, связанной с забытым юзингом.
А с забытым вызовом Dispose для подобъекта? Или с вызовом Dispose для частично сконструированного объекта? Или с неправильно реализованной Dispose Pattern?
Posted via RSDN NNTP Server 2.0 alpha
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
>> Я тебе, как суровый практик, могу сказать: using хватает выше крыши. Не встречал еще ни одной реальной проблемы, связанной с забытым юзингом.
ПК>А с забытым вызовом Dispose для подобъекта? Или с вызовом Dispose для частично сконструированного объекта? Или с неправильно реализованной Dispose Pattern?
VladD2,
> ПК> Может, и так, но тот же C# поддерживает не все возможности generics.
> Точно, Пашь. Причем когда специально для Шарпа придумывали джененики, то долго думали, как бы так извернуться, чтобы придумать для них такие возможности, чтобы в нем нельзя использовать было.
Это демагогия. Реальность же состоит в том, что C# не поддерживает некоторые из возможностей generics. Например, ковариантные и контравариантные generic параметры (см. Common Language Infrastructure (CLI) Partition II: Metadata Definition and Semantics, 9.5 Generics variance).
Posted via RSDN NNTP Server 2.0 alpha
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>А с забытым вызовом Dispose для подобъекта? Или с вызовом Dispose для частично сконструированного объекта? Или с неправильно реализованной Dispose Pattern?
Кагда же ты поймешь, что нет этой проблемы? Случаи когда нужно вручную реализовывать Dispose очень редки. Грамотные люди обычно стараются не делать никаких вложенных диспозов. Диспозы есть только у анменеджед-ресурсов коих в программах где нет сурового интеропа просто мизер.
Скачай исходники R#-а... погляди сколько там диспозов. Или глянь на Янус (там почти все вызовы диспозов сгенерированы дизайнером).
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
ПК> А с забытым вызовом Dispose для подобъекта? Или с вызовом Dispose для частично сконструированного объекта? Или с неправильно реализованной Dispose Pattern?
> Кагда же ты поймешь, что нет этой проблемы? <...> Скачай исходники R#-а... погляди сколько там диспозов. Или глянь на Янус (там почти все вызовы диспозов сгенерированы дизайнером).
На R# глядеть не стал — лень устанавливать 7-zip. Глянул на Янус. Не впечатлило:
1) Последняя выделенная scrollBitmap всегда остается неосвобожденной, т.к. Dispose у ScrollingLine нет.
2) При исключении между точками 1 и 2 выделенная Bitmap утекает (Dispose для нее вызван не будет).
public class DockPanel : Panel
{
. . .
public DockPanel()
{
m_dragHandler = new DragHandler(this);
m_panes = new DockPaneCollection(); // <-- 1
m_floatWindows = new FloatWindowCollection(); // <-- 2
. . .
m_localWindowsHook = new LocalWindowsHook(HookType.WH_CALLWNDPROCRET);
// <-- 3
m_localWindowsHook.HookInvoked += new LocalWindowsHook.HookEventHandler(this.HookEventHandler);
m_localWindowsHook.Install();
m_dummyContent = new DockContent(); // <-- 4
ResumeLayout();
// <-- 5
}
. . .
protected override void Dispose(bool disposing)
{
if (!m_disposed)
{
try
{
if (disposing)
{
FloatWindows.Dispose();
Panes.Dispose();
DummyContent.Dispose();
}
m_localWindowsHook.Uninstall();
m_disposed = true;
}
finally
{
base.Dispose(disposing);
}
}
}
В случае исключения где-нибудь по дороге между точкой 1 и 5 "утекут" ранее выделенные ресурсы (для них не будет вызван Dispose).
И т.п.
В общем, классические грабли управления ресурсами вручную.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2 пишет:
> Ты случаем про финализаторы не забыл? Если что за нами быстро > подгребут. Можеш ради хомы попробовать в цикле битмапы создавать. > Например, так: > >private void button1_Click(object sender, EventArgs e) >{ > System.Threading.Thread.CurrentThread.Priority--; > > while (true) > new System.Drawing.Bitmap(20, 20); >} > > А потом ради той же хохмы попробуй сделать тоже самое на обычных плюсах.
> Серьезно следить нужно только за блокирющимися ресурсами вроде файлов > или каналов. И то ошибки подобного рода становятся видны очень быстро.
Сама возможность ошибки — уже плохо.
> А код разные люди пишут. Такие с тем же успехом будут вручню new и > delete звать. Так что уж лучше за ними ЖЦ подбирет, чем программа > грохнится.
А delete вообще руками в С++ можно не вызывать — на это умные указатели
есть.
ЗЫ: отсутствие аналогов умных указателей для детерминированного
управления ресурсами — это практически единственное, что мне жутко не
нравится в C#.
>> Серьезно следить нужно только за блокирющимися ресурсами вроде файлов >> или каналов. И то ошибки подобного рода становятся видны очень быстро.
C>Сама возможность ошибки — уже плохо.
Ну, лучего метода пока не придумали. От человека всегда что-то зависит. А ошибку я могу и на ровном месте влепить.
C>А delete вообще руками в С++ можно не вызывать — на это умные указатели C>есть.
Диспоз в шарпе тоже. Однако умельцы всегда находятся. Особенно в открытых проектах.
C>ЗЫ: отсутствие аналогов умных указателей для детерминированного C>управления ресурсами — это практически единственное, что мне жутко не C>нравится в C#.
Фигня это полная. Хоть бы раз об этом кто вспомнил. Погляди Янусовский форум. Много там об утечках ресурсов разговоров? Если они и есть, то обычно ошибки в библиотеках.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Разница есть — у меня ресурсы утекать не будут.
> C>Сама возможность ошибки — уже плохо. > Ну, лучего метода пока не придумали. От человека всегда что-то > зависит. А ошибку я могу и на ровном месте влепить.
С++ный механизм детерминированного уничтожения объектов как раз от
утечек ресурсов спасает нормально. То есть, если объекты уничтожаются
правильно — то и ресурсы не потекут.
> C>А delete вообще руками в С++ можно не вызывать — на это умные указатели > C>есть. > Диспоз в шарпе тоже. Однако умельцы всегда находятся. Особенно в > открытых проектах.
В том-то и дело, что умные указатели заставляют программиста правильно
их использовать, а вот using можно и забыть поставить.
> C>ЗЫ: отсутствие аналогов умных указателей для детерминированного > C>управления ресурсами — это практически единственное, что мне жутко не > C>нравится в C#. > Фигня это полная. Хоть бы раз об этом кто вспомнил.
Я вспомнил — так что один раз уже есть Более того, даже не раз
натыкался на реальные баги из-за забытых dispose'ов.
> Погляди Янусовский форум. Много там об утечках ресурсов разговоров? > Если они и есть, то обычно ошибки в библиотеках.
Мне еще просто не нравится, что в моей программе могут быть ошибки,
которые обычно не проявляются, но могут при серьезной нагрузке создать
проблемы.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Именно так и сделали в C++/CLI: там деструкторы ref классов связаны именно с Dispose, а не с Finalize, как это почему-то сделали в C#.
А интерфейс автоматом реализуют?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
ПК>>Именно так и сделали в C++/CLI: там деструкторы ref классов связаны именно с Dispose, а не с Finalize, как это почему-то сделали в C#.
IT>А интерфейс автоматом реализуют?
Я бы с удовольствием ответил на вопрос, но, к сожалению, его не понял. О какой именно возможности идет речь?
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>>>Именно так и сделали в C++/CLI: там деструкторы ref классов связаны именно с Dispose, а не с Finalize, как это почему-то сделали в C#.
IT>>А интерфейс автоматом реализуют?
ПК>Я бы с удовольствием ответил на вопрос, но, к сожалению, его не понял. О какой именно возможности идет речь?
Dispose — это единственный метод интерфейса IDisposable. Ты утверждаешь выделенное выше, т.е. чтобы связать класс с Dispose нужно реализовать IDisposable.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Здравствуйте, IT, Вы писали:
ПК>>>Именно так и сделали в C++/CLI: там деструкторы ref классов связаны именно с Dispose, а не с Finalize, как это почему-то сделали в C#.
IT>>А интерфейс автоматом реализуют?
ПК>Я бы с удовольствием ответил на вопрос, но, к сожалению, его не понял. О какой именно возможности идет речь?
Finalize вызывается GC при сборке мусора обрабатывая таблицу объектов требующих финалтзации, Dispose же привязан к IDisposable
который использует например using для автоматического вызова ( при этом таблица очищается при помощи SuppressFinalize)
На верное про ентот интерфейс и идет речь.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
IT,
> ПК>>> Именно так и сделали в C++/CLI: там деструкторы ref классов связаны именно с Dispose, а не с Finalize, как это почему-то сделали в C#.
> IT>> А интерфейс автоматом реализуют?
> ПК> Я бы с удовольствием ответил на вопрос, но, к сожалению, его не понял. О какой именно возможности идет речь?
> Dispose — это единственный метод интерфейса IDisposable. Ты утверждаешь выделенное выше, т.е. чтобы связать класс с Dispose нужно реализовать IDisposable.
Торможу. Видимо, смутило использование слова "реализует": для меня это означает какие-то действия по предоставлению реализаций функций, определенных в интерфейсе — с C# мало общаюсь Ладно, это лирика.
Да, добавление деструктора в ref class добавляет в список базовых интерфейсов неявное наследование от System::IDisposable, если его там еще нет. Плюс, если класс унаследован от System::IDisposable, и программист не предоставил деструктор, он будет определен неявно. Т.е., скажем, при наследовании от IEnumerable, который в свою очередь унаследован от IDisposable, явно прописывать Dispose(), как в C#, не нужно.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
P.S.
> при наследовании от IEnumerable, который в свою очередь унаследован от IDisposable, явно прописывать Dispose(), как в C#, не нужно.
Можно обобщить, что язык непосредственно поддерживает Dispose Pattern, поэтому ручной работы вокруг IDisposable, Dispose(), Dispose(bool) и Finalize() намного меньше по сравнению с VB.Net или C#, если вообще есть.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
>> при наследовании от IEnumerable, который в свою очередь унаследован от IDisposable, явно прописывать Dispose(), как в C#, не нужно.
ПК>Можно обобщить, что язык непосредственно поддерживает Dispose Pattern, поэтому ручной работы вокруг IDisposable, Dispose(), Dispose(bool) и Finalize() намного меньше по сравнению с VB.Net или C#, если вообще есть.
И как я понимаю, для агрегированных значений тоже генерируется вызов Dispose, если они его поддерживают? А если у меня агрегированный объект is object or ArrayList?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Если нам не помогут, то мы тоже никого не пощадим.
IT,
>>> при наследовании от IEnumerable, который в свою очередь унаследован от IDisposable, явно прописывать Dispose(), как в C#, не нужно.
> ПК> Можно обобщить, что язык непосредственно поддерживает Dispose Pattern, поэтому ручной работы вокруг IDisposable, Dispose(), Dispose(bool) и Finalize() намного меньше по сравнению с VB.Net или C#, если вообще есть.
> И как я понимаю, для агрегированных значений тоже генерируется вызов Dispose, если они его поддерживают?
Да, если эти значения прописаны "по значению":
public ref class M
{
public:
~M() { }
};
public ref class C
{
private:
M m;
};
Тем самым мы обозначаем, что класс C является владельцем объекта m, а не просто на него ссылается. Соответственно, если у M есть деструктор (aka Dispose()), как в нашем примере, то для C также будет сгенерирован деструктор (реализована Dispose Pattern), плюс объект m будет автоматически создан в конструкторе.
> А если у меня агрегированный объект is object or ArrayList?
Object "по значению" создать не выйдет, но можно сделать обертку Disposer, которая будет пытаться приводить Object к IDisposable, и хранить ее. В ArrayList тоже "по значению" положить ничего нельзя, но это и не нужно: можно использовать cli::vector<T>, cli::list<T> и т.п., которые умеют работать с Managed типами, и унаследованы от соответствующих интерфейсов .Net.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, IT, Вы писали:
IT>И как я понимаю, для агрегированных значений тоже генерируется вызов Dispose, если они его поддерживают? А если у меня агрегированный объект is object or ArrayList?
Ценное замечание. Нужно срочно сообщить в группу разработки, чтобы они пытались приводить все возможные варианты к диспозу. Ну, на всякий пожарный.
Но вообще-то ПК прав. Интеграция реализации паттернов в язык — это правильно. Чем меньше нужно думать, тем лучше. Все эти навороты по реализации диспоза отнюдь не радуют. Радует, только то что их крайне редко приходится реализовывать вручную. А использование упрощается юсингом (тоже, кстати, встроенная поддержка паттерна).
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> IT> И как я понимаю, для агрегированных значений тоже генерируется вызов Dispose, если они его поддерживают? А если у меня агрегированный объект is object or ArrayList?
> Ценное замечание. Нужно срочно сообщить в группу разработки, чтобы они пытались приводить все возможные варианты к диспозу. Ну, на всякий пожарный.
Так делать нельзя: Object нельзя хранить "по значению", следовательно остается только ссылка/указатель. В этом случае никакой уверенности, что класс, содержащий ссылку, является владельцем объекта, нет. Так можно запросто разрушить чужие данные.
> Все эти навороты по реализации диспоза отнюдь не радуют. Радует, только то что их крайне редко приходится реализовывать вручную.
Недавно на работе ребята полтора дня искали ошибку. Нашли: не вызывался Dispose. Кажется, для одного из членов класса. Finalize был абсолютно бесполезен, т.к. в этом Dispose объект должен был удалять себя из некоего реестра. Т.к. этого не происходило, ссылка на него жила (в реестре), и Finalize, очевидно, никогда не мог быть вызван.
Другая проблема — сохранение инвариантов при возникновении исключений. Т.к. в C# на уровне языка поддержки для автоматизации транзакций нет (худо-бедно, но обеспечиваемой в C++ деструкторами), в итоге после "неожиданного" исключения программа легко может просто перестать работать. Она обычно не вылетает, но и правильно не работает. Вот такие пироги...
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Недавно на работе ребята полтора дня искали ошибку. Нашли: не вызывался Dispose. Кажется, для одного из членов класса. Finalize был абсолютно бесполезен, т.к. в этом Dispose объект должен был удалять себя из некоего реестра. Т.к. этого не происходило, ссылка на него жила (в реестре), и Finalize, очевидно, никогда не мог быть вызван.
Мне интересно, эта ошибка была ошибкой проектирования? То есть от Dispose'ов ожидалось поведение сишных деструкторов? Или я не понял о чем речь?
Там есть существенная неточность в отношении Dispose и Finalize применительно к C++/CLI:
The Dispose(bool) pattern still must be done.
В релизе Whidbey Dipose Pattern будет реализовываться компилятором автоматически. Более того, руками там особо ничего не сделаешь: программа на C++/CLI не сможет явно вызывать функции Dispose(), Dispose(bool) и Finalize(), если они перекрывают функции System::Object::IDisposable::Dispose и System::Object::Finalize.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
>> Ценное замечание. Нужно срочно сообщить в группу разработки, чтобы они пытались приводить все возможные варианты к диспозу. Ну, на всякий пожарный.
ПК>Так делать нельзя:...
Пашь, ну, хоть чуть-чуть юмора то нужно иметь.
ПК>Недавно на работе ребята полтора дня искали ошибку. Нашли: не вызывался Dispose. Кажется, для одного из членов класса. Finalize был абсолютно бесполезен, т.к. в этом Dispose объект должен был удалять себя из некоего реестра. Т.к. этого не происходило, ссылка на него жила (в реестре), и Finalize, очевидно, никогда не мог быть вызван.
У вас случаем на работе фины не работают? Полтора дня искать такую ошибку — это достойно книги гинеса.
ПК>Другая проблема — сохранение инвариантов при возникновении исключений. Т.к. в C# на уровне языка поддержки для автоматизации транзакций нет (худо-бедно, но обеспечиваемой в C++ деструкторами), в итоге после "неожиданного" исключения программа легко может просто перестать работать. Она обычно не вылетает, но и правильно не работает. Вот такие пироги...
Пошь, это уже просто клинический случай предвзятости. Если бы все было как ты описывашь, то все по прежнему писали бы на плюсах и никто на шарп даже не взглянул.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Хитрик Денис, Вы писали:
ХД>Мне интересно, эта ошибка была ошибкой проектирования? То есть от Dispose'ов ожидалось поведение сишных деструкторов? Или я не понял о чем речь?
Дуамаю это проблемы ментолитета. Когда человек 10 лет вынужден был особождать ресурсы, то даже будучи освобожденным от этого он по привычке продолжает строить свой код подобным образом.
В общем, пора писать статью "Жизть после того как память перестала быть ресурсом".
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ХД> Мне интересно, эта ошибка была ошибкой проектирования? То есть от Dispose'ов ожидалось поведение сишных деструкторов? Или я не понял о чем речь?
> Дуамаю это проблемы ментолитета. Когда человек 10 лет вынужден был особождать ресурсы, то даже будучи освобожденным от этого он по привычке продолжает строить свой код подобным образом. В общем, пора писать статью "Жизть после того как память перестала быть ресурсом".
LOL. Один из людей, о которых идет речь, к "плюсам" уже как минимум несколько лет не прикасался, пожалуй, за исключением чтения и мелких правок, и в языках, с которыми он в основном работает, управлять памятью не приходится и близко. Просто (естественно) хочется сделать так, чтобы язык хоть как-то помогал автоматизировать работу, а не выписывать многочисленные паттерны вручную.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Там есть существенная неточность в отношении Dispose и Finalize применительно к C++/CLI: ПК>
ПК>The Dispose(bool) pattern still must be done.
ПК>В релизе Whidbey Dipose Pattern будет реализовываться компилятором автоматически. Более того, руками там особо ничего не сделаешь: программа на C++/CLI не сможет явно вызывать функции Dispose(), Dispose(bool) и Finalize(), если они перекрывают функции System::Object::IDisposable::Dispose и System::Object::Finalize.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>LOL. Один из людей, о которых идет речь, к "плюсам" уже как минимум несколько лет не прикасался, пожалуй, за исключением чтения и мелких правок, и в языках, с которыми он в основном работает, управлять памятью не приходится и близко. Просто (естественно) хочется сделать так, чтобы язык хоть как-то помогал автоматизировать работу, а не выписывать многочисленные паттерны вручную.
После плюсов слова "чтобы язык хоть как-то помогал автоматизировать работу, а не выписывать многочисленные паттерны вручную" звучат как издевательство. Я тут как раз воюю с Синтиловским кодом...
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>В релизе Whidbey Dipose Pattern будет реализовываться компилятором автоматически. Более того, руками там особо ничего не сделаешь: программа на C++/CLI не сможет явно вызывать функции Dispose(), Dispose(bool) и Finalize(), если они перекрывают функции System::Object::IDisposable::Dispose и System::Object::Finalize.
Слабо в это верится. Всегда можно втупую привести объект к IDispose и вызвать метод.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> После плюсов слова "чтобы язык хоть как-то помогал автоматизировать работу, а не выписывать многочисленные паттерны вручную" звучат как издевательство. Я тут как раз воюю с Синтиловским кодом...
Видимо, авторы "Синтиловского кода" "плюсы" готовить не умеют.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
> ПК> В релизе Whidbey Dipose Pattern будет реализовываться компилятором автоматически. Более того, руками там особо ничего не сделаешь: программа на C++/CLI не сможет явно вызывать функции Dispose(), Dispose(bool) и Finalize(), если они перекрывают функции System::Object::IDisposable::Dispose и System::Object::Finalize.
> Слабо в это верится. Всегда можно втупую привести объект к IDispose и вызвать метод.
В C++/CLI (по крайней мере, в текущей спецификации) использовать System::IDisposable напрямую будет нельзя. Компилятор должен будет выдать сообщение об ошибке. Не вижу, как они предполагают обходиться, если будет нужен именно System::IDisposable, но в данный момент это так, как написано выше.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>В C++/CLI (по крайней мере, в текущей спецификации) использовать System::IDisposable напрямую будет нельзя. Компилятор должен будет выдать сообщение об ошибке. Не вижу, как они предполагают обходиться, если будет нужен именно System::IDisposable, но в данный момент это так, как написано выше.
Ну, тогда напиши друзьям занимающимся реализацией этой спецификации, что у них ничего не получилось:
VladD2,
> ПК> В C++/CLI (по крайней мере, в текущей спецификации) использовать System::IDisposable напрямую будет нельзя. Компилятор должен будет выдать сообщение об ошибке. Не вижу, как они предполагают обходиться, если будет нужен именно System::IDisposable, но в данный момент это так, как написано выше.
> Ну, тогда напиши друзьям занимающимся реализацией этой спецификации, что у них ничего не получилось: <...>
См. выделенное выше. Это еще не вошло в билд, который есть у тебя. Но спецификация еще может измениться. И не раз
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2 пишет:
> ПК>Видимо, авторы "Синтиловского кода" "плюсы" готовить не умеют. > А их умею готовить только гуры и то в примерах. А в раельном где > большого проекта всегда попадается подобная фигня:
А давайте ее чуть-чуть перепишем:
void ScintillaWin::Paste() {
if (!::OpenClipboard(MainHWND()))
return;
ON_BLOCK_EXIT(CloseClipboard,MainHWND());
pdoc->BeginUndoAction();
ON_BLOCK_EXIT_OBJ(*pdoc,ScintillaDocument::EndUndoAction);
int selStart = SelectionStart();
ClearSelection();
bool isRectangular = ::IsClipboardFormatAvailable(cfColumnSelect) != 0;
// Always use CF_UNICODETEXT if available
HGLOBAL hmemUSelection = ::GetClipboardData(CF_UNICODETEXT);
if (hmemUSelection) {
wchar_t *uptr = static_cast<wchar_t
*>(::GlobalLock(hmemUSelection));
ON_BLOCK_EXIT(::GlobalUnlock,hmemUSelection);
if (uptr) {
unsigned int len;
std::wstring putf;
unsigned int bytes = ::GlobalSize(hmemUSelection);
putf=std::wstring(uptr,bytes/sizeof(wchar_t));
// Default Scintilla behaviour in Unicode modeif (IsUnicodeMode()) {
if (isRectangular) {
PasteRectangular(selStart, putf.c_str(), len);
} else {
if (pdoc->InsertString(currentPos, putf.c_str(), len)) {
SetEmptySelection(currentPos + len);
}
}
} else {
// CF_UNICODETEXT available, but not in Unicode mode
// Convert from Unicode to current Scintilla code page
std::string converted=convert_from_unicode(putf,
pdoc->dbcsCodePage);
if (isRectangular) {
PasteRectangular(selStart, converted.c_str(), len);
} else {
if (pdoc->InsertString(currentPos,
converted.c_str(), len)) {
SetEmptySelection(currentPos + len);
}
}
}
}
} else {
//I'm bored with it
}
NotifyChange();
Redraw();
}
У меня тут наверняка куча ошибок, но если нормально писать на
современном С++, то код будет выглядеть примерно как у меня.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Торможу. Видимо, смутило использование слова "реализует": для меня это означает какие-то действия по предоставлению реализаций функций, определенных в интерфейсе — с C# мало общаюсь Ладно, это лирика.
Привыкай к терминологии В нете интерфейс это отдельная сущность, а не абстрактный класс, как в плюсах. Поэтому класс не наследует интерфейс, а реализует, и, имхо, это правильно, поскольку наследование реализаций и интерфейсов вещи вобщем то концептуально различные.
ПК>Да, добавление деструктора в ref class добавляет в список базовых интерфейсов неявное наследование от System::IDisposable
Реализацию
ПК>, если его там еще нет. Плюс, если класс унаследован от System::IDisposable
Реализует
ПК>Т.е., скажем, при наследовании от IEnumerable,
Реализации
ПК> который в свою очередь унаследован от IDisposable
А вот здесь правильно.
Это касательно терминологии. Теперь касательно сути — ни в 1.1 ни в 2.0 IEnumerable от IDisposable не наследуется.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Недавно на работе ребята полтора дня искали ошибку. Нашли: не вызывался Dispose. Кажется, для одного из членов класса. Finalize был абсолютно бесполезен, т.к. в этом Dispose объект должен был удалять себя из некоего реестра. Т.к. этого не происходило, ссылка на него жила (в реестре), и Finalize, очевидно, никогда не мог быть вызван.
WeekReference спасет ваших отцов русской демократии
AndrewVK,
> Привыкай к терминологии В нете интерфейс это отдельная сущность, а не абстрактный класс, как в плюсах. Поэтому класс не наследует интерфейс, а реализует
Это в C#. В C++/CLI взаимозаменяемо используют "наследует" и "реализует". Более того, в C++/CLI интерфейс CLI называется интерфейсным классом
> и, имхо, это правильно, поскольку наследование реализаций и интерфейсов вещи вобщем то концептуально различные.
Далеко не всегда хочется разделять наследование от ref класса и от interface класса. Например:
template< typename T >
ref class C : public T
{
. . .
};
здесь в качестве T может быть как ref class, так и interface class (а в будущем — и просто class), и все время мучиться выговаривая "базовый ref класс или реализуемый интерфейс" никакой выгоды, по-моему, не дает. А в будущем еще и придется все эти места поправить, добавив "или класс". В общем, я пока не вижу большого смысла в постоянном подчеркивании различия между наследованием от ref class, interface class и class.
> Теперь касательно сути — ни в 1.1 ни в 2.0 IEnumerable от IDisposable не наследуется.
Не расширяет?
Видимо, ошибочка в примере вышла. С другой стороны, для сути совершенно неважно, какой именно интерфейс был бы приведен в качестве примера — это не суть, а несущественная деталь. Можно взять IEnumerator<T>, который таки наследуется от (расширяет ?) IDisposable. Суть-то не в том, что облегчается реализация классов, реализующих (экая тавтология получается ) IEnumerable, а в том, что облегчается реализация классов, (возможно косвенно) наследующих (так в данном случае, имхо, звучит приятнее ) IDisposable.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
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). Не то чтобы это было фатально (обычно легко найти), но все-таки.
Здравствуйте, vdimas, Вы писали:
V>У меня таких перлов из реальных проектов на C#, которые давали мне на "лечение", тонна. Это что-нибудь доказывает? Какая нахрен разница — какой язык. Пургу одинаково легко нести на любом ЯП.
Не так давно мне пришлось лечить ЭТО:
Dim dataarray(1000,1,1,1,1) as String' ..................Dim j as int16 = 0
do while DataReader2.Read()
dataarray(j,0,0,0,0) = datareader2("trade_date")
dataarray(j,1,0,0,0) = datareader2("open_price")
dataarray(j,0,1,0,0) = datareader2("high_price")
dataarray(j,0,0,1,0) = datareader2("low_price")
dataarray(j,0,0,0,1) = datareader2("close_price")
j = j + 1
loop
Нет, вы не ошиблись — это он написал вместо Dim dataarray(1000,4) As String. Хотя конечно красиво смотрится
И килобайт где-то 150 в одном файле подобной бредятины:
<select class="menuList" title="Pattern Name" style="WIDTH: 200px" onchange="document.getElementById('cb_invert_pattern').checked = false;OnChangeEventPattern('id_td_pattern_description', 'id_pattern_rel', array_pattern_desc, array_pattern_rel, this.options[this.selectedIndex].value);" size="8"name="lst_pattern_names">
<%
'document.getElementByID("id_td_pattern_description").innerHTMLFor Each pattern in patternReader.Tables("pattern_list").Rows
%><option value="<%=pattern.Item("patternid")%>" <%
if cl.query_requested<>0 and cl.lst_pattern_names = pattern.Item("patternid") then
response.write("selected")
else if cl.query_requested=0 and first=0 then
response.write ("selected")
first = 1
end if %>><%=pattern.Item("name")%></option>
<%
next
first = 0
%>
</select>
Здравствуйте, Cyberax, Вы писали:
C>Почему же, я вот нормальный код пишу
Возможно тебе это просто кажется. Я вот смотрю на свой код двух-годичной давности и понимаю, что мне тоже это только казалось.
И вообще, на форумах все божтся, что пишут нормальный код. Но весь код который попадается почему-то далек от нормальности. Видимо опять в консерватории нужно что-то править.
C>Агащаз. Встречались индусы, которые очень любили статические переменные C>(типа theLastError и errorVector). Утечек памяти было вагон.
И все же лучшу уж они на Яве пишут. Потому как на С++ их код просто вылился бы в трагедию.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>У меня таких перлов из реальных проектов на C#, которые давали мне на "лечение", тонна. Это что-нибудь доказывает? Какая нахрен разница — какой язык. Пургу одинаково легко нести на любом ЯП.
Понимашь ли в чем дело. Я что-то не видел здесь гордых заявлений о том, что на Шарпе или Жлабэйсике пишут более прямой код.
Я говорил совсем о другом. Тут сплош и рядом твердят, что мол — защита и безопастность Шарпа и Явы все фигня, — и что мол — руки нужно иметь прямые. Но простите, где эти с прямыми руками? И уж если 90% с кривыми рождаются. То пусть уж они пишут на том, что мне проще отлаживать и затем рефакторить будет.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
>> компилятор брыкается по поводу совпадения имени свойства и типа.
ПК>Гм... А ты полагаешь, лучше, если он молча будет догадываться, что же из двух ты имел в данном месте?..
А мне и пологать не чего. Я беру прекрасно работающий код из C#... копирую его в МС++... добавляю необходимые ^, юсинги и т.п. и получаю... полную задницу с не внятными сообщениями компилятора. Ну, хорошо я не в первый раз на это нарываюсь. Да и в плюсах еще что-то помню. Но новичку такой подарок на раз отобъет желание связываться с МС++. И никакими ковришками в виде шаблонв и т.п. его уже туда не заманишь.
На фиг не упала такая "защита".
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, vdimas, Вы писали:
V>>У меня таких перлов из реальных проектов на C#, которые давали мне на "лечение", тонна. Это что-нибудь доказывает? Какая нахрен разница — какой язык. Пургу одинаково легко нести на любом ЯП.
VD>Понимашь ли в чем дело. Я что-то не видел здесь гордых заявлений о том, что на Шарпе или Жлабэйсике пишут более прямой код.
VD>Я говорил совсем о другом. Тут сплош и рядом твердят, что мол — защита и безопастность Шарпа и Явы все фигня, — и что мол — руки нужно иметь прямые. Но простите, где эти с прямыми руками? И уж если 90% с кривыми рождаются. То пусть уж они пишут на том, что мне проще отлаживать и затем рефакторить будет.
Эдак ты завернул. Я как-то высказывался уже, что развитие ср-в и языков принесло отрасли больше вреда, чем пользы. Все должны дружно начинать ориентироваться на того самого "криворукого" программиста, коих по твоим оценкам уже 90%.
И что дальше? Чем проще и "безопасней" будут языки и платформы, тем выше будет процент криворукости, тем хуже будут программы... во как...
VladD2 пишет:
> C>Почему же, я вот нормальный код пишу > Возможно тебе это просто кажется. Я вот смотрю на свой код > двух-годичной давности и понимаю, что мне тоже это только казалось.
Я тоже Смотрю и думаю: "Ну что за идиот это написал???". Просто мой
код нормален в каждый момент врмени.
> И вообще, на форумах все божтся, что пишут *нормальный код*. Но весь > код который попадается почему-то далек от нормальности. Видимо опять в > консерватории нужно что-то править.
Ну чего делать, если 90% программистов на этих форумах не бывает.
> C>Агащаз. Встречались индусы, которые очень любили статические переменные > C>(типа theLastError и errorVector). Утечек памяти было вагон. > И все же лучшу уж они на Яве пишут. Потому как на С++ их код просто > вылился бы в трагедию.
Пусть уж лучше вообще не писали бы. Тогда бы к нам не приходили вопли:
"Спасите проект! Через две недели выставка!".
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Павел Кузнецов, Вы писали:
ПК>>Гм... А ты полагаешь, лучше, если он молча будет догадываться, что же из двух ты имел в данном месте?..
AVK>C# догадывается. И очень даже неплохо в итоге получается.
это потому как у него нет typedef и отсутствуют конструкции одновременного объявления типа и переменной, типа этого:
>csc /reference:Hello.dll Print.cs
bla bla ...
>Print
Hello world!
>csc /reference:Hello.dll,Nicelib.dll Print.cs
bla bla ...
>Print
2.7182818284590451
Здравствуйте, Трурль, Вы писали:
Т>А это так важно?
Т>
//Nicelib.cs
Т>namespace A {
Т> public class B {
Т> public double C = 2.71828182845904523;
Т> }
Т>}
Статик забыл.
ЗЫ
В общем, согласен, что лучше бы если бы компилятор выдавал ошибку на стадии компиляции, но реально такие случае крайне редки. А вот приведенная мной ситуция встерчается сплошь и рядом.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
А то я в терминах не силен.
И чё все строем не ходят?
Если нам не помогут, то мы тоже никого не пощадим.
