Использование голого Win32 API для написания GUI - Философия программирования

Привет всем.

Извините, что слишком часто будирую эту тему, но для меня это
вопрос принципа.

Долгие дебаты на тему Delphi vs VC и .NET vs C/C++ свидетельствуют
о правоте как тех, так и других. Сторонники Delphi и .NET выдвигают
такие аргументы, как скорость разработки и удобство ИСР. Стронники
С/С++ приводят аргументы в пользу высокого быстродействия и малого
объема кода. Непонятным остается одно. Почему, например, при разработке
прогаммного комплекса наподобие filemon или regmon я не могу для написания
управляющей части использовать BCB и VCL без риска быть обвиненным в
профнепригодности. В своих проектах на BCB5 и BCB6 я неоднократно использовал
WinNT native API (ZwLoadDriver, ZwGetSystemInformation, ZwRaiseHardError и др.),
а также сложные SCM API, Crypto API и Setup API. Но хоть убей не пойму, на кой
леший я должен на голом API разрабатывать пользовательский интерфейс. Да мне
проще взать все это из палитры визуальных компонентов, чем сабкласить эти
дурацкие окна или писать хренотень наподобие такой


    BEGIN_MSG_MAP(CBackupDlg)
        MESSAGE_HANDLER(WM_INITDIALOG, OnInitDialog)
        MESSAGE_HANDLER(WM_EB_PRESS, OnEditBrowserCtrlPress)
        MESSAGE_HANDLER(WM_ENTERIDLE, OnEnterIdle)
        COMMAND_ID_HANDLER(IDOK, OnOK)
        COMMAND_ID_HANDLER(IDCANCEL, OnCancel)
        COMMAND_ID_HANDLER(IDC_ASSIGN_PASSWORD, OnAssignPasswordClick)
        COMMAND_RANGE_HANDLER(IDC_RADIO_REPLICA, IDC_RADIO_COMPACT, OnSelectOption)
    END_MSG_MAP()
 
    BEGIN_DDX_MAP(CBackupDlg)
        DDX_TEXT_LEN(IDC_FOLDERPATH, m_szPath, MAX_PATH)
        DDX_TEXT(IDC_PASSWORD, m_bstrPassword)
        DDX_CHECK(IDC_PASSWORD, m_nAssignPassword)
        DDX_RADIO(IDC_RADIO_REPLICA, m_nReplicaOrCompact)
    END_DDX_MAP()

    BEGIN_UPDATE_UI_MAP(CBackupDlg)
        UPDATE_ELEMENT(IDC_ENCRYPT_COMPACT, UPDUI_CHILDWINDOW)
        UPDATE_ELEMENT(IDC_ASSIGN_PASSWORD, UPDUI_CHILDWINDOW)
        UPDATE_ELEMENT(IDC_PASSWORD, UPDUI_CHILDWINDOW)
    END_UPDATE_UI_MAP()

В связи с этим я сделал вывод, что сейчас нет объективных оснований для написания оконного интерфейса на голом API, GTK или WTL. Посему те разработчики, кто его используют, делают это либо для демонстрации собственной крутизны, либо в погоне за гонорарами. Но я допускаю, что в чем-то могу ошибаться. Посему хотел бы услышать разумные доводы в пользу применения вышеприведенных инструментов.

С уважением, Orifiel
-

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

O>Извините, что слишком часто будирую эту тему, но для меня это
O>вопрос принципа.

O>Долгие дебаты на тему Delphi vs VC и .NET vs C/C++ свидетельствуют
O>о правоте как тех, так и других. Сторонники Delphi и .NET выдвигают
O>такие аргументы, как скорость разработки и удобство ИСР. Стронники
O>С/С++ приводят аргументы в пользу высокого быстродействия и малого
O>объема кода. Непонятным остается одно. Почему, например, при разработке
O>прогаммного комплекса наподобие filemon или regmon я не могу для написания
O>управляющей части использовать BCB и VCL без риска быть обвиненным в
O>профнепригодности.

Если уж серьезно, то никто тебя не обвинит в профнепригодности , если напишешь продукт лучше, чем filemon/regmon. В нем пользовательский интерфейс — мелочь и не имеет существенного значения, на чем именно написан. Напиши свой filemon хоть на VB, убуди мир в том. что он лучше чем тот, что у Руссиновича — и никто тебе и слова не скажет насчет того, на чем он написан.

