Привет всем.

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

Долгие дебаты на тему 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 не пробовали использовать?

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

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

отнюдь

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

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

> Долгие дебаты на тему 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-средами лень.

Orifiel wrote:

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

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

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

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

Здравствуйте, 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? Нормальный компилятор ?

Здравствуйте, 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го фактора

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

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

Здравствуйте, 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, Вы писали:

O>Здравствуйте, Cyberax, Вы писали:
O> В новой версии BCB 2006 надеюсь на полный перевод кода VCL на С++.
Не надейся
Forms.hpp из preRelease BDS 2006 :

// Borland C++ Builder
// Copyright (c) 1995, 2005 by Borland Software Corporation
// All rights reserved

// (DO NOT EDIT: machine generated header) 'Forms.pas' rev: 10.00

За оставшееся до релиза время не успеют

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

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

O>MFC, как и VCL, слишком неповоротливая и запутанная, к тому же старая и отжившая. Вдобавок писать GUI на ней не намного проще, чем на голом API. WTL намного компактнее и понятнее, но тоже слишком тупорылая в плане разработки GUI.

А чем, на твой взгляд, принципиально MFC отличается от WTL ? (Шаблоны в расчет не берем)

Здравствуйте, Глеб Алексеев, Вы писали:

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

O>>Хорошо, но для этого я должен использовать VC 2003
O>>вместо более компактного и менее тяжеловесного VC6.
ГА>И что такого тяжеловесного в VC 2003? Нормальный компилятор ?
Не компилятор а сама среда.
В сравнении с VS6 VS2003 периодически еле ползает. P4 640 + 1G DDR2. Только не говорите что мало...

Orifiel wrote:

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

MFC назвать "неповоротливой"? Ндаааа....

Запутаной я бы тоже ее не назвал — есть определенные сложности (роутинг
сообщений, система Документ-Вид), но они скорее проистекают из сложности
решаемых задач. Ну а простые классы диалогов или окон — куда уж проще.

Я сейчас как раз заканчиваю сложное приложение на MFC, использующее OLE
2 и COM на полную катушку — так я до сих пор поражаюсь простоте
использования MFC для решения сложных проблем.

> Вдобавок писать GUI на ней не намного проще, чем на голом API. WTL
> намного компактнее и понятнее, но тоже слишком тупорылая в плане
> разработки GUI.

Что значит "писать GUI"? Бросать кнопочки на формочки? Так простите, это
далеко не "писать GUI". Писать GUI — это например:
http://www.elewise.ru/portfolio/software/oda.html (скриншоты первой
версии, сейчас все еще красивее) или http://www.bcgsoft.com/

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

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

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

Давайте посмотрим на исходники старого filemon:

файл                       байт    строк
-----------------------------------------------
filemon434\exe\Filemon.c   94023    3161
filemon434\exe\Instdrv.c    8491     265
filemon434\exe\filemon.h    3144     122
filemon434\exe\Ioctlcmd.h   3018      98
filemon434\exe\resource.h   2624      64   

filemon434\sys\Filemon.c  179193    5717
filemon434\sys\Filemon.h    5626     179
filemon434\sys\wintypes.h  18832     322

filemon434\vxd\Filemon.c   49648    1827
filemon434\vxd\Filemon.h    2438      94

К GUI относится лишь часть первого файла.
Как видно, основной функционал реализован несколько ниже, чем native API.

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

Может быть, авторы считают, что тулза должна иметь небольшой размер, и не вызывать проблем со скачиванием у пользователей dial-up?
Судя по дате:

/*
* FileMon - File System Monitor for Windows NT/9x
*       
* Copyright (c) 1996-2000 Mark Russinovich and Bryce Cogswell
*/

это было актуально.

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

По поводу профпригодности.
Russinovich и Cogswell очевидно не являются профи в область кидания контролов на форму. Поэтому они реализовали GUI способом, который они знают лучше всего.
А как ещё должны они были поступить для реализации GUI с минимальной функциональностью? Потратить энное количество времени на изучение VCL?

Я думаю, создание GUI заняло не больше 2% от общего времени разработки filemon. Если же искать какие-то основания на чём делать GUI — то можно запросто получить 50% .

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

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

гуй — это как раз то место, где микрооптимизации не имеют ни малейшего смысла. Потому что их эффекта пользователь просто не заметит.
так что здесь я полностью согласен
каждую задачу надо решать наиболее подходящим для этого инструментом!
BCB использовать конечно необязательно, ибо крив он и неповоротлив. Но на нем свет клином не сошелся — есть еще Qt, например. А его цена не так уж велика по сравнению с зарплатой хорошего разработчика, и очень быстро скомпенсируется сэкономленным временем.

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

C>Запутаной я бы тоже ее не назвал — есть определенные сложности (роутинг
C>сообщений, система Документ-Вид), но они скорее проистекают из сложности
C>решаемых задач. Ну а простые классы диалогов или окон — куда уж проще.

напомни-ка, как там у tree view чекбоксы включаются?

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

CC>Не компилятор а сама среда.
CC>В сравнении с VS6 VS2003 периодически еле ползает. P4 640 + 1G DDR2. Только не говорите что мало...

Ну проц явно слабоват.

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

CC>>В сравнении с VS6 VS2003 периодически еле ползает. P4 640 + 1G DDR2. Только не говорите что мало...

_>Ну проц явно слабоват.
Чутка очепятался. Не 640 а 630
Впрочем P4 630 = P4 3Gz, 2Mb cache, EMT64, 800 MHz FSB
Или ты шмайлик забыл поставить?

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

O>>MFC, как и VCL, слишком неповоротливая и запутанная, к тому же старая и отжившая. Вдобавок писать GUI на ней не намного проще, чем на голом API. WTL намного компактнее и понятнее, но тоже слишком тупорылая в плане разработки GUI.

AJD>А чем, на твой взгляд, принципиально MFC отличается от WTL ? (Шаблоны в расчет не берем)

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

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

Д>напомни-ка, как там у tree view чекбоксы включаются?

Стилем TVS_CHECKBOXES (в MSDN не смотрел).

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

AJD>А чем, на твой взгляд, принципиально MFC отличается от WTL ? (Шаблоны в расчет не берем)

Тем, что MFC — это фреймворк, а WTL — библиотека. Цитатка из Фаулера

Автор: Зверёк Харьковский
Дата: 04.10.05

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

SDB>Стилем TVS_CHECKBOXES (в MSDN не смотрел).

угу. который нужно устанавливать с помощью SetWindowLong, а не стандартных средств. причем в строго определенный момент жизненного цикла контрола.
в общем, всё предельно просто и логично

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

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

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

GN>Давайте посмотрим на исходники старого filemon:
GN>

GN>файл                       байт    строк
GN>-----------------------------------------------
GN>filemon434\exe\Filemon.c   94023    3161
GN>filemon434\exe\Instdrv.c    8491     265
GN>filemon434\exe\filemon.h    3144     122
GN>filemon434\exe\Ioctlcmd.h   3018      98
GN>filemon434\exe\resource.h   2624      64   

GN>filemon434\sys\Filemon.c  179193    5717
GN>filemon434\sys\Filemon.h    5626     179
GN>filemon434\sys\wintypes.h  18832     322

GN>filemon434\vxd\Filemon.c   49648    1827
GN>filemon434\vxd\Filemon.h    2438      94
GN>

GN>К GUI относится лишь часть первого файла.
GN>Как видно, основной функционал реализован несколько ниже, чем native API.

Что касается драйверов режима ядра, то здесь вы абсолютно правы. Хотя в
последнее время даже такие серьезные модули можно писать на языках высокого уровня
благодаря усилиям Compuware, Tetradyne, Vireo etc. Однако писать драйвера я предпочитаю
на голом DDK API, ибо в таких модулях важно контролировать все до мелочей.

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

GN>Может быть, авторы считают, что тулза должна иметь небольшой размер, и не вызывать проблем со скачиванием у пользователей dial-up?
GN>Судя по дате:
GN>

/*
GN>* FileMon - File System Monitor for Windows NT/9x
GN>*       
GN>* Copyright (c) 1996-2000 Mark Russinovich and Bryce Cogswell
GN>*/
GN>

это было актуально.

GN>Раньше исходники были доступны. Могли ли люди, их распространяющие, расчитывать на то, что их придётся компилировать двумя разными компиляторами?

GN>По поводу профпригодности.
GN>Russinovich и Cogswell очевидно не являются профи в область кидания контролов на форму. Поэтому они реализовали GUI способом, который они знают лучше всего.
GN>А как ещё должны они были поступить для реализации GUI с минимальной функциональностью? Потратить энное количество времени на изучение VCL?

GN>Я думаю, создание GUI заняло не больше 2% от общего времени разработки filemon. Если же искать какие-то основания на чём делать GUI — то можно запросто получить 50% .

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

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

O>>MFC, как и VCL, слишком неповоротливая и запутанная, к тому же старая и отжившая. Вдобавок писать GUI на ней не намного проще, чем на голом API. WTL намного компактнее и понятнее, но тоже слишком тупорылая в плане разработки GUI.

AJD>А чем, на твой взгляд, принципиально MFC отличается от WTL ? (Шаблоны в расчет не берем)

Прежде всего малым размером экзешников и продуманным механизмом обработки сообщений.
Также отмечу отсутствие всяких глупых классов-оберток вроде CServerSocket, CRecordset
и COleDispatchDriver. Кроме того, WTL куда рациональнее взаимодействует с COM, чем MFC.

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

Д>в общем, всё предельно просто и логично

