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

SDB>Гх-м-м... а Янус? Вполне себе работающий (и полезный) проект. Это я не "подлизываюсь", просто ближе всего к сердцу. Да и другие тулзы есть, у нас в "Средствах..." недавно ссылка проскакивала, я скачал парочку — очень даже ничего.

А я сталкивался уже с десятком проектов на .Net, из которых нормально работали два. Остальные просто кошмарны. Причем часть из них принудительно навязываются — например, "Анкета ФКЦБ" — просто чудо. Если бы эти проекты писались на C++, они не увидели бы свет — их создатели умерли бы на отловке эксцепшенов. А так криво, но работает. По-моему, это плохая тенденция. Я неправ ?

Я понимаю, что это цена прогресса — надо заставлять людей покупать новое железо и новый софт для решения все тех же задач. Это экстенсивное развитие, которое обычно приводит к тупику. После чего начинается развитие интенсивное. Пока ресурсы есть. Рано или поздно они кончатся. История развивается по спирали — думаю, лет через 15 тема оптимального программирования снова станет актуальной.

SDB>Блин! Так мой пост и был посвящен ответу на этот вопрос... и сводился он к тому, что я (пока!) не пишу на .NET, не потому что считаю его плохим, а потому что (пока!) у моих заказчиков не хватает "производственных мощностей", а у меня хватает средств удоветворить их (заказчиков) при помощи MFC.

Так а кто спорит ? Про это здесь речь и идет. Разумная рациональность при высокой производительности и приемлимой скорости разработки. Только это немодно.

NN>>>>И вот идет человек на форум, да пишет, почему ему удобно работать на том, на чем он работает... и получает в ответ пачку флейма.

SDB>Ну, я бы не был так резок. Пока что почти все, что я прочел в ответ, было для меня очень интересно... даже Влад на удивление мягок. Пока...

Пачку интересного флейма. Но это конференция такая.

SDB>дебУрг!!
Сорри

SDB>Nick, у меня есть убедительная просьба — давайте не будем "пихаться копчиками" с .NET-чиками, поклонниками WTL, etc. У каждого из нас своя ниша, сезонно мы мигрируем... (сезонность определяет MS — и я рад, что ее кто-то определяет). Я написал про "здесь и сейчас", которое "завтра" изменится, это был просто срез по настоящему (для меня)

Дык об чем речь. Есть проекты, которые удобнее решать на WTL. Вообще хорошо любое средство разработки, которое позволяет решить задачу в поставленные сроки и в заданном объеме. Чем больше платформ и идеологий разработки тебе доступны, тем легче тебе работать.

Меня просто раздражает очень навязчивая реклама, которая позиционирует .Net как универсальное и оптимальное средство для решения любых задач. Это не так. Это в общем-то обман, за который иногда приходитя отвечать разработчику. Вот и все %-)

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

NN>По-моему, это плохая тенденция. Я неправ ?

Неправ. Ты увидил предпослыки и не смог их правильно интерпретировать.

Мужики писавшие софт что ты называшь кривым, просто били или недостаточно опытными, или видили средство разработки на котором работали первый день. И даже в таких условиях дотнет снял с них чать работы и они смогли сделать продукт. Точно так же для высоко квалифицированного программиста он снимет часть работы и программист сможет сделать бьльше чем раньше, или столько же, но значительно быстрее.

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

VD>Неправ. Ты увидил предпослыки и не смог их правильно интерпретировать.
VD>Мужики писавшие софт что ты называшь кривым, просто били или недостаточно опытными, или видили средство разработки на котором работали первый день. И даже в таких условиях дотнет снял с них чать работы и они смогли сделать продукт. Точно так же для высоко квалифицированного программиста он снимет часть работы и программист сможет сделать бьльше чем раньше, или столько же, но значительно быстрее.

Влад, так это хорошо ? То есть ты считаешь, что разработчики, сделавшие проект как попало за счет того, что платформа скрыла большую часть их ошибок — это нормально ???? Ничо себе вывод.
А я -то сижу время трачу на анализ и проектирование. Как я отстал от жизни. Надо наслаждаться ее RADостями, а юзер потом привыкнет.

