Цитата(Coocky @ 8.11.2005, 15:37)

Никто не купит твою прогу, когда вылетит сообщение Ups! I Want FrameWork,I Want Framework! Никто не кинется за дистрибутивом Виндос, что б установит FW Особенно буржуины и особенно америкосы!

Буржуины уже давно переехали на .Net и сейчас активно переписывают софтину под нее. Тебе никто не мешает включить фреймворк в инсталяцию, точно также как ты это делаешь распостраняя софт написанный на MFC, включая mfc42.dll, MDAC и прочую трэшню необходимую для работы. Объем дистрибутива здесь всем абсолютно пофигу.

Цитата

Я стараюсь найти истину. И пока лучше по всем параметрам, чем MFC под С++ я не вижу. Хоть он и урод редкостный (МФС)... Появится другая библа под С++, я перейду на нее с удовольствием. Я и на шарпак перейду, когда он будет поддерживаться вся и все

Просто MFC это пример плохого ООП дизайна. А Qt - пример отличного ООП дизайна. Попробуй перенести MFC на Unix или MacOS. Или попробуй использовать его не в Visual Studio. Какая это нафиг свобода? Это форменное рабство.

Coocky вот в чем вразумление:

Цитата

Буржуины уже давно переехали на .Net и сейчас активно переписывают софтину под нее. Тебе никто не мешает включить фреймворк в инсталяцию, точно также как ты это делаешь распостраняя софт написанный на MFC, включая mfc42.dll, MDAC и прочую трэшню необходимую для работы. Объем дистрибутива здесь всем абсолютно пофигу.

Крупные корпорации, конечно, переезжают, но и на Западе далеко не все так уж компьютеризировано. Мне приходилось сталкиваться с тем, что во Франции агенты по продаже билетов таскают свои апдейты на дискетках в центральный офис, потому что у них нет ни локалки, ни модема.
Добавлено @ 21:03
Это я к тому, что технологии, которые для одних являются настоящим, для других - недалекое, но будущее.

Цитата(Lamer @ 8.11.2005, 21:02)

Крупные корпорации, конечно, переезжают

Опередил
Половина буржуинов(юзеров) даже не знают, КАК УСТАНАВЛИВАТЬ дополнительные компоненты Windows.
Ну что ж, добивать вас ребята, так по полной...
Итак, поехали..
Что требуют приложения для пользователей(ВСЕХ пользователей). Приложение должно запустится и работать! Без всяких дополнительных установок(читайте -беганье в поисках софта для дополнительной установки).
Если вы пишите для американской компании, которая работает исключительно с вашим софтом ,исключительно для внутренего пользования,исключительно с настроеной конфигурацией, тогда разговора нет. Но мы берем универсальность.
Я не могу позволить себя даже наличие установленой БД! Все с собой(низкий поклон тебе -Sqlite )
Вы под FW можете себе позволить это? Нет! да и сомневаюсь , что есть какие -либо стороние библиотеки под C#. А вод под С++-куча,от баз данных ,до регулярных выражений.Все с собой. Никак Error & Warning после инсталяции.

Цитата(Sun @ 8.11.2005, 19:13)

Тебе никто не мешает включить фреймворк в инсталяцию, точно также как ты это делаешь распостраняя софт написанный на MFC, включая mfc42.dll, MDAC и прочую трэшню необходимую для работы

Да что ты говоришь?
И обьем пофигу?
Да никто не будет качать четырех метровые инсталянты(это касается и Qt), ради того, что б установить себе 30 долларовый снифер, или системную службу!

Цитата(Sun @ 8.11.2005, 19:13)

Просто MFC это пример плохого ООП дизайна. А Qt - пример отличного ООП дизайна. Попробуй перенести MFC на Unix или MacOS. Или попробуй использовать его не в Visual Studio. Какая это нафиг свобода? Это форменное рабство.