М-м-м... я бы так сказал — MFC является удобной, "простой и логичнной" библиотекой для тех, кто имеет неоднолетний опыт разработки на ней. Понятно, что с точки зрения сегодняшнего Стандарта и сегодняшних компиляторов ее дизайн нельзя назвать высокохудожественным, но вспомните, сколько ей лет и каким компилятор от МС был тогда, в самом начале (Microsoft C/C++ 7.0, еще даже не Visual). А обратную совместимость они свято блюли, в отличие от Борланда, перекроившего OWL во 2-й версии так, что потребовался специальный ковертор проектов, написанных на OWL 1.0. Кроме того, несомненным и большим плюсом MFC для меня является тот факт, что зная, как нечто реализовать на "голом" АПИ, ты очень быстро разберешься, как то же самое сделать на MFC.

P.S.
Сердцем чую "священный" флейм...

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

O>Что касается драйверов режима ядра, то здесь вы абсолютно правы. Хотя в
O>последнее время даже такие серьезные модули можно писать на языках высокого уровня
O>благодаря усилиям Compuware, Tetradyne, Vireo etc.

А без фреймворка от того же CW разве можно только на асме?

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

E>Можно еще и сюда заглянуть: http://www.geocities.com/SiliconValley/Vista/7184/guitool.html

Интересная страничка, столько нового узнал

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

SDB>М-м-м... я бы так сказал — MFC является удобной, "простой и логичнной" библиотекой для тех, кто имеет неоднолетний опыт разработки на ней.

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

SDB>в отличие от Борланда, перекроившего OWL во 2-й версии так, что потребовался специальный ковертор проектов, написанных на OWL 1.0.

скажу честно — такой путь кажется мне намного более правильным если конечно этот конвертор работает нормально, а не "я тут что-то немного переделал, а дальше вы сами разбирайтесь"

SDB>Сердцем чую "священный" флейм...

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

Д>просто на инкапсуляцию они положили большой толстый болт, вот и все

Мне кажется, что дело тут все же не в "покладании болта", а в тривиальном "маркетинге" — ведь до 7-й версии MSC++ разработка под Винду в 99% случает велась на pure C и этих самых чистых сишников нужно было безболезненно и незаметно "подсадить на иглу". Вот и получился этакий "C с классами". Кроме того, хотелось бы в очередной раз процитировать очень правильный, на мой взгляд, пост

Автор: Юнусов Булат
Дата: 08.04.04

от Юнусов Булат-а:

Если непредвзято посмотреть — то в мфц уже в 92 году использовалось изрядное количество паттернов проектирования — одна серилизация чего стоит, тут тебе и фабрика и регистрация и двойная диспатчеризация и это повторяю в 92 году (книга Гаммы с сотоварищами, кстати, вышла много позже).

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

Вдогонку MFC-шний документ-вид практически пинками заставляет разделять данные и собственно гуй, не ахти какой паттерн, но много лучше чем тысячистроковые обработчики кликов в борландовских радостях.

Д>И не дай бог тебе сделать шаг влево или вправо — все отступники будут жестоко покараны

Это да, есть такое. Но опять-таки — неоднолетний опыт позволяет ИМХО справляться и с этим.

Д>скажу честно — такой путь кажется мне намного более правильным

М-м-м... не соглашусь, но тут предмета для спора у нас нет — как и товарищей на вкус и цвет.

P.S.
Приятно все-таки сойтись с "противником" без брызганья слюной и размахивания кулакакми...

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

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

O>>Что касается драйверов режима ядра, то здесь вы абсолютно правы. Хотя в
O>>последнее время даже такие серьезные модули можно писать на языках высокого уровня
O>>благодаря усилиям Compuware, Tetradyne, Vireo etc.

GN> А без фреймворка от того же CW разве можно только на асме?

Если речь идет об NT, можно на обычном С, являющимся языком среднего уровня.
Если VxD, то так и да на асме.

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

O>Если речь идет об NT, можно на обычном С, являющимся языком среднего уровня.

Без каких-либо проблем пишу на C++. Ходят слухи, что и на Delphi пишут

O>Если VxD, то таки да на асме.

С этим лично не знаком, но таки не соглашусь:

 Содержимое папки \filemon\vxd

25.11.2005  19:03    <DIR>          .
25.11.2005  19:03    <DIR>          ..
24.09.2001  20:56            49 648 Filemon.c
31.10.2000  22:48             2 438 Filemon.h
24.09.2001  20:56             1 179 Filevxd.def
26.12.2000  12:48             1 586 FILEVXD.EXP
24.09.2001  20:56             1 756 Filevxd.lib
26.08.1999  16:54             7 024 Filevxd.map
06.09.2001  08:07               484 FILEVXD.RES
10.08.1998  22:04             1 972 Filevxd.sym
24.09.2001  20:58               370 Filevxd.vrc
24.09.2001  20:56            23 140 FILEVXD.VXD
26.12.2000  12:48               397 Makefile
              11 файлов         89 994 байт

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

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

SDB>

SDB>Если непредвзято посмотреть — то в мфц уже в 92 году использовалось изрядное количество паттернов проектирования — одна серилизация чего стоит, тут тебе и фабрика и регистрация и двойная диспатчеризация и это повторяю в 92 году (книга Гаммы с сотоварищами, кстати, вышла много позже).

SDB>Кстати мфцшная серилизация при всей своей некрасивости работает без радикальных изменений уже больше 10 лет. а бустовскую мы уже три года ждем.

только к интерфейсу это имеет довольно-таки косвенное отношение
а document-view — да, правильно придумали

SDB>Это да, есть такое. Но опять-таки — неоднолетний опыт позволяет ИМХО справляться и с этим.

не хочется тратить годы обучения на постижение тонкостей перемещения по полю, густо засыпанному граблями
хотя конечно, и на это любители находятся

SDB>М-м-м... не соглашусь, но тут предмета для спора у нас нет — как и товарищей на вкус и цвет.

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

SDB>Приятно все-таки сойтись с "противником" без брызганья слюной и размахивания кулакакми...

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

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

Д>только к интерфейсу это имеет довольно-таки косвенное отношение

Ну, это я так, до кучи.

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

Вот в Видби они этим и начали заниматься — версия MFC под Windows CE переписана наново (правильнее говоря, наново портирована с десктопа). Так что по предварительным прогнозам фирму, где я работаю, ожидает в ближайшем будущем бурная сексуальная жизнь.

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

Не перевелись еще достойные последователи апокрифов Петцольда... Я это обязательно вверну эпиграфом к какой-нибудь своей статье.

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

O>Прежде всего малым размером экзешников
MFC приложение с динамической линковкой будет еще меньше места занимать. При статич

O>и продуманным механизмом обработки сообщений.
Чем она принципиально отличается?

O>Также отмечу отсутствие всяких глупых классов-оберток вроде CServerSocket, CRecordset
O>и COleDispatchDriver.
А классы типа CRect, Cpoint и т.д. тоже глупые?

O>Кроме того, WTL куда рациональнее взаимодействует с COM, чем MFC.
Это заслуга ATL , a не WTL. Более того, имхо, написание COM клиента (не сервера) на MFC проще, чем на ATL/WTL.

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

Д>Потому и приходилось, чтобы ей пользоваться, разбираться досконально как работает каждый контрол. В какой версии шелла его ввели, в какой и как модифицировали, какие баги в нем есть. И не дай бог тебе сделать шаг влево или вправо — все отступники будут жестоко покараны
Это проблема не MFC, а WIN32 API

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

AJD>Это проблема не MFC, а WIN32 API

если MFC не скрывает проблемы Win32 от программиста — то это проблема именно MFC

Дарней wrote:

> C>Запутаной я бы тоже ее не назвал — есть определенные сложности (роутинг
> C>сообщений, система Документ-Вид), но они скорее проистекают из
> сложности
> C>решаемых задач. Ну а простые классы диалогов или окон — куда уж проще.
> напомни-ка, как там у tree view чекбоксы включаются?

Устанавливаем стиль TVS_CHECKBOXES, а используем затем макрос TreeView_SetCheckState.

Ищется абсолютно просто — открываем в MSDN Windows Shell\Windows Controls\Individual Control Reference\Tree-View Controls\Constants\Styles.

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

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

AJD>>Это проблема не MFC, а WIN32 API
Д>если MFC не скрывает проблемы Win32 от программиста — то это проблема именно MFC

Не уверен. Shell менялся позже, чем вышла MFC.

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

C>Устанавливаем стиль TVS_CHECKBOXES, а используем затем макрос TreeView_SetCheckState.

а почему нельзя в CreateEx его прописать, как все остальные стили?

C>Ищется абсолютно просто — открываем в MSDN Windows Shell\Windows Controls\Individual Control Reference\Tree-View Controls\Constants\Styles.

я знаю, как пользоваться MSDN

Дарней wrote:

> AJD>Это проблема не MFC, а WIN32 API
> если MFC не скрывает проблемы Win32 от программиста — то это проблема
> именно MFC

А зачем их скрывать? Чтобы они раскрывались в самый неподходящий момент?

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

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

AJD>Не уверен. Shell менялся позже, чем вышла MFC.

никто ведь не запрещал обновить версию MFC после этого

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

C>А зачем их скрывать? Чтобы они раскрывались в самый неподходящий момент?

значит — надо скрывать так, чтобы не раскрывались

Дарней wrote:

> C>А зачем их скрывать? Чтобы они раскрывались в самый неподходящий момент?
> значит — надо скрывать так, чтобы не раскрывались

Пока это получилось только у тех библиотек, которые полностью сами
рисуют виджеты.

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