Что касается опыта конкретно этих ребят — они уже третий вариант лепят, такой же кривой, как два предыдущих. И кстати, официально не использовать его нельзя. Неофициально у нас работает мой вариант, сделанный под MFC, и дающий на выходе такие-же файлы. Влад, сделать аналог этой программы отняло у меня десять дней, из них 4 — на то, чтобы разобраться, что должно быть на входе и на выходе. Работает везде, и 20 Мб фреймворка + 10Мб сервис-пака не требует. Какие из этого следуют выводы ?

Что касается этого разрекламированного "значительно быстрее" я тоже не согласен. Значительный прирост скорости разработки от использования .Net появляется тогда, когда на 95% ты используешь библиотеки платформы для решения стандартных задач. Это не отнять. Совершенно такой же эффект от применения Бильдера/Дельфей — если есть подходящие тебе компоненты, время разработки минимально.
Но как показывает опыт, по достижению определенного запаса готовых библиотек и уровня разработки, большая часть времени уходит на создание уникальной функциональности, ради которой проект и затевается. И тут уж извини, от платформы мало что зависит. Нету тут "драматического увеличения скорости разработки". Попробуй сделай программу по отрисовке изолиний, например — не совсем тривиальная задача, хотя ничего эксклюзивного в ней тоже нет. Время разработки под .Net и под MFC с профусом будет одинково.

Последний раз повторяюсь — я не говорю, что .Net не имеет будущего, или что это плохая платформа, упаси Святой Билл. Это нормальное средство разработки, не хуже и не лучше Java или Delphi-подобных RADов, ( что не странно, учитывая спернуто-гибридную суть .Net ). Все, что я хочу сказать — не стоит слишком доверять рекламе, и стоит иногда помнить, что у компьютера есть ресурсы, и они конечны. И исходя из этого и задачи, выбирать платформу разработки.

Хороший флейм получился. Качественный.

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

NN>Влад, так это хорошо ?

А что, плохо?

NN> То есть ты считаешь, что разработчики, сделавшие проект как попало за счет того, что платформа скрыла большую часть их ошибок

Она их не скрыла, она не дала их совершить. Чувствуешь разницу?

NN>- это нормально ???? Ничо себе вывод.

Нормальный вывод. Вам шашечки или ехать? Тут ведь альтернатива простая — либо глючный, но работающий софт на дотнете, либо вобще никакого софта и все руками. Ну а то что некоторые госконторы имеют наглость навязывать кривой софт собственной кухни так это проблема совсем не программирования.

NN>А я -то сижу время трачу на анализ и проектирование. Как я отстал от жизни. Надо наслаждаться ее RADостями, а юзер потом привыкнет.

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

NN>Что касается опыта конкретно этих ребят — они уже третий вариант лепят, такой же кривой, как два предыдущих. И кстати, официально не использовать его нельзя.

А виноват во всем этом дотнет .

NN> Неофициально у нас работает мой вариант, сделанный под MFC, и дающий на выходе такие-же файлы. Влад, сделать аналог этой программы отняло у меня десять дней, из них 4 — на то, чтобы разобраться, что должно быть на входе и на выходе. Работает везде, и 20 Мб фреймворка + 10Мб сервис-пака не требует. Какие из этого следуют выводы ?

А какие ты делаешь? Я например сделал такой — надо законодательно запретить навязывать министерствам софт и обязать их выпускать полное описание используемых форматов. И критерием правильности данных должно служить это описание, а не ихняя заглатывалка.

NN>Что касается этого разрекламированного "значительно быстрее" я тоже не согласен.

Есть опыт разработки аналогичных проектов на дотнете и классической платформе?

NN> Значительный прирост скорости разработки от использования .Net появляется тогда, когда на 95% ты используешь библиотеки платформы для решения стандартных задач. Это не отнять. Совершенно такой же эффект от применения Бильдера/Дельфей — если есть подходящие тебе компоненты, время разработки минимально.

Это все в теории. А на практике большинство сторонних компонент для Дельфи применять невозможно — неконтроллируемый код, способный испортить твой собственный это страшно.

NN>Но как показывает опыт, по достижению определенного запаса готовых библиотек и уровня разработки, большая часть времени уходит на создание уникальной функциональности, ради которой проект и затевается. И тут уж извини, от платформы мало что зависит.

