d Bratik пишет:

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

С чего бы? Из-за запросов на каждый клик мышки? Так это сами виноваты.

> из-за того, что модель данных в пользовательском интерфейсе совершенно
> не согласуется с моделью данных в БД.

Скорее оно начинает тормозить из-за того, что у GUI-программистов кривые
руки.

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

Какая проблема? Торможение дерева?

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

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

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

ABS>Вообше, зачем делать этот долбанный var в хеадере функци, которая импортируется из винды?

Саша, ну что за глупые вопросы? Ответы ты и так знаешь ( Гладиолус кстати не на последнем месте в очереди ответов). Ты еще спроси почему там не все функции и virtual keys определены...

C>QT, GTK, MFC.... 99% виндового софта, написанного на С++... ...FireFox....

MS Office, IE, все продукта Adobe написаны на C++. и все они с весьма навороченным гуем.
а на ДЕльфе я всего одну коммерческую программу не являюуюся "поделкой" знаю — это TOAD
(оболочка для Oracle баз данных)

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

A>>Что касается Си и Си++, то, на мой взгляд, это их недостаток, что отсутствуют переносимые средства обнаружения переполнений. Но и такие, как checked в Си-Шарпе не очень-то полезны.

VD>Да как раз очнь даже полезны. Это компромис между надежность и скорость. Я в любой момент включив одну галку в VS могу получить приложение с контролем переполения и убедиться что хотя бы нет явных ошибок. Ну, а далее если есть проблемы то могу подумать как их проще устранить. Если скорость не важна, то ввести проверку. Если важна, или недопустимы вылеты, то делать ручной контроль.

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

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

VD>"Осознавать" на практике означет отказ от интуитивного поведения и жесточайший контроль. Это плохой подход. Конструкции С++ в основном интуитивны. И когда встречается нечто требующее контроля усилием воли, процесс разработки значительно усложняется.

Я не вижу здесь ничего "неинтуитивного". В конце концов, с точки зрения математики конструкция

x = x + 1;

тоже не блещет интуитивностью.

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

VD>Ну, а почему в C++ и C# имеются беззнаковыи и переполнения совершенно понятно. Погоня за эффектиностью. Если плевать на нее, то можно было бы просто ввести тип int который не имел бы размеров и ограничеий (как в Руби и Питоне). А для контроля значений вообще лучше подошел бы тип с ограничениями. Но это не эффективно.

О чём и речь. В погоне за дешёвенькой "интуитивностью" с точки зрения разработчика не стоит заходить слишком далеко, иначе никаких суперкомпьютеров не хватит.

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

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

C>>QT, GTK, MFC.... 99% виндового софта, написанного на С++... ...FireFox....
C>>Нет, не делают С++-программисты нормальных GUI — только НАСТАЯЩИЕ пацаны
C>>делают GUI, и только на Дельфи.
C>>Да, да, да. Поэтому от Дельфовых программистов и получаем все время
C>>уродцев типа "Рассчета налогов", "Электронной бухгалтерии" и т.п.

P>Ой, щас чувствую меня ногами запинают, но молчать не могу: как противовес всем этим дельфевым "Расчетам налогов" и пр. можно привести 1С, которая АФАИК целиком написана на VC++. Как говорится "почувствуйте разницу".

99% приложений под винду написаны на C++.
из того что использую каждый день — Visual Studio, MS Office, Adobe Photoshop, Discreet 3DS Max
лидеры в области коммерческого ПО почему-то не пишут на Дельфях хотя это проще и удобнее. неспроста
из того что я использую только TOAD на Дельфях.

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


DB>Неужели большинство именно под Linux-ом, а не под WIndows-ом? Вы переспросите отдел маркетинга. И сколько в процентном отношении пользователей сидит на Solaris?

У нас продукты главным образом ориентированы на серьезные и крупные компании в секторах Military/Aerospace и Telecom: Motorola, Nokia, Sony-Ericcson, Lucent, Lookhead Martin Corp, Bae Systems, Thales, etc. Здесь на виндах свет клином не сошелся.

DB>Еще пару вопросов. Интересно, как выполняется поддержка и разработка новых версий? Ведь программа-то на MFC. Это значит, что сначала появляется версия под Windows. Потом эта версия портируется под Linux, на котором есть Wine (эмулятор WinAPI). А как же делается Solaris-версия? Как там эмулируется WinAPI и MFC? И если действительно как-то эмулируется, то как обстоят дела, если пользовательский интерфейс использует multi-threading?