Здравствуйте, Дарней, Вы писали:
Д>гуй — это как раз то место, где микрооптимизации не имеют ни малейшего смысла. Потому что их эффекта пользователь просто не заметит.
То-то я смотрю, что программы писанные левой пяткой, начинают дивно подмигивать и похрюкивать при банальном ресайзе формы. Одно действие, занявшее 10 мс вместо 1й, пользователь конечно не заметит. Но если у тебя перерисовка окна занимает 1с вместо 100 мс, то ресайз будет смотреться просто отвратительно.

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

S>То-то я смотрю, что программы писанные левой пяткой, начинают дивно подмигивать и похрюкивать при банальном ресайзе формы. Одно действие, занявшее 10 мс вместо 1й, пользователь конечно не заметит. Но если у тебя перерисовка окна занимает 1с вместо 100 мс, то ресайз будет смотреться просто отвратительно.

Да уж. На компьютере, который в своё время продавал Ваш тёзка, такого никогда не было! Может он был намного быстрее?

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

S>То-то я смотрю, что программы писанные левой пяткой, начинают дивно подмигивать и похрюкивать при банальном ресайзе формы. Одно действие, занявшее 10 мс вместо 1й, пользователь конечно не заметит. Но если у тебя перерисовка окна занимает 1с вместо 100 мс, то ресайз будет смотреться просто отвратительно.

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

надо просто писать программы руками, а не левой пяткой

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

Д>как правило, это связано с кривой логикой, которая обновляет то, что обновлять не нужно. и перерисовывает то, что не нуждается в перерисовке.
Д>быстродействие как таковое здесь вообще ни при чем
Не, там как правило фищка в том, что происходит решение системы уравнений методом последовательных приближений — типа "уменьшили окно->укоротили панель->изменили количество видимых записей в списке->надо пересчитать размер панели->потребовалось показать скроллер->уменьшилась видимая ширина" и т.п. И на каждом шаге происходит перерисовка, т.к. все свойства изменяются синхронно. Не последнюю роль в этом играет большое количество виртуальных и косвенных вызовов, хотя я лично не мерил потери именно на это. Теоретически, они почти ничего по сравнению с самой перерисовкой весить не должны.
Д>надо просто писать программы руками, а не левой пяткой
Гм. "Не левой пяткой" в частности, означает:
— аккуратно блокировать/разблокировать перерисовку. С учетом того, что это поддерживается далеко не всеми контролами, а теми, которыми поддерживается — поддерживается по-разному.
— Упрощать GUI, сокращая количество Panel и прочих элементов, введенных исключительно для позиционирования.

Ни то ни другое чрезмерно простой задачей не назовешь. В то же время это вовсе не пересмотр архитектуры, а всего лишь микрооптимизации.

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

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

кто-то мешает заблокировать перерисовку, пока размеры всех контролов не устаканятся?
к тому же, если при ресайзе окна сдвигаются/меняются в размере все дочерние контролы, но с дизайном этого окна явно что-то не в порядке

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

я тоже так думаю

S>Гм. "Не левой пяткой" в частности, означает:
S>- аккуратно блокировать/разблокировать перерисовку. С учетом того, что это поддерживается далеко не всеми контролами, а теми, которыми поддерживается — поддерживается по-разному.

перехватить WM_PAINT (например) и добавить там необходимую обработку — что два байта переслать

S>- Упрощать GUI, сокращая количество Panel и прочих элементов, введенных исключительно для позиционирования.

совсем необязательно (ИМХО)

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

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

Д>кто-то мешает заблокировать перерисовку, пока размеры всех контролов не устаканятся?
Для тех, кто читает по диагонали, повторю еще раз:
Вообще-то блокировка перерисовки для всех контролов делается по разному. И работает не для всех.
Д>к тому же, если при ресайзе окна сдвигаются/меняются в размере все дочерние контролы, но с дизайном этого окна явно что-то не в порядке
На жаргоне это называется "резиновый дизайн", и, вообще говоря, является очень правильной мерой. потому что другого способа корректно адаптироваться к различным размерам окна нет. Обрати внимание, что почти все встроенные диалоги стали в XP резиновыми.

Д>перехватить WM_PAINT (например) и добавить там необходимую обработку — что два байта переслать
Да ну? Попробуй подавить таким способом обновление ListView. А я посмотрю на результат. Ты думаешь, микрософт от делать нечего добавила в него специальный способ для временного подавления отрисовки?

Д>что действительно нужно:
Д>удостовериться, что если контролу назначили "новый" размер, который не отличается от старого — то он не должен делать перерисовку
Это и так делают практически все контролы.
Д>если перерисовка все-таки нужна, то перерисовывать только ту часть, которая действительно в этом нуждается.
Угу. Я боюсь тебя разочаровать, но для большинства контролов вычисление этой новой части — весьма нетривиальная задача. Особенно это касается всяких контейнеров, которые плохо себе представляют, как отреагируют их дочерние контролы на ресайз или перепозиционирование.
Д>Если соблюдать эти простые правила, то быстродействие самой перерисовки может уменьшаться хоть в тысячу раз — разницы никто не заметит.
Смешной же ты. Это и есть микрооптимизации — тщательно проверять, какие перерисовки можно безопасно поскипать. Если бы все было так просто, то накидывания контролов и выставления анкоров было бы достаточно для обеспечения скоростной перерисовки.
Бета 2005й студии, к примеру, страшно тормозила при докинге окон. А релиз все делает мгновенно. Ты что думаешь, там архитектуру поменяли? Нет, просто сели, проанализировали все узкие места, и выкинули лишние перерисовки.

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

S>Обрати внимание, что почти все встроенные диалоги стали в XP резиновыми.

обрати внимание, что у них почти все дочерние контролы не меняют своего размера при ресайзе. Как правило, меняет свой размер только один из контролов — например, дерево каталогов у диалога открытия файлов.

S>Да ну? Попробуй подавить таким способом обновление ListView. А я посмотрю на результат.

Я именно так и делал, когда была необходимость обеспечить унифицированное подавление вывода для контролов. А что, в чем проблема то? Наверно, я что-то неправильно делал, если ее не заметил

S>Ты думаешь, микрософт от делать нечего добавила в него специальный способ для временного подавления отрисовки?

микрософт вообще много странного делает
меня например удивляет, что в новой студии quickwatch напрочь потерял полосу горизонтальной прокрутки.

S>Это и так делают практически все контролы.

кроме тех, которые написаны "левой пяткой" — о чем собственно и шла речь изначально

S>Угу. Я боюсь тебя разочаровать, но для большинства контролов вычисление этой новой части — весьма нетривиальная задача. Особенно это касается всяких контейнеров, которые плохо себе представляют, как отреагируют их дочерние контролы на ресайз или перепозиционирование.

на всякий случай уточню — см. ниже

S>Смешной же ты.

может быть, обойдемся без перехода на личности?

S>Это и есть микрооптимизации — тщательно проверять, какие перерисовки можно безопасно поскипать. Если бы все было так просто, то накидывания контролов и выставления анкоров было бы достаточно для обеспечения скоростной перерисовки.
S>Бета 2005й студии, к примеру, страшно тормозила при докинге окон. А релиз все делает мгновенно. Ты что думаешь, там архитектуру поменяли?

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

Дарней wrote:

> S>Гм. "Не левой пяткой" в частности, означает:
> S>- аккуратно блокировать/разблокировать перерисовку. С учетом того,
> что это поддерживается далеко не всеми контролами, а теми, которыми
> поддерживается — поддерживается по-разному.
> перехватить WM_PAINT (например) и добавить там необходимую обработку —
> что два байта переслать

А кто даст ее перехватить? WM_PAINT приходит непосредственно элементам
управления, а не окну, и чтобы его перехватить нужно сабклассить
контролы. А это куча проблем с двойным сабклассингом и т.п.

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

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

C>А кто даст ее перехватить? WM_PAINT приходит непосредственно элементам
C>управления, а не окну, и чтобы его перехватить нужно сабклассить
C>контролы. А это куча проблем с двойным сабклассингом и т.п.

неудачный пример я привел с WM_PAINT . не то чтобы это так уж геморройно — просто на самом деле не нужно
если использовать библиотеку классов, то обычно достаточно просто оверрайдить OnPaint или его аналог

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

O> Непонятным остается одно.
O>Почему, например, при разработке
O>прогаммного комплекса наподобие filemon или regmon я не могу для написания
O>управляющей части использовать BCB и VCL без риска быть обвиненным в
O>профнепригодности.
Ну вы вроде бы уже взрослый, может не стоить их слушать.
А причина почему Русинович в конкретном случае писал на чистом АПИ всего одна, у его утилит нет никаких зависимостей от остальных библиотек и они у него получились очень маленькие и я ему за это очень благодарен, вот почему его filemon и regmon пользуют столько людей, а всякие красивые цацки которые местами лучше не имеют спроса. Простенькая обёртка над WinAPI делается за час-два.

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

Мой ответ "серебряной пули" не существует. Зайдите на форум shareware и спросите почему очень многие их них пишут на чистом апи или MFC думаю они вам достаточно аргументировано ответят, хотя почитав историю форума вы и сами всё поймёте. Если вам приятнее на писать на VCL и ограничения проэкта это позволяют,
то почему бы нет. Меня VCL не устаривает потому что мне слишком сложно делать вещи которые выходят за рамки их готовой архитектуры.
O>Но я допускаю, что в чем-то могу ошибаться. Посему хотел бы услышать разумные доводы в пользу применения вышеприведенных инструментов.
Демонстрацию собственной крутизны можно делать только в свободное от работы время, а роботодатель поверьте мне проверит чтобы вы не занимальсь фигнёй в рабочее время. Я не пользуюся WTL(ну достали они меня, то ли я такой везучий, но постоянно скачиваю от них релизы где даже ихние демки не компилятся), но я пишу иногда на MFC и чаще на чистом WinAPI, что я получаю отстутствие зависимостей от сторонних компонент, плюс малые размеры исполняемого файла.

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

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