В своих проектах на BCB5 и BCB6 я неоднократно использовал
O>WinNT native API (ZwLoadDriver, ZwGetSystemInformation, ZwRaiseHardError и др.),
O>а также сложные SCM API, Crypto API и Setup API. Но хоть убей не пойму, на кой
O>леший я должен на голом API разрабатывать пользовательский интерфейс.

А кто тебя заставляет ? На нем сейчас и так никто не пишет.

>Да мне
O>проще взать все это из палитры визуальных компонентов, чем сабкласить эти
O>дурацкие окна или писать хренотень наподобие такой

<skipped>

А это, насколько я понимаю, MFC, а не голый Win32. Кроме того, это обычно вставляет мастер, а не пишут вручную. Но вообще споры Delphi/Builder против MFC — это ИМХО в Священные войны.

O>В связи с этим я сделал вывод, что сейчас нет объективных оснований для написания оконного интерфейса на голом API, GTK или WTL.

Не хочешь — не пиши.

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

почему в качестве альтернативы для быстрой разработки GUI рассматривается только BCB, Delphi, .Net? Я про Delphi ничего не скажу, но вот Builder точно использовать в серьезных проектах не буду. По крайней мере существующие версии — нахлебался в свое время. Есть и другие библиотеки под C++. Я например уже долгое время использую Qt, и ничего плохого сказать не могу. Есть вполне нормальный дизайнер, понятная документация, обширная библиотека классов, кроссплатформенная, очень просто используется в студии

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

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

O>>Извините, что слишком часто будирую эту тему, но для меня это
O>>вопрос принципа.

PD>:-)

O>>Долгие дебаты на тему Delphi vs VC и .NET vs C/C++ свидетельствуют
O>>о правоте как тех, так и других. Сторонники Delphi и .NET выдвигают
O>>такие аргументы, как скорость разработки и удобство ИСР. Стронники
O>>С/С++ приводят аргументы в пользу высокого быстродействия и малого
O>>объема кода. Непонятным остается одно. Почему, например, при разработке
O>>прогаммного комплекса наподобие filemon или regmon я не могу для написания
O>>управляющей части использовать BCB и VCL без риска быть обвиненным в
O>>профнепригодности.

PD>Если уж серьезно, то никто тебя не обвинит в профнепригодности , если напишешь продукт лучше, чем filemon/regmon. В нем пользовательский интерфейс — мелочь и не имеет существенного значения, на чем именно написан. Напиши свой filemon хоть на VB, убуди мир в том. что он лучше чем тот, что у Руссиновича — и никто тебе и слова не скажет насчет того, на чем он написан.

PD>В своих проектах на BCB5 и BCB6 я неоднократно использовал
O>>WinNT native API (ZwLoadDriver, ZwGetSystemInformation, ZwRaiseHardError и др.),
O>>а также сложные SCM API, Crypto API и Setup API. Но хоть убей не пойму, на кой
O>>леший я должен на голом API разрабатывать пользовательский интерфейс.

PD>А кто тебя заставляет ? На нем сейчас и так никто не пишет.

>>Да мне
O>>проще взать все это из палитры визуальных компонентов, чем сабкласить эти
O>>дурацкие окна или писать хренотень наподобие такой

PD><skipped>

PD>А это, насколько я понимаю, MFC, а не голый Win32. Кроме того, это обычно вставляет мастер, а не пишут вручную. Но вообще споры Delphi/Builder против MFC — это ИМХО в Священные войны.

Да, в MFC вставляет мастер, а в WTL все пишет программист.

O>>В связи с этим я сделал вывод, что сейчас нет объективных оснований для написания оконного интерфейса на голом API, GTK или WTL.

PD>Не хочешь — не пиши.

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

O>Да, в MFC вставляет мастер, а в WTL все пишет программист.

WTL Helper не пробовали использовать?

[ posted via RSDN@Home 1.1.4 stable SR1 r568, accompanied by silence ]

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

O>Да, в MFC вставляет мастер, а в WTL все пишет программист.

отнюдь

http://salos.narod.ru/WtlWiz/WTLWizards.html
http://salos.narod.ru/WTLHelper/WTLHelper.html

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

O>>Да, в MFC вставляет мастер, а в WTL все пишет программист.

OE>отнюдь

OE>http://salos.narod.ru/WtlWiz/WTLWizards.html
OE>http://salos.narod.ru/WTLHelper/WTLHelper.html

OE> :up:

Хорошо, но для этого я должен использовать VC 2003
вместо более компактного и менее тяжеловесного VC6.

Orifiel wrote:

> Да, в MFC вставляет мастер, а в WTL все пишет программист.

Я уже лет 5 не пользуюсь Class Wizard'ом в VS. Программирую под MFC. Что
я не так делаю?

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

> Долгие дебаты на тему Delphi vs VC и .NET vs C/C++ свидетельствуют
> о правоте как тех, так и других. Сторонники Delphi и .NET выдвигают
> такие аргументы, как скорость разработки и удобство ИСР. Стронники
> С/С++ приводят аргументы в пользу высокого быстродействия и малого
> объема кода. Непонятным остается одно. Почему, например, при разработке
> прогаммного комплекса наподобие filemon или regmon я не могу для написания
> управляющей части использовать BCB и VCL без риска быть обвиненным в
> профнепригодности.

А что, кто-то обвиняет?

> В своих проектах на BCB5 и BCB6 я неоднократно использовал
> WinNT native API (ZwLoadDriver, ZwGetSystemInformation, ZwRaiseHardError и
> др.),
> а также сложные SCM API, Crypto API и Setup API.

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

Да привык он так, может.

> Да мне проще взать все это из палитры визуальных компонентов, чем
> сабкласить эти
> дурацкие окна или писать хренотень наподобие такой

Ну а Руссиновичу проще наваять на голом API, а не устанавливать (и покупать
перед этим, за свои кровные) билдер и учить VCL.

> В связи с этим я сделал вывод, что сейчас нет объективных оснований для
> написания оконного интерфейса на голом API, GTK или WTL.

Да их сколько угодно, этих оснований. Например, если хочется сделать
екзешник такой же маленький, как у большинства руссиновичевских утилит. И не
факт, что Руссинович пишет гуй на голом апи медленней, чем вы на VCL.

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

Либо просто потому, что им так хочется. Или билдера у них нет. Или екзешники
маленькие нужны. Или учиться пользоваться RAD-средами лень.

Posted via RSDN NNTP Server 1.9

Orifiel wrote:

> В связи с этим я сделал вывод, что сейчас нет объективных оснований
> для написания оконного интерфейса на голом API, GTK или WTL.

Эээ... А что тут не нравится? Вроде все логично и понятно — определяем
обработчики, определяем привязку переменных и контролов.

То же самое на Delphi потребует долгого вождения мышки, а тут у нас
просто текст.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

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

C>Orifiel wrote:

>> Да, в MFC вставляет мастер, а в WTL все пишет программист.

C>Я уже лет 5 не пользуюсь Class Wizard'ом в VS. Программирую под MFC. Что
C>я не так делаю?

MFC, как и VCL, слишком неповоротливая и запутанная, к тому же старая и отжившая. Вдобавок писать GUI на ней не намного проще, чем на голом API. WTL намного компактнее и понятнее, но тоже слишком тупорылая в плане разработки GUI. В новой версии BCB 2006 надеюсь на полный перевод кода VCL на С++. Кроме того, настройки опций компилятора и
компоновщика обещают сделать гибкими по аналогии с VC6. Что же касается .NET Framework
и WinForms в частности, то этот инструмент представляет собой COM-сервер, косвенно использующий Win32 API. Так на фига юзать .NET, если можно вызывать API напрямую через
BCB.

C>--
C>С уважением,
C> Alex Besogonov (alexy@izh.com)

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

O>Хорошо, но для этого я должен использовать VC 2003
O>вместо более компактного и менее тяжеловесного VC6.
И что такого тяжеловесного в VC 2003? Нормальный компилятор

... << RSDN@Home 1.2.0 alpha rev. 619>>

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

O>Что же касается .NET Framework и WinForms в частности, то этот инструмент представляет собой COM-сервер, косвенно использующий Win32 API

это ты откуда взял?

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

O>Хорошо, но для этого я должен использовать VC 2003
O>вместо более компактного и менее тяжеловесного VC6.

попробуй Qt. У меня версия 3.2 очень хорошо работает на шестерке

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

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

O>>Хорошо, но для этого я должен использовать VC 2003
O>>вместо более компактного и менее тяжеловесного VC6.

S>попробуй Qt. У меня версия 3.2 очень хорошо работает на шестерке

А как Qt в плане GUI? Лучше, чем WTL, или такое же говно на палочке?

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

[]

Флейма развелось