МФС-пример ООП! Единственый недостаток-трудная работа с GUI...Тут разговора нет.
Но когда разрабатывался МФС, Java была в зародыше, про Делфятину не знали(Паскаль вообще считался ругательством и обзывательством), Qt-.....промолчим
А про переносимость я молчу. Ты WinForms перенеси
А зачем мне переносить в другую среду разработки? Каждая УВАЖАЮЩАЯ себя компания имеет свой компилятор и среду разработки. Все должно быть под марку!А свобода заключается в свободной отладке, собирании проекта,в НОРМАЛЬНОЙ поддержке и отсуствии тягания библиотек и компиляция страшных mak файлов!
На данный момент под OC Виндовс известны следующие языки/библиотеки:
С++
Borland(за него писали и повторятся не будем..Итак весь в грязи и ругательстве...)
MFC (оболочка WinApi. Тяжелая разработка GUI,хорошая ,но разбросаная документация,шикарные классы для работы со всем,кроме интерфейса)
Кроссплатформеные гибриды Qt и FXWidget( последний недалеко ушел от МФС, но имеет плохую документацию..)
Qt-не удостоилась даже своей СР, хотя бабки уже дерут, плюс еще в последних версиях диктуют свои условия,типа поддержки только своих БД и т.д.
Остальных АНЧОУСОВ я не беру-мелко плавают. Да и в основнос удел Пингвинов.Они не чуть не лучше самой Линукс, так что геммора при работе не меньше. Зато круто! Как я говорил когда-то-есть свой трамвай,этим и гордимся...
Pascal
Delphi( я ласково зову ее Делфятина). Говорят хорошая, я б перешел, если б не паскаль. Начал изучать его в институте-появился токсикоз. Лучше не с кем, чем с кем попало..
Java.
Незнаю как называется GUI библиотека,но знаю, что тормозит. Это признают и Джависты
по удобству-говорят хорошо.
говорили ,что и сама java медленая,но тесты показывают, что сама Java не хуже С++ по скорости..
Но если по установке ,как C#, то уж лучше шарпак. Ближе к С++.Мне так показалось при изучении..
С#
Window Forms. Пользовался, понравилось. Хотя сбиваетс толку его "ООП" Иной раз думаешь когда пишешь на нем-как так можно?
Радует отсутсвие указателей и халява с освобождением памяти. Иногда раздражает куча new и точек Остальные недостатки -выше

Это сообщение отредактировал(а) Coocky - 8.11.2005, 22:59

Цитата(Coocky @ 8.11.2005, 18:37)

Проги должны идти на ВСЕМ. Это тебе не игрушки какие-то, где все зависит от конфигурации компа...

Это как раз обязательное требование для шароварного пасьянса, идти на любой системе. А серьезное приложение может предъявлять дополнительные требования к системе. Тот же офис при установке требует себе IE не ниже такой-то версии, и ничего. А для нашей системы мы не только указываем какой софт должен стоять (при невыполнении этих требований претензии не рассматриваются), но и в подавляющем большинстве случаев указываем какое железо использовать.

Цитата(Coocky @ 8.11.2005, 22:52)

Но когда разрабатывался МФС, Java была в зародыше, про Делфятину не знали(Паскаль вообще считался ругательством и обзывательством), Qt-.....промолчим

Почитай вот эту статейку.

Coocky

Цитата

Что требуют приложения для пользователей(ВСЕХ пользователей). Приложение должно запустится и работать! Без всяких дополнительных установок(читайте -беганье в поисках софта для дополнительной установки).

Согласен, но такова MS: создает технологии, а потом сама же объявляет их устаревшими, ибо создала нечто новое. Возможно сейчас есть у кого-нить проблемы с поддержкой .net приложений, из-за отсутствия framework'a в системе, но опять же - дай время: например, уже в SP3 будет поставляться .net, в win2003 он уже есть, ну а после прихода Vista виндовозы, не имеющие framework на борту не просто устареют - ИХ НЕ СТАНЕТ!
Так что, если софт пишется под винду и со взглядом в будущее, то выбор только .net. А какие альтернативы? MFC, WinApi?

Цитата

Я люблю МФС чуть больше тебя, только потому, что он иеня кормит.

Это пока. Придет время и ты с ним попрощаешься, так как mfc уже сейчас не развивается (все усилия на .net), а через пару лет и вообще станет неприемлимым, так как на нем нельзя уже будет писать современный софт. А сейчас - да, но это не долго.

WinApi? Да ну не смешите. Вот тебе пример. Софтина писалась исключительно на Api и в win2000. После переноса приложения на Xp не работала. А проблема вот в чем. Строчки, работающие в win2000:

Код

if (тип_найденного_окна == TEdit) /*или просто Edit, эти тонкости rtfm*/)  {...}

уже в XP должны выглядить так:

Код

if (... == TEdt) {...}

И таких примеров не мало.
А ты говорил

Цитата

Приложение должно запустится и работать!

Так что

Цитата

Ну что ж, добивать вас ребята, так по полной...

как-то не выходит.

Это сообщение отредактировал(а) alir - 9.11.2005, 01:30

Цитата(alir @ 9.11.2005, 01:28)

уже в SP3 будет поставляться .net, в win2003 он уже есть, ну а после прихода Vista виндовозы, не имеющие framework на борту не просто устареют - ИХ НЕ СТАНЕТ! Так что, если софт пишется под винду и со взглядом в будущее, то выбор только .net.