При классическом подходе (Дельфи, С++ без шаблонов) это примерно так. Но вот как только мы начинаем использовать сложные структурные решения, то сразу всплывают паттерны. И вот тут все становится не так просто — С++ к примеру, за счет шаблонов и техник а-ля Александреску позволяет создавать библиотеки паттернов, в C# и Java много частоупотребимых паттернов встроено в язык. А вот классический подход остается по эффективности далеко позади, поскольку каждый раз приходится изобретать велосипед, т.е. опять и опять реализовывать паттерн.
Например — если мне нужно создать ленивый потокобезопасный синглтон, то на шарпе я не задумываясь напишу статическое поле с инициализацией, на С++ один раз напишу шаблон. А на Дельфи? Не хочешь привести минимальный код?

NN> Нету тут "драматического увеличения скорости разработки".

Не могу с тобой согласится, поскольку мой опыт свидетельствует об обратном. Что такое янус представляешь? Так вот — до него у меня был опыт реализации схожих систем, может чуть попроще. Один раз на Дельфи, другой раз на C#. На Дельфи проект занял 8 месяцев, на шарпе 3.

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

NN>Влад, так это хорошо?

Да.

NN> То есть ты считаешь, что разработчики, сделавшие проект как попало за счет того, что платформа скрыла большую часть их ошибок — это нормально ????

Неверная интерпретация. У каждого есть свой потолок. Будь ты трижды гением не всегда найдется задача ктороая тебе не подсилу. Например, почти любой дебил на любом средстве напишет Хэлоу Волд. Но создать качественную ОС подсилу очень не многим.

В общем, можно говорить об некой общей (кумулятивной) производительности. Она склаывается из возможностей программиста и уровня системы разработки.

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

Так вот, проблема в том, что как только программист становится чуть-чуть опытнее он сразу заявляет, что средство тут не причем, и что все дело в людях. Это ошибка. Дело и в том, и в другом. Квалифицированный программист тоже выигрывает используя более высокоуровневое средство.

Как я отстал от жизни. Надо наслаждаться ее RADостями, а юзер потом привыкнет.

Я невидил ни одного программиста который бы сказал, что недостаточно опытен и т.п. По крайней мере на формумах все круты как вореные яйца. Но вот гляжу на сойт и понимаю, что все это бравада.

NN>Что касается опыта конкретно этих ребят — они уже третий вариант лепят, такой же кривой, как два предыдущих. И кстати, официально не использовать его нельзя. Неофициально у нас работает мой вариант, сделанный под MFC, и дающий на выходе такие-же файлы. Влад, сделать аналог этой программы отняло у меня десять дней, из них 4 — на то, чтобы разобраться, что должно быть на входе и на выходе. Работает везде, и 20 Мб фреймворка + 10Мб сервис-пака не требует. Какие из этого следуют выводы?

Что твоей уровень был несколько выше чем у них. И что если бы ты освоил фрэймворк, то смог бы решить задачу за 4 дня.

NN>Что касается этого разрекламированного "значительно быстрее" я тоже не согласен.

И зря. Переоценка своих сил никогда до бобра не доводила.


NN> Значительный прирост скорости разработки от использования .Net появляется тогда, когда на 95% ты используешь библиотеки платформы для решения стандартных задач.

Библиотеки это несмоненно одно из слагаемых успеха. Но далеко не самое важное, и точно не единственное. Применение дотнета дает и ряд других приемуществ.

NN>Но как показывает опыт, по достижению определенного запаса готовых библиотек и уровня разработки, большая часть времени уходит на создание уникальной функциональности, ради которой проект и затевается. И тут уж извини, от платформы мало что зависит.

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

NN>Хороший флейм получился. Качественный.

Фирма веников не фажет.

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

CS>>>Как только чуть чуть сложнее ирерхия окон — все — абздольц — HWND только мешают.

SDB>>Смелое заявление.

AVK>Да нет, все правильно — хендлы и сообщения по современным меркам очень неудобны. Вот только позиционировать им на замену убогий HTML — из огня да в полымя.

Это по всей видимости неудачный опыт с IE сказывается.

тут есть принципиальная разница. В IE например размер абсолютно позиционированног блока <DIV> с текстом внутри (т.е. + неявный TextNode) по косвенным оценкам примерно 5 kb.
Плюс на это дело накладывается COM интерфейсы через которые script до DOMа достукивается.

Что понятное дело для целей динамического насыщенного UI неприемлемо.

