Привет всем !
Вопрос скорее философский. Задача — обработка данных, много графики, передача данных через по сети нужна, но не критична, базы данных используються, но обработку данных я делаю сам (выводить таблицу опорных точек как-то незачем), засим грид мне сильно не нужен.
А вот быстродействие важно, даже критично.
Имеет ли мне смысл переезжать на .Net и C# или нет? Сейчас большая чать проекта сделана на VC6 + Intel C++ 5.0,дополнительные модули на BCB 5...
Буду благодарен многоуважаемому All за любые идеи по этому поводу.
22.04.03 10:58: Перенесено модератором из '.NET' — TK
Интуитивно понятный интерфейс — это интерфейс, для работы с которым нужна недюжинная интуиция...
Здравствуйте, Nick Notabene, Вы писали:
NN>Вопрос скорее философский. Задача — обработка данных, много графики, передача данных через по сети нужна, но не критична, базы данных используються, но обработку данных я делаю сам (выводить таблицу опорных точек как-то незачем), засим грид мне сильно не нужен. NN>А вот быстродействие важно, даже критично. NN>Имеет ли мне смысл переезжать на .Net и C# или нет? Сейчас большая чать проекта сделана на VC6 + Intel C++ 5.0,дополнительные модули на BCB 5... NN>Буду благодарен многоуважаемому All за любые идеи по этому поводу.
В большинстве случаев вычислительные задачи в .NET Framework будут работать медленнее, чем написанные на том-же c++ и откомпилированные "тяжелым" компилятором.
С другой стороны — использование .NET может дать такие преимущества, которые тяжело или практически не возможно получить при использовании "старых" средств разработки.
* Код программы пишется однократно и может использовать возможности конкретной платформы. Для случая-же с++ придется поставлять несколько версий одного и того-же кода — оптимизируя его под каждую архитектуру. (особенно, учитывая, что наборы команд процессора постоянно расширяются, тот-же windows портируется на разные процессоры x86, Itanium, AMD 64 и т.п.)
* Используя CodeDOM или Reflection.Emit можно в процессе выполнения генерировать код который учитывает особенности входных данных. например заменяя некоторые переменные на константы, разворачивая часть циклов и т.п.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
YL>А ты сделай тестик на скорость работы и все поймешь.
Ага. И какие результаты ??? У меня что-то все плохо выходит по быстродействию, тяжелая такая хрень...
Но может я чего-то недогоняю, и потом железо у меня не фонтан — PII 400 да Duron 750...
Может я чо с оптимизацией не понял... YL>P.S. У меня приблизительно такая же проблема, но с моей точки зрения переспективы не радужные. YL>С уважением, Юрий
Хмы... И какие перспективы ??
А вообще буржуи советуют С# использовать....
Интуитивно понятный интерфейс — это интерфейс, для работы с которым нужна недюжинная интуиция...
Если скорость главное, то дотнет не лучший выбор. При умелом использовании из него можно выжать очень приличную скорость, но оптимизирующий native-компилятор типа Intel 7 (вроде должен уже появиться) или VC7 один фиг будут давать более высокую скорость. А если учесть оптимизации на шаблонах и работы с адресной арифметикой, то С++ может дать выигрыш довольно ощуюимый.
С другой стороны лежат такие показатели как:
1. Скорость разработки.
2. Надежность.
Если они не интересуют, а нужна скорость, то и думать нечего. Если же нужны, то можно подумать о смешанном варианте. МС++ позволяет делать высокопроизводительные сборки часть которых может быть native-ой, а часть менеджед. В студии 2003 МС++ значительно улучшен. Скорость создаваемого кода всего на проценты меньше native-ного и поддерживается визульная разработка форм и веб-интерфейсов.
... << RSDN@Home 1.0 beta 6a >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Nick Notabene, Вы писали:
NN>Вопрос скорее философский. Задача — обработка данных, много графики, передача данных через по сети нужна, но не критична, базы данных используються, но обработку данных я делаю сам (выводить таблицу опорных точек как-то незачем), засим грид мне сильно не нужен. NN>А вот быстродействие важно, даже критично. NN>Имеет ли мне смысл переезжать на .Net и C# или нет? Сейчас большая чать проекта сделана на VC6 + Intel C++ 5.0,дополнительные модули на BCB 5...
На мой взгляд — .Net рулит во всем что касается интерфейса, в остальных задачах — хоть и удобен, но медлителен.
А ты не думал о таком решении — все критичные расчеты — на том же VC6 или VC7, а все остальное — на .Net?
Что можно сказать, по мне так очень медленно, но это и понятно. Работает верифицируемый код.Но надо сказать что возможности потрясающие. Скорость разработки, маштабируемость, но пока за это надо платить.
Но не все так плохо. Скорость машин растет пропорционально чему-то там, память увеличивается. И года через 2-3 разработанные на .NET серьезные проекты будет впереди
Здравствуйте, VladD2, Вы писали:
VD>1. Скорость разработки.
Откуда разница в скорости разработки для математики?
VD>2. Надежность.
Тоже очень большой вопрос. Так ты используешь голый натив код, а так у тебя добавляется немерянный рантайм.
Здравствуйте, gwg-605, Вы писали:
G6>Здравствуйте, VladD2, Вы писали:
VD>1. Скорость разработки. G6>Откуда разница в скорости разработки для математики?
Я не имел в виду математику.Описал ситуацию обобщено( например для распределенных систем)
VD>2. Надежность. G6>Тоже очень большой вопрос. Так ты используешь голый натив код, а так у тебя добавляется немерянный рантайм.
Извини не совсем понял. Голый натив код это чистый Си ? А немерянный рантайм это нетовские библиотеки ?
Не понял вывода, т.к. пока только новичок.
N>На мой взгляд — .Net рулит во всем что касается интерфейса, в остальных задачах — хоть и удобен, но медлителен. N>А ты не думал о таком решении — все критичные расчеты — на том же VC6 или VC7, а все остальное — на .Net?
Ты знаешь, нет,не думал. Что касается скорости и удобства разработки интерфейса, .Net далеко до С++ Бильдера или Дельфей, с которого он собственно и слизан . Если в бильдере делать статические экзешники, без VCL, то они получаются здоровые, но все-таки не 10 метров.
Да и вообще у меня под VC6 уже скопился удобный набор open-source библиотек,интерфейс получается не хуже, а немного кода ручками мне сильно не мешает Большая часть времени уходит не на разработку мордочек, а на обработку данных, а визуализация у меня преимущественно своя — 1) кривые 2)карты-поверхности 3)таблицы просмотра больших массивов данных ( по 2-5 Мб на столбец таблицы). Стандартных компонент, которые работали бы с приемлимой скоростью и делали то что надо, я не видел
Другое дело, что масштабиремость и переносимость, но тут тоже анекдот — "Ваша программа будет работать везде... где установлен Windows..." — так она и так работает...
В общем дело ясное что дело темное.
Что будет дальше, я не знаю, но пока из всего вышепрописанного могу сделать вывод:
ЕСЛИ НАДО СДЕЛАТЬ ЧТО-ТО ОТЛИЧНОЕ ОТ ТЕКСТОВОГО РЕДАКТОРА ИЛИ ПРОГРАММЫ СОСТАВЛЕНИЯ АНКЕТ, .Net НИЗАЧЕМ НЕ НУЖЕН
Интуитивно понятный интерфейс — это интерфейс, для работы с которым нужна недюжинная интуиция...
Здравствуйте, Nick Notabene, Вы писали:
NN> ЕСЛИ НАДО СДЕЛАТЬ ЧТО-ТО ОТЛИЧНОЕ ОТ ТЕКСТОВОГО РЕДАКТОРА ИЛИ ПРОГРАММЫ СОСТАВЛЕНИЯ АНКЕТ, .Net НИЗАЧЕМ НЕ НУЖЕН
Не стоит себя успокаивать. .NET значительно ускоряет разработку многих вещей и убеждать себя что это не так по меньшей мере неперспективно.
Здравствуйте, Alexey Shirshov, Вы писали:
AS>Ускорение процесса разработки не самое главное в жизни.
Ну насчет жизни может конечно и так, но вот в сфере производства коммерческого софта это один из главных моментов. По моему давно уже доказано что посредственный продукт через год значительно лучше превосходного продукта через три.
Здравствуйте, Alexey Shirshov, Вы писали:
AS>Здравствуйте, AndrewVK, Вы писали:
AS>хъ
AVK>Не стоит себя успокаивать. .NET значительно ускоряет разработку многих вещей и убеждать себя что это не так по меньшей мере неперспективно.
AS>Ускорение процесса разработки не самое главное в жизни. AS>Не нужно идти по пути Delphi.
Кто сказал что Delphi ускаряет ? Это ФИГция! Примитивный UI в шесть кликов + DB app в четыре, это же не показатель быстрой разработки. Помнится месяца работы над небольшой desctop системкой (когда уже сдавали release), при закрытии начал нерегуляно появлятся "access violation" и фиг что с ним сделали, так и не победили сколько не бились, т.к. обработка ошибок во всем VCL — детский лепет...
А то что "Net далеко до С++ Бильдера или Дельфей", это точно т.к. они идут в разные стороны и между ними пропасть не меньше великого каньона. Borland сколько лет уже на ладан дышит, все эти игры Borland или inprise почему? Да потому что перестали поддерживать OWL, и кучу проектов которые на ней были написаны пришлось переписывать под другие библиотеки. Буржуи после этого borland вообще за фирму не считают... , а у нас — О-О-О билдер, О-О-О дельфи... Что же пользуйте, деньги и ассинезаторам платят...
J>Кто сказал что Delphi ускаряет ? Это ФИГция! Примитивный UI в шесть кликов + DB app в четыре, это же не показатель быстрой разработки.
Это точно.
J>Помнится месяца работы над небольшой desctop системкой (когда уже сдавали release), при закрытии начал нерегуляно появлятся "access violation" и фиг что с ним сделали, так и не победили сколько не бились
Нда... всего за месяц написать прогу, где не можете исправить AV... Талант.
И при чем тут Delphi?
Здравствуйте, Igor Trofimov, Вы писали:
J>Кто сказал что Delphi ускаряет ? Это ФИГция! Примитивный UI в шесть кликов + DB app в четыре, это же не показатель быстрой разработки.
iT>Это точно.
J>Помнится месяца работы над небольшой desctop системкой (когда уже сдавали release), при закрытии начал нерегуляно появлятся "access violation" и фиг что с ним сделали, так и не победили сколько не бились
iT>Нда... всего за месяц написать прогу, где не можете исправить AV... Талант. iT>И при чем тут Delphi?
Здравствуйте, Nick Notabene, Вы писали:
NN>Вопрос скорее философский. Задача — обработка данных, много графики, передача данных через по сети нужна, но не критична, базы данных используються, но обработку данных я делаю сам (выводить таблицу опорных точек как-то незачем), засим грид мне сильно не нужен. NN>А вот быстродействие важно, даже критично. NN>Имеет ли мне смысл переезжать на .Net и C# или нет? Сейчас большая чать проекта сделана на VC6 + Intel C++ 5.0,дополнительные модули на BCB 5... NN>Буду благодарен многоуважаемому All за любые идеи по этому поводу.
Это экстремально с Intel C++ на MS C#.
Это все равно, что пересаживаться из спортиного авто
в инвалидную коляску(хоть и позолоченную).
Много графики + .NET == тормоза навсегда
Обработка графики + .NET == real time(но только на P4 3.06Ghz)
Поверь моему опыту. Недавно писал на C# color quantizer
для записи GIF'ов через GDI+(так как сам по себе
он это делает паршиво). Самый быстрый вариант(просто re-mapping
24bit -> 15 bit -> 8 bit через таблицу) работал на
изображениях 256x256 со средней скоростью 1шт. / 0.1 сек,
а это очень медленно. Про octree я уже молчу .
Здравствуйте, Nick Notabene, Вы писали:
NN>Здравствуйте, nzeemin, Вы писали:
N>На мой взгляд — .Net рулит во всем что касается интерфейса, в остальных задачах — хоть и удобен, но медлителен. N>А ты не думал о таком решении — все критичные расчеты — на том же VC6 или VC7, а все остальное — на .Net?
NN>Ты знаешь, нет,не думал. Что касается скорости и удобства разработки интерфейса, .Net далеко до С++ Бильдера или Дельфей, с которого он собственно и слизан . Если в бильдере делать статические экзешники, без VCL, то они получаются здоровые, но все-таки не 10 метров.
Нет, все таки он слизан с Java. А вот Delphi и "Бильдер" слизаны с Visual Basic, который
задолго до них появился. .NET это попытка совместить Java и VB. Почти удачная.
NN>Другое дело, что масштабиремость и переносимость, но тут тоже анекдот — "Ваша программа будет работать везде... где установлен Windows..." — так она и так работает...
Переносимость в моем понимании это когда на дискету взял и перенес пять копий одной программы и чтоб еще места осталось.
NN>Что будет дальше, я не знаю, но пока из всего вышепрописанного могу сделать вывод: NN> ЕСЛИ НАДО СДЕЛАТЬ ЧТО-ТО ОТЛИЧНОЕ ОТ ТЕКСТОВОГО РЕДАКТОРА ИЛИ ПРОГРАММЫ СОСТАВЛЕНИЯ АНКЕТ, .Net НИЗАЧЕМ НЕ НУЖЕН
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Nick Notabene, Вы писали:
NN> ЕСЛИ НАДО СДЕЛАТЬ ЧТО-ТО ОТЛИЧНОЕ ОТ ТЕКСТОВОГО РЕДАКТОРА ИЛИ ПРОГРАММЫ СОСТАВЛЕНИЯ АНКЕТ, .Net НИЗАЧЕМ НЕ НУЖЕН
AVK>Не стоит себя успокаивать. .NET значительно ускоряет разработку многих вещей и убеждать себя что это не так по меньшей мере неперспективно.
Согласен, разработку форм он ускоряет. Только ведь тут закономерность простая — чем "проще" разработка для "пользователя-программиста", тем сложнее внутренняя реалицация кода. Чем больше и универсальнее "компоненты" тем больше дубляжа кода и маразма взаимосвязей.
Нет, господа, воля ваша — я поюзал VS 2002, и впечатление самое плачевное. Чувство удовлетворения от того, как все просто и быстро получается сначала, быстро перерастает в раздражение, когда приходится сделать маааленький шажок в сторону. А текстовый редактор мне не нужен — мне не за него деньги платят.
Может VS 2003 что-то изменит — как пишут боссы из Майкрософт, они "снова повернулись лицом к С++ программистам" в этой версии... посмотрим... только лицо у них все какое-то однообразное...
Интуитивно понятный интерфейс — это интерфейс, для работы с которым нужна недюжинная интуиция...
U>Нет, все таки он слизан с Java. А вот Delphi и "Бильдер" слизаны с Visual Basic, который U>задолго до них появился. .NET это попытка совместить Java и VB. Почти удачная.
Ага. А я думал, с чего это они Дельфи слизали.
Короче, бред. Дельфи к VB никакого отношения не имеет. В VB у тебя сильно высокоуровневый язык, но руки связаны. Примерно, как в DBase, Clarion или Power Builder. Калека мозга получается
Здравствуйте, unprogrammer, Вы писали:
NN>Что будет дальше, я не знаю, но пока из всего вышепрописанного могу сделать вывод: NN> ЕСЛИ НАДО СДЕЛАТЬ ЧТО-ТО ОТЛИЧНОЕ ОТ ТЕКСТОВОГО РЕДАКТОРА ИЛИ ПРОГРАММЫ СОСТАВЛЕНИЯ АНКЕТ, .Net НИЗАЧЕМ НЕ НУЖЕН U>Точно! Ну еще для Web он еще куда ни шло.
Да и в Web'ђ им многое не свђтит. Для подавляющего большинства хватит PHP, а там, гдђ мог бы пригодится ASP.NET есть куча других технологий.
Здравствуйте, mihailik, Вы писали:
U>Нет, все таки он слизан с Java. А вот Delphi и "Бильдер" слизаны с Visual Basic, который U>задолго до них появился. .NET это попытка совместить Java и VB. Почти удачная.
M>Ага. А я думал, с чего это они Дельфи слизали.
M>Короче, бред. Дельфи к VB никакого отношения не имеет. В VB у тебя сильно высокоуровневый язык, но руки связаны. Примерно, как в DBase, Clarion или Power Builder. Калека мозга получается
Я в принципе аналогичного мнения, но причем здесь это?
Язык Delphi сам по себе вещь конечно самобытная и уникальная,
никто не спорит и только за попытку что-то противопоставить C++ — большой .
НО! Концепция(как продукта) полностью слизана. Ты имел счастье наблюдать VB и Delphi первых версий?
Да они ведь даже если по IDE судить — братья близнецы. Все одинаковое. Только названия и язык разный.
Borland последние десять лет только и пытается отнять кусочек у Microsoft. Своих идей, своих мыслей, а тем более долгосрочных планов у них нет. Все что они делают — это лишь попытка хоть что нибудь противопоставить. Но видимо в последнее время силенок то стало не хватать — вот тебе и пожалуйста интеграция с .NET. А то обычно бы они начали делать свой .COM, .WEB, что нибудь еще.
Здравствуйте, unprogrammer, Вы писали:
U>Borland последние десять лет только и пытается отнять кусочек у Microsoft. Своих идей, своих мыслей, а тем более долгосрочных планов у них нет. Все что они делают — это лишь попытка хоть что нибудь противопоставить. Но видимо в последнее время силенок то стало не хватать — вот тебе и пожалуйста интеграция с .NET. А то обычно бы они начали делать свой .COM, .WEB, что нибудь еще.
Скорее Microsoft "пытается отнять кусочек", точнее купить, еще точнее пыталась, и совсем точно — успешно.
Для линухов и прочих БСДей есть MONO.
Те, кто говорят об урезонности и неполноценности, обладают очень устаревшей информацией. Зайдите на http://www.go-mono.org
ASP.NET (под APACHE!)
Провайдеры для ADO.NET, в том числе для MSSQL2000
Что касается WinForms — тут некоторая ограниченность есть. Работают пока только базовые элементы.
Мне интересно другое — судя по реакции Майкрософта, они либо согласны на то, чтобы реальную кроссплатформенность за них, либо ждут, когда можно будет этот проект "прикупить" и вломиться в Линуксовый монастырь.
А вообще — все вполне круто у них, Mono-вцев.
Real programmers don't comment their code.
If it was hard to write, it should be hard to understand.
Re: А нужен ли мне .Net...
От:
Аноним
Дата:
26.04.03 11:23
Оценка:
Здравствуйте, Nick Notabene, Вы писали:
Нужно действовать по обствоятельствам. То есть если критична производительность, уверен, выбор будет не в пользу Нэта и Шарпа.
M>>Короче, бред. Дельфи к VB никакого отношения не имеет. В VB у тебя сильно высокоуровневый язык, но руки связаны. Примерно, как в DBase, Clarion или Power Builder. Калека мозга получается
U>НО! Концепция(как продукта) полностью слизана. Ты имел счастье наблюдать VB и Delphi первых версий? U>Да они ведь даже если по IDE судить — братья близнецы. Все одинаковое. Только названия и язык разный.
С Дельфи большой опыт. С VB, слава богу, небольшой
И согласиться с тобой не могу.
В Дельфи компонентность грамотно построена на минимальных "магических" моментах: RTTI, TPersistent и виртуальные конструкторы. С самой первой версии архитектура не перестраивается.
А VB был первым, но до сих пор он выглядит как догоняющий. Всё запичкано "магией", потому что сам язык слишком ограничен. Как будто делали его на коленках, наспех, догоняя чужой грамотный проект, "пристёгивая" на ходу функции прямо по живому.
Здравствуйте, gwg-605, Вы писали:
VD>1. Скорость разработки. G6>Откуда разница в скорости разработки для математики?
А она для всего. Просто все настроено на большую скорость разработки (и библиотеки, и GC, и компонентная модель, и среда...)
VD>2. Надежность. G6>Тоже очень большой вопрос. Так ты используешь голый натив код, а так у тебя добавляется немерянный рантайм.
Так я использую прямой дуступ к мамяи и вынужден конролировать все вручную. А так я испоьзую безопасные алгоритмы и готовые библиотеки.
... << RSDN@Home 1.0 beta 7a >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Можно так же , на мой взгляд спросить , зачем в NET , навороченный сборщик мусора ? ? ? Много аргументов программисты не освобождают ресурсы , и он сам их освобождает и прочее , но на мой взгляд это проблемма программистов . Излишняя забота может вылится в большое безразличие . Плюс ко всему хоть и ресурсы машин выросли ощютимо за последние несколько лет , но представлять все через объекты , расточительно на мой взгляд , поэтому хоть и пытаюсь писать на С# , более склонен к С++ . По крайней мере при разработке С++ учитывали то что большинство написано на С , C# — учитыет это ? ? ? Забили М$ на всех . Я не говорю о том что они лохи и несмогли реализовать это . JIT компиляция , решение проблем маршалинга нравится в общем может что то и пропустил но не об этом разговор , но более особо ничего . И если взглянуть со стороны , как и MFC только намного...намного продвинутей. Теже яйца только в профиль .
Здравствуйте, Slavva, Вы писали:
S>Можно так же , на мой взгляд спросить , зачем в NET , навороченный сборщик мусора ? ? ? Много аргументов программисты не освобождают ресурсы , и он сам их освобождает и прочее , но на мой взгляд это проблемма программистов . Излишняя забота может вылится в большое безразличие .
Сборщик мусора не только освобождает за тебя память. Он также позволяет взглянуть на ООП с несколько другой стороны. Сильно упрощает проектирование некоторых вещей, что дает возможность увеличения сложности программ с уменьшением потраченных на нее ресурсов.
А падение производительности на нем во многих случаях несущественно.
7. О чем невозможно говорить, о том следует молчать.
Здравствуйте, WFrag, Вы писали:
WF>Сборщик мусора не только освобождает за тебя память. Он также позволяет взглянуть на ООП с несколько другой стороны. Сильно упрощает проектирование некоторых вещей, что дает возможность увеличения сложности программ с уменьшением потраченных на нее ресурсов.
WF>А падение производительности на нем во многих случаях несущественно.
И с какой же стороны сборщик мусора в ООП смотрит ??? Каких вещей он упрощает проектирование ??? Если не следование правилу взял отдай рассматривать как проектирование , то да упрощает. Но это немного не проектирование . Увеличить сложность , действильно как существовали сложные системы без сборщика мусора представить просто невозможно , может их писали "аккуратно" . Или ты об этом не задумывался ???
Здравствуйте, Slavva, Вы писали:
WF>>Сборщик мусора не только освобождает за тебя память. Он также позволяет взглянуть на ООП с несколько другой стороны. Сильно упрощает проектирование некоторых вещей, что дает возможность увеличения сложности программ с уменьшением потраченных на нее ресурсов.
WF>>А падение производительности на нем во многих случаях несущественно.
S>И с какой же стороны сборщик мусора в ООП смотрит ??? Каких вещей он упрощает проектирование ??? Если не следование правилу взял отдай рассматривать как проектирование , то да упрощает. Но это немного не проектирование . Увеличить сложность , действильно как существовали сложные системы без сборщика мусора представить просто невозможно , может их писали "аккуратно" . Или ты об этом не задумывался ???
Я не говорил, что без GC нельзя написать сложную и надежную систему. Утверждение было: дает возможность увеличения сложности программ с уменьшением потраченных на нее ресурсов.
Пример: Переписал я один свой проект с C++, и как говорится, почувствовал разницу. Усилий на написание/отладку потратил значительно меньше (на технические части, алгоритмические части обдумывать, конечно, уже не пришлось). И значительная заслуга этого именно GC.
Кстати, вариант на C++ имеет только одно преимущество — он потребляет меньше памяти. Но это просто свойство систем с GC — они более прожорливые.
В C++, например, ООП получается (у меня, может у других как-то иначе?) либо очень линейным (владелец объекта строго определен), либо приходится извращаться с всякими умными указателями и подсчетом ссылок (опять же вспоминаем про циклические графы, которые могут случайно получиться ). Я уже где-то тут рассуждал на эту тему, вот пример: Swing из Java. Мое утверждение: написать такую библиотеку без сборщика мусора просто невозможно, поскольку там ссылки на объекты довольно свободно передаются, и владельца объекта определить зачастую довольно проблематично.
Я начал чувствовать сильную разницу между ООП без GC и ООП с GC, когда плотно познакомился с Java. Объяснить словами более понятно разницу, наверное, не смогу , это надо просто пробовать.
Здравствуйте, Slavva, Вы писали:
S>И с какой же стороны сборщик мусора в ООП смотрит ??? Каких вещей он упрощает проектирование ??? Если не следование правилу взял отдай рассматривать как проектирование , то да упрощает.
Возьми шире — подумай об управлением временем жизни объектов вобще.
Здравствуйте, al, Вы писали:
al>Основная цель сборщика мусора — предотвращение фрагментации памяти в программах, работающих очень долго (например, Web-серверах и т.п.)
Основная цель сборщика мусора, как это не удивительно, собирать мусор.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Slavva, Вы писали:
S>>И с какой же стороны сборщик мусора в ООП смотрит ??? Каких вещей он упрощает проектирование ??? Если не следование правилу взял отдай рассматривать как проектирование , то да упрощает.
AVK>Возьми шире — подумай об управлением временем жизни объектов вобще.
Подумал , больше чем необходимо они жить не должны (или ОС знает скольно нужно жить объекту ??? Так может она и проги сама писать будет ??? ), процесс все равно на мой взгляд должен контролироваться программистом . Я читал про сборщик мусора и его механизм действия , в целом я склонен к его необходимости, но не везде. Имею ввиду то что нет средств управлять этим процессом , скажем так как С++ new выделит delete освободит (Насильно вызвать можно , но это немного не то).
S>>И с какой же стороны сборщик мусора в ООП смотрит ??? Каких вещей он упрощает проектирование ??? Если не следование правилу взял отдай рассматривать как проектирование , то да упрощает.
AVK>Возьми шире — подумай об управлением временем жизни объектов вобще.
S>Подумал , больше чем необходимо они жить не должны (или ОС знает скольно нужно жить объекту ??? Так может она и проги сама писать будет ??? ), процесс все равно на мой взгляд должен контролироваться программистом .
Пока один программист — понятно. Как только появляются несколько (например, компонент используется внешней программой), возникают вопросы.
Возьми, например, какое-нибудь сложное приложение. Типа там Access. Его извне открыли, получили какие-то объекты. Потом часть объектов уже не нужна, а часть ещё нужна во внешнем коде.
Когда тут можно процесс Access'а выключать? И что делать, если к этому Access'у ещё несколько внешниъ программ подключились?
Есть разные методы борьбы, и GC на сегодняшний момент — один из лучших.
Здравствуйте, mihailik, Вы писали:
M>Пока один программист — понятно. Как только появляются несколько (например, компонент используется внешней программой), возникают вопросы.
Которые прекрасно решаются и без GC. Хотя с GC, безусловно, для их решения приходится предпринимать несколько меньше усилий.
M>Возьми, например, какое-нибудь сложное приложение. Типа там Access. Его извне открыли, получили какие-то объекты. Потом часть объектов уже не нужна, а часть ещё нужна во внешнем коде.
M>Когда тут можно процесс Access'а выключать? И что делать, если к этому Access'у ещё несколько внешниъ программ подключились?
А что делать, если к нему юзер "подключился" и в этом процессе Access'а отчеты разглядывает? Меня это всегда веселило. Никакой GC или подсчет ссылок против юзера не поможет Это, извините, просто bad design.
M>Есть разные методы борьбы, и GC на сегодняшний момент — один из лучших.
Я бы сказал, один из самых ресурсоемких.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
M>Пока один программист — понятно. Как только появляются несколько (например, компонент используется внешней программой), возникают вопросы.
S>Которые прекрасно решаются и без GC. Хотя с GC, безусловно, для их решения приходится предпринимать несколько меньше усилий.
GC решает проблему циклических ссылок. Более стандартные и типичные технологии на этом здорово буксут.
M>Возьми, например, какое-нибудь сложное приложение. Типа там Access. Его извне открыли, получили какие-то объекты. Потом часть объектов уже не нужна, а часть ещё нужна во внешнем коде.
M>Когда тут можно процесс Access'а выключать? И что делать, если к этому Access'у ещё несколько внешниъ программ подключились?
S>А что делать, если к нему юзер "подключился" и в этом процессе Access'а отчеты разглядывает? Меня это всегда веселило. Никакой GC или подсчет ссылок против юзера не поможет Это, извините, просто bad design.
Ну, если юзер — действительно bad design и т.п. А если это сервер без интерфейса? Access "в невидимом виде"?
Это как раз и будет отличной иллюстрацией проблемы циклических ссылок. Какой-нибудь Recordset держит ссылку на ColumnCollection, а ColumnCollection держит ссылку на Recordset. Простой подсчёт ссылок такую круговую поруку не сможет освободить, тут нужно крепко сидеть и крепко комбинировать. Что чревато ошибками, утечками ресурсов.
M>Есть разные методы борьбы, и GC на сегодняшний момент — один из лучших.
S>Я бы сказал, один из самых ресурсоемких.
На RSDN'е я видел статью о сравнении GC и традиционных heap. Комментарии там хорошо проясняют суть вопроса.
Здравствуйте, mihailik, Вы писали:
M>GC решает проблему циклических ссылок. Более стандартные и типичные технологии на этом здорово буксут.
Однако, побуксовав, с успехом решают К слову, некоторые реализации GC на циклических ссылках тоже буксуют. Например, ActivePerl такой фигней страдал.
M>>Возьми, например, какое-нибудь сложное приложение. Типа там Access. Его извне открыли, получили какие-то объекты. Потом часть объектов уже не нужна, а часть ещё нужна во внешнем коде.
M>Ну, если юзер — действительно bad design и т.п. А если это сервер без интерфейса? Access "в невидимом виде"?
Ну так нефиг примеры некорректные приводить Кстати, отделение "внешних" клиентов от "внутренних" сильно облегчает разрешение циклических ссылок. Так что выделение сервера в отдельный процесс ты зря упомянул
M>Это как раз и будет отличной иллюстрацией проблемы циклических ссылок. Какой-нибудь Recordset держит ссылку на ColumnCollection, а ColumnCollection держит ссылку на Recordset. Простой подсчёт ссылок такую круговую поруку не сможет освободить, тут нужно крепко сидеть и крепко комбинировать. Что чревато ошибками, утечками ресурсов.
Простой — не сможет, более сложный (сильные/слабые ссылки, например, или ведение списка обратных ссылок) — без особых проблем.
M>>Есть разные методы борьбы, и GC на сегодняшний момент — один из лучших.
S>>Я бы сказал, один из самых ресурсоемких.
M>На RSDN'е я видел статью о сравнении GC и традиционных heap. Комментарии там хорошо проясняют суть вопроса.
Ты имеешь в виду комментарий про сравнение производительности Boehm's GC, Loki::SmallObjectAllocator и непонятно какого хипа общего назначения от непонятно какого компилятора? Так извини, там ни условий тестирования нет, ни исходников теста. Т.е. сравнивается непонятно что с непонятно чем (например, во время теста могла ни разу не запуститься процедура сборки мусора). А ты обрати внимание вот на что — в многопоточном приложении на время сборки мусора и дефрагментации памяти все потоки приходится останавливать. Либо удваивать объем памяти, потребляемой приложением. Либо не дефрагментировать память. Вот определись сначала, про какой GC ты говоришь, потому будем обсуждать его конкретные недостатки (с достоинствами, вроде, все понятно).
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, mihailik, Вы писали:
M>GC решает проблему циклических ссылок. Более стандартные и типичные технологии на этом здорово буксут.
На самом деле циклические ссылки не главно. Главное это то что GC-подобные алгоритмы не требуют явных действий для освобождения объекта непосредственно в месте, где он перестает быть нужен. Т.е. прелесть GC не в том что программисту не надо заботиться об освобождении памяти, прелесть в том что не нужно озабочиваться этим вобще никому, в том числе и рантайму. Главное это обеспечить четкий признак нужности объекта. В результате связей в программе становится значительно меньше. Это тот самый бенефит, который несколько меняет подходы к проектированию в условиях GC.
Причем применение подобных алгоритмов отнюдь не ограничивается управлением памятью. Вот буквально совсем недавно понадобилось хранить часть информации в файлах на диске, а точно отловить момент, когда файл становится ненужен было весьма затруднительно. Применение GC-подобного алгоритма позволило решить задачку весьма просто, хотя конечно ценой небольшой потери производительности и немгновенного удаления ненужных файлов.
S>Я бы сказал, один из самых ресурсоемких.
Ресурсы это не только процессор. Труд программистов и тестеров это тоже ресурс, причем один из самых дорогостоящих и дефицитных.
Здравствуйте, Sergey, Вы писали:
S>Ты имеешь в виду комментарий про сравнение производительности Boehm's GC, Loki::SmallObjectAllocator и непонятно какого хипа общего назначения от непонятно какого компилятора?
Здравствуйте, AndrewVK, Вы писали:
S>>Ты имеешь в виду комментарий про сравнение производительности Boehm's GC, Loki::SmallObjectAllocator и непонятно какого хипа общего назначения от непонятно какого компилятора?
AVK>http://www.rsdn.ru/article/?dotnet/GCnet.xml
Угу, как обычно — тестируется однопоточная программа. А про влияние GC на скорость работы многопоточной программы — ни слова.
Да и для выделения мелких объектов, если нужна скорость, нет смысла использовать хип MSVC — Loki::SmallObjAllocator рулит. Ну или QH из статьи. Так что мой вывод — если нужна скорость или критично минимальное время реакции, GC использовать нельзя.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, AndrewVK, Вы писали:
M>>GC решает проблему циклических ссылок. Более стандартные и типичные технологии на этом здорово буксут.
AVK>На самом деле циклические ссылки не главно. Главное это то что GC-подобные алгоритмы не требуют явных действий для освобождения объекта непосредственно в месте, где он перестает быть нужен.
И без GC не часто требуется освобождать объект руками. Я вот посчитал ради интереса количество вызовов new/delete в одном из своих проектов — 148 new и 21 delete на 936 kb исходников. Ну не использовать же из-за двух десятков delete GC.
AVK>Т.е. прелесть GC не в том что программисту не надо заботиться об освобождении памяти, прелесть в том что не нужно озабочиваться этим вобще никому, в том числе и рантайму.
Ну-ну. Это только если не считать GC частью рантайма.
AVK> Главное это обеспечить четкий признак нужности объекта.
Насколько я понимаю, в Boehm's GC (и базирующимися на нем Java GC и .Net GC) таким признаком служит размещение адреса объекта в стеке (объект на периметре). Ну и само собой, нужными считаются все объекты, на которые ссылаются объекты, находящиеся на периметре. Почти то же самое делается с помощью смартпойнтеров без особых затрат.
AVK> В результате связей в программе становится значительно меньше. Это тот самый бенефит, который несколько меняет подходы к проектированию в условиях GC.
Бывает и такое, хотя мне такие ситуации встречались достаточно редко.
AVK>Причем применение подобных алгоритмов отнюдь не ограничивается управлением памятью. Вот буквально совсем недавно понадобилось хранить часть информации в файлах на диске, а точно отловить момент, когда файл становится ненужен было весьма затруднительно. Применение GC-подобного алгоритма позволило решить задачку весьма просто, хотя конечно ценой небольшой потери производительности и немгновенного удаления ненужных файлов.
А я не имею ничего против применения GC-подобных алгоритмов Мне только не нравится, когда GC применят там, где он нафиг не нужен.
S>>Я бы сказал, один из самых ресурсоемких.
AVK>Ресурсы это не только процессор. Труд программистов и тестеров это тоже ресурс, причем один из самых дорогостоящих и дефицитных.
Угу, однако если продукт труда программистов будет сильно тормозить и выжирать всю доступную системе память, то этот самый труд рискует остаться неоплаченным
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
S>Да и для выделения мелких объектов, если нужна скорость, нет смысла использовать хип MSVC — Loki::SmallObjAllocator рулит.
Приведи тесты.
S>Так что мой вывод — если нужна скорость или критично минимальное время реакции, GC использовать нельзя.
А вот в некоторых случаях время отклика серверов приложений, написанных на джаве оказывалось заметно лучше чем их же на С++, хотя разброс был повыше. Ну а то что есть моменты, когда GC будет не лучшим решением, с этим вроде бы никто и не спорит.
Здравствуйте, Sergey, Вы писали:
AVK> Главное это обеспечить четкий признак нужности объекта.
S>Насколько я понимаю, в Boehm's GC (и базирующимися на нем Java GC и .Net GC) таким признаком служит размещение адреса объекта в стеке (объект на периметре). Ну и само собой, нужными считаются все объекты, на которые ссылаются объекты, находящиеся на периметре. Почти то же самое делается с помощью смартпойнтеров без особых затрат.
Нет. Ключевое отличие этих самых поинтеров от GC в том что в них надо явно указывать что объект стал не нужен. Пускай это обеспечивает компилятор, но к сожалению компилятор не сможет нам такого гарантировать в распредленной среде. Сбои могут привести к тому что где то смартпоинтер не сможет декрементировать счетчик ссылок и самое страшное что такая ситуация фатальна — никакими способами отловить это и исправить ситуацию нет. Ну и остается проблема циклических ссылок, которая тоже смартпоинтерами не решается.
AVK> В результате связей в программе становится значительно меньше. Это тот самый бенефит, который несколько меняет подходы к проектированию в условиях GC.
S>Бывает и такое, хотя мне такие ситуации встречались достаточно редко.
Но не стоит наверное по тому что такие ситуации тебе встречаются редко делать окончательный вывод о применимости технологии, согласен? Мне вот например встречаются часто.
S>А я не имею ничего против применения GC-подобных алгоритмов Мне только не нравится, когда GC применят там, где он нафиг не нужен.
А где он применяется где он нафик не нужен? К чему собственно притензии?
AVK>Ресурсы это не только процессор. Труд программистов и тестеров это тоже ресурс, причем один из самых дорогостоящих и дефицитных.
S>Угу, однако если продукт труда программистов будет сильно тормозить и выжирать всю доступную системе память, то этот самый труд рискует остаться неоплаченным
Опять же ты правильно заметил — все зависит от конкретной задачи. Иногда производительность не является самым главным фактором. По секрету могу сказать что заваленных из-за недостаточной производительности проектов мне видеть не приходилось, а вот заваленных из-за огромного количества багов, недостаточной гибкости и функциональности, неудобной архитектуры я видел море. Поэтому мне вполне понятно движение в сторону улучшения цикла разработки, пусть даже в ущерб перфомансу.
Здравствуйте, Sergey, Вы писали:
S>Здравствуйте, AndrewVK, Вы писали:
S>Насколько я понимаю, в Boehm's GC (и базирующимися на нем Java GC и .Net GC) таким признаком служит размещение адреса объекта в стеке (объект на периметре). Ну и само собой, нужными считаются все объекты, на которые ссылаются объекты, находящиеся на периметре. Почти то же самое делается с помощью смартпойнтеров без особых затрат.
Так вроде в Java в свое время отказались от GC по схеме подсчета ссылок, из-за ее медленности (пусть даже пара асмовых команд). Просто там очень много операция с объектами делается и накладные расходы сильно возрастают.
7. О чем невозможно говорить, о том следует молчать.
Здравствуйте, AndrewVK, Вы писали:
S>>Да и для выделения мелких объектов, если нужна скорость, нет смысла использовать хип MSVC — Loki::SmallObjAllocator рулит.
AVK>Приведи тесты.
Тебе исходники показать или результаты? Исходники не раньше чем завтра, а результаты я и так помню — 1.5 — 2 раза для объектов размером ~ 50 байт.
S>>Так что мой вывод — если нужна скорость или критично минимальное время реакции, GC использовать нельзя.
AVK>А вот в некоторых случаях время отклика серверов приложений, написанных на джаве оказывалось заметно лучше чем их же на С++, хотя разброс был повыше. Ну а то что есть моменты, когда GC будет не лучшим решением, с этим вроде бы никто и не спорит.
Ну вот и замечательно.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
S>Здравствуйте, AndrewVK, Вы писали:
S>Насколько я понимаю, в Boehm's GC (и базирующимися на нем Java GC и .Net GC) таким признаком служит размещение адреса объекта в стеке (объект на периметре). Ну и само собой, нужными считаются все объекты, на которые ссылаются объекты, находящиеся на периметре. Почти то же самое делается с помощью смартпойнтеров без особых затрат.
Так вроде в Java в свое время отказались от GC по схеме подсчета ссылок, из-за ее медленности (пусть даже пара асмовых команд). Просто там очень много операция с объектами делается и накладные расходы сильно возрастают.
7. О чем невозможно говорить, о том следует молчать.
Здравствуйте, AndrewVK, Вы писали:
AVK>> Главное это обеспечить четкий признак нужности объекта.
S>>Насколько я понимаю, в Boehm's GC (и базирующимися на нем Java GC и .Net GC) таким признаком служит размещение адреса объекта в стеке (объект на периметре). Ну и само собой, нужными считаются все объекты, на которые ссылаются объекты, находящиеся на периметре. Почти то же самое делается с помощью смартпойнтеров без особых затрат.
AVK>Нет. Ключевое отличие этих самых поинтеров от GC в том что в них надо явно указывать что объект стал не нужен. Пускай это обеспечивает компилятор, но к сожалению компилятор не сможет нам такого гарантировать в распредленной среде.
В распределенной среде — да, не сможет. И чистый GC тоже не сможет (либо производительность его будет никакая). В обоих случаях нужны дополнительные телодвижения.
AVK> Сбои могут привести к тому что где то смартпоинтер не сможет декрементировать счетчик ссылок и самое страшное что такая ситуация фатальна — никакими способами отловить это и исправить ситуацию нет.
А что, уже есть распределенные реализации GC? Причем в которых при пересечении объектом границ между машинами для уничтожения объекта используется именно GC, а не подсчет ссылок? Дык извини, они так же (или в большей степени) будут подвержены воздействию ошибок, как и подсчет ссылок.
AVK> Ну и остается проблема циклических ссылок, которая тоже смартпоинтерами не решается.
Сильные/слабые ссылки + переопределение оператора new вполне помогают.
AVK>Но не стоит наверное по тому что такие ситуации тебе встречаются редко делать окончательный вывод о применимости технологии, согласен? Мне вот например встречаются часто.
Цитату, пожалуйста — где я говорю о том, что GC неприменим нигде. В компиляторах, например, ему самое место.
AVK>А где он применяется где он нафик не нужен?
Ну например в игрушках.
AVK>К чему собственно притензии?
А претензии собственно я не предъявлял — я просто упомянул пару недостатков GC.
AVK>Опять же ты правильно заметил — все зависит от конкретной задачи. Иногда производительность не является самым главным фактором. По секрету могу сказать что заваленных из-за недостаточной производительности проектов мне видеть не приходилось, а вот заваленных из-за огромного количества багов, недостаточной гибкости и функциональности, неудобной архитектуры я видел море.
А при чем здесь недостаточная гибкость, функциональность и неудобная архитектура?
AVK>Поэтому мне вполне понятно движение в сторону улучшения цикла разработки, пусть даже в ущерб перфомансу.
Мне тоже, кстати. Но применение GC сильно усложняет разработку в том случае, если есть критичные по быстродействию части.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
M>GC решает проблему циклических ссылок. Более стандартные и типичные технологии на этом здорово буксут.
AVK>На самом деле циклические ссылки не главно.
Циклические ссылки — не главное, но принципиальное преимущество. Остальные уже больше к скорости относятся. AddRef/Release по удобству мало отличается от GC.
Например, в Дельфи можно при желании забивать на освобождение объектов:
var obj : IMyObject;
i : integer;
begin
for i:=0 to 100 do
if Random>0.5
then obj:=TMyObject.Create
end;
Здравствуйте, Sergey, Вы писали:
S>В распределенной среде — да, не сможет. И чистый GC тоже не сможет (либо производительность его будет никакая). В обоих случаях нужны дополнительные телодвижения.
Но согласись что гарантии, даваемые смартпоинтерами даже в случае единственного процесса все таки поменьше, всегда из за какого либо сбоя может не вызваться деструктор смартпоинтера.
AVK> Сбои могут привести к тому что где то смартпоинтер не сможет декрементировать счетчик ссылок и самое страшное что такая ситуация фатальна — никакими способами отловить это и исправить ситуацию нет.
S>А что, уже есть распределенные реализации GC?
Есть, лизинг называется.
S>Причем в которых при пересечении объектом границ между машинами для уничтожения объекта используется именно GC, а не подсчет ссылок?
Именно GC-подобный алгоритм. Никаких счетчиков ссылок.
S>Дык извини, они так же (или в большей степени) будут подвержены воздействию ошибок, как и подсчет ссылок.
Да вот как раз нет, любой сбой в итоге приведет к недосягаемости того кто ссылается и GC тут же пришибет такие объекты.
AVK> Ну и остается проблема циклических ссылок, которая тоже смартпоинтерами не решается.
S>Сильные/слабые ссылки + переопределение оператора new вполне помогают.
Это все больше и больше гемороя. Уже смартпоинтеры это увеличение объема ручной работы. Причем ты никак не застрахован от того что смартпоинтер будут использовать неверно или вобще не будут использовать. А уж ручное распределение куда воткнуть слабую ссылку совсем не фонтан.
AVK>Но не стоит наверное по тому что такие ситуации тебе встречаются редко делать окончательный вывод о применимости технологии, согласен? Мне вот например встречаются часто.
S>Цитату, пожалуйста — где я говорю о том, что GC неприменим нигде.
M>Пока один программист — понятно. Как только появляются несколько (например, компонент используется внешней программой), возникают вопросы.
Которые прекрасно решаются и без GC. Хотя с GC, безусловно, для их решения приходится предпринимать несколько меньше усилий.
...
M>Есть разные методы борьбы, и GC на сегодняшний момент — один из лучших.
Я бы сказал, один из самых ресурсоемких.
Заметь, не некоторые, не иногда. А именно все задачи использования компонент внешней программой прекрасно решаются без GC.
В общем у меня сложилось впечатление что основная мысль была в том что можно обойтись без GC практически всегда, а те мелкие удобства которые он дает перекрываются его выдающейся ресурсоемкостью.
AVK>А где он применяется где он нафик не нужен?
S>Ну например в игрушках.
Много видел игрушек на дотнете? Я пока ни одной, если не считать сапера, который я сам же написал и его порта под WinCE.
AVK>Опять же ты правильно заметил — все зависит от конкретной задачи. Иногда производительность не является самым главным фактором. По секрету могу сказать что заваленных из-за недостаточной производительности проектов мне видеть не приходилось, а вот заваленных из-за огромного количества багов, недостаточной гибкости и функциональности, неудобной архитектуры я видел море.
S>А при чем здесь недостаточная гибкость, функциональность и неудобная архитектура?
Да все при том. Куча рутинной работы, вроде написания и использования смартпоинтеров со слабыми ссылками или беклогом удобству и скорости разработки не способствуют.
AVK>Поэтому мне вполне понятно движение в сторону улучшения цикла разработки, пусть даже в ущерб перфомансу.
S>Мне тоже, кстати. Но применение GC сильно усложняет разработку в том случае, если есть критичные по быстродействию части.
Вот как то за 2 с лишним года программирования сначала под джаву, а потом под дотнет я что то особо не страдал. Зато перед этим на дельфях страдал от утечек регулярно.
Здравствуйте, mihailik, Вы писали:
M>Циклические ссылки — не главное, но принципиальное преимущество. Остальные уже больше к скорости относятся. AddRef/Release по удобству мало отличается от GC.
Отличается. Ровно в два раза — Release не нужен
M>Например, в Дельфи можно при желании забивать на освобождение объектов:
M>
M>var obj : IMyObject;
M> i : integer;
M>begin
M> for i:=0 to 100 do
M> if Random>0.5
M> then obj:=TMyObject.Create
M>end;
M>
Здравствуйте, WFrag, Вы писали:
AVK>>>А где он применяется где он нафик не нужен?
S>>Ну например в игрушках.
WF>Мменя поглючило или в Ил-2 java использовалась? Я там вроде какие-то классы видел, JVM.
Вот про Ил-2 я как раз и говорил Там AI на java написан. В связи с чем иногда наблюдается такой прикол: заходишь на цель, враги разбегаются, их AI жутко напрягается, что вызывает сборку мусора. В результате сборки мусора (пара секунд) имеем лежащие на земле горящие обломки самолета Хотя может я и ошибаюсь и это не GC виноват.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, AndrewVK, Вы писали:
AVK>Но согласись что гарантии, даваемые смартпоинтерами даже в случае единственного процесса все таки поменьше, всегда из за какого либо сбоя может не вызваться деструктор смартпоинтера.
Не может. При таких сбоях, в результате которых не вызываются деструкторы смартпойнтеров, приложение просто не выживет.
AVK>> Сбои могут привести к тому что где то смартпоинтер не сможет декрементировать счетчик ссылок и самое страшное что такая ситуация фатальна — никакими способами отловить это и исправить ситуацию нет.
S>>А что, уже есть распределенные реализации GC?
AVK>Есть, лизинг называется.
url?
S>>Причем в которых при пересечении объектом границ между машинами для уничтожения объекта используется именно GC, а не подсчет ссылок?
AVK>Именно GC-подобный алгоритм. Никаких счетчиков ссылок.
Т.е., сервер сканирует все адресное пространство всех клиентов и ищет там свои адреса? Или все-таки ведется отдельная таблица всех внешних ссылок?
S>>Дык извини, они так же (или в большей степени) будут подвержены воздействию ошибок, как и подсчет ссылок.
AVK>Да вот как раз нет, любой сбой в итоге приведет к недосягаемости того кто ссылается и GC тут же пришибет такие объекты.
А если сбой случится именно во время работы GC? За здорово живешь прибъется нужный объект?
AVK>> Ну и остается проблема циклических ссылок, которая тоже смартпоинтерами не решается.
S>>Сильные/слабые ссылки + переопределение оператора new вполне помогают.
AVK>Это все больше и больше гемороя. Уже смартпоинтеры это увеличение объема ручной работы. Причем ты никак не застрахован от того что смартпоинтер будут использовать неверно или вобще не будут использовать.
Неверное использование исключить можно почти всегда, неиспользование вообще — естественно, никак не контролируется.
AVK>А уж ручное распределение куда воткнуть слабую ссылку совсем не фонтан.
Это как?
AVK>>Но не стоит наверное по тому что такие ситуации тебе встречаются редко делать окончательный вывод о применимости технологии, согласен? Мне вот например встречаются часто.
S>>Цитату, пожалуйста — где я говорю о том, что GC неприменим нигде. AVK>
M>>Пока один программист — понятно. Как только появляются несколько (например, компонент используется внешней программой), возникают вопросы.
AVK>Которые прекрасно решаются и без GC. Хотя с GC, безусловно, для их решения приходится предпринимать несколько меньше усилий.
AVK>...
M>>Есть разные методы борьбы, и GC на сегодняшний момент — один из лучших.
AVK>Я бы сказал, один из самых ресурсоемких.
AVK>Заметь, не некоторые, не иногда. А именно все задачи использования компонент внешней программой прекрасно решаются без GC.
Решаются, разумеется. Иногда с большими усилиями, чаще — не очень.
AVK>В общем у меня сложилось впечатление что основная мысль была в том что можно обойтись без GC практически всегда,
Обойтись без GC можно не практически всегда, а вообще всегда. Иногда — малой кровью, иногда — большой.
По крайней мере, до появления Java GC оставался в области академических изысков.
AVK>а те мелкие удобства которые он дает перекрываются его выдающейся ресурсоемкостью.
Чаще — перекрываются, иногда — нет. Но, опять же, про то, что GC неприменим нигде, я не говорил. Тебе не приходило в голову, что целесообразность применения какого-то средства для решения задачи и принципиальная возможность решения задачи без этого средства — разные вещи?
AVK>>А где он применяется где он нафик не нужен?
S>>Ну например в игрушках.
AVK>Много видел игрушек на дотнете? Я пока ни одной, если не считать сапера, который я сам же написал и его порта под WinCE.
А при чем здесь дотнет? Я про GC говорил, дотнет сам по себе меня не интересует.
AVK>>Опять же ты правильно заметил — все зависит от конкретной задачи. Иногда производительность не является самым главным фактором. По секрету могу сказать что заваленных из-за недостаточной производительности проектов мне видеть не приходилось, а вот заваленных из-за огромного количества багов, недостаточной гибкости и функциональности, неудобной архитектуры я видел море.
S>>А при чем здесь недостаточная гибкость, функциональность и неудобная архитектура?
AVK>Да все при том. Куча рутинной работы, вроде написания и использования смартпоинтеров со слабыми ссылками или беклогом удобству и скорости разработки не способствуют.
Есть куча готовых библиотек, а то, чего нет — пишется один раз. И работу эту я рутиной назвать не могу. Использование же смартпойнтеров — исключительно дело привычки, почти не напрягает. А связи между количеством рутиной работы и неудобной архитектурой я все равно не вижу.
AVK>>Поэтому мне вполне понятно движение в сторону улучшения цикла разработки, пусть даже в ущерб перфомансу.
S>>Мне тоже, кстати. Но применение GC сильно усложняет разработку в том случае, если есть критичные по быстродействию части.
AVK>Вот как то за 2 с лишним года программирования сначала под джаву, а потом под дотнет я что то особо не страдал.
Ты писал на дотнете критичные к скорости исполнения вещи? Или ты делал это на джаве?
AVK>Зато перед этим на дельфях страдал от утечек регулярно.
Странно, я при работе на С++ с утечками памяти сталкиваюсь не чаще раза в несколько месяцев. И локализую их достаточно быстро.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
S>Обойтись без GC можно не практически всегда, а вообще всегда. Иногда — малой кровью, иногда — большой. S>По крайней мере, до появления Java GC оставался в области академических изысков.
Не согласен . Есть вещи, после переписывания которых без GC поменяются (причем скорее всего) принципы их работы и структура.
Java JFC Swing. Переписать, наверное, можно. Только получится уже не то.
Хотя это смотря с какой точностью смотреть. На уровне Asm-а и WinApi, напрмер, никакого GC нет... А любая прога под Винды в результате в это и вырождается...
7. О чем невозможно говорить, о том следует молчать.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ну и дальше? При чем тут Дельфи?
Ну как, можно отключить проверку рантайм-ошибок, не ловить исключения, никогда не закрывать за собой файлы и SQL-соединения, а пользователей научить кнопке reset, благо положить NTFS тяжело )
Ты будешь рыдать, но таких приложений на Delphi я видел N+1. К нам они попадают как раз в тот момент, когда главный архитектор оригинального проекта уходит создавать свою контору, а остатки IT-отдела умудряются добавлять не более одной фичи в месяц. И вот тогда наступает время нанять русских.
... << RSDN@Home 1.0 beta 7a >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sergey, Вы писали:
S>Не может. При таких сбоях, в результате которых не вызываются деструкторы смартпойнтеров, приложение просто не выживет.
Ну это ты зря. Если произошел сбой в потоке, обслуживающем клиента, его можно просто пришибить. В этом случае GC все равно весь мусор приберет, а вот смартпоинтеры так и останутся незакрытыми.
AVK>Есть, лизинг называется.
S>url?
MSDN
AVK>Именно GC-подобный алгоритм. Никаких счетчиков ссылок.
S>Т.е., сервер сканирует все адресное пространство всех клиентов и ищет там свои адреса? Или все-таки ведется отдельная таблица всех внешних ссылок?
Есть такая штука как спонсоры. Подробности в MSDN.
AVK>Да вот как раз нет, любой сбой в итоге приведет к недосягаемости того кто ссылается и GC тут же пришибет такие объекты.
S>А если сбой случится именно во время работы GC? За здорово живешь прибъется нужный объект?
Вероятность сбоя самого GC значительно меньше, поскольку код не пользовательский, да и выполняется нечасто. В любом случае, даже если GC сбойнет, то он таки все почистит при следующем запуске.
S>Неверное использование исключить можно почти всегда,
Сказки это все. Если можно что то сделать не так как надо, это обязательно сделают.
AVK>А уж ручное распределение куда воткнуть слабую ссылку совсем не фонтан.
S>Это как?
Это так. Все эти алгоритмы отслеживания циклов, если их выполнять для всех смартпоинтеров, приводят к тому что производительность становится хуже производительности GC. Ранние реализации GC в джаве здесь уже в качестве примера приводили. Единсвенный способ добиться приемлемой производительности — программисту указывать хинты в тех местах где могут встретиться циклические ссылки.
S>Решаются, разумеется. Иногда с большими усилиями, чаще — не очень.
Вот о том и речь что я не согласен с тем что чаще всего GC не нужен.
AVK>а те мелкие удобства которые он дает перекрываются его выдающейся ресурсоемкостью.
S>Чаще — перекрываются, иногда — нет.
То есть, следуя твоей логике, оказывается что GC практически никогда не нужен. Что и требовалось доказать.
S>Но, опять же, про то, что GC неприменим нигде, я не говорил.
Ну хорошо, пусть будет как правило неприменим. Это мало что меняет.
S>Есть куча готовых библиотек, а то, чего нет — пишется один раз. И работу эту я рутиной назвать не могу. Использование же смартпойнтеров — исключительно дело привычки, почти не напрягает.
Да собственно и явный вызов деструктора тоже дело привычки и в общем то не напрягает. Вот только почему то утечки памяти явление не такое уж и редкое даже у опытных программистов.
S>А связи между количеством рутиной работы и неудобной архитектурой я все равно не вижу.
Одна из главных задач архитектуры приложения — снижение количества рутинной работы.
AVK>Вот как то за 2 с лишним года программирования сначала под джаву, а потом под дотнет я что то особо не страдал.
S>Ты писал на дотнете критичные к скорости исполнения вещи? Или ты делал это на джаве?
Серверные приложения являются критичными к скорости исполнения? А десктоп-клиенты, вроде почтовых являются?
S>Странно, я при работе на С++ с утечками памяти сталкиваюсь не чаще раза в несколько месяцев. И локализую их достаточно быстро.
Ну значит у тебя такие задачки. Чаще же все намного печальнее.
Здравствуйте, AndrewVK, Вы писали:
S>>Не может. При таких сбоях, в результате которых не вызываются деструкторы смартпойнтеров, приложение просто не выживет.
AVK>Ну это ты зря. Если произошел сбой в потоке, обслуживающем клиента, его можно просто пришибить. В этом случае GC все равно весь мусор приберет, а вот смартпоинтеры так и останутся незакрытыми.
Ах вон ты про что. В результате такой ситуации запросто может получиться, что клиент что-то куда-то записал только на половину, объекты, порожденные в этом потоке имеют неправильное состояние и породят еще один сбой в коде финализации при сборке мусора и т.п. В любом случае надеятся на правильное поведение программы, в которой произошло непонятно что, просто глупо.
AVK>>Именно GC-подобный алгоритм. Никаких счетчиков ссылок.
S>>Т.е., сервер сканирует все адресное пространство всех клиентов и ищет там свои адреса? Или все-таки ведется отдельная таблица всех внешних ссылок?
AVK>Есть такая штука как спонсоры. Подробности в MSDN.
"The lease manager maintains a lease list with leases sorted by remaining lease time" "The lease manager maintains a list of the sponsors (they implement the ISponsor interface) stored in order of decreasing sponsorship time." Я примерно об этом и говорил — список ссылок. То же самое запросто делается на смартпойнтерах без GC — какая разница, как убивать объекты по ссылкам из листа — гарбадж коллектором или вызовом release.
AVK>>Да вот как раз нет, любой сбой в итоге приведет к недосягаемости того кто ссылается и GC тут же пришибет такие объекты.
S>>А если сбой случится именно во время работы GC? За здорово живешь прибъется нужный объект?
AVK>Вероятность сбоя самого GC значительно меньше, поскольку код не пользовательский, да и выполняется нечасто. В любом случае, даже если GC сбойнет, то он таки все почистит при следующем запуске.
Давай-ка сначала договоримся, про какие сбои мы говорим — про сбои коммуникаций или ошибки в программе? Я так понял, начал говорить ты именно про ошибки коммуникаций — иначе при чем здесь распределенные системы?
S>>Неверное использование исключить можно почти всегда,
AVK>Сказки это все. Если можно что то сделать не так как надо, это обязательно сделают.
Если бы это всегда соответствовало действительности, ни одна работоспособная программа не была бы до сих пор написана Больше возможностей, больше и ответственность — по-другому не бывает. А запретить неправильное использование класса и смартпойнтера для него иногда (не всегда, к сожалению) очень просто: приватные конструктор и деструктор, смартпойнтер нужного типа объявляется другом.
AVK>Это так. Все эти алгоритмы отслеживания циклов, если их выполнять для всех смартпоинтеров, приводят к тому что производительность становится хуже производительности GC. Ранние реализации GC в джаве здесь уже в качестве примера приводили. Единсвенный способ добиться приемлемой производительности — программисту указывать хинты в тех местах где могут встретиться циклические ссылки.
Теперь понятно. Да, программисту придется использовать для слабых ссылок один класс, для сильных — другой.
S>>Решаются, разумеется. Иногда с большими усилиями, чаще — не очень.
AVK>Вот о том и речь что я не согласен с тем что чаще всего GC не нужен.
Ну, это действительно зависит от того, что ты чаще всего делаешь.
AVK>То есть, следуя твоей логике, оказывается что GC практически никогда не нужен. Что и требовалось доказать.
Не то чтобы практически никогда, но очень часто — не нужен.
S>>Но, опять же, про то, что GC неприменим нигде, я не говорил.
AVK>Ну хорошо, пусть будет как правило неприменим. Это мало что меняет.
Довольно многое, на мой взгляд.
S>>Есть куча готовых библиотек, а то, чего нет — пишется один раз. И работу эту я рутиной назвать не могу. Использование же смартпойнтеров — исключительно дело привычки, почти не напрягает.
AVK>Да собственно и явный вызов деструктора тоже дело привычки и в общем то не напрягает.
Это разные вещи. Принципиально разные. Одно дело писать autoref_ptr<Object> obj(new Object) вместо Object* obj = new Object, и совсем другое — отслеживать, где объект перестал быть нужен.
AVK>Вот только почему то утечки памяти явление не такое уж и редкое даже у опытных программистов.
Вредные привычки долго умирают, это да. Ну а GC в этом плане всего лишь заменяет утечки памяти на утечки хэндлов.
S>>А связи между количеством рутиной работы и неудобной архитектурой я все равно не вижу.
AVK>Одна из главных задач архитектуры приложения — снижение количества рутинной работы.
Но не наоборот Уменьшение количества рутиной работы вовсе не означает автоматического улучшения архитектуры.
AVK>Серверные приложения являются критичными к скорости исполнения?
Не всегда. Часто самым узким местом у них является внешняя БД, и хоть ты свое серверное приложение до последней строчки обоптимизируй — ощутимо быстрее оно не станет.
AVK>А десктоп-клиенты, вроде почтовых являются?
Mail и news клиенты, естественно, не являются критичными ни к скорости работы, ни к объему пожираемой памяти — если они пишутся для современного писишного железа.
S>>Странно, я при работе на С++ с утечками памяти сталкиваюсь не чаще раза в несколько месяцев. И локализую их достаточно быстро.
AVK>Ну значит у тебя такие задачки. Чаще же все намного печальнее.
Да обычные совершенно задачки. Но действительно, чаще все намного печальнее.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
AVK>Есть такая штука как спонсоры. Подробности в MSDN.
S>"The lease manager maintains a lease list with leases sorted by remaining lease time" "The lease manager maintains a list of the sponsors (they implement the ISponsor interface) stored in order of decreasing sponsorship time." Я примерно об этом и говорил — список ссылок. То же самое запросто делается на смартпойнтерах без GC — какая разница, как убивать объекты по ссылкам из листа — гарбадж коллектором или вызовом release.
Точно! В случае с внешними клиентами AddRef/Release и GC пользуются одинаковой стратегией.
Здравствуйте, Sergey, Вы писали:
S>Ах вон ты про что. В результате такой ситуации запросто может получиться, что клиент что-то куда-то записал только на половину, объекты, порожденные в этом потоке имеют неправильное состояние и породят еще один сбой в коде финализации при сборке мусора и т.п.
Неверный вывод. Все неуправляемые ресурсы должны оборачиваться try .. finally, все управляемые ресурсы прибьются гарантированно в любом состоянии.
S>В любом случае надеятся на правильное поведение программы, в которой произошло непонятно что, просто глупо.
Не глупо а насущная необходимость.
S>"The lease manager maintains a lease list with leases sorted by remaining lease time" "The lease manager maintains a list of the sponsors (they implement the ISponsor interface) stored in order of decreasing sponsorship time." Я примерно об этом и говорил — список ссылок. То же самое запросто делается на смартпойнтерах без GC — какая разница, как убивать объекты по ссылкам из листа — гарбадж коллектором или вызовом release.
Разница в причинах. Список ссылок управляется целиком и полностью сервером, а для смартпоинтеров такой список будет управляться клиентом.
AVK>Вероятность сбоя самого GC значительно меньше, поскольку код не пользовательский, да и выполняется нечасто. В любом случае, даже если GC сбойнет, то он таки все почистит при следующем запуске.
S>Давай-ка сначала договоримся, про какие сбои мы говорим — про сбои коммуникаций или ошибки в программе? Я так понял, начал говорить ты именно про ошибки коммуникаций — иначе при чем здесь распределенные системы?
И ошибки и сбои коммуникаций.
AVK>Сказки это все. Если можно что то сделать не так как надо, это обязательно сделают.
S>Если бы это всегда соответствовало действительности, ни одна работоспособная программа не была бы до сих пор написана
Тем не менее куча умерших из-за наличия трудноисправимых ошибок проектов существует.
S>Теперь понятно. Да, программисту придется использовать для слабых ссылок один класс, для сильных — другой.
А это вери бед дизайн, поскольку мы навешиваем свои проблемы на программера.
AVK>То есть, следуя твоей логике, оказывается что GC практически никогда не нужен. Что и требовалось доказать.
S>Не то чтобы практически никогда, но очень часто — не нужен.
Вот с этим я и не согласен.
AVK>Ну хорошо, пусть будет как правило неприменим. Это мало что меняет.
S>Довольно многое, на мой взгляд.
А по моему ничего. Малоприменимость технологии переводит ее в разряд ненужных.
S>>Есть куча готовых библиотек, а то, чего нет — пишется один раз. И работу эту я рутиной назвать не могу. Использование же смартпойнтеров — исключительно дело привычки, почти не напрягает.
AVK>Да собственно и явный вызов деструктора тоже дело привычки и в общем то не напрягает.
S>Это разные вещи. Принципиально разные. Одно дело писать autoref_ptr<Object> obj(new Object) вместо Object* obj = new Object, и совсем другое — отслеживать, где объект перестал быть нужен.
Вот только не все так просто. Все это катит если смартпоинтер можно разместить на стеке. Тогда компилер позаботится о вызове его деструктора. А если время жизни объекта больше области видимости? А? Таким же манером нужно явно вызывать деструктор смартпоинтера.
AVK>Вот только почему то утечки памяти явление не такое уж и редкое даже у опытных программистов.
S>Вредные привычки долго умирают, это да. Ну а GC в этом плане всего лишь заменяет утечки памяти на утечки хэндлов.
Каких хендлов? Ты о чем?
S>>А связи между количеством рутиной работы и неудобной архитектурой я все равно не вижу.
AVK>Одна из главных задач архитектуры приложения — снижение количества рутинной работы.
S>Но не наоборот Уменьшение количества рутиной работы вовсе не означает автоматического улучшения архитектуры.
Зато увеличение количества рутинной работы точно свидетельствует о недостатках архитектуры. Так есть связь?
AVK>Серверные приложения являются критичными к скорости исполнения?
S>Не всегда. Часто самым узким местом у них является внешняя БД, и хоть ты свое серверное приложение до последней строчки обоптимизируй — ощутимо быстрее оно не станет.
AVK>А десктоп-клиенты, вроде почтовых являются?
S>Mail и news клиенты, естественно, не являются критичными ни к скорости работы, ни к объему пожираемой памяти — если они пишутся для современного писишного железа.
Так что же тогда из часто встречающихся задач критично к скорости выполнения?
S>Да обычные совершенно задачки.
Здравствуйте, mihailik, Вы писали:
M>Например, в Дельфи можно при желании забивать на освобождение объектов:
AVK>Ну и дальше? При чем тут Дельфи?
M>При том, что Дельфи работает без GC. Те же самые удобства для программиста и без GC достижимы, на AddRef/Release
Чего? Ты о каких таких AddRef в дельфях? Если ты создал объект в Дельфях то ты его должен грохнуть, никто за тебя это не сделает. Исключение составляют только ссылки на СОМ объекты. Твой код приведет к утечкам.
M>При том, что Дельфи работает без GC. Те же самые удобства для программиста и без GC достижимы, на AddRef/Release
AVK>Чего? Ты о каких таких AddRef в дельфях? Если ты создал объект в Дельфях то ты его должен грохнуть, никто за тебя это не сделает. Исключение составляют только ссылки на СОМ объекты. Твой код приведет к утечкам.
Исключение составляют интерфейсы, которые всегда работают по AddRef/Release, включая COM-объекты. Мой код не приведёт к утечкам.
M>Точно! В случае с внешними клиентами AddRef/Release и GC пользуются одинаковой стратегией.
AVK>Стратегия принципиально разная. Если клиент не вызовет Release то все, полный писец.
Даже в DCOM есть какие-то дополнительные механизмы для этих случаев. Слышал я, что там некое "пингование" происходит, кода по сети работают. Это пример.
А стратегия-то одна: хранить список внешних ссылок, и периодически проверять их жизнеспособность. В принципе, тот же AddRef/Release, только доделанный.
Интерестно, есть ли в природе более гладкие и остроумные стратегии на этот счёт? Пулы какие-нибудь — это старо и неостроумно.
Здравствуйте, AndrewVK, Вы писали:
S>>Ах вон ты про что. В результате такой ситуации запросто может получиться, что клиент что-то куда-то записал только на половину, объекты, порожденные в этом потоке имеют неправильное состояние и породят еще один сбой в коде финализации при сборке мусора и т.п.
AVK>Неверный вывод. Все неуправляемые ресурсы должны оборачиваться try .. finally, все управляемые ресурсы прибьются гарантированно в любом состоянии.
Ты не видишь разницы между ресурсами и состоянием объекта, которое в результате ошибки будет inconsistent?
S>>В любом случае надеятся на правильное поведение программы, в которой произошло непонятно что, просто глупо.
AVK>Не глупо а насущная необходимость.
Насущная необходимость — писать программы, которые вычисляют незнамо что? Гы
S>>"The lease manager maintains a lease list with leases sorted by remaining lease time" "The lease manager maintains a list of the sponsors (they implement the ISponsor interface) stored in order of decreasing sponsorship time." Я примерно об этом и говорил — список ссылок. То же самое запросто делается на смартпойнтерах без GC — какая разница, как убивать объекты по ссылкам из листа — гарбадж коллектором или вызовом release.
AVK>Разница в причинах. Список ссылок управляется целиком и полностью сервером, а для смартпоинтеров такой список будет управляться клиентом.
Ага, щаз. Кем захочу, тем и будет управляться. Клиентом оно будет управляться только если я решу одноуровневой схемой смартпойнтеров обойтись.
AVK>>Вероятность сбоя самого GC значительно меньше, поскольку код не пользовательский, да и выполняется нечасто. В любом случае, даже если GC сбойнет, то он таки все почистит при следующем запуске.
S>>Давай-ка сначала договоримся, про какие сбои мы говорим — про сбои коммуникаций или ошибки в программе? Я так понял, начал говорить ты именно про ошибки коммуникаций — иначе при чем здесь распределенные системы?
AVK>И ошибки и сбои коммуникаций.
Тогда причем здесь сбои GC и пользовательского кода?
AVK>Тем не менее куча умерших из-за наличия трудноисправимых ошибок проектов существует.
Подобные проекты с GC просто еще не успели появится, не то что умереть
S>>Теперь понятно. Да, программисту придется использовать для слабых ссылок один класс, для сильных — другой.
AVK>А это вери бед дизайн, поскольку мы навешиваем свои проблемы на программера.
Угу, а вызывать руками Dispose при наличии циклических ссылок — вери гуд дизайн и никакой головной боли, да?
AVK>>Ну хорошо, пусть будет как правило неприменим. Это мало что меняет.
S>>Довольно многое, на мой взгляд.
AVK>А по моему ничего. Малоприменимость технологии переводит ее в разряд ненужных.
Существует куча узкоприменимых технологий, не являющихся ненужными.
S>>Это разные вещи. Принципиально разные. Одно дело писать autoref_ptr<Object> obj(new Object) вместо Object* obj = new Object, и совсем другое — отслеживать, где объект перестал быть нужен.
AVK>Вот только не все так просто. Все это катит если смартпоинтер можно разместить на стеке.
Или сделать членом класса
AVK>Тогда компилер позаботится о вызове его деструктора. А если время жизни объекта больше области видимости?
А ничего страшного. Если объект нужен, где-то в программе будут находящиеся внутри какой-нибудь области видимости объект (смартпойнтер, если мы не хотим неприятностей), ссылающийся на экземпляр Object. Когда этот смартпойнтер создавался, он увеличил счетчик ссылок мастер-пойнтера на Object (скрытого в данном случае от программиста — его создает autoref_ptr при конструировании на основе raw-указателя).
GC, кстати, тоже считает нужными только те объекты, адрес которых встретился на стеке, в регистрах или его внутренних таблицах (в которые объект заносится, чтобы предотвратить его уничтожение при взаимодействии со внешним миром), и те обекты, на которые они прямо или косвенно ссылаются.
AVK>А? Таким же манером нужно явно вызывать деструктор смартпоинтера.
Ужас какой
S>>Вредные привычки долго умирают, это да. Ну а GC в этом плане всего лишь заменяет утечки памяти на утечки хэндлов.
AVK>Каких хендлов? Ты о чем?
О ресурсах.
S>>Но не наоборот Уменьшение количества рутиной работы вовсе не означает автоматического улучшения архитектуры.
AVK>Зато увеличение количества рутинной работы точно свидетельствует о недостатках архитектуры. Так есть связь?
Прямой связи нет. Увеличение количества рутинной работы может происходить по самым разным причинам, не только из-за недостатков архитектуры.
AVK>Так что же тогда из часто встречающихся задач критично к скорости выполнения?
Да много чего. В общем-то, определяется это конкретными требованиями, а не принадлежностью софта к какому-либо классу. Какая разница сервер или клиент, главное — будет оно тормозить или нет, если тот код, что ты пишешь, замедлить/ускорить, и заметит ли эти тормоза кто-нибудь.
А так, часто критична по быстродействию 2D-3D графика, кое-какая мультимедия, иногда — парсинг текстов, движки баз данных, сервера, расчитанные на риалтайм использование большим количеством клиентов, иногда — вычислительная математика, некоторые игры, "умный" GUI — да всего и не перечислить.
S>>Да обычные совершенно задачки.
AVK>Какие?
Ну, на моем нынешнем месте работы — GUI (почти весь спектр, от "формочек" до визуализации весьма объемных данных), кой-какая вычислительная математика в клиент-серверном исполнении, кой-кая работа с базами данных.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
S>>В любом случае надеятся на правильное поведение программы, в которой произошло непонятно что, просто глупо.
AVK>Не глупо а насущная необходимость.
S>Насущная необходимость — писать программы, которые вычисляют незнамо что? Гы
Насущная необходимость застраховываться от ситуаций, которые изначально были непредусмотрены.
AVK>Разница в причинах. Список ссылок управляется целиком и полностью сервером, а для смартпоинтеров такой список будет управляться клиентом.
S>Ага, щаз. Кем захочу, тем и будет управляться. Клиентом оно будет управляться только если я решу одноуровневой схемой смартпойнтеров обойтись.
Только если убрать зависимость от действий клиента то как раз GC и получится, тока геморою в 10 раз больше.
S>>Давай-ка сначала договоримся, про какие сбои мы говорим — про сбои коммуникаций или ошибки в программе? Я так понял, начал говорить ты именно про ошибки коммуникаций — иначе при чем здесь распределенные системы?
AVK>И ошибки и сбои коммуникаций.
S>Тогда причем здесь сбои GC и пользовательского кода?
При том что возможность этих сбоев надо учитывать.
AVK>Тем не менее куча умерших из-за наличия трудноисправимых ошибок проектов существует.
S>Подобные проекты с GC просто еще не успели появится, не то что умереть
Про джаву забыл?
AVK>А по моему ничего. Малоприменимость технологии переводит ее в разряд ненужных.
S>Существует куча узкоприменимых технологий, не являющихся ненужными.
Ок, ненужна в универсальном средстве разработок, я правильно формулирую твою мысль?
S>А ничего страшного. Если объект нужен, где-то в программе будут находящиеся внутри какой-нибудь области видимости объект (смартпойнтер, если мы не хотим неприятностей), ссылающийся на экземпляр Object. Когда этот смартпойнтер создавался, он увеличил счетчик ссылок мастер-пойнтера на Object (скрытого в данном случае от программиста — его создает autoref_ptr при конструировании на основе raw-указателя).
Ты перечитай что ты написал и подумай. А потом сравни с GC.
AVK>А? Таким же манером нужно явно вызывать деструктор смартпоинтера.
S>Ужас какой
Не ужас, но потенциальный источник глюков.
S>>Вредные привычки долго умирают, это да. Ну а GC в этом плане всего лишь заменяет утечки памяти на утечки хэндлов.
AVK>Каких хендлов? Ты о чем?
S>О ресурсах.
С чего это вдруг ты о них вспомнил?
S>>Но не наоборот Уменьшение количества рутиной работы вовсе не означает автоматического улучшения архитектуры.
AVK>Зато увеличение количества рутинной работы точно свидетельствует о недостатках архитектуры. Так есть связь?
S>Прямой связи нет. Увеличение количества рутинной работы может происходить по самым разным причинам, не только из-за недостатков архитектуры.
А я и не писал что связь прямая.
S>А так, часто критична по быстродействию 2D-3D графика, кое-какая мультимедия, иногда — парсинг текстов, движки баз данных, сервера, расчитанные на риалтайм использование большим количеством клиентов, иногда — вычислительная математика, некоторые игры, "умный" GUI — да всего и не перечислить.
Вот вот, о том и речь. Сразу тебе скажу — для этих областей дотнет в общем то и не создавался. Так же как не создавался для реалтайм задач к примеру. Никто ведь не возмущается что в багажник мерса мало кирпичей входит.
AVK>Какие?
S>Ну, на моем нынешнем месте работы — GUI (почти весь спектр, от "формочек" до визуализации весьма объемных данных), кой-какая вычислительная математика в клиент-серверном исполнении, кой-кая работа с базами данных.
И ты рассказываешь о том как важно быстродействие? В гуях? По моему это не та задача где можно много выиграть, ручками управляя памятью. Существуют гораздо более другие методы повышения быстродействия подобного класса задач.
В общем дисскусия вырождается в обычный флейм, новые аргументы я уже не вижу, одно перетирание всем известных фактов. Я наверное продолжать не буду.
Здравствуйте, mihailik, Вы писали:
M>Исключение составляют интерфейсы, которые всегда работают по AddRef/Release, включая COM-объекты. Мой код не приведёт к утечкам.
Во первых по твоему коду совершенно непонятно что речь идет об интерфейсах, во вторых интерфесы в Дельфи таки добавили как раз для поддержки кома.
Здравствуйте, AndrewVK, Вы писали:
S>>Насущная необходимость — писать программы, которые вычисляют незнамо что? Гы
AVK>Насущная необходимость застраховываться от ситуаций, которые изначально были непредусмотрены.
Тут вопрос, что в конкретном случае важнее — живучесть программы или достоверность данных. Получается — GC повышает живучесть программы за счет снижения достоверности данных и снижения детерменированности поведения.
AVK>>Разница в причинах. Список ссылок управляется целиком и полностью сервером, а для смартпоинтеров такой список будет управляться клиентом.
S>>Ага, щаз. Кем захочу, тем и будет управляться. Клиентом оно будет управляться только если я решу одноуровневой схемой смартпойнтеров обойтись.
AVK>Только если убрать зависимость от действий клиента то как раз GC и получится, тока геморою в 10 раз больше.
Во-первых, это не GC. Во-вторых, решение с GC менее гибкое.
AVK>>Тем не менее куча умерших из-за наличия трудноисправимых ошибок проектов существует.
S>>Подобные проекты с GC просто еще не успели появится, не то что умереть
AVK>Про джаву забыл?
Смайлик заметил? Ты процент умерших сравни, от общего числа проектов, а не абсолютное количество.
AVK>>А по моему ничего. Малоприменимость технологии переводит ее в разряд ненужных.
S>>Существует куча узкоприменимых технологий, не являющихся ненужными.
AVK>Ок, ненужна в универсальном средстве разработок, я правильно формулирую твою мысль?
Неправильно. В универсальном средстве разработки GC не повредит, но — как опция, а не как безальтернативный способ работы с памятью.
S>>А ничего страшного. Если объект нужен, где-то в программе будут находящиеся внутри какой-нибудь области видимости объект (смартпойнтер, если мы не хотим неприятностей), ссылающийся на экземпляр Object. Когда этот смартпойнтер создавался, он увеличил счетчик ссылок мастер-пойнтера на Object (скрытого в данном случае от программиста — его создает autoref_ptr при конструировании на основе raw-указателя).
AVK>Ты перечитай что ты написал и подумай. А потом сравни с GC.
Поясни, о чем ты?
AVK>>А? Таким же манером нужно явно вызывать деструктор смартпоинтера.
S>>Ужас какой
AVK>Не ужас, но потенциальный источник глюков.
Естественно, поэтому так никто не делает.
S>>>Вредные привычки долго умирают, это да. Ну а GC в этом плане всего лишь заменяет утечки памяти на утечки хэндлов.
AVK>>Каких хендлов? Ты о чем?
S>>О ресурсах.
AVK>С чего это вдруг ты о них вспомнил?
Потому что это вполне реальная проблема, более "вредная", чем утечки памяти.
S>>А так, часто критична по быстродействию 2D-3D графика, кое-какая мультимедия, иногда — парсинг текстов, движки баз данных, сервера, расчитанные на риалтайм использование большим количеством клиентов, иногда — вычислительная математика, некоторые игры, "умный" GUI — да всего и не перечислить.
AVK>Вот вот, о том и речь. Сразу тебе скажу — для этих областей дотнет в общем то и не создавался. Так же как не создавался для реалтайм задач к примеру. Никто ведь не возмущается что в багажник мерса мало кирпичей входит.
Т.е., приличный гуй на нем не сделать?
S>>Ну, на моем нынешнем месте работы — GUI (почти весь спектр, от "формочек" до визуализации весьма объемных данных), кой-какая вычислительная математика в клиент-серверном исполнении, кой-кая работа с базами данных.
AVK>И ты рассказываешь о том как важно быстродействие? В гуях?
Угу. Попробуй pie-chart изобразить, у которого подписи к долькам пирога друг на друга не налазят — сразу поймешь, нужно там быстродействие или нет. Bin packing задачи и Point feature labeling problem в гуях возникают постоянно.
AVK>По моему это не та задача где можно много выиграть, ручками управляя памятью.
Расположение узлов графов — вполне подходящий тому пример.
AVK>Существуют гораздо более другие методы повышения быстродействия подобного класса задач.
AVK>В общем дисскусия вырождается в обычный флейм, новые аргументы я уже не вижу, одно перетирание всем известных фактов. Я наверное продолжать не буду.
Ну и не продолжай.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
AVK>Во первых по твоему коду совершенно непонятно что речь идет об интерфейсах,
Должно быть понятно. IMyObject — что это ещё может быть за тип, конечно интерфейс. Тем более это становится понятно, когда увидеть, что этому объекту присваивается TMyObject.Create.
AVK> во вторых интерфесы в Дельфи таки добавили как раз для поддержки кома.
Ввели для поддержки, а теперь уже используют не только (в седьмой версии особенно!) Очень уж удобная вещь оказалась.
Кстати, пример приводился как иллюстрация GC vs AddRef/Release. Для программиста преимуществ в удобстве записи GC не даёт.
Здравствуйте, unprogrammer, Вы писали:
<...> U>Borland последние десять лет только и пытается отнять кусочек у Microsoft. Своих идей, своих мыслей, а тем более долгосрочных планов у них нет. Все что они делают — это лишь попытка хоть что нибудь противопоставить. Но видимо в последнее время силенок то стало не хватать — вот тебе и пожалуйста интеграция с .NET. А то обычно бы они начали делать свой .COM, .WEB, что нибудь еще.
ЗДря Вы так Борланд не любите.
Он один реально продвинул платформу Java в корпоративный сектор (в J2EE по большей части его идеи воплощены). JBuilder — лучшая среда для разработки корпоративного софта на Java. Кстати, основные доходы (более 60%) — рынок Java-решений, а отнюдь не Win. J2EE-сервер BES — лучший в своём классе (масштабируемость, кластеризуемость, многоплатформенность).
Delphi — это так, пустяк, чтобы быть откусить мааленький кусочек ОГРОМНОГО пирога Win-решений.
Просто некоторые хотят играть на нескольких досках сразу, чтобы не проиграть за раз.
Здравствуйте, Nick Notabene, Вы писали:
NN>Ты знаешь, нет,не думал. Что касается скорости и удобства разработки интерфейса, .Net далеко до С++ Бильдера или Дельфей, с которого он собственно и слизан . Если в бильдере делать статические экзешники, без VCL, то они получаются здоровые, но все-таки не 10 метров. NN>Да и вообще у меня под VC6 уже скопился удобный набор open-source библиотек,интерфейс получается не хуже, а немного кода ручками мне сильно не мешает Большая часть времени уходит не на разработку мордочек, а на обработку данных, а визуализация у меня преимущественно своя — 1) кривые 2)карты-поверхности 3)таблицы просмотра больших массивов данных ( по 2-5 Мб на столбец таблицы). Стандартных компонент, которые работали бы с приемлимой скоростью и делали то что надо, я не видел
NN>Другое дело, что масштабиремость и переносимость, но тут тоже анекдот — "Ваша программа будет работать везде... где установлен Windows..." — так она и так работает... NN>В общем дело ясное что дело темное. NN>Что будет дальше, я не знаю, но пока из всего вышепрописанного могу сделать вывод:
NN> ЕСЛИ НАДО СДЕЛАТЬ ЧТО-ТО ОТЛИЧНОЕ ОТ ТЕКСТОВОГО РЕДАКТОРА ИЛИ ПРОГРАММЫ СОСТАВЛЕНИЯ АНКЕТ, .Net НИЗАЧЕМ НЕ НУЖЕН
Вы знаете, уважаемый, вы исходите из логики "если мне сейчас хорошо, то мне будет хорошо всегда". Либы для плюсов у вас есть гуйные? А то, что в дотнете как раз именно ручками этот самый гуй разрабатывать в разы проще вы не задумывались? А этот спор — что откуда слизано? Ясное дело, если человеку нравится дельфи (как например, mihailik), то он будет всячески отпираться от того, что этот самый дельфи слизан с VB.
Хотя VB был первой визуальной средой разработки, а визуальность — не последнее "ключевое" слово в дельфи. А если человек любит VB, так для него, извините, и весь дотнет с него слизан (в чем, кстати сказать, есть малая толика правды).
Значит, теперь к вопросу, откуда слизан дотнет. Что там? Жаба, дельфи, билдер, васька...? Мне вот лично вообще пофигу откуда он слизан. Какая собственно разница? В виде дотнета я получаю хорошую визуальную среду разработку, обладающую огромной гибкостью благодаря сериализации в код, удобство до-диеза и прежнюю старую добрую мощность плюсов — все это сгодится не только для того, чтобы писать текстовые редакторы или программы составления анкет. И, кстати, народ в дотнете уже вовсю пишет. Так что не надо здесь прописными буквами прописные истины писать. Если вы сами в дотнете ничего другого сделать не можете, то это уж, извините, ваша проблема.
Здравствуйте, Aquila, Вы писали:
ВВ>И, кстати, народ в дотнете уже вовсю пишет.
A>И чего он написал, если не секрет?
Можешь такую тему открыть. Ответов думаю будет немало. Лично я почти завершил программу для разработки электронной учебной литературы. Причем существенную часть гуя дел сам.
Здравствуйте, Aquila, Вы писали:
A>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>И, кстати, народ в дотнете уже вовсю пишет.
A>И чего он написал, если не секрет?
Здравствуйте, WFrag, Вы писали:
A>>И чего он написал, если не секрет? WF>Ну для затравки — RSDN, RSDN@Home.
Это я видел уже. Ещё DeltaForth знаю . А ещё?
Здравствуйте, Nick Notabene, Вы писали:
NN>А вот быстродействие важно, даже критично.
В быстродействии работы с БД можно существенно выиграть. Особенно если в качестве БД используется mssql. С точки зрения скорости исполнения, то скорее несколько проиграешь. Хотя в первую очередь все зависит от выбранных алгоритмов.
Вот в чем ты вииграешь 100%-но — это в скорости разработки.
По скорости на этом сайте есть несколько статей. Шустрики и сравннение средств доступа к данным. Посмотри.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mihailik, Вы писали:
M>21 апреля: NN>А вот быстродействие важно, даже критично.
M>24 июня: VD>В быстродействии работы с БД можно существенно выиграть.
M>
Пересмеялся что ли?
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
M>21 апреля: NN>А вот быстродействие важно, даже критично.
M>24 июня: VD>В быстродействии работы с БД можно существенно выиграть.
M>
VD>Пересмеялся что ли?
В контектсе быстродействия умилила скорость отклика
Здравствуйте, Igor Trofimov, Вы писали:
J>>Кто сказал что Delphi ускаряет ? Это ФИГция! Примитивный UI в шесть кликов + DB app в четыре, это же не показатель быстрой разработки.
iT>Это точно.
J>>Помнится месяца работы над небольшой desctop системкой (когда уже сдавали release), при закрытии начал нерегуляно появлятся "access violation" и фиг что с ним сделали, так и не победили сколько не бились
iT>Нда... всего за месяц написать прогу, где не можете исправить AV... Талант. iT>И при чем тут Delphi?
По-моему товарищ прав — Borland и отладка — вещи несовместимые, хотя бы потому, что чтоб это дело по-человечески отлаживать нужны исходники, а Borland по ним лазить при отладке вещь неблагодарная, в VC же это сделано весьма органично (неважно в каком), — влез, глянул, глянул пораметры, глянул коментарии, глянул что там отладочные макросы проверяют и как, и вообщем многое проясняеться...
Знаете, господа, по-моему спор не о чем — все рассматриваемые среды различны по своему назначению и обсуждать чем одна лучше другой не учитывая круг задач бессмысленно. Любая задача может быть решена на любом языке программирования, вопрос в затраченных усилиях (тезис Черча, курс дискретной математики института ). Насколько мне видно положение такого: VB — среда для создание оффисных и прикладных приложений, оринетированная на специалистов средней квалификации (без обид ) — в каждой "лавочке" сидит свой программист и что-то для нее ваяет.... VC++ — высокопрофессиональная среда для разработки сложных, ресурсоемких продуктов (системные, прикладные, научные, аналитические задачи), использующая все преимущества С++ — скорость, гибкость и т.д.; отсюда навороченность среды, огромное кол-во библиотек, эффективный компилятор и проч...... Borland — Delphi, среда, ориентированная прежде всего на работу с БД и сопуствующие задачи (как то графический интерфейс пользователя), в чем привосходит Microsoft (объективный факт — системы на Delphi более устойчивы, например возможна ситуация 1000 конектов, Microsoft на 300 падал...), Builder же прямой клон Delphi, ориентированный на программистов С++. По моему дела обстоят так, если нет поправте.... Что до нет, то это просто концепция и большой набор библиотек (за что большое спасибо). По-моему VC# и VC++ — предназначены для разных задач...
K>По-моему товарищ прав — Borland и отладка — вещи несовместимые, хотя бы потому, что чтоб это дело по-человечески отлаживать нужны исходники,
То-то сырцы FCL Microsoft не предоставляет
K> а Borland по ним лазить при отладке вещь неблагодарная,
обоснуй
K> в VC же это сделано весьма органично (неважно в каком), — влез, глянул, глянул пораметры, глянул коментарии, глянул что там отладочные макросы проверяют и как, и вообщем многое проясняеться...
нда.. несомненно, именно это, а не кривые руки, позволяет людям писать кривые проги )
Здравствуйте, Igor Trofimov, Вы писали:
iT>Я в курсе. Но человек хотел — чтобы прям из IDE, в процессе отладки...
И это тоже народ делает. Я тут как-то видел плагин к чему-то который позволял прикрутить Reflector к VS.NET и видеть код процедуры выделенной в колстеке.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Nick Notabene, Вы писали:
NN>Привет всем ! NN>Вопрос скорее философский. Задача — обработка данных, много графики, передача данных через по сети нужна, но не критична, базы данных используються, но обработку данных я делаю сам (выводить таблицу опорных точек как-то незачем), засим грид мне сильно не нужен. NN>А вот быстродействие важно, даже критично. NN>Имеет ли мне смысл переезжать на .Net и C# или нет? Сейчас большая чать проекта сделана на VC6 + Intel C++ 5.0,дополнительные модули на BCB 5... NN>Буду благодарен многоуважаемому All за любые идеи по этому поводу.
Может не в тему, но когда эта тема начиналась я сам с недоверием посматривал в сторону НЕТ, теперь я уже на нём пишу а тема всё живёт
? Это ФИГция! Примитивный UI в шесть кликов + DB app в четыре, это же не показатель быстрой разработки. Помнится месяца работы над небольшой desctop системкой (когда уже сдавали release), при закрытии начал нерегуляно появлятся "access violation" и фиг что с ним сделали, так и не победили сколько не бились, т.к. обработка ошибок во всем VCL — детский лепет... 
, а у нас — О-О-О билдер, О-О-О дельфи... Что же пользуйте, деньги и ассинезаторам платят...
.
.
.jpg)
. Есть вещи, после переписывания которых без GC поменяются (причем скорее всего) принципы их работы и структура.
)