CC>Здравствуйте, Глеб Алексеев, Вы писали:

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

O>>>Хорошо, но для этого я должен использовать VC 2003
O>>>вместо более компактного и менее тяжеловесного VC6.
ГА>>И что такого тяжеловесного в VC 2003? Нормальный компилятор ?
CC>Не компилятор а сама среда.
CC>В сравнении с VS6 VS2003 периодически еле ползает. P4 640 + 1G DDR2. Только не говорите что мало...
Ну єто у вас батенька что-то с компом, я проєкты под ACE на Duron 600 + 512 SDRAM в VC2003 + VAssist.NET нормально собирал, и тормозов чесно говоря не имел, при том что по удобству оно значительно лучше шестьорки. Хотя 6-ая лествительно запускается быстрее, но редактирование, запуск мастеров, клас броузер в VC2003 у меня было на скорости более чем достаточной для нормальной работы.
Правда полная перекомпиляция библиотеки занимала около 40 минут

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

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

Ну, в общем, не стоит сваливать в одну кучу коня и трепетную лань, то бишь API и библиотеки.

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

А очень просто. Не все программы требуют шибко развитого пользовательского интерфейса. Порой интерфейс ограничивается простеньким диалогом настроек. И всё. И нафига в такую программу тянуть под сотню килобайт кода, который нагенерится библиотеками — не понятно. Гораздо проще написать собственную WinProc и вуаля.

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

Вот так вот, или примерно так.

Здравствуйте, Дарней, Вы писали:
Д>неудачный пример я привел с WM_PAINT . не то чтобы это так уж геморройно — просто на самом деле не нужно
Д>если использовать библиотеку классов, то обычно достаточно просто оверрайдить OnPaint или его аналог
Мне это нравится. Начали мы с утверждения, что "в GUI оптимизировать нечего". А закончили тем, что добавили "... если использовать библиотеку классов, в которой можно перегрузить OnPaint". Очень, знаете ли, кашу из топора напоминает. Тоже вроде ничего и не надо. Если всё добавить.

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

S>Мне это нравится. Начали мы с утверждения, что "в GUI оптимизировать нечего". А закончили тем, что добавили "... если использовать библиотеку классов, в которой можно перегрузить OnPaint". Очень, знаете ли, кашу из топора напоминает. Тоже вроде ничего и не надо. Если всё добавить.

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

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

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

S>>Мне это нравится. Начали мы с утверждения, что "в GUI оптимизировать нечего". А закончили тем, что добавили "... если использовать библиотеку классов, в которой можно перегрузить OnPaint". Очень, знаете ли, кашу из топора напоминает. Тоже вроде ничего и не надо. Если всё добавить.

Д>бррр, ничего не понял
Д>надеюсь, ты следил за ходом нашей беседы?
Да. А ты? Смотрим сюда

Автор: Дарней
Дата: 25.11.05

:

гуй — это как раз то место, где микрооптимизации не имеют ни малейшего смысла. Потому что их эффекта пользователь просто не заметит.

Д>так или иначе, но задача вполне решаема. Другой вопрос — что нередко можно и без этого обойтись, если просто сделать ресайз без перерисовки контролов на каждый чих.
Еще раз: никто не говорит, что задача не решаема. Речь идет о том, что при использовании готовой библиотеки почему-то нужна доработка напильником. Т.е. те самые микрооптимизации, которые якобы не имеют ни малейшего смысла. Тем более, если мы заговорили о перехвате WM_PAINT — вот мы и уперлись в переход к WinAPI для оптимизации. Причем предлагаешь это ты, забыв о том, что говорил тремя постами выше.

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

C>Пока это получилось только у тех библиотек, которые полностью сами
C>рисуют виджеты.

да, ты прав
и у меня все сильнее крепнет уверенность, что в среде Win32 это — наименее корявый путь

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

S>Еще раз: никто не говорит, что задача не решаема. Речь идет о том, что при использовании готовой библиотеки почему-то нужна доработка напильником. Т.е. те самые микрооптимизации, которые якобы не имеют ни малейшего смысла. Тем более, если мы заговорили о перехвате WM_PAINT — вот мы и уперлись в переход к WinAPI для оптимизации. Причем предлагаешь это ты, забыв о том, что говорил тремя постами выше.

Доработка библиотеки с целью добавить новую функциональность — это микрооптимизации? "Ну уж извините!" (С)
добавить для каждого контрола функцию, которая будет возвращать список подходящих для него размеров — это тоже микрооптимизация?

а WM_PAINT в качестве примера я привел неудачно — про это я сам написал, не так ли?
я вообще не понимаю, к чему спор об этой мелочи.
Ты сначала сказал:

Да ну? Попробуй подавить таким способом обновление ListView. А я посмотрю на результат.

Микрооптимизация это или нет — вообще дело десятое.

Давай не будем отклоняться от темы, ок?

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

Д>а WM_PAINT в качестве примера я привел неудачно — про это я сам написал, не так ли?
Д>я вообще не понимаю, к чему спор об этой мелочи.
Д>Ты сначала сказал:
Д>

Д>Да ну? Попробуй подавить таким способом обновление ListView. А я посмотрю на результат.

Ок, я был неправ. Мне казалось, что в подавлении перерисовки ListView без использования WM_SETREDRAW делать нечего. И, насколько я помню, этот мессадж работал не для всех контролов, так что приходилось делать LockWindowUpdate. И он тоже глючил в разных ситуациях. Но это все было лет шесть назад, поэтому я мог забыть подробности или просто глючить тогда по неопытности.
Д>Давай не будем отклоняться от темы, ок?
Давай. Вопрос был в том — зачем писать на голом WinGUI. Ты стал критиковать аргументы "для производительности", утверждая, что оптимизация гуя вообще не нужна. Ок, вполне возможно, что есть способ написать враппер на WinGUI, который не будет давать просада в производительности. Хотя мой опыт указывает обратное — я в основном работал с VCL, и без оптимизации результат был удручающим. И причем как правило оптимизация заключалась не столько в дописывании библиотеки, сколько в правке пользовательского кода, который с ней работал — именно в вызове в нужных местах BeginUpdate/EndUpdate, в выкидывании лишних панелей, в отказе от автопозиционирования и ручной установке размеров всех детей пачкой и т.п.

А в общем, хочу отметить, что практически любая оптимизация — это выкидывание лишних действий. С этой точки зрения, твоя позиция несколько противоречива — ты считаешь, что в ГУИ не надо ничего оптимизировать, а достаточно просто не выполнять лишних перерисовок. Ок, в проектировании баз данных не надо ничего оптимизировать — надо просто избегать лишних table scan; в проектировании бизнес логики не надо ничего оптимизировать — достаточно не выполнять лишних обращений к серверу; да и в математике не надо оптимизировать сортировку — достаточно не делать лишних сравнений и перестановок.

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

S>Ок, я был неправ. Мне казалось, что в подавлении перерисовки ListView без использования WM_SETREDRAW делать нечего. И, насколько я помню, этот мессадж работал не для всех контролов, так что приходилось делать LockWindowUpdate. И он тоже глючил в разных ситуациях. Но это все было лет шесть назад, поэтому я мог забыть подробности или просто глючить тогда по неопытности.

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

S>Давай. Вопрос был в том — зачем писать на голом WinGUI. Ты стал критиковать аргументы "для производительности", утверждая, что оптимизация гуя вообще не нужна. Ок, вполне возможно, что есть способ написать враппер на WinGUI, который не будет давать просада в производительности. Хотя мой опыт указывает обратное — я в основном работал с VCL, и без оптимизации результат был удручающим. И причем как правило оптимизация заключалась не столько в дописывании библиотеки, сколько в правке пользовательского кода, который с ней работал — именно в вызове в нужных местах BeginUpdate/EndUpdate, в выкидывании лишних панелей, в отказе от автопозиционирования и ручной установке размеров всех детей пачкой и т.п.

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

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

Д>это объясняется скорее общей корявостью VCL, я думаю.
Д>что я пытался объяснить — с помощью микрооптимизаций можно скрыть кривизну общей архитектуры и добиться приемлемой производительности. Но лучше просто не делать архитектуру кривой, и тогда все эти танцы с бубном будут просто не нужны
Д>Если существующая архитектура при каждом изменении размера окна вызывает множественные изменения размеров вложенных контролов, да еще и с перерисовкой на каждый чих — то эта архитектура просто ни к черту не годится.
Это не архитектура. Это всего лишь реализация отображения. Архитектура редко заморачивается такими понятиями, как ресайз и перерисовка. Да, если мы работаем с CAD системой, то для скоростной отрисовки потребуется поддержка отсечения по viewport на уровне Model, а не View. Однако CAD системы пишутся редко. А вот формочки с большим количеством контролов — сплошь и рядом. И вот в них архитектура никакого отношения к ресайзу не имеет. Архитектурные оптимизации скорее относятся к кэшированию содержимого drop-down во избежание лишних обращений к серверу. А ГУИ приходится оптимизировать. Вот ты, кстати, в курсе, что время перерисовки Progress Bar линейно падает с увеличением его прогресса? Это означает, что частый вызов PBM_SETPOS приводит к тормозам, даже если видимое положение прогресса не изменяется из-за того, что PBM_SETRANGE32 установил ему пределы много больше, чем ширина в пикселах. И что? Архитектуру менять? Или сабклассить его так, чтобы он перерисовывал только дельту?
Я тебе еще пример приведу — вот та же студия 2005. Обрати внимание, как сделан докинг. Ты думаешь, пользователь не заметит оптимизаций подкраски места назначения? Очень сомневаюсь.