У меня размеры получаются на порядки меньше. Плюс каждый Node у меня native script object. Т.е. цена
вызова например element.nextSibling в принципе не намного выше чем из hsmile C++ DOM interface.

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

_FR>>Из моего скромного опыта — "шаг вправо-шаг влево — расстрел", то есть очень жёстко заточена на то, что при её использовании должно получаться и как это должно работать. Можно и к плюсам отнести, но до тех пор, пока не потребуется чего-то "этакого".
SDB>Формально я с Вами полностью согласен, но фактически — "общественность" уже придумала тысячу и один способ смягчать жесткость MFC-шной архитектуры. Тем не менее, я отношу эту жесткость к одним из самых существенных недостатков данной библиотеки.

Так это уже не МФЦ получается, а МФС & Co — это оттуда, это отсюда... венегред.

_FR>>необходимо лезть глубоко в потроха самой библиотеки, смотреть что и как она делает
SDB>А это ИМХО всегда полезно — в "потрохах" поковыряться. Знай и люби свой город, так сказать.
Всё-таки согласен. Это даже приятнее чем рефлектором вскрывать

_FR>>Это не то, что с пионерскими галочками и крестиками у кнопок ОК и Отмена?
SDB>Э-э-э... "это такой белый прикол, в который черные не въезжают?.." (с) "Карты, деньги, два ствола"


_FR>>Боюсь показаться грубым, но есть ли уверенность, что МФЦ и дальше будет развиваться, стремиться быть ближе к своим поклонникам, а не застынет в ближайшем будущем?
SDB>Есть. Лет несколько еще точно — слишком много серьезных продуктов написано с ее участием, и энное их количество продолжает создаваться "даже" сейчас. Развитие это будет, в основном эво- , а не рево- люционным... фиксы багов, предоставление доступа к фичам новых версий винды. По моим предположениям MFC сойдет со сцены года через 3-5, уступив место WinFroms'ам и перейдя в категорию legacy code.
Угу.

_FR>>Тогда уж либо другой предмет поклонения искать (а годы идут...) или переходить в отношения платонические...
SDB>Я не поклоняюсь ни одной технологии — они приходят и уходят, а мы остаемся...
Этому предшествовало признание в любви, которое я и приравнял к поклонению. Извиняюсь

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

VD>Я не видел ни одного программиста, который бы сказал, что недостаточно опытен и т.п.

Показываю, Влад — вот он:

Я искренне и без кокетства могу сказать, что не считаю свой опыт в какой-либо из областей программерской деятельности, к которым я прикладывал голову и пальцы, "достаточным". Потому что каждый раз я нахожу все более оптимальные и красивые способы решения "одних и тех же" задач... и каждый раз задаюсь вопросом — интересно, что же я упустил на этот раз? какой будет следующая ступень этой лесницы? Более того — если я поймаю себя хотя бы на тени мысли о том, что "достаточно опытен", то немедленно уйду из программирования, поскольку это будет означать мою смерть как профессионала. Я не вижу способа двигаться вперед без осознания собственного несовершенства.

P.S.
Наверно, получилось слишком лирично и пафосно...

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

_FR>Так это уже не МФЦ получается, а МФС & Co — это оттуда, это отсюда... венегред.

Не соглашусь. Грамотно написанные "компоненты", расширяющие и углубляющие базовую библиотеку, обогощают наши с вами возможности ее (библиотеки) использования.

_FR>Этому предшествовало признание в любви, которое я и приравнял к поклонению. Извиняюсь

Принимаю.

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

AVK>Нормальный вывод. Вам шашечки или ехать? Тут ведь альтернатива простая — либо глючный, но работающий софт на дотнете, либо вобще никакого софта и все руками.

Хм... Нечто похожее говорит Дик Столман:

Я скоре бы выбрал едва работающую, неэффективную, ненадежную, но бесплатную программу, чем удобную и надежную, но проприетарную программу, которая не уважает мою свободу.

А как насчет глючной, неэффективной и едва работающей проприетарной программы?

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

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

_FR>>Так это уже не МФЦ получается, а МФС & Co — это оттуда, это отсюда... венегред.

SDB>Не соглашусь. Грамотно написанные "компоненты", расширяющие и углубляющие базовую библиотеку, обогощают наши с вами возможности ее (библиотеки) использования.

