прошу приводить более менее тезисно.

DenWPF, 
http://tinyurl.com/3d2qtzf

и вообще откуда такая аллергия искать самому ответ на свой вопрос ?

Это сообщение отредактировал(а) wester - 21.4.2011, 23:17

То что им можно управлять 

не хотите как хотите..

DenWPF, при чем тут хотите или не хотите, это просто холивар. мне, к примеру, просто C# нравится больше чем си/си++. нравиться хотя бы тем что в шарпе я не могу обратиться к несуществующему элементу массива, CLR не позволит, а в си это сделать запросто можно и сложить при этом все что угодно в памяти. но это детали, и больше относится к совести программиста...

Экскалупатор, не хочу холивара, хочу конкретных фактов. вот как ты сказал 




а это говорит, что управляемый код это безопасный код.

Хотя и есть возможность писать не безопасный код.

Это сообщение отредактировал(а) DenWPF - 22.4.2011, 09:32

управляемый безопасней.

likegift, угу, мы это уже выяснили постом выше, что то новое будет?

DenWPF, 
я же дал ссылку.... ты почитал что там написано ?

я потом написал 

пойми на любой мой вопрос можно найти ответ в интеренете...ттогда вопрос зачем этот форум?

DenWPF, 
от того что будешь сам искать ответ на свой вопрос немного повысится твой уровень как разработчика

wester, угу, я думаю ты, конечно же, пришел на этот форум только для того что бы давать советы другим, и никогда ни о чем не спрашивал(следуя своему собственному совету). но бывает что люди хотят получить ответ от других людей.

Да сборка ж мусора, ребята.

Экскалупатор, 
да но есть два случая 
1) ребят, мне надо написать парсер для языка YX, дайте готовый класс!
2) ребят, пишу парсер для языка YX, написал основу но при парсинге он почему то падает со NullRefenceException. Вот код парсера, где может быть ошибка ?

тут первый случай

ну да...

меня интересует личный опыт участников. так как теория не всегда совпадает с практикой.

Имхо, никаких фундаментальных преимуществ управляемый код не дает. Просто Microsoft из конъюнктурных соображений прекратило развивать неуправляемые средства, и программистам пришлось переходить на .NET. Старые средства уже давно не позволяют разрабатывать приложения современного уровня, а новые средства - управляемые.

Утверждения насчет безопасности .NET очень спорное. С одной стороны, сборка мусора достаточно удобна. С другой стороны, из-за крайне непродуманной и неудачной архитектуры самой .NET и языка C# сборка мусора не защищает от утечки памяти, а сами программы на C# чреваты бОльшим количеством ошибок, чем аналогичные программы на неуправляемом C++.

Это сообщение отредактировал(а) snav - 7.5.2011, 08:49

Ну тут не только безопасность на уровне памяти, но и безопасность в смысле "секьюрити".


Все верно, это не панацея. Правильное проектирование и прямые руки программистов никто не отменял. Да и чаще всего утечка памяти происходит при неверном событийном управлении. Введут завтра новый тип WeekDelegate и новую конструкцию языка weekdelegate void Handler() и эти вопросы будут решены. Только пользоваться лично я им буду в крайне редких случаях, так как предпочитаю чистить за собой.


Интересное утверждение, готов поспорить.

-Mikle-
Проблема в том, что большинство учебников по C# говорит о сборке мусора именно как о панацее, создавая у новичков ложное представление, будто сборка мусора автоматически решает все проблемы управления памятью. На самом деле, правильное управление памятью в .NET - это нетривиальная задача, требующая от программиста внимательности, глубокого понимания механизмов работы .NET и достаточно большого опыта. Для новичков это почти нереально (имхо). Многие просто не подозревают о подводных камнях.

Насчет вероятности ошибок в языках C++ и С#, я написал свое личное мнение, основанное на моем опыте. Хотя, по заверениям Microsoft, язык С# разрабатывался с упором на снижение вероятности ошибок, на мой взгляд, конструкции C# содержат большее количество потенциальных ловушек, чем C++. Например:
1. Модель освобождения ресурсов IDispose - один из самых кривых и неудачных элементов .NET, чреватый серьезными ошибками и проблемами (испытал на себе).
2. Риск утечки памяти при сохранении скрытых (незамеченных) ссылок на объекты.
3. Очень путанная схема работы операторов и методов сравнения объектов, с трудно предсказуемыми результатами.
4. Отсутствие единообразия в использование ключевых слов. Например, по непонятным причинам члены интерфейса запрещено объявлять как public и требуется описывать их подобно приватным членам.
5. Отсутствие константных методов и невозможность передачи методу константных объектов.
6. Различие между структурными и ссылочными типами - при одинаковом синтаксисе они ведут себя по-разному, что является потенциальным источником путаницы.
Список можно продолжить.

Это всё потенциальные ловушки языка C#, которые невозможно устранить с помощью "правильного" стиля программирования. Поэтому утверждения, что C# якобы снижает риск программных ошибок, на мой взгляд, не соответствуют действительности и являются просто рекламным разводом.

P.S.
Справедливости ради, надо отметить, что перечисленные ловушки - это не проблемы управляемого кода вообще. Это просто неудачные решения разработчиков .NET.


Это сообщение отредактировал(а) snav - 8.5.2011, 08:47