Опять же, гуи бывает разный. Если бы мы спросили у разработчика семидесятых, стоит ли оптимизировать пользовательский интерфейс, он бы посмеялся — че там оптимизировать? Вывод четырех строчек на терминал все равно быстрее не сделаешь, да и редкий пользователь успеет давить кнопки так быстро.

В середине девяностых для показа содержимого окна в процессе его перемещения (какой там ресайз!) надо было ставить специальный пакет в винду. Потому что по дефолту это считалось безнадежно дорогой операцией.

В 2000 году мы увидели встроенный hover — перерисовку контролов в ответ на пролет над ними мыщки. Немыслимо! Это ж сколько лишних перерисовок! Тогда же появилась некоторая прозрачность.

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

Теперь вернемся к нашим баранам.
С одной стороны, библиотека может поднимать скорость работы благодаря всяким умным вещам — типа копирования фрагмента окна для перерисовки только того, что на самом деле изменилось. С другой стороны, библиотеки привносят накладные расходы "на абстрактность". Сами по себе эти накладные расходы не так уж велики. Зато могут оказаться тяжелыми расходы на то, чтобы стричь всех под одну гребенку. Вот к примеру та же VCL — почему она не подавляет перерисовку всех контролов на форме на время выполнения Align/Layout? Там же жутко сложный код выполняется, и в том числе множественные перерисовки. Ладно, спишем на фатальную некомпетентность инженеров Борланд и необходимость тащить совместимость с версией VCL 2.0. Покажите мне general-purpose библиотеку, которая подавляет обновление дочерних контролов при обработке ресайза. Я хочу узнать, как можно делать платформу, позволяющую просто накидывать GUI и не заботиться об его оптимизации. (HTML не предлагать).

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

S>Это не архитектура. Это всего лишь реализация отображения. Архитектура редко заморачивается такими понятиями, как ресайз и перерисовка.

Я так думаю, для оконной библиотеки управление layout'ами — это один из ключевых элементов архитектуры.

S>С одной стороны, библиотека может поднимать скорость работы благодаря всяким умным вещам — типа копирования фрагмента окна для перерисовки только того, что на самом деле изменилось. С другой стороны, библиотеки привносят накладные расходы "на абстрактность". Сами по себе эти накладные расходы не так уж велики. Зато могут оказаться тяжелыми расходы на то, чтобы стричь всех под одну гребенку. Вот к примеру та же VCL — почему она не подавляет перерисовку всех контролов на форме на время выполнения Align/Layout? Там же жутко сложный код выполняется, и в том числе множественные перерисовки. Ладно, спишем на фатальную некомпетентность инженеров Борланд и необходимость тащить совместимость с версией VCL 2.0.

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

S>Покажите мне general-purpose библиотеку, которая подавляет обновление дочерних контролов при обработке ресайза. Я хочу узнать, как можно делать платформу, позволяющую просто накидывать GUI и не заботиться об его оптимизации. (HTML не предлагать).

а почему не предлагать, собственно?
могу еще посоветовать Qt, например — сделано вроде бы очень грамотно. Хотя я его знаю не очень детально, так что могу и ошибаться.

Дарней,

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

Ага, яркий пример действий компетентных инженеров.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Ага, яркий пример действий компетентных инженеров.

это вопрос компетентности менеджмента, а не инженеров
к тому же у всех перед глазами пример М$, который доминирует на рынке, регулярно выдавая кривые продукты

Дарней,

> ПК> Ага, яркий пример действий компетентных инженеров.

> это вопрос компетентности менеджмента, а не инженеров

Менеджеры должны принимать технические решения?..

> к тому же у всех перед глазами пример М$, который доминирует на рынке, регулярно выдавая кривые продукты

"Кривые" в сравнении с чем?

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Менеджеры должны принимать технические решения?..

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

ПК>"Кривые" в сравнении с чем?

Кривые, просто кривые (С) Безотносительно к чему-либо.

Дарней,

> ПК> Менеджеры должны принимать технические решения?..
>
> менеджеры говорят "мы выпускаем продукт вот к этому сроку! кто сказал — нужно в три раза больше времени? упал-отжался!"

Вот такие вот оторванные от реальностей этого мира менеджеры... Не интересуются у инженеров, сколько реально времени нужно на разработку, а просто так берут, и говорят: "вот к этому сроку!". Тяжело, наверное, в таких условиях инженерам работать?

> ПК>"Кривые" в сравнении с чем?
>
> Кривые, просто кривые (С) Безотносительно к чему-либо.

И продукты просто кривые, а не относительно конкурирующих вариантов. Тяжело, наверное, в таких условиях менеджерам работать?

Здравствуйте, Павел Кузнецов, Вы писали:

<skipped>
честное слово, не понимаю, чем вызван этот глумливый тон

Дарней,

> честное слово, не понимаю, чем вызван этот глумливый тон

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

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Извини, у меня такую реакцию вызвало сочетание в одном сообщении утверждения о грамотности инженеров с перечислением целого ряда заведомо неэффективных [полу]технических решений. Последовавшее описание картины того, как менеджеры принимают данные решения без согласования с инженерами реалистичности сроков разработки и т.п. усугубило произведенный эффект.

тимлидер разве не инженер?
что касается сроков разработки — я насмотрелся на большое количество примеров, когда сроки урезали из политических или экономических соображений. Случаи, когда на разработку выделяется необходимое количество времени — это скорее исключение, чем правило.
К тому же, поскольку мы говорим о VCL, позволю себе напомнить — на момент, когда разрабатывался Дельфи, Борланд находился в глубочайшей финансовой заднице.

Здравствуйте, Дарней, Вы писали:
Д>К тому же, поскольку мы говорим о VCL, позволю себе напомнить — на момент, когда разрабатывался Дельфи, Борланд находился в глубочайшей финансовой заднице.
Все десять лет? Я с VCL плотно работал с 3й по 6ю версию, с 7й эпизодически.

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

S>Все десять лет? Я с VCL плотно работал с 3й по 6ю версию, с 7й эпизодически.

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

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

Д>что касается сроков разработки — я насмотрелся на большое количество примеров, когда сроки урезали из политических или экономических соображений. Случаи, когда на разработку выделяется необходимое количество времени — это скорее исключение, чем правило.

Свежий пример. Microsoft выпускает сырую версию XBox360 с кучей багов только для того, чтобы иметь преимущество в полгода перед Sony PlayStation3 (Sony только недавно заявило о переносе выхода SP3 на конец года). Кроме того им необходимо было выпуститься до рождества, чтобы получить высокие продажи на праздники.

Дарней,

> ПК>Извини, у меня такую реакцию вызвало сочетание в одном сообщении утверждения о грамотности инженеров с перечислением целого ряда заведомо неэффективных [полу]технических решений. Последовавшее описание картины того, как менеджеры принимают данные решения без согласования с инженерами реалистичности сроков разработки и т.п. усугубило произведенный эффект.

> тимлидер разве не инженер?

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

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

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

AndrewJD,

> Д> что касается сроков разработки — я насмотрелся на большое количество примеров, когда сроки урезали из политических или экономических соображений <...>

> Свежий пример. Microsoft выпускает сырую версию XBox360 с кучей багов только для того <...>

Ага, хороший пример. Напомни-ка мне, пожалуйста, когда его планировали выпустить изначально? Т.е. на сколько "сократился" срок разработки в результате?

Здравствуйте, Павел Кузнецов, Вы писали:

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

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

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Ага, хороший пример. Напомни-ка мне, пожалуйста, когда его планировали выпустить изначально? Т.е. на сколько "сократился" срок разработки в результате?

К сожелалению эта информация не доступна. Все знают когда менеждеры планировали выпустить. По-видимому сроки были не реальные

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

Д>нет, на момент разработки первой версии. А дальше уже приходилось думать о совместимости.
Д>Во всяком случае, я объясняю этот факт для себя таким образом.
Д>Если у кого-то есть идеи получше — буду рад услышать
Идей нет, но о борландовской совместимости лучше не заикаться. За одно это расстреливать надо.

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

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

> ...BEGIN_MSG_MAP(CBackupDlg)...

Вообще-то это примеры ATL/MFC. Так что ты скорее говоришь не о WinAPI vs. VCL/WinForms, а о КОП vs. сэкс на С++.

Попробую не вдаваясь во флэйм предложить варианты того почему и зачем пишут на том или ином.

1. Голимый ВыньАПИ (ну, или разные GTK) используется обычно в очень простых случаях, ну например: а) для игрушки нужно окошко создать, б) в коде рассчитанных на компиляцию на разных компиляторах.
2. ATL/WTL. Лично сам использовал чтобы на трахаясь как в случае голого ВыньАПИ получить лехковесные С++-приложения и библиотеки. Эти библиотеки позволяют уменьшить размер исполняемых файлов до едениц килобайтов. Так же ATL/WTL выбирают С-шники знающие ВыньАПИ но не хотящие трахаться с ним и при этом не хотящие изучать разные запутанные библиотеки вроде МФЦ.
3. MFC. Используется в основном теми кто эту библиотеку уже давно и хорошо знает. В принципе — это самый простой способ создать оконное приложение на VC++. Все же ATL/WTL куда более ограничены и приводят к большему траху. Хотя конечно намного больше зависит от степени знакомства с библиотеками. Собственно суда же можно, наверно, отнести так же и QT.
4. VCL/WinForms/SWING используется теми кто понимает толк в компонентрой разработке, ну и морем начинающих для которых эти библиотеки упрощают вхождение в мир програмирования.