На самом деле все зависит, как и в большинстве случаев от 3х фаторов ( перечислены в порядке убывания важности ):
1)Заказчика;
2)Исполнителя;
3)Задачи.

Первый фактор:
Если заказчик упирается и хочет на C# под .Net 1.1 то Вы его можете и не убедить, что С++ и boost будут лучше.

Второй фактор:
Если исполнитель не знает C#, то лучше убедить заказчика перейти на С++ и boost, в противном случае — или учить Шарп или отказываться о задачи.

Третий фактор:
Если задача легко решается, предложенными исполнителем, средствами, удовлетворяющими заказчика, то все ОК.
Если таковых средств несколько, от имеет место учет предпочтений исполнителя.

ИМХО профессионализм это работа на уровне 3го фактора

А Делфи- не Делфи это не важно.

... << RSDN@Home 1.1.4 stable rev. 510>>

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

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

O>>Что же касается .NET Framework и WinForms в частности, то этот инструмент представляет собой COM-сервер, косвенно использующий Win32 API

S>это ты откуда взял?

Внутреннее устройство Windows, 4-е издание. Автор книги пишет filemon'ы,
отличается большой слабостью к голому API и совершенно не использует С++.

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

S>>попробуй Qt. У меня версия 3.2 очень хорошо работает на шестерке

O>А как Qt в плане GUI? Лучше, чем WTL, или такое же говно на палочке?

Сам посмотри: http://www.trolltech.com/screenshots/index.html?cid=20
Главный недостаток у Qt -- это цена.
Ну, еще может смущать, что внутри в Qt все в Unicode работает.

Да и на Qt с wxWidgets свет клином не сошелся. Можно еще и сюда заглянуть: http://www.geocities.com/SiliconValley/Vista/7184/guitool.html
А так же посмотреть на относительно новый тоолкит для C++: http://upp.sourceforge.net/

... << RSDN@Home 1.1.4 stable rev. 510>>

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

O>А как Qt в плане GUI? Лучше, чем WTL, или такое же говно на палочке?

у Qt есть графический дизайнер, где формочки создаются также легко, как и в Builder-е, Delphi и т.п. Кроме того, она написана на чистом C++ с использованием своих метакомпайлеров. Т.е. ты мышкой набросал на форму контролы, сохранил файл формы с расширением .ui (в формате xml) и метакомпайлером откомпил его. В студии это все делается добавлением Custom Build Steps к файлу проекта. И все — у тебя полноценный класс формы. Хочешь используй его, хочешь наследуйся от него. Сама Qt объектно-ориентированая, причем написана доволно грамотно

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

O>В новой версии BCB 2006 надеюсь на полный перевод кода VCL на С++.

Хотел бы я быть таким оптимистом. Борланд на это никогда не пойдет, борланд любит паскаль (вся линейка BCB наглядное тому подтверждение). Да и не рационально это ни с маркетинговой ни с технической точки зрения. Скажи спасибо, если они компилятор до ума доведут (хотя бы в части соответствия стандарту, на нормальную оптимизацию я не надеюсь). Хотя лично я и в этом сильно сомневаюсь.

O>Кроме того, настройки опций компилятора и
O>компоновщика обещают сделать гибкими по аналогии с VC6.

Это обещали еще в BCB6. Так же как и нормальный code completion. Итог: куча народа "попробовав" BCB6 откатилась на BCB5. Не верю (с).

O>Что же касается .NET Framework
O>и WinForms в частности, то этот инструмент представляет собой COM-сервер,

Ты сильно заблуждаешься.

	От:	Orifiel
	Дата:	24.11.05 13:24
	Оценка:	+3

	От:	Pavel Dvorkin
	Дата:	24.11.05 14:00
	Оценка:

От:	sadomovalex	http://sadomovalex.blogspot.com
Дата:	24.11.05 14:17
Оценка:	+5

	От:	Orifiel
	Дата:	24.11.05 14:38
	Оценка:

От:	SchweinDeBurg	http://zarezky.spb.ru/
Дата:	24.11.05 15:09
Оценка:	5 (1)

От:	Odi$$ey	http://malgarr.blogspot.com/
Дата:	24.11.05 15:10
Оценка:	5 (1)

	От:	Глеб Алексеев
	Дата:	24.11.05 15:36
	Оценка:	+1

От:	eao197	http://eao197.blogspot.com
Дата:	24.11.05 16:17
Оценка:	12 (2)