Ну не мечта ли — иметь систему, целиком построенную на "грамотно написанных компонентах,расширяющих, обогощающих, ..."
Только БЦГ под это определение подвести могу, зато да, библиотека Но вот ведь — и в ней тот же недостаток МФЦ — жёсткость каркаса
Остальное — гибкое, не монстроподобное — не всегда один-в-один возмёшь к себе и прикрутишь — от чего-то наследоваться придётся, что-то править. Но всё это слишком не конкретно, потому — непродуктивно. Попробую с другой стороны. Немного ранее было:
SDB>"общественность" уже придумала тысячу и один способ смягчать жесткость MFC-шной архитектуры.
Вот. Способы разнородные, придуманные не одним человеком с размыми взглядами на "что такое "хорошо". В итоге изучаешь проект, в котором хоть десяток сторонних (не МС и не своих) компонентов, с разной архитектурой доступа, с разными соглашениями по именованию классов... Тихо ругаешься
В то же время существуют библиотеки гораздо более "развесистые" и которые не так часто требуется исправлять

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

SDB>Наверно, получилось слишком лирично и пафосно...

Да, уж. Но если в этих словах есть хотя бы 10% правды, то они уже достойны уважения.

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

AVK>>Да нет, все правильно — хендлы и сообщения по современным меркам очень неудобны. Вот только позиционировать им на замену убогий HTML — из огня да в полымя.

CS>Это по всей видимости неудачный опыт с IE сказывается.

CS>тут есть принципиальная разница. В IE например размер абсолютно позиционированног блока <DIV> с текстом внутри (т.е. + неявный TextNode) по косвенным оценкам примерно 5 kb.
CS>Плюс на это дело накладывается COM интерфейсы через которые script до DOMа достукивается.
CS>Что понятное дело для целей динамического насыщенного UI неприемлемо.

Это все мелочи. Взгляни немножко пошире. Я могу создать собственный элемент управления? Я могу ввести собственный DSL внутрь? Я могу использовать нормальный язык, а не убогий JScript? Могу декларативно задавать триггеры, аниматоры, хитрые закраски? Так можно еще долго перечислять. Я ведь не зря тебе говорил ознакомится поподробнее с тем что такое XAML. А размеры DIV блока? Мне лично пофигу.

CS>У меня размеры получаются на порядки меньше. Плюс каждый Node у меня native script object. Т.е. цена
CS>вызова например element.nextSibling в принципе не намного выше чем из hsmile C++ DOM interface.

Цена вызова это далеко не главная проблема современных интерфейсов.

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

AVK>>Нормальный вывод. Вам шашечки или ехать? Тут ведь альтернатива простая — либо глючный, но работающий софт на дотнете, либо вобще никакого софта и все руками.

MS>Хм... Нечто похожее говорит Дик Столман:
MS>

MS>Я скоре бы выбрал едва работающую, неэффективную, ненадежную, но бесплатную программу, чем удобную и надежную, но проприетарную программу, которая не уважает мою свободу.

Он говорит прямо противоположное.

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

SDB>Данная ветка затеята исключительно с целью спокойно и конструктивно обсудить с коллегами причины выбора той или иной технологии, так что любителей "пихаться копчиками" и воевать я бы очень просил сюда не поститься.

SDB>"Есть, чем платить, но я не хочу
SDB>Победы любой ценой.
SDB>Я никому
SDB>Не хочу ставить ногу на грудь..."
SDB>(с) Цоюшка

SDB>"Патриотизм — религия бешеных..." (с) Вальтер Скотт

SDB>

Очень правильный и пост, и брат
Мой выбор MFC, правда очень #import мне нравиться
До базы легко достучаться. А если добавить ATL, то вообще
Моя прога писанная на MFC(VC++ 6) + #import + MS Access(97) пахала на 486-66/RAM 32Mb,
причем не сильно тормозила

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

CS>У меня размеры получаются на порядки меньше. Плюс каждый Node у меня native script object. Т.е. цена
CS>вызова например element.nextSibling в принципе не намного выше чем из hsmile C++ DOM interface.

Отстал ты от жизни. Сейчас модно объектную модель не эмулировать и выставлять скриптам, а строить на базе управляемых сред. И цена вызова становится такой же как у любого другого метода в С++-программе, и скрипты не нунжы вовсе, так как есть полноценные языки с теми же свойствами.

Здравствуйте, SchweinDeBurg!