Редкостный оптимист Тут человек недавно писал, что многие до сих пор под DOS и Win3.11, и всё отлично работает, про .NET там и краем уха не слыхивали.
Кстати вспомнил: друг у меня есть, так у него на работе база FoxPro, проект ещё с девяностых годов ведётся, чёрт ногу сломит. Они до сих под FoxPro и сидят, попробуй перепиши такую махину.
Когда Билли под Настрадамуса косил, говорил, что через 10 лет каждый чиньгачкук в Зимбабве будет сидеть на широком канале online круглые сутки.
Так что TurboC жил, жив и будет жить!

Цитата(alir @ 9.11.2005, 01:28)

MS: создает технологии

ИМХО MS крадёт технологии, выдает за свои и навязывает всему миру, заведомо делая несовместимым со всем остальным

А если серьёзно, то я этим .NET просто брезгаю, платформа Delphi его как Тузик грелку порвёт...
И вообще что вы сравниваете? На ком легче и красивее GUI написать? Базара нет на НЕТ(offtopic на Delphi), а всё остальное не чем???... То-то же. Сам то НЕТ написан на плюсах, а например Delphi написан на Delphi.
Если же брать платформу, то лучше жабки не найти.
Итого каждый должен занимать свою нишу, делать то, что у него получается лучше других. Поэтому ни один из этих языков как и спрос на этих специалистов не исчезнет.

Это сообщение отредактировал(а) Vadim999 - 9.11.2005, 02:38

Цитата(Coocky @ 8.11.2005, 19:52)

Половина буржуинов(юзеров) даже не знают, КАК УСТАНАВЛИВАТЬ дополнительные компоненты Windows. Ну что ж, добивать вас ребята, так по полной... Итак, поехали.. Что требуют приложения для пользователей(ВСЕХ пользователей). Приложение должно запустится и работать! Без всяких дополнительных установок(читайте -беганье в поисках софта для дополнительной установки). Если вы пишите для американской компании, которая работает исключительно с вашим софтом ,исключительно для внутренего пользования,исключительно с настроеной конфигурацией, тогда разговора нет. Но мы берем универсальность.

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

У большинства энд-зеров за бугром настроен динамический апдейт оськи и прочего софта. За месяц они выкачивают сотни мегабайт и совершенно не заботятся надо это им или нет. Размер программы имеет значение только для микроустройств. А для персоналок - если это помещается на один DVD - это нормально.

А пингвинов, троллей и анчоусов не обижай! Благодаря им развиваются самые прогрессивные технологии, которые потом нагло тырятся M$.

Цитата(Coocky @ 8.11.2005, 19:52)

Да никто не будет качать четырех метровые инсталянты(это касается и Qt), ради того, что б установить себе 30 долларовый снифер, или системную службу!

Извини, но писать снифер на MFC это тоже изврат. Небольшие утилиты можно писать на чистом API или использовать легковесные библиотеки.

alir

Цитата

WinApi? Да ну не смешите. Вот тебе пример. Софтина писалась исключительно на Api и в win2000. После переноса приложения на Xp не работала. А проблема вот в чем. Строчки, работающие в win2000: Код if (тип_найденного_окна == TEdit) /*или просто Edit, эти тонкости rtfm*/)  {...} уже в XP должны выглядить так: Код if (... == TEdt) {...} И таких примеров не мало.

Ну ты, брат загнул . Где ты такого в WinAPI увидал???
TEdit, TEdt

WInAPI был и остается самой переносимой платформой в Windows . А NET даже со своими виндовозами подружить не могут, какой уж им там MONO?

Цитата(Coocky @ 8.11.2005, 19:52)

МФС-пример ООП!

Да ладно. Это тоже ООП?

Код