Программа не на MFC. MFC глубоко похоронен в недрах Stingray-я + нашего собственного framework-а поверх Stingray-я. Потом GUI здесь отнюдь не самая
сложная часть продукта.
Собирается все из исходников на разных платформах одновременно и единообразно. Просто на на Linux-е/Solaris-е GUI линкуется с библиотеками от MainSoft-а. А эмуляция MFC — задача MainSoft-а, не наша. Все, что не GUI, вообще не использует ничего Windows-specific.

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

DB>Может нам отдельную тему организовать, посвященную вопросам кросс-платформенной разработки на С++.

Какие проблемы! Хотите, эту ветку (начиная отсюда

Автор: _Obelisk_
Дата: 17.02.05

) отделю?

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

C>Скорее оно начинает тормозить из-за того, что у GUI-программистов кривые
C>руки.

Скорее всего нету никаких GUI-программистов. Просто есть программисты, которые не разбираются в проблемах GUI.

C>Обычно схема БД проектируется и оптимизируется так, чтобы
C>соответствовать предметной области.

Если БД не соответствует запросам (в прямом и переносном смысле) пользователя, то она не соответствует предметной области.

C> GUI обычно проектируется с такой же
C>целью (и обычно является далеко не самой главной частью).

Большое заблуждение.

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

C>>>QT, GTK, MFC.... 99% виндового софта, написанного на С++... ...FireFox....
C>>>Нет, не делают С++-программисты нормальных GUI — только НАСТАЯЩИЕ пацаны
C>>>делают GUI, и только на Дельфи.
C>>>Да, да, да. Поэтому от Дельфовых программистов и получаем все время
C>>>уродцев типа "Рассчета налогов", "Электронной бухгалтерии" и т.п.

P>>Ой, щас чувствую меня ногами запинают, но молчать не могу: как противовес всем этим дельфевым "Расчетам налогов" и пр. можно привести 1С, которая АФАИК целиком написана на VC++. Как говорится "почувствуйте разницу".

A>99% приложений под винду написаны на C++.
A>из того что использую каждый день — Visual Studio, MS Office, Adobe Photoshop, Discreet 3DS Max
A>лидеры в области коммерческого ПО почему-то не пишут на Дельфях хотя это проще и удобнее. неспроста
A>из того что я использую только TOAD на Дельфях.

И все же я пока не видел ни одной промышленной GUI бибилиотеки на С++, которая бы отдаленно приближалась по качеству к VCL и .NET Framework. Обыскал весь Интернет — таковой в природе нет. Qt более-менее ничего, но когда основательно начинаешь пользовать, начинаешь плеваться.

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


DB>>Неужели большинство именно под Linux-ом, а не под WIndows-ом? Вы переспросите отдел маркетинга. И сколько в процентном отношении пользователей сидит на Solaris?

_O_>У нас продукты главным образом ориентированы на серьезные и крупные компании в секторах Military/Aerospace и Telecom: Motorola, Nokia, Sony-Ericcson, Lucent, Lookhead Martin Corp, Bae Systems, Thales, etc. Здесь на виндах свет клином не сошелся.

Список внушает, но на вопрос не отвечает Я просто немного усомнился, что у Вас больше пользователей на Linux, чем на Windows. И я предположил, что пользователей на Solaris, во много-много раз меньше.

DB>>Еще пару вопросов. Интересно, как выполняется поддержка и разработка новых версий? Ведь программа-то на MFC. Это значит, что сначала появляется версия под Windows. Потом эта версия портируется под Linux, на котором есть Wine (эмулятор WinAPI). А как же делается Solaris-версия? Как там эмулируется WinAPI и MFC? И если действительно как-то эмулируется, то как обстоят дела, если пользовательский интерфейс использует multi-threading?

_O_>Программа не на MFC. MFC глубоко похоронен в недрах Stingray-я + нашего собственного framework-а поверх Stingray-я. Потом GUI здесь отнюдь не самая
_O_>сложная часть продукта.
_O_>Собирается все из исходников на разных платформах одновременно и единообразно. Просто на на Linux-е/Solaris-е GUI линкуется с библиотеками от MainSoft-а. А эмуляция MFC — задача MainSoft-а, не наша. Все, что не GUI, вообще не использует ничего Windows-specific.

Вы меня вконец запутали. Что же представляет собой Ваш собственный framework? И наконец, сокраментальный вопрос: нельзя ли взглянуть краем глаза на скриншот с Sun Solaris-а (на SPARK-е)?

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

К>Здравствуйте, d Bratik, Вы писали:

DB>>Может нам отдельную тему организовать, посвященную вопросам кросс-платформенной разработки на С++.

К>Какие проблемы! Хотите, эту ветку (начиная отсюда

Автор: _Obelisk_
Дата: 17.02.05

) отделю?

Давайте.

d Bratik пишет:

> A>99% приложений под винду написаны на C++.
> A>из того что использую каждый день — Visual Studio, MS Office, Adobe
> Photoshop, Discreet 3DS Max
> A>лидеры в области коммерческого ПО почему-то не пишут на Дельфях хотя
> это проще и удобнее. неспроста
> A>из того что я использую только TOAD на Дельфях.
> И все же я пока не видел ни одной промышленной GUI бибилиотеки на С++,
> которая бы отдаленно приближалась по качеству к VCL и .NET Framework.
> Обыскал весь Интернет — таковой в природе нет.

MFC, WTL, raw WinAPI, GTK. _Качество_ у них ничуть не хуже.

А к интуитивности использования _библиотека_ отношение имеет весьма
слабое, важна среда. Тот же Glade для GTK позволяет интуитивно рисовать
интерфейсы на чистом С.

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

d Bratik пишет:

> C>Скорее оно начинает тормозить из-за того, что у GUI-программистов
> кривые
> C>руки.
> Скорее всего нету никаких GUI-программистов. Просто есть программисты,
> которые не разбираются в проблемах GUI.

Я и говорю — криворукие программисты. Если программист не способен
нормально доставать дерево из базы, то он, скорее всего, криворук.

> C>Обычно схема БД проектируется и оптимизируется так, чтобы
> C>соответствовать предметной области.
> Если БД не соответствует запросам (в прямом и переносном смысле)
> пользователя, то она не соответствует предметной области.

Ну значит у вас там БД не так спроектировали. И причем здесь GUI?

> C> GUI обычно проектируется с такой же
> C>целью (и обычно является далеко не самой главной частью).
> Большое заблуждение.

То-то более 99% процентов кода на Земле — невизульного (т.е. не имеющий
отношения к UI).

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

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

A>Во всех случаях, когда я сталкивался с необходимостью контролировать переполнение, сам факт переполнения был вещью ожидаемой, не катастрофической для хода вычислений и, хоть и требовал специальной обработки, не служил поводом для исключения. Мне важней было бы иметь некую операцию, скажем, сложения, которая, уподобляясь команде АЛУ, не только бы давала результат, но и формировала бы логический признак — флаг переноса, а не исключение.

Просто там где ты не ожидал переполнения у тебя были глюки. Я же не даром привел простой пример:

a - b

казалось бы... что тут ожидать? Ан нет тебе может быть.

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

C>d Bratik пишет:

>> A>99% приложений под винду написаны на C++.
>> A>из того что использую каждый день — Visual Studio, MS Office, Adobe
>> Photoshop, Discreet 3DS Max
>> A>лидеры в области коммерческого ПО почему-то не пишут на Дельфях хотя
>> это проще и удобнее. неспроста
>> A>из того что я использую только TOAD на Дельфях.
>> И все же я пока не видел ни одной промышленной GUI бибилиотеки на С++,
>> которая бы отдаленно приближалась по качеству к VCL и .NET Framework.
>> Обыскал весь Интернет — таковой в природе нет.

C>MFC, WTL, raw WinAPI, GTK. _Качество_ у них ничуть не хуже.

Под качеством я имел в виду не степень отлаженности, а уровень технического совершенства. Чтобы понять разницу, попробуйте, используя эти библиотеки, создать окно с обычной кнопкой OK, текст которой написан нестандартным шрифтом. Сколько нужно потратить на это времени?

C>А к интуитивности использования _библиотека_ отношение имеет весьма
C>слабое, важна среда. Тот же Glade для GTK позволяет интуитивно рисовать
C>интерфейсы на чистом С.

Если образцом для подражания Вы считаете "raw WinAPI" (а также GTK и MFC), то нам не о чем больше спорить.

d Bratik пишет:

>>> И все же я пока не видел ни одной промышленной GUI бибилиотеки на С++,
>>> которая бы отдаленно приближалась по качеству к VCL и .NET Framework.
>>> Обыскал весь Интернет — таковой в природе нет.
> C>MFC, WTL, raw WinAPI, GTK. _Качество_ у них ничуть не хуже.
> Под качеством я имел в виду не степень отлаженности, а уровень
> технического совершенства.

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

> Чтобы понять разницу, попробуйте, используя эти библиотеки, создать
> окно с обычной кнопкой OK, текст которой написан нестандартным
> шрифтом. Сколько нужно потратить на это времени?

1. Рисуем диалог с кнопкой ОК (идентификатор IDD_OKDIALOG).
2. Пишем класс диалога:

class OkDialog : public CDialogImpl<OkDialog>, public 
CDialogResize<OkDialog>
{
    CPrettyButton btn; //Mine
public:
    enum { IDD = IDD_OKDIALOG};

    BEGIN_MSG_MAP(OkDialog)
        MESSAGE_HANDLER(WM_INITDIALOG, OnInitDialog)
    END_MSG_MAP()

    BEGIN_DLGRESIZE_MAP(OkDialog)
        DLGRESIZE_CONTROL(IDOK, DLSZ_MOVE_X|DLSZ_MOVE_Y)
    END_DLGRESIZE_MAP()

    LRESULT OnInitDialog(UINT /*uMsg*/, WPARAM /*wParam*/, LPARAM 
/*lParam*/, BOOL& /*bHandled*/)
    {
        // Init dialog resizing
        DlgResize_Init();
        btn.SubclassWindow(GetDlgItem(IDOK)); //Mine
        btn.SetFont(...); //Mine
    }
};

CPrettyButton — это моя кнопочка, которая умеет менять свой шрифт,
цвета, работать как push-like-button и т.п.

Большая часть кода в данном диалоге генерируется визардом (или
cut&paste'ом), мои три строчки отмечены. Размер скомпиленой программы —
16Кб.

> C>А к интуитивности использования _библиотека_ отношение имеет весьма
> C>слабое, важна среда. Тот же Glade для GTK позволяет интуитивно рисовать
> C>интерфейсы на чистом С.
> Если образцом для подражания Вы считаете "raw WinAPI" (а также GTK и
> MFC), то нам не о чем больше спорить.

Да, мне очень нравится WinAPI. Более правильную _низкоуровневую_ GUIшную
либу я видел только на Маках. GTK мне тоже очень нравится, хотя это уже
и не низкоуровневая библиотека.

MFC мне нравится не особо, но в ней очень много функциональности.

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

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

>> Чтобы понять разницу, попробуйте, используя эти библиотеки, создать
>> окно с обычной кнопкой OK, текст которой написан нестандартным
>> шрифтом. Сколько нужно потратить на это времени?

C>1. Рисуем диалог с кнопкой ОК (идентификатор IDD_OKDIALOG).
C>2. Пишем класс диалога:
C>

C>class OkDialog : public CDialogImpl<OkDialog>, public 
C>CDialogResize<OkDialog>
C>{
C>    CPrettyButton btn; //Mine
C>public:
C>    enum { IDD = IDD_OKDIALOG};

C>    BEGIN_MSG_MAP(OkDialog)
C>        MESSAGE_HANDLER(WM_INITDIALOG, OnInitDialog)
C>    END_MSG_MAP()

C>    BEGIN_DLGRESIZE_MAP(OkDialog)
C>        DLGRESIZE_CONTROL(IDOK, DLSZ_MOVE_X|DLSZ_MOVE_Y)
C>    END_DLGRESIZE_MAP()

C>    LRESULT OnInitDialog(UINT /*uMsg*/, WPARAM /*wParam*/, LPARAM 
C>/*lParam*/, BOOL& /*bHandled*/)
C>    {
C>        // Init dialog resizing
C>        DlgResize_Init();
C>        btn.SubclassWindow(GetDlgItem(IDOK)); //Mine
C>        btn.SetFont(...); //Mine
C>    }
C>};
C>

C>CPrettyButton — это моя кнопочка, которая умеет менять свой шрифт,
C>цвета, работать как push-like-button и т.п.

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

C>Большая часть кода в данном диалоге генерируется визардом (или
C>cut&paste'ом), мои три строчки отмечены. Размер скомпиленой программы —
C>16Кб.

Дело не в том, что мало печатать приходится, потому что визард генерит, а в том, что потом такое читать невозможно.

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

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

Под шумок вылезли дельфисты, я верно понимаю?

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

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

K_O>Дело не в том, что мало печатать приходится, потому что визард генерит, а в том, что потом такое читать невозможно.

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

Kh_Oleg пишет:

> C>CPrettyButton — это моя кнопочка, которая умеет менять свой шрифт,
> C>цвета, работать как push-like-button и т.п.
> В Вилариба уже давно сменили стандартное свойство у стандартного
> контрола,
> а в Вилабаджо все еще пишут свои классы для кнопочек.

Нет, Вилабаджо уже давным-давно знают про сайт
http://www.codeproject.com/ и уже давно скачали кучу всяких контролов
(там есть и поддержка изменения шрифтов:
http://codeproject.com/wtl/wtlwindowfont.asp).

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

> C>Большая часть кода в данном диалоге генерируется визардом (или
> C>cut&paste'ом), мои три строчки отмечены. Размер скомпиленой программы —
> C>16Кб.
> Дело не в том, что мало печатать приходится, потому что визард
> генерит, а в том, что потом такое читать невозможно.

Читается это элементарно. Кстати, этот пример я набрал руками в Студии,
без всяких визардов (я ими не пользуюсь из принципа).

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