Везёт Вам
А у нас в конторе, к сожалению, используется перебранная ручками WTL, ATL и даже STL.
И когда-то давно была подправленная MFC. Было это в 1998 году. Тогда MFC была ещё подростком, с кучей подростковых болячек. И править их порой было так тоскливо...
Так что когда я весной 1999 года обнаружил в одном из примеров от ATL atlctrls.h, я сразу забил и забыл про MFC.
А что касается того, что у MFC все шикарно с базами данных, то позвольте спросить, Вы хоть раз заглядывали в daocore.cpp? И как Вам? И что из этого Вы не смогли бы написать самостоятельно?
Что касается меня, то я вполне способен использовать DAO на такой лад:

    ATL::CComPtr<_DAODBEngine>        pDAODBEngine;
    ATL::CComPtr<DAODatabase>        pDAODatabase;
    ATL::CComPtr<DAOWorkspaces>        pDAOWorkspaces;
    ATL::CComPtr<DAOWorkspace>        pDAOWorkspace;
    HRESULT                    hr;

    hr = pDAODBEngine.CoCreateInstance(CLSID_CDAODBEngine);
    ATLASSERT(SUCCEEDED(hr));

    if (SUCCEEDED(hr))
    {
        // Get default workspace from the workspaces collection
        hr = pDAODBEngine->get_Workspaces(&pDAOWorkspaces);
        if (SUCCEEDED(hr))
        {
            ATL::CComVariant    varIndex(0, VT_I4);
            hr = pDAOWorkspaces->get_Item(varIndex, &pDAOWorkspace);
        }
    }

// И понеслась...

Зачем мне эти странные MFC-шные обертки?
Вобщем, у меня за годы жизни сложилось обратное впечатление: MFC это библиотека для сборки WordPad'а и именно WordPad'а. Любая попытка выйти за рамки реализации -- тяжкая борьба с особенностями MFC.

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

БП>А что касается того, что у MFC все шикарно с базами данных, то позвольте спросить, Вы хоть раз заглядывали в daocore.cpp?

Во-первых, "шикарности" я не утверждал. Во-вторых — DAO не использую, предпочитаю ODBC (для которого в MFC сделаны ИМХО вполне удобные обертки типа CDatabase/CRecordset) или нативные интерфейсы (например, OCI).

БП>И как Вам? И что из этого Вы не смогли бы написать самостоятельно?

Это, Павел, тонкий вопрос. Можно и CRT самостоятельно написать, и контейнеры свои на шаблонах, и библиотеку классов, которая будет виндовый GUI инкапсулировать. Но в 99% случаев у меня не окажется на это времени. Хотя червячок оппортунизма "а ведь я могу это написать сам и написать красивее" будет неутомимо ползать по моим извилинам, "отравляя" их мыслями об "идеальной библиотеке". Может быть, причина моей нынешней терпимости к (ни в коем случае не отрицаемым мной) недостаткам, странностям, жесткости MFC заключается в том, что в свое время я вволю наизобретался собственных велосипедов и напереписывался чужих.

БП>Вобщем, у меня за годы жизни сложилось обратное впечатление: MFC это библиотека для сборки WordPad'а и именно WordPad'а. Любая попытка выйти за рамки реализации -- тяжкая борьба с особенностями MFC.

Вы знаете, Павел, MFC ведь можно использовать двумя способами. Можно колдуном сгенерировать "скелет приложения", колдуном же нарастить на нем мясо, следуя пошаговым инструкциям вида "нажмите в колдуне вот эту кнопку, а потом наберите вот это" из MSDN... а можно — разобраться в архитектуре библиотеки (какой бы она ни была), понять ее сильные и слабые стороны, научиться использовать первые и обходить/заменять/усиливать вторые — после чего писать "руками", с полным осознанием каждой написанной строчки. Я выбрал именно второй способ.

В процессе написания предыдущего абзаца неожиданно сделал для себя такой вывод — очень опасно для программиста, когда используеая им библиотека выглядит в его глазах идеальной и непогрешимой. При таком подходе любая мало-мальски нетривиальная проблема (в ней ли самой, или в собственном коде) придет к мгновенному "опусканию рук". А так — я не жду от MFC граблей на каждом шагу, но знаю, что они могут быть, и готов потрассировать не только свой, но и ее исходный код, получив ручкой по лбу. И я не верю, что не смогу найти решения, причем достаточно элегантного.

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