Лично я считаю, что единствено разумный выбор на сегодня это именно компонентные библиотеки. VCL вряд ли можно назвать перспективной, а вот WinForms и SWING очень даже. Продуманный дизайн, довольно добротное исполнение, хорошая поддержка, очень хорошая инкапсуляция, простота расшериея, поддержка визуальных дизайнеров и сред разработки. В общем, хайтек одним словом. Единственное что может сподвигнуть к выбору других вариантов — это нежелание связываться с рантаймами дотнета и Явы.

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

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

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

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

Ой, а можно цитату? А то в твоем изложении это выглядит как бред после передозировки.

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

C>Запутаной я бы тоже ее не назвал — есть определенные сложности (роутинг
C>сообщений, система Документ-Вид), но они скорее проистекают из сложности
C>решаемых задач. Ну а простые классы диалогов или окон — куда уж проще.

Во как? Сложности задач? Я плякаль. А что же на тех же VB, Delphi, C# эти сложности в упор не видны?

Ты про инкапсуляцию и компонетный подход слышал? Может это как раз то что нехватает MFC, WTL и другим С++-ным библиотекам?

C>Я сейчас как раз заканчиваю сложное приложение на MFC, использующее OLE
C>2 и COM на полную катушку — так я до сих пор поражаюсь простоте
C>использования MFC для решения сложных проблем.

Бло бы забавно если бы ты использовал OLE 2 бзе COM.
А вообще я поражаюсь как люди умудряются радоваться от того, что тратят 80% своего времени на трах с хтими достисторическими технологиями. Мир давно стал проще.

C>Что значит "писать GUI"? Бросать кнопочки на формочки? Так простите, это
C>далеко не "писать GUI". Писать GUI — это например:
C>http://www.elewise.ru/portfolio/software/oda.html (скриншоты первой
C>версии, сейчас все еще красивее) или http://www.bcgsoft.com/

Вот представь себе, что все тоже самое, доступно от доброго десятка производителей в виде контролов.
Можешь на досуге погуглить на тему .net controls.

В общем, если уж седиш в прошлом веке, то хоть не рекламируй его. А то ведь смешно.

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

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

>> ...BEGIN_MSG_MAP(CBackupDlg)...

VD>Вообще-то это примеры ATL/MFC. Так что ты скорее говоришь не о WinAPI vs. VCL/WinForms, а о КОП vs. сэкс на С++.

VD>Попробую не вдаваясь во флэйм предложить варианты того почему и зачем пишут на том или ином.

VD>1. Голимый ВыньАПИ (ну, или разные GTK) используется обычно в очень простых случаях, ну например: а) для игрушки нужно окошко создать, б) в коде рассчитанных на компиляцию на разных компиляторах.
VD>2. ATL/WTL. Лично сам использовал чтобы на трахаясь как в случае голого ВыньАПИ получить лехковесные С++-приложения и библиотеки. Эти библиотеки позволяют уменьшить размер исполняемых файлов до едениц килобайтов. Так же ATL/WTL выбирают С-шники знающие ВыньАПИ но не хотящие трахаться с ним и при этом не хотящие изучать разные запутанные библиотеки вроде МФЦ.
VD>3. MFC. Используется в основном теми кто эту библиотеку уже давно и хорошо знает. В принципе — это самый простой способ создать оконное приложение на VC++. Все же ATL/WTL куда более ограничены и приводят к большему траху. Хотя конечно намного больше зависит от степени знакомства с библиотеками. Собственно суда же можно, наверно, отнести так же и QT.
VD>4. VCL/WinForms/SWING используется теми кто понимает толк в компонентрой разработке, ну и морем начинающих для которых эти библиотеки упрощают вхождение в мир програмирования.

VD>Лично я считаю, что единствено разумный выбор на сегодня это именно компонентные библиотеки. VCL вряд ли можно назвать перспективной, а вот WinForms и SWING очень даже. Продуманный дизайн, довольно добротное исполнение, хорошая поддержка, очень хорошая инкапсуляция, простота расшериея, поддержка визуальных дизайнеров и сред разработки. В общем, хайтек одним словом. Единственное что может сподвигнуть к выбору других вариантов — это нежелание связываться с рантаймами дотнета и Явы.

Что касается WinForms, то их использование предполагает программирование на VB.NET/C#,
которые хороши для прикладников, но не для системщиков. Чем хороша VCL, это тем, что
я могу визуально проектировать GUI и одновременно вызывать любую WinAPI без переходников,
включая Native WinNT API. Если брать WTL, то неоспоримым преимуществом является малый размер бинарника и прозрачность архитектуры. В отношении MFC могу сказать, что это
то ли недоделанная VCL, то ли перекачанная WTL. Одним словом, MFC использовать в чистом виде нет смысла.
С расширением MFC BCG немного знаком. Впечатления хорошие, но опять же, этот фреймворк
рассчитан на прикладников.

P.S. Еще один аргумент в пользу VC и WTL. К сожалению, такие Open Source библиотеки как
PGP SDK и OW32 без лишней головной боли можно юзать только под VC. Но GUI под них лучше писать на легковесной и продуменной WTL, чем на старой дурноватой MFC.

VladD2 wrote:

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

Swing — это вообще мой любимый GUI, архитектура там самая лучшая из
всех, что я видел. Только вот Sun его как-то совсем не развивает, он
фактически остался на уровне 2002 года. Вместо того, чтобы выкинуть
#%&^$( AWT и переписать Swing _нормально_, они до сих пор занимаются
эмуляцией Windows GUI.

WinForms мне не очень нравятся архитектурно — там нет полноценного MVC.
Хотя layout'ы уже добавили

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

VladD2 wrote:

> C>Запутаной я бы тоже ее не назвал — есть определенные сложности (роутинг
> C>сообщений, система Документ-Вид), но они скорее проистекают из
> сложности
> C>решаемых задач. Ну а простые классы диалогов или окон — куда уж проще.
> Во как? Сложности задач? Я плякаль. А что же на тех же VB, Delphi, C#
> эти сложности в упор не видны?

А они эти задачи не решают В MFC очень легко сделать OLE-приложение,
которое будет работать в виде embedded-фрэйма в Word'е или в виде
отдельного приложения. А еще есть всякие фичи типа предварительного
просмотра документов, drag&drop, интеграции в shell и т.п.

Поверьте, я пытался сделать тоже самое на ATL/WTL. Через месяц бросил —
нужно было писать оооочень много всего.

> Ты про инкапсуляцию и компонетный подход слышал? Может это как раз то
> что нехватает MFC, WTL и другим С++-ным библиотекам?

Ну WTL неплохо и так сделан, там очень удобно использовать компоненты.
MFC это бы не помешало, но ей можно простить в силу преклонного возраста

> C>Я сейчас как раз заканчиваю сложное приложение на MFC, использующее OLE
> C>2 и COM на полную катушку — так я до сих пор поражаюсь простоте
> C>использования MFC для решения сложных проблем.
> Бло бы забавно если бы ты использовал OLE 2 бзе COM.

Просто под COM я имею в виду не только сам OLE, а еще и обычный COM и DCOM.

> А вообще я поражаюсь как люди умудряются радоваться от того, что
> тратят 80% своего времени на трах с хтими достисторическими
> технологиями. Мир давно стал проще.

Ага, и как в этом простом мире сделать так, чтобы в документ Word'а
можно было вставить мой объект? Вообще убил бы MS, за 6 лет так и не
удосужилсь сделать замену для OLE2, хотя сами используют его на полную
катушку.

> В общем, если уж седиш в прошлом веке, то хоть не рекламируй его. А то
> ведь смешно.

Это ответ на рекламу VCL из прошлого века

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

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

C>Поверьте, я пытался сделать тоже самое на ATL/WTL. Через месяц бросил —
C>нужно было писать оооочень много всего.

Я все это делал на ATL. Может встраеваемый догумент и проще сделать на МФЦ, но при шаге в право в лево начинашь жалеть, что с ним связался.

>> Ты про инкапсуляцию и компонетный подход слышал? Может это как раз то
>> что нехватает MFC, WTL и другим С++-ным библиотекам?

C>Ну WTL неплохо и так сделан, там очень удобно использовать компоненты.

Да, удобствно еще то.

C>MFC это бы не помешало, но ей можно простить в силу преклонного возраста

Жлабэйсик по страше будет, но что-то у него таких проблем нет.

C>Ага, и как в этом простом мире сделать так, чтобы в документ Word'а
C>можно было вставить мой объект?

Бросить контрол на форму. Например, прекрасно работает контрол банального IE.

C> Вообще убил бы MS, за 6 лет так и не
C>удосужилсь сделать замену для OLE2, хотя сами используют его на полную
C>катушку.

Ну, в управляемых средах ничего и делать не нужно. Есть сборки, есть контролы, есть дизайнеры. В общем, все есть. Осталось только чтобы все прилоежения стали управляемыми и предоставляли своей функционал в виде контрола.

>> В общем, если уж седиш в прошлом веке, то хоть не рекламируй его. А то
>> ведь смешно.

C>Это ответ на рекламу VCL из прошлого века

Ну, все же VCL хоть компонентный фрэйворк. Хотя конечно явно устаревший. Ну, да сам Борланд давно понял откуда ветер дует. Это просто его поклонники долго раскачиваются.

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

