Здравствуйте, 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 НИЗАЧЕМ НЕ НУЖЕН

Точно! Ну еще для Web он еще куда ни шло.

Здравствуйте, 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-вцев.

Здравствуйте, 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>Тоже очень большой вопрос. Так ты используешь голый натив код, а так у тебя добавляется немерянный рантайм.

Так я использую прямой дуступ к мамяи и вынужден конролировать все вручную. А так я испоьзую безопасные алгоритмы и готовые библиотеки.

Можно так же , на мой взгляд спросить , зачем в NET , навороченный сборщик мусора ? ? ? Много аргументов программисты не освобождают ресурсы , и он сам их освобождает и прочее , но на мой взгляд это проблемма программистов . Излишняя забота может вылится в большое безразличие . Плюс ко всему хоть и ресурсы машин выросли ощютимо за последние несколько лет , но представлять все через объекты , расточительно на мой взгляд , поэтому хоть и пытаюсь писать на С# , более склонен к С++ . По крайней мере при разработке С++ учитывали то что большинство написано на С , C# — учитыет это ? ? ? Забили М$ на всех . Я не говорю о том что они лохи и несмогли реализовать это . JIT компиляция , решение проблем маршалинга нравится в общем может что то и пропустил но не об этом разговор , но более особо ничего . И если взглянуть со стороны , как и MFC только намного...намного продвинутей. Теже яйца только в профиль .

Здравствуйте, Slavva, Вы писали:

S>Можно так же , на мой взгляд спросить , зачем в NET , навороченный сборщик мусора ? ? ? Много аргументов программисты не освобождают ресурсы , и он сам их освобождает и прочее , но на мой взгляд это проблемма программистов . Излишняя забота может вылится в большое безразличие .

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

А падение производительности на нем во многих случаях несущественно.

Здравствуйте, WFrag, Вы писали:

WF>Сборщик мусора не только освобождает за тебя память. Он также позволяет взглянуть на ООП с несколько другой стороны. Сильно упрощает проектирование некоторых вещей, что дает возможность увеличения сложности программ с уменьшением потраченных на нее ресурсов.

WF>А падение производительности на нем во многих случаях несущественно.

И с какой же стороны сборщик мусора в ООП смотрит ??? Каких вещей он упрощает проектирование ??? Если не следование правилу взял отдай рассматривать как проектирование , то да упрощает. Но это немного не проектирование . Увеличить сложность , действильно как существовали сложные системы без сборщика мусора представить просто невозможно , может их писали "аккуратно" . Или ты об этом не задумывался ???

Здравствуйте, Slavva, Вы писали:

Основная цель сборщика мусора — предотвращение фрагментации памяти в программах, работающих очень долго (например, Web-серверах и т.п.)

Здравствуйте, Slavva, Вы писали:

WF>>Сборщик мусора не только освобождает за тебя память. Он также позволяет взглянуть на ООП с несколько другой стороны. Сильно упрощает проектирование некоторых вещей, что дает возможность увеличения сложности программ с уменьшением потраченных на нее ресурсов.

WF>>А падение производительности на нем во многих случаях несущественно.

S>И с какой же стороны сборщик мусора в ООП смотрит ??? Каких вещей он упрощает проектирование ??? Если не следование правилу взял отдай рассматривать как проектирование , то да упрощает. Но это немного не проектирование . Увеличить сложность , действильно как существовали сложные системы без сборщика мусора представить просто невозможно , может их писали "аккуратно" . Или ты об этом не задумывался ???

Я не говорил, что без GC нельзя написать сложную и надежную систему. Утверждение было: дает возможность увеличения сложности программ с уменьшением потраченных на нее ресурсов.

Пример: Переписал я один свой проект с C++, и как говорится, почувствовал разницу. Усилий на написание/отладку потратил значительно меньше (на технические части, алгоритмические части обдумывать, конечно, уже не пришлось). И значительная заслуга этого именно GC.

Кстати, вариант на C++ имеет только одно преимущество — он потребляет меньше памяти. Но это просто свойство систем с GC — они более прожорливые.

В C++, например, ООП получается (у меня, может у других как-то иначе?) либо очень линейным (владелец объекта строго определен), либо приходится извращаться с всякими умными указателями и подсчетом ссылок (опять же вспоминаем про циклические графы, которые могут случайно получиться ). Я уже где-то тут рассуждал на эту тему, вот пример: Swing из Java. Мое утверждение: написать такую библиотеку без сборщика мусора просто невозможно, поскольку там ссылки на объекты довольно свободно передаются, и владельца объекта определить зачастую довольно проблематично.

Я начал чувствовать сильную разницу между ООП без GC и ООП с GC, когда плотно познакомился с Java. Объяснить словами более понятно разницу, наверное, не смогу , это надо просто пробовать.

А насчет аккуратно, GC, и.т.д, посмотри флейм http://www.rsdn.ru/forum/Message.aspx?mid=237487&only=1

Автор:
Дата: 09.04.03

Здравствуйте, Slavva, Вы писали:

S>И с какой же стороны сборщик мусора в ООП смотрит ??? Каких вещей он упрощает проектирование ??? Если не следование правилу взял отдай рассматривать как проектирование , то да упрощает.

Возьми шире — подумай об управлением временем жизни объектов вобще.

Здравствуйте, al, Вы писали:

al>Основная цель сборщика мусора — предотвращение фрагментации памяти в программах, работающих очень долго (например, Web-серверах и т.п.)

Основная цель сборщика мусора, как это не удивительно, собирать мусор.

Здравствуйте, AndrewVK, Вы писали:

AVK>Основная цель сборщика мусора, как это не удивительно, собирать мусор.

А также следить за состоянием памяти и предотвращать ее фрагментацию

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Slavva, Вы писали:

S>>И с какой же стороны сборщик мусора в ООП смотрит ??? Каких вещей он упрощает проектирование ??? Если не следование правилу взял отдай рассматривать как проектирование , то да упрощает.

AVK>Возьми шире — подумай об управлением временем жизни объектов вобще.

Подумал , больше чем необходимо они жить не должны (или ОС знает скольно нужно жить объекту ??? Так может она и проги сама писать будет ??? ), процесс все равно на мой взгляд должен контролироваться программистом . Я читал про сборщик мусора и его механизм действия , в целом я склонен к его необходимости, но не везде. Имею ввиду то что нет средств управлять этим процессом , скажем так как С++ new выделит delete освободит (Насильно вызвать можно , но это немного не то).