Здравствуйте, FR, Вы писали:
FR>Это ни проблема языка, ни C# ни java, ни помогут в решении подобных проблем, если фирме выгоднее выпускать глючные програмы, чем доводить их до ума, то они и будут выпускатся. И вообще очень часто вместо вылета программа написанная на языке с GC неправильно работает после критической ошибки.
Никому не выгодно производить глючные программы. Просто еще больше не охота вкладывать денег в тотальное обезбаживаение, так как при производстве софта на С/С++ процесс этот становится двольно дорогой (особенно в рамках большой команды).
А язык тут как раз причем. Вместо паттернов и дорогущих систем контроля качества можно просто применять средства разработки минимизирующие ошибки и точно гарантирующие отсуствие ошибок связанных с порчей памяти. При этом сбои становятся значительно более редки, не столь критичны (диаложик с возможностью продолжения против полного краха) и значительно проще вылавливаются. Наличие метаданных позволяет так же значительно упростить создание тех самых систем контроля качества. Более легкий в парсинге язык позволяет автоматизированный проивзводить анализ код. Да и просто читать код становится намного проще, что резко упрощает его модификацию.
В итоге даже опер-сорс-продукты вроде Януса, разрабатываемые очень разноскильной публикой, работают намного устойчевее чем коммерческие продукты, хотя денег и сил на их обезбаживание практически не тратится. А 90% тормозов и багов вылезающих в Янусе являются проявлением используемых в нем анменеджед-контролов вроде редактора или броузера.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>А я ни разу ни видел на C++ программу которая посылает систему в такой swap что приходится снимать задачу из-за того что GC не хватило памяти
Ну, к примеру, тормоза при загрузке в Янусе связаны с использованием MS Access, который написан на С++.
А вообще я знаю море продуктов написанных на плюсах и ждрущих память очень неплохо. Да и не видел как дотнентый софт так уж "посылал в своп". Занимает памяти он больше (если она есть), но такова стратегия работы ЖЦ. Да и какой смысл экономить если на борту сотни мег неиспользуемой памяти?
То что у дотнетных процессов при создании занимается сразу по нескольку мег памяти — это ровным счетом ничего не значит. То что мы наблюдаем — это не реальная память, а виртуальная и так называемый ворксет. Можешь провести вот такой простенький эксперемент:
using System;
using System.Runtime.InteropServices;
namespace ConsoleApplication1
{
class Class1
{
[DllImport("kernel32.dll")]
public static extern bool SetProcessWorkingSetSize(IntPtr handle,
int minimumWorkingSetSize, int maximumWorkingSetSize);
static void Main(string[] args)
{
Console.WriteLine("Before");
Console.ReadLine();
SetProcessWorkingSetSize(
System.Diagnostics.Process.GetCurrentProcess().Handle,
-1, -1);
byte[] array = new byte[1000];
Console.WriteLine("After");
Console.ReadLine();
}
}
}
после второго нажатия объем памяти приложения станет около 540 кил.
Приблизительно тоже самое делает Виндовс при минимизации окна приложения.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Ну и что я видел несколько лет назад как люди с JBuilder мучались, судя по звукам он у них каждые полчаса дох
Вот это явная неправда. Я не разу не видел, чтобы JBuilder вылетал. Он тормозил при отрисовке, так как весь гуи был написан на Свинге, но это проблема технологии. Возми, к примеру, Эклипс или ИДЕЮ. Они и шустры и стабильны.
Кстати, новая среда для C++ BuilderX написана на Яве правда я не знаю каков процент кода борланда, а коков потыренный. Но это уже не важно. Важна сама тенденция.
FR>И вообще не надо представлять тут языки с GC как панацею, не так далеко они и ушли в плане безглючности от плюсов или дельфи.
Очень далеко! Неимоврено, бы сказал. Причем ЖЦ тут в общем-то и не причем. Вернее причем, но это процентов 10. Остальное дизайн языков и заслуга рантаймов.
Например, создаем ГУИевое приложение, добавляем на форму две кнопки и в их обработчиках пишем:
запускаем не под отладчиком (хоть в релизе) и жмем на кнопки... Вылетает окошко с сообщением об ошибке. Жмем на продолжить и приложение как ни в чем нибывало работает дальше. Причем это во общем-то мелочи. Главное, что впринципе невозоможно не используя анменеджед- или ансэйф-код попртить память и получить многочасовую (а то и многонедельную) отладку.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Здесь все ошибки со времён голого С. Я не говрю, что в С++ ошибок меньше, я говорю, Java/.Net не абсолютно безопасная среда.
А, ну, да. Ты конечно строки и массивы никогда в стэке не занимал. А код для виндовс пишется без пременения МФЦ и АТЛ на сквозь пропитанных этим делом...
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, VladD2, Вы писали:
VD>>Точно на С то тоже ламеры пишут. Ну, найди бокрепорт любого С++-ного софта сравним количество мемориликов и неинициализированных переменных с Янусом.
A>А где гарантия что багрепорты будут одинакового качества?
А я тебе как писавший часть этого проекта и постоянно следящий за ним скажу, что мемори-лик в Янусе был только однажды и потери были настолько слабыми, что до проблем от нехватки памяти не доходило. Дохла производительность так как списки обработчиков событий имеют экспонентциальную потерю провизодительности при увеличении в нем элементов (баг был в том, что не отключались от событий).
Больше проблем с памятью или ресурсами небыло. И это при том, что порой глядя на код думашь, что он вообще работать не должен (настолько он коряв).
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Больше проблем с памятью или ресурсами небыло. И это при том, что порой глядя на код думашь, что он вообще работать не должен (настолько он коряв).
Зато были проблемы с неуникодностью Scintilla, с IE неосвобождающим память... Узкое у тебя видение проблемы.
Здравствуйте, VladD2, Вы писали:
A>>Здесь все ошибки со времён голого С. Я не говрю, что в С++ ошибок меньше, я говорю, Java/.Net не абсолютно безопасная среда.
VD>А, ну, да. Ты конечно строки и массивы никогда в стэке не занимал.
Занимал.
VD>А код для виндовс пишется без пременения МФЦ и АТЛ на сквозь пропитанных этим делом...
Нет MFC И ATL используются довольно часто, но они довольно хорошо уже отлажены.
Здравствуйте, VladD2, Вы писали:
VD>Кое-кто переходит. Слава богу МС уже немало кода переводит на менеджед-остнову. Другие тоже надеюсь со времением перейдут.
А я вот совмневаюсь. Тот же Adobe пишет свой редактор под несколько платформ и думаю им лучше использовать такой язык, чтоб большую часть кода можно было перекомпилировать, а не писать заново.
A>>А знаешь как ECC Registred память работает? Если считалось ошибочное значение, то оно считывается заново. Может это просто тенденция IT, которая лично тебе чужда?
VD>А какое отношение ECC имеет к вылетающему софту?
Один и тот же способ проблемы решения сбоев.
VD>А ведь софт который сбоит крайне редко все же есть. У того же МС есть MSSQL который я вообще не видел чтобы сбол. Значит неглючный софт таки писать можно и дело только в цене? Так какого хрена не применить средство понижающее цену и повышающее качество, чтобы уменьшить вылеты до незаметных глазу размеров?
Потому что у этого средства помимо удешевления есть и недостатки.
VD>Славо богу похоже с Вордом проблема скоро решится. ИнДизайн еще видимо лет 5 будет глючить.
Зато он есть и на Маках. Тебе не говорили, что PC-версия не является основной? Ведь если кто-то портирует Янус под МОНО, тебе будет плевать на эту версию — Win-Версию отладить важнее. Так что In-Design не показатель.
Здравствуйте, Alxndr, Вы писали:
A>Влад, пара вопросов: A>1) Ты видишь в этой тенденции что-то плохое? На ОО-дизайне разве свет клином сошелся?(задаю этот вопрос и плачу, поскольку сам горячий сторонник ОО-дизайна )
Если бы мы говорили о каком-нибудь С, Хаскле, Клосе и т.п., то возможно ОО-дизайн действительно был бы не причем. Но в языке который авторами назван ОО довольно странно видель как люди всяческими ужимкми и увертками избегают этого ОО.
Ну, а что касается дизайна. Если бы отсуствие ОО-дизайна компенсировалось бы наличием функционального дизайна или какого-бы то нибыло другого, то еще пол беды, но вместо ОО-дизайно зачастую присуствуют хакерские оптимизации и "закладывание" на разные аспекты реализации.
A>2) Что значит "мифические" парадигмы? За этими словами есть что-то кроме твоей личной неприязни?
Это значит, что С++ как следует поддерживает только две парадигмы — ООП и структурное программирование. Функциональную парадигму он поддерживает хуже чем C# или какй-нибудь Питон. Если только считать поддержкой ФП такие вещи как рекурсивные шаблоны с ручной специализацией. Но это изврат для метапрограммирования. Код так не попишешь. А парадигмы вроде АОП и т.п. ему просто не знакомы.
A>3) Влад, а разве люди всерьез подсевшие на диезы, не начинают с большой радостью рассуждать о весьма конкретных парадигмах программирования, отличных от объектно-ориентированного? Например, о компоненто-ориентированном программировании?
По-моему, компонентный подход — это не парадигма как таковая. Это просто доведенный до ума ООП.
Да и вопрос в чем... Я могу на шарпе писать и в функциональном стиле (чуть менее убого чем на С++, но все же убого). Я могу изобразить кое что из АОП. Я могу создавать компоненты, но я ни разу не слышал чтобы кто-то говорил о том, что главное в Шарпе — это возможность писать в разных стилях.
Наоборот я вижу, что авторы языка предосталяя некоторые возможности все же акцентировали именно ОО-возможности и всячески избегают разных хаков. Собственно этот постулат вынесен в первые строки целей языка в его спецификации:
* C# is intended to be a simple, modern, general-purpose, object-oriented programming language.
Это же я вижу и в развитии языка. Дженерики и анонимные методы прекрасно вписываются в концеции ООП.
Я вижу только две серьезные проблемы в этом языке:
1. Отсуствие средств подключения реализации (нечто вроде минсинов или упрощенного множественного наследования).
2. Отсуствие средств метапрограммирования.
Обе проблемы закрываются R#-ом. Так что...
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Alxndr, Вы писали:
A>Не вижу преимуществ С применительно к данному случаю
Дык если С++ испоьзовать как С, то конечно разницы нет. А елси начать использовать ООП и выкрутасы на шаблонах, то объем сжираемой памяти точно увеличится. Тут уже нужно скорее говорить о стиле С.
A>Я считаю, что для некритичных с памяти/скорости приложений и/или для программистов, которые считают, что надежность в С++ немыслима без виртуальности деструктора по умолчанию и т.п. подобных фенечек, C# — лучший выбор.
C# лучший выбор для пользователя. А большинство программистов делают выбор исключительно на базе своих привычек и догм.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> A> 1) Ты видишь в этой тенденции что-то плохое? На ОО-дизайне разве свет клином сошелся?(задаю этот вопрос и плачу, поскольку сам горячий сторонник ОО-дизайна )
> Если бы мы говорили о каком-нибудь С, Хаскле, Клосе и т.п., то возможно ОО-дизайн действительно был бы не причем. Но в языке который авторами назван ОО <...>
Это утверждение не соответствует действительности. Авторами язык C++ назван поддерживающим много парадигм, в том числе и ООП. В частности, у Страуструпа даже статья специальная есть, Why C++ isn't just an Object-Oriented Programming Language.
> A>2) Что значит "мифические" парадигмы? За этими словами есть что-то кроме твоей личной неприязни?
> Это значит, что С++ как следует поддерживает только две парадигмы — ООП и структурное программирование.
Как минимум, прочитать статью, на которую дана ссылка чуть выше.
Posted via RSDN NNTP Server 1.9 delta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, adontz, Вы писали:
VD>>А, ну, да. Ты конечно строки и массивы никогда в стэке не занимал. A>Занимал.
Ну, значит свою лепту в буфер адеран внес. Как и я.
VD>>А код для виндовс пишется без пременения МФЦ и АТЛ на сквозь пропитанных этим делом... A>Нет MFC И ATL используются довольно часто, но они довольно хорошо уже отлажены.
Если доведется запустить АТЛ-ьные проекты на новых АМД с включенной защитой от переполнения буферов и т.п. расскажи ощущения... посмеемся вместе.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>А я вот совмневаюсь. Тот же Adobe пишет свой редактор под несколько платформ и думаю им лучше использовать такой язык, чтоб большую часть кода можно было перекомпилировать, а не писать заново.
Ява? Моно?
VD>>А какое отношение ECC имеет к вылетающему софту?
A>Один и тот же способ проблемы решения сбоев.
Ничего похожего. Отлов битой памяти и проверки четности чтения — это совсем разные вещи.
A>Потому что у этого средства помимо удешевления есть и недостатки.
В основном придуманные.
A>Зато он есть и на Маках.
А вот Маки мне фиолетовы. К тому же на Маках есть Моно и Ява.
A> Тебе не говорили, что PC-версия не является основной?
Нет. Говорили обратное. Вот уже 5 лет как Адобе основными версиями считает Виндвс-версии. И знаешь почему? Потому что основные продажи под Виндовс.
A> Ведь если кто-то портирует Янус под МОНО, тебе будет плевать на эту версию — Win-Версию отладить важнее. Так что In-Design не показатель.
Ну, вот пусть плюет на Маки.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
AndrewVK,
> S>На жабе/шарпе выбирать, конечно, не приходится, там объектов без оверхеда не бывает.
> Ты наверное забыл, но в шарпе еще и структуры есть.
Ага, есть. Только наследоваться от них нельзя. Кстати, интересно, а можно ли в C# передавать эти структуры в функции по ссылке, так чтобы их можно было в функциях модифицировать (соответственно, боксинг не подходит)?
Posted via RSDN NNTP Server 1.9 delta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
правда я не знаю каков процент кода борланда, а коков потыренный. Но это уже не важно. Важна сама тенденция. 
Кстати, интересно, а можно ли в C# передавать эти структуры в функции по ссылке, так чтобы их можно было в функциях модифицировать (соответственно, боксинг не подходит)?