O>Что касается WinForms, то их использование предполагает программирование на VB.NET/C#,
O>которые хороши для прикладников, но не для системщиков.

Во, как. Дискоссию о Синкулярити читал?
Ну, да ладно. Ответь на несколько вопросов.
Какой смысл ты вкладываешь в термин "системщик" и "системное программирование"?
Считаеш ли ты сам себя системщиком?
Что мешает создавть программы с использованием WinForms на Delphi или C++?
Какие системные вещи созданы на Дельфи или Билдере с применением VCL?

O>Чем хороша VCL, это тем, что
O>я могу визуально проектировать GUI и одновременно вызывать любую WinAPI без переходников,
O>включая Native WinNT API.

А в чем, по-твоему, заключается трудность с вызовом любых WinAPI-функций из управляемых языков?

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

C>Swing — это вообще мой любимый GUI, архитектура там самая лучшая из
C>всех, что я видел. Только вот Sun его как-то совсем не развивает, он
C>фактически остался на уровне 2002 года. Вместо того, чтобы выкинуть
C>#%&^$( AWT и переписать Swing _нормально_, они до сих пор занимаются
C>эмуляцией Windows GUI.

Согасен, что архитектурно Свинг неплох, но реализован хреновенько.

C>WinForms мне не очень нравятся архитектурно — там нет полноценного MVC.
C>Хотя layout'ы уже добавили

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

ЗЫ

В любом, случаи это куда лучше чем МФЦ, ВТЛ и ГДИ вместе взятые.

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

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

O>>Что касается WinForms, то их использование предполагает программирование на VB.NET/C#,
O>>которые хороши для прикладников, но не для системщиков.

VD>Во, как. Дискоссию о Синкулярити читал?
VD>Ну, да ладно. Ответь на несколько вопросов.
VD>Какой смысл ты вкладываешь в термин "системщик" и "системное программирование"?

В термин системное программирование применительно к Винде вкладываю такой смысл:
— программирование драйверов устройств и драйверов файловых систем;
— программирование системных сервисов;
— программирование утилит, реализующих доступ к драйверам посредством таких WinAPI,
как ReadFile, WriteFile и DeviceIoControl;
— работа с системой безопасности Винды на уровне чистого WinAPI (SetFileSecurity,
LsaAddAcountRights, AdjustTokenPrivileges и т.д.);
— работа с CryptoAPI и SmartCardAPI на чистом API;
— использование различных низкоуровневых библиотек (ASPI SDK, PGP SDK, OW32)
для работы с железом, системой, атакже подсистемами безопасности и криптозащиты.

VD>Считаеш ли ты сам себя системщиком?
VD>Что мешает создавть программы с использованием WinForms на Delphi или C++?

Большое количество P-Invoke существоенно снижает быстродействие, к тому же
хваленный .NET Framework есть ни что иное, как COM-сервер (см. 4-е издание книги
Соломона и Русиновича) и так или иначе обращается к низкоуровневому API.

VD>Какие системные вещи созданы на Дельфи или Билдере с применением VCL?

Системщики избегают данных платформ исключительно из стереотипных соображений.
Известно, что Delphi и С++ Builder поддерживают Platform SDK в полном объеме.
Более того, ассемблер от Борланд на порядок круче мелкософтного.
Единственным препятствием, буть может, является отсутствие опций тонкой настройки
компилятора и компоновщика, но в BCB 2006, насколько мне известно, эту проблему решили.

O>>Чем хороша VCL, это тем, что
O>>я могу визуально проектировать GUI и одновременно вызывать любую WinAPI без переходников,
O>>включая Native WinNT API.

VD>А в чем, по-твоему, заключается трудность с вызовом любых WinAPI-функций из управляемых языков?

Частые переходы managed/unmanaged негативно сказываются на быстродействии и приводят
к путанице в чтении такого кода.

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

O>Известно, что Delphi и С++ Builder поддерживают Platform SDK в полном объеме.


А почему тогда на форумах разработчики на Delphi постоянно спрашивают где взять описания какой-нибудь структуры или константы?

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

O>Известно, что Delphi и С++ Builder поддерживают Platform SDK в полном объеме.

и где лежит текущий PSDK (win 2003 sp1) для delphi?

VladD2 wrote:

> C>Поверьте, я пытался сделать тоже самое на ATL/WTL. Через месяц бросил —
> C>нужно было писать оооочень много всего.
> Я все это делал на ATL. Может встраеваемый догумент и проще сделать на
> МФЦ, но при шаге в право в лево начинашь жалеть, что с ним связался.

Да, есть такая проблема. Хотя MFC достаточно гибкая — обычно можно
переписать проблемные функции в MFC

> C>MFC это бы не помешало, но ей можно простить в силу преклонного
> возраста
> Жлабэйсик по страше будет, но что-то у него таких проблем нет.

Ну как бы и встраиваемые документы на нем не делают Вообще, MFC
следовало бы назвать MEF (Microsoft Editors Framework) — так как она
ориентированая на создание разных редакторов. Это у нее получается очень
неплохо, а вот все остальное....

> C>Ага, и как в этом простом мире сделать так, чтобы в документ Word'а
> C>можно было вставить мой объект?
> Бросить контрол на форму. Например, прекрасно работает контрол
> банального IE.

Нет, вы не поняли. Чтобы _мое_ приложение работало внутри документа
Word'а. Наоборот каждый дурак умеет

> C> Вообще убил бы MS, за 6 лет так и не
> C>удосужилсь сделать замену для OLE2, хотя сами используют его на полную
> C>катушку.
> Ну, в управляемых средах ничего и делать не нужно. Есть сборки, есть
> контролы, есть дизайнеры. В общем, все есть. Осталось только чтобы все
> прилоежения стали управляемыми и предоставляли своей функционал в виде
> контрола.

Нет. Придется все равно делать Compound Documents, протоколы
согласования менюшек/тулбаров и размеров окон, трансляцию акселераторов
и т.п.

В общем получится то, что сейчас есть, но managed. Это было бы удобнее,
но в МС не хотят переделывать то, что и так работает.

> C>Это ответ на рекламу VCL из прошлого века
> Ну, все же VCL хоть компонентный фрэйворк. Хотя конечно явно
> устаревший. Ну, да сам Борланд давно понял откуда ветер дует. Это
> просто его поклонники долго раскачиваются.

Ага.

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

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


OE>и где лежит текущий PSDK (win 2003 sp1) для delphi?
здесь

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

VD>>Какой смысл ты вкладываешь в термин "системщик" и "системное программирование"?

O>В термин системное программирование применительно к Винде вкладываю такой смысл:
O>- программирование драйверов устройств и драйверов файловых систем;

Тут я с тобой соглашусь. Действительно создание драйвера явно задача для системного программиста.
И это единственная из перечисленных задачь которую пока что нельзя решить на управляемом языке вроде Шарпа. Почему "пока что"? Да на горизонте уже маячит Синкулярити гди и это уже возможно.

Ну, а все это:
O>- программирование системных сервисов;
O>- программирование утилит, реализующих доступ к драйверам посредством таких WinAPI,
O>как ReadFile, WriteFile и DeviceIoControl;
O>- работа с системой безопасности Винды на уровне чистого WinAPI (SetFileSecurity,
O>LsaAddAcountRights, AdjustTokenPrivileges и т.д.);
O>- работа с CryptoAPI и SmartCardAPI на чистом API;
O>- использование различных низкоуровневых библиотек (ASPI SDK, PGP SDK, OW32)
O>для работы с железом, системой, атакже подсистемами безопасности и криптозащиты.

Без проблем реализуется даже на Жлабэйсике, не то что на C#-е. Так что получается, что если рассматритвать "системное программирование" с твоей точки зрения, то 99% случаев его применения прекрасно проходят на управляетмых языках.

Кстати... А почему ты все время подчеркивашь "на чистом API"? Что же если я решаю одну и ту же задачу вроде шифрования открытым ключем с использованием алгоритма Х, то получаю в случае использования "голого API" системное ПО, а воспользовавшись классом написанным на C# сразу получаю прикладное решение?

Я не даром задал тебе этот вопрос. Дело в том, что ты как и многие другие, не верно воспринимашь этот термин. Термин "систеный" в случае применения его к ПО, его разработке, программистам и т.е. означет "не прикладной". То есть любая задача/программа/пработа результатами которой не пользуется конечный потребитель (юзер) является системной. Так написание контрола уже можно считать системной задачей. В общем-то термин "системный" можно трактовать широко, например, "системное ОП" можно воспринимать как "ПО для нужд ОС", но это уже детали. В любом случае твое восприятие явно неверное.

Задачи которые ты перечислил выше, за исключением создания драйверов все как одни могут быть прикладными. Тот же сервис может оказаться срвисом генерирующим отчеты для системы автоматизация предриятия (вещи сугубо прикладной). Ну, и естественно любая "низкоуровневая" библиотека тоже может использоваться в пркладных нуждах.

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

VD>>Считаеш ли ты сам себя системщиком?

На этот вопрос ты, кстати, не ответил.

VD>>Что мешает создавть программы с использованием WinForms на Delphi или C++?

O>Большое количество P-Invoke существоенно снижает быстродействие,

Ты проверял? Или повторяшь заученную догму? Я вот проверял. И могу тебе сказать, что в 99% случаев замедление ты не заметишь и в микроскоп. Дело в том, что большинство Функций АПИ которые нужно вызвать являются сами по себе очень не быстрыми. Например, по сравнению с временим шифрования время затрачиваемое на маршалинг параметров прочто ничтожно. Ну, а функции вроде IntersectRect и OffsetRect легко реализуются в управляемом коде и как правило уже имеют аналоги. Так что аргумент про P-Invoke сильно надуман.