БП>Здравствуйте, SchweinDeBurg!

БП>Везёт Вам
БП>А у нас в конторе, к сожалению, используется перебранная ручками WTL, ATL и даже STL.
БП>И когда-то давно была подправленная MFC. Было это в 1998 году. Тогда MFC была ещё подростком, с кучей подростковых болячек. И править их порой было так тоскливо...
Вообще-то, назвать в 1998 году MFC подростком я не могу. Писал на ней еще под Win16. Были болячки по поводу перехода на Win32, но они к этому времени были решены (хотя, на мой взгляд, не совсем красиво).
В основном такие слова говорят о небольшом опыте использования библиотеки.

БП>Так что когда я весной 1999 года обнаружил в одном из примеров от ATL atlctrls.h, я сразу забил и забыл про MFC.
Я несколько раньше посмотрел atlctrls и забил на них. Тратить время на программирование того, что делается значительно легче, не очень хотелось. Использовал только в составе ActiveX.

БП>А что касается того, что у MFC все шикарно с базами данных, то позвольте спросить, Вы хоть раз заглядывали в daocore.cpp? И как Вам? И что из этого Вы не смогли бы написать самостоятельно?
БП>Что касается меня, то я вполне способен использовать DAO на такой лад:
Наоборот, написал OleDB библиотеку (поддержки OleDB атлом еще не было). Прекрасно использовалось вместе с MFC.

БП>Вобщем, у меня за годы жизни сложилось обратное впечатление: MFC это библиотека для сборки WordPad'а и именно WordPad'а.
MFC — библиотека для сборки WordPad'а, и ваша задача ее расширить до границ вашего приложения. Почему все меряют эффективность MFC, Delphi или Net по стандартным контролам? Ну не предназначены эти ублюдочные контролы для серьезного приложения. Они специально сделаны, чтобы третьи фирмы могли заработать себе на хлеб. А в MFC, они не больше чем враппер на WinAPI, и легко расширяются до нужных границ. Не будете же вы говорить, что GUI предназначено только для написания WordPad'а?

БП>Любая попытка выйти за рамки реализации -- тяжкая борьба с особенностями MFC.
Нормальная борьба. Я еще не встречал систем, в которой данной борьбы не было. Тем что MFC большей частью является враппером на API, определяет успех в этой борьбе. Моя борьба с ранними версиями WTL закончилась в их пользу. После одного проекта, на WTL забил (думал до нормальной безглючной версии, получилось что больше никогда не использовал).

С уважением, Gleb.

Здравствуйте, AndrewVK, Вы писали:
Давненько я сюда не заходил. Заглохла ветка, и слава богу

НО !!! Вот эта фраза:

AVK>Нормальный вывод. Вам шашечки или ехать? Тут ведь альтернатива простая — либо глючный, но работающий софт на дотнете, либо вобще никакого софта и все руками.

это просто 5 баллов ) я ее себе записал и буду цитировать. Звучит просто как слоган для одной малоизвестной софтверной корпорации )

AVK>Есть опыт разработки аналогичных проектов на дотнете и классической платформе?

AVK>Не могу с тобой согласится, поскольку мой опыт свидетельствует об обратном. Что такое янус представляешь? Так вот — до него у меня был опыт реализации схожих систем, может чуть попроще. Один раз на Дельфи, другой раз на C#. На Дельфи проект занял 8 месяцев, на шарпе 3.

Янус хороший проект, достаточно сложный, и .Net как специально для него разрабатывали — тут ничего странного.

.
У меня есть опыт разработки равноценных проектов на С#, Java и С++. В итоге живут только проекты на MFC (по ресурсам и производительности оптимум на машинах заказчика), и на Java (там мужики Windows никогда не считали за серьезную ОС). Net-овский проект так и остался демонстрашкой. По крайней мере пока. Специфика — много 2D — графики, "псевдореальность времени", и очень большие блоки данных ( до 170 блоков по 20-25 Мб каждый). Java проект кстати приемлимо работает только потому, что техника серьезная — Sun SparkStation и Солярис. MFCшный работает везде,.Net — нигде.

В общем, все это уже обсуждалось пофлеймили и будет. Спасибо за шикарную фразу " или кривой софт, или никакого