BEGIN_MESSAGE_MAP(CMFCTestApp, CWinApp)     ON_COMMAND(ID_APP_ABOUT, OnAppAbout)     // Standard file based document commands     ON_COMMAND(ID_FILE_NEW, CWinApp::OnFileNew)     ON_COMMAND(ID_FILE_OPEN, CWinApp::OnFileOpen)     // Standard print setup command     ON_COMMAND(ID_FILE_PRINT_SETUP, CWinApp::OnFilePrintSetup) END_MESSAGE_MAP() // Раскроем макросы #ifdef _AFXDLL #define BEGIN_MESSAGE_MAP(theClass, baseClass) \     const AFX_MSGMAP* PASCAL theClass::GetThisMessageMap() \         { return &theClass::messageMap; } \     const AFX_MSGMAP* theClass::GetMessageMap() const \         { return &theClass::messageMap; } \     AFX_COMDAT const AFX_MSGMAP theClass::messageMap = \     { &baseClass::GetThisMessageMap, &theClass::_messageEntries[0] }; \     AFX_COMDAT const AFX_MSGMAP_ENTRY theClass::_messageEntries[] = \     { \ #else #define BEGIN_MESSAGE_MAP(theClass, baseClass) \     const AFX_MSGMAP* theClass::GetMessageMap() const \         { return &theClass::messageMap; } \     AFX_COMDAT const AFX_MSGMAP theClass::messageMap = \     { &baseClass::messageMap, &theClass::_messageEntries[0] }; \     AFX_COMDAT const AFX_MSGMAP_ENTRY theClass::_messageEntries[] = \     { \ #endif #define ON_COMMAND(id, memberFxn) \     { WM_COMMAND, CN_COMMAND, (WORD)id, (WORD)id, AfxSigCmd_v, \         static_cast<AFX_PMSG> (memberFxn) },         // ON_COMMAND(id, OnBar) is the same as         //   ON_CONTROL(0, id, OnBar) or ON_BN_CLICKED(0, id, OnBar)

Боюсь Бьярни Страуструп на пару с Гради Бучем матом гнут, когда видят такое ООП.

Sun

Цитата(Sun @ 9.11.2005, 17:33)

Да ладно. Это тоже ООП?

Вот оно )...

Цитата(DeadSoul @ 7.11.2005, 14:04)

Вот, вот. На компилер у начальства я денег выбью, а на QT.....

Компилер 100% бесплатный
Добавлено @ 18:39
Подброшу линк в топку разговора
ЗЫ. Потом скажу своё мнение, сейчас на ноуте каждая буква даёться с трудом.

chipset
Спасибо за поддержку!
Вообщем автор ничем не дополнил наш разговор, а только потвердил
Добавлено @ 22:42
Sun

Цитата(Sun @ 9.11.2005, 13:33)

Боюсь Бьярни Страуструп на пару с Гради Бучем матом гнут, когда видят такое ООП.

Тебе так пугают макросы?
Это всего лишь маленькое неудобство(для тебя), взамен длинного оператора switch, с помощью которого обрабатывается сообщения на WinAPI. Получив нечитабельные макросы, мы избавились от громадного switch!

Coocky

Цитата(Coocky @ 9.11.2005, 22:39)

Это всего лишь маленькое неудобство(для тебя), взамен длинного оператора switch, с помощью которого обрабатывается сообщения на WinAPI. Получив нечитабельные макросы, мы избавились от громадного switch!

как будто switch - решение всех проблем. Сигналы и слоты, вот где руль .

Sun а кот в тему привел. Я минут 10 смотрел, любовался .

Это сообщение отредактировал(а) Perchilla - 10.11.2005, 10:37

Coocky, макросы были придуманы для языка С. Конечно они полезны в некоторых случаях, но MFC перегружено макросами и структурами. Макросы скрывают реализацию и ты просто перестаешь понимать что они реально делают. Ты тупо делаешь copy/paste того что тебе нагенерил визард, не вдаваясь в смысл того что ты делаешь.

Вот скажи мне, на кой ляд я должен использовать класс CWinThread, если для создания его экземпляра я должен вызывать стороннюю функцию AfxBeginThread?

Код

CWinThread* AfxBeginThread( AFX_THREADPROC pfnThreadProc, LPVOID pParam, int nPriority = THREAD_PRIORITY_NORMAL, UINT nStackSize = 0, DWORD dwCreateFlags = 0, LPSECURITY_ATTRIBUTES lpSecurityAttrs = NULL );

Может легче не парится а использовать WinAPI?

Код

HANDLE CreateThread(   LPSECURITY_ATTRIBUTES lpThreadAttributes,   SIZE_T dwStackSize,   LPTHREAD_START_ROUTINE lpStartAddress,   LPVOID lpParameter,   DWORD dwCreationFlags,   LPDWORD lpThreadId );

Во первых согласно канонам ООП, экземпляр класса должен создаватся с помощью конструктора, а не сторонней функции. Во вторых, где желаемое упрощение кода? Где приимущество использования C++? На хрена делать так все сложно?
Да лучше бы просто написали библиотеку Сишных макросов для работы с WinAPI, больше пользы было-бы.

А теперь посмотрим для контраста класс QThread, из Qt

Цитата

QThread::QThread ( QObject * parent = 0 ) Constructs a new thread with the given parent. The thread does not begin executing until start() is called.

В конструкторе используется всего 1 параметр! Причем технология создания объектов в Qt одинакова для всех классов. Мне не нужно перерывать тысячи страниц MSDNа и искать значения структур, макросов и прочей трэшни. Я один раз запомнил принцип и могу его использовать постоянно.