O> к тому же
O>хваленный .NET Framework есть ни что иное, как COM-сервер (см. 4-е издание книги
O>Соломона и Русиновича) и так или иначе обращается к низкоуровневому API.

Когда читашь книги таких авторов как Русиновичь нужно уметь правильно воспринимать сказанное. Нужно понимать, что это люди пришущие о глубинных вопросах ОС и т.п. Воспринимать их слова буквально просто бессмысленно. Думаю, если ты прочтешь их слова внимательно, то поймшь, что речь там идето о том, что ядро CLR запускается как КОМ-сервер и управляется через КОМ-интерфейсы. Вот только какое это имеет отношение к самому ЦЛР? Он то является Объеязыковой Средой Исполения и внутри себя чихать хотел на КОМ. Да и КОМ-ма там ровно IUnclown. Погляди Ротор. Он перенесен на Free BSB, Mak OS и т.п. В них КОМ-мом и не пахнет и тем неменее все что нужно от кома там реализовано десятком строк кода.

К тому же есть реализации CLI не имеющие вообще никакого отношения к КОМ-у — это Моно и ГНУ-Дотнет.

VD>>Какие системные вещи созданы на Дельфи или Билдере с применением VCL?

O>Системщики избегают данных платформ исключительно из стереотипных соображений.

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

O>Известно, что Delphi и С++ Builder поддерживают Platform SDK в полном объеме.

Что значит поддерживаются? Можно вызвать функцию? Есть конверторы заголовочных файлов которые никогда не ошибаются? Есть полноценный пакет с документацией и оддержкой?

O>Более того, ассемблер от Борланд на порядок круче мелкософтного.

Что то ты путашь. Насколько я знаю, народ сильно мучается от того, что встроенный в Дельфи ассемблер не поддерживает SSE/SSE2-инструкции. А вот в VC вроде как они очень даже поддерживаются. Вот только использование ассемблера в переносимых ОС даже в драйверах нельзя называть разумным решением. К тому еж никто не мешает использовать врешний ассемблер.

O>Единственным препятствием, буть может, является отсутствие опций тонкой настройки
O>компилятора и компоновщика, но в BCB 2006, насколько мне известно, эту проблему решили.

Клавное препятствие заключается в том, что для любой серьезной задачи вроде разработки драйверов требуеется добротный фрэймворк, примеры кода и море документации. Вот как раз их то нет и никогда не будет ни для Дельфи, ни даже для Билдера. Ну, а работая на уровне PSDK проще применять тот же VC, так как они друг под друга заточены.

VD>>А в чем, по-твоему, заключается трудность с вызовом любых WinAPI-функций из управляемых языков?

O>Частые переходы managed/unmanaged негативно сказываются на быстродействии и приводят
O>к путанице в чтении такого кода.

Ну, про первое я уже сказал. Это миф. А что до путанницы, то все как раз с точностью до наоборот. При импорте функций через PInvoke можно описать функцию намного более удобным образом устранив такие нелепости как приведения типов. К тому же прямое использование АПИ-функций в ООЯ является откровенным ламероством. Грамотные программисты даже программируя на С++ стараются создать высокоуровневые обертки защищающие их пользователей от ошибок (как то неверные приведения типов) и упрощающие работу с ними. Так что читается такой код намного лучше. Вот тебе простой пример Перебор файлов с использованием FindFirstFile/FindNextFile и

Автор: VladD2
Дата: 27.09.05

. Попробуй попользоваться этим хэлпером и сравни с ручным использованием FindFirstFile/FindNextFile.

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

VD>Что то ты путашь. Насколько я знаю, народ сильно мучается от того, что встроенный в Дельфи ассемблер не >поддерживает SSE/SSE2-инструкции. А вот в VC вроде как они очень даже поддерживаются.

Это заблуждение.
Delphi6 inline assembler —
Supports all instructions found in the Intel Pentium III, Intel MMX extensions, Streaming SIMD Extensions (SSE), and the AMD Athlon (including 3D Now!)
в Delphi 2005 добавленно —
Supports for Intel Pentium IV SSE3 and SSE2 Instructions Op Codes and Data Types

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

S>Ок, я был неправ. Мне казалось, что в подавлении перерисовки ListView без использования WM_SETREDRAW делать нечего. И, насколько я помню, этот мессадж работал не для всех контролов, так что приходилось делать LockWindowUpdate. И он тоже глючил в разных ситуациях. Но это все было лет шесть назад, поэтому я мог забыть подробности или просто глючить тогда по неопытности.

в свое время я тоже наступил на эти грабли, когда нам надо было написать комплект нестандартных контролов для проги (заказчику очень сильно хотелось )
я тогда решил использовать стандартные win32-контролы как основу, заменив у них отрисовку на собственную, чтобы сэкономить на разработке. О чем очень сильно и не один раз потом пожалел, когда пришло время тестировать прогу на всех версиях винды начиная с 98ой.
В конце концов бОльшую часть контролов пришлось просто написать самим, с нуля. На что ушло раза в два меньше времени, чем на попытку отладить предыдущие версии

что касается твоей задачи — с помощью субклассирования она решается минут за 30 (при наличии необходимого опыта) — или за пару дней, если опыта нет, но знаешь, где копать

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

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

CC>>>В сравнении с VS6 VS2003 периодически еле ползает. P4 640 + 1G DDR2. Только не говорите что мало...

_>>Ну проц явно слабоват.
CC>Чутка очепятался. Не 640 а 630
CC>Впрочем P4 630 = P4 3Gz, 2Mb cache, EMT64, 800 MHz FSB
CC>Или ты шмайлик забыл поставить?

что-то не то с компом, у меня VC++ 7.1 + визуал асист на атлоне 1.7 с 512 мозгов бегает вообще без тормозов.

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

С>Нет, вы не поняли. Чтобы _мое_ приложение работало внутри документа
C>Word'а. Наоборот каждый дурак умеет
Это очень легко делается при помощи шарпа. На Днях разработчика показывали как.

XilenteZ wrote:

> С>Нет, вы не поняли. Чтобы _мое_ приложение работало внутри документа
> C>Word'а. Наоборот каждый дурак умеет
> Это очень легко делается при помощи шарпа. На Днях разработчика
> показывали как.

Я не говорю про макросы через VSA, а про настоящее встраивание в
документ (aka Embedding). Пока что такое невозможно.

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

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

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

C>>Swing — это вообще мой любимый GUI, архитектура там самая лучшая из
C>>всех, что я видел. Только вот Sun его как-то совсем не развивает, он
C>>фактически остался на уровне 2002 года. Вместо того, чтобы выкинуть
C>>#%&^$( AWT и переписать Swing _нормально_, они до сих пор занимаются
C>>эмуляцией Windows GUI.

VD>Согасен, что архитектурно Свинг неплох, но реализован хреновенько.

C>>WinForms мне не очень нравятся архитектурно — там нет полноценного MVC.
C>>Хотя layout'ы уже добавили

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

VD>ЗЫ

VD>В любом, случаи это куда лучше чем МФЦ, ВТЛ и ГДИ вместе взятые.

"Шашечки или ехать?"

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

_>Это заблуждение.
_>Delphi6 inline assembler -
_>Supports all instructions found in the Intel Pentium III, Intel MMX extensions, Streaming SIMD Extensions (SSE), and the AMD Athlon (including 3D Now!)
_>в Delphi 2005 добавленно -
_>Supports for Intel Pentium IV SSE3 and SSE2 Instructions Op Codes and Data Types

Рад за ний. Видимо это была информация о версиях до 2005. В прочем проблем с ассемблером в VC я тоже особо не замечал, как в прочем и не замечал тех ктого на сегодня это интересует.

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

VD>>В любом, случаи это куда лучше чем МФЦ, ВТЛ и ГДИ вместе взятые.

CS>"Шашечки или ехать?"

Ехать. Потому говорю.

ЗЫ

Не оверквоть, так плиз.

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

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

_>>Это заблуждение.
_>>Delphi6 inline assembler -
_>>Supports all instructions found in the Intel Pentium III, Intel MMX extensions, Streaming SIMD Extensions (SSE), and the AMD Athlon (including 3D Now!)
_>>в Delphi 2005 добавленно -
_>>Supports for Intel Pentium IV SSE3 and SSE2 Instructions Op Codes and Data Types

VD>Рад за ний. Видимо это была информация о версиях до 2005.
> В прочем проблем с ассемблером в VC я тоже особо не замечал, как в прочем и не замечал тех ктого на сегодня это >интересует.
Это было до delphi6. (до 1991 г.) К чему бы это? Почему не раньше?
в D2005 добавили только SSE3.

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

C>что-то не то с компом, у меня VC++ 7.1 + визуал асист на атлоне 1.7 с 512 мозгов бегает вообще без тормозов.
Думаю что скорее не с самим компом а с набором софта который там понаставлен...
Впрочем если в VC7 создать проектик из 5-10 файлов то тормозов тоже не наблюдается
А вот на текущем проекте непонятные тормозюки на ровном месте быват, быват...
Впрочем до того как проект перекинули на 7-ю сюху он был под 6-й. Так он грузился долго но работал потом без тормозов.
А тут грузится умеренно но в процессе работы может задуматься.
особенно часто выезжающие окошки сами обратно заезжать не спешат. т.е. когда такому окошку (solution explorer например) надо заехать обратно появляются тормоза у IDE