Re[11]: Почему настоящие программисты избегают C++
От: Amidlokos Россия  
Дата: 24.02.05 12:17
Оценка:
Этот пост должен был уйти минимум два часа назад, но отвалился интернет... Всё же оставлю его.

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

DB>Я уже привык к этой реакции обиженных Си-плюс-плюс-ом. Если Вам не нравится этот пример вот Вам другой. Объясните, какого черта в Windows и в MFC для обычного окна и окна диалога существуют разные классы объектов?! Ведь отличие лишь в модальности, т.е. в режиме показа. Прежде, чем Вы броситесь это обосновывать, подумайте, почему в .NET Framework, который делался намного позже Windows и MFC, все совсем не так и ОЧЕНЬ напоминает VCL?


Точно! А ведь и правда — не только обычные окна и диалоги, но также и кнопочки, поля ввода, списки — это всё ОКНА! И какого лешего им всем намутили разные классы?!

В идеальной библиотеке класс будет один, и называться будет Window! А уж в него мы засунем всё доступное, и навсегда забудем о неудобствах при показе модальных ComboBox-ов, флажков, имеющих свою кнопку на таскбаре и прочего. Даёшь также все модальные окна изменяемого размера!

Руль! Гибкость — закачаешься!


А для начала — RTFM Platform SDK в разделах WinApi...

.NET же, отвечая на вопрос "почему"... Во-первых, вряд ли прародителем была именно Дельфа. Во-вторых, что мешало в том же MFC слить окно и диалог в один класс? Да ничто не мешало, в VCL же слили! Но разработчики MFC не сделали этого по той же причине, по которой не добавили кучу кода для создания цветных кнопочек. Модальное окно изменяемого размера — своего рода форс-мажор, а не нормальная практика.

Более того, советую хоть немного изучить удобство такого подхода. Так сказать, "домашнее задание" дельфийцам — создайте в трёх местах своей программы одну и ту же страницу настройки. Не цветные кнопочки, не голосистые флажки, не прыгающие списки — простую серенькую страницу настройки. Её можно вызывать в отдельном окне по щелчку правой кнопки, либо среди множества вкладок где-то в диалоге настроек, либо в визарде. MFC-шный (а, по сути, WinAPI-евский) подход позволяет сделать это достаточно быстро и просто.
WARNING: expression "to_be || !to_be" is always true
Re[3]: Почему настоящие программисты избегают C++
От: AlexEagle Украина http://www.vik.oil
Дата: 24.02.05 12:22
Оценка: +1
Здравствуйте, Кирпа В.А., Вы писали:

КВА>И еще наверное любят Делфи за отсуствие операции целочисленного деления

Это не DIV и MOD по случаю? А то они там есть

КВА>Предлагаю этот список вынести на отдельную страничку форума Пусть любители Делфи читают и гордятся

Я такую веду локально для гордости за используемый язык программирования. Ну и плюс эта будет. а вообще все замечания и дополнения можно слать на мыло в профайле
Re[12]: Почему настоящие программисты избегают C++
От: Кодёнок  
Дата: 24.02.05 12:41
Оценка:
DB>>Для людей с не очень хорошим зрением этот шрифт довольно мелкий, поэтому в программах, где важна простота и понятность (мультимедиа-программы, программы для детей, программы для домохозяек), этот шрифт иногда в массовом порядке заменяют на шрифт Arial 11 pt. При этом важно, чтобы настройки рабочего стола никак не менялись. Пример не на пустом месте — это было обязательное требование к одной из моих мультимедиа-программ (хотя я сам предпочитаю стандартный размер кнопок).

__>Понятно теперь, откуда эти интерфейсные уродцы берутся, у которых вся морда перекашивается при смене dpi шрифтов на экране. Тебе в голову никогда не приходило, что если у человека зрение слабое, то у него, соответственно, и установки схемы стоят такие, что шрифтов в 8 пунктов просто нет нигде ?


Полностью поддерживаю! Я когда на Дельфе сидел, даже сделал надстройку над всеми контролами для себя, свойство FontModify, которое не задает фиксированный шрифт, а меняет его свойства/размер.
Re[12]: Почему настоящие программисты избегают C++
От: AlexEagle Украина http://www.vik.oil
Дата: 24.02.05 12:47
Оценка:
Здравствуйте, sc, Вы писали:

sc>А в чем проблема создания шрифта?

sc>
LOGFONT lf;
sc>memset(&lf, 0, sizeof(LOGFONT));       
sc>lf.lfHeight = 16;                      
sc>strcpy(lf.lfFaceName, "Arial");        
sc>VERIFY(m_font.CreateFontIndirect(&lf));
sc>m_button.SetFont(&m_font, TRUE);


Не ручаюсь за 100% корректность кода (придумал только что), но можно и так приколоться:

Подготовка:
#define BEGIN_CHANGE_CONTROL_FONT(hDlg, nCtrl) \
 { \
  HFONT hFont; \
  LOGFONT lf; \
  hFont = (HFONT)SendDlgItemMessage(hDlg, nCtrl, WM_GETFONT,0,0); \
  if (!hFont) \
    hFont = GetStockObject(SYSTEM_FONT); \
  if(GetObject(hFont,sizeof(LOGFONT),(LPVOID)&lf)){

#define END_CHANGE_CONTROL_FONT(hDlg, nCtrl) \ 
   SendDlgItemMessage(hDlg, nCtrl, WM_SETFONT, hFont, 0L); \
  } \
}


Ну и сам код:

void CMyDialog::OnInitDialog()
{
...
  BEGIN_CHANGE_CONTROL_FONT(m_hWnd, IDOK)
    lf.lfWeight = FW_BOLD;
    lf.lfUnderline = TRUE;
  END_CHANGE_CONTROL_FONT(m_hWnd, IDOK)

  BEGIN_CHANGE_CONTROL_FONT(m_hWnd, IDCANCEL)
    lf.lfWeight = FW_BOLD;
    lf.lfUnderline = TRUE;
  END_CHANGE_CONTROL_FONT(m_hWnd, IDCANCEL)
...
}
Re[27]: Почему настоящие программисты избегают C++
От: _Obelisk_ Россия http://www.ibm.com
Дата: 24.02.05 13:02
Оценка: 1 (1)
Здравствуйте, Kh_Oleg, Вы писали:

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


A>>И вместе с тем попрошу себе не противоречить C/С++? Без сомнения! Сделан офигительный интерфейс? Сделан! Так что и этот пример вполне подойдёт, разве что не в номинации "MFC"...

K_O>Не подойдет. Бибилиотеку для создания такого "офогительного" интерфейса MS разработчикам не предосталяет. Речь шла не о GUI на С++, а о библиотеке для GUI на С++.

Никто никогда никому не даст библиотеку делающию "офигительный" интрефейс. Если кто-то такую библиотеку предоставил, то либо она будет стоит БОЛЬШИХ денег, либо ее производитель может сделать еще более "офигительный" интерфейс, не реализуемый данной библиотекой, либо библиотека решает не все задачи.
"Офигительный" интерфейс — это конкурентное преимущество, им так просто не разбрасываются.



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[28]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 24.02.05 13:16
Оценка:
_Obelisk_ пишет:

> Никто никогда никому не даст библиотеку делающию "офигительный" интрефейс.


Почему? Есть, например, BCG (http://www.bcgsoft.com/), стоит весьма
умеренные деньги ($300). Интерфейсы позволяет делать офигительные
(скинабельные и конфигурабельные). Написана как расширение MFC.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[28]: Почему настоящие программисты избегают C++
От: Amidlokos Россия  
Дата: 24.02.05 13:20
Оценка:
Здравствуйте, _Obelisk_, Вы писали:

_O_>"Офигительный" интерфейс — это конкурентное преимущество, им так просто не разбрасываются.


Сейчас дельфисты с гордостью начнут утверждать, что у них-то такой интерфейс давно уже есть, и на самую натуральную халяву.

Ой, что будет...

WARNING: expression "to_be || !to_be" is always true
Re[29]: Почему настоящие программисты избегают C++
От: _Obelisk_ Россия http://www.ibm.com
Дата: 24.02.05 13:29
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>_Obelisk_ пишет:


>> Никто никогда никому не даст библиотеку делающию "офигительный" интрефейс.


C>Почему? Есть, например, BCG (http://www.bcgsoft.com/), стоит весьма

C>умеренные деньги ($300). Интерфейсы позволяет делать офигительные
C>(скинабельные и конфигурабельные). Написана как расширение MFC.

C>--

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

Хм..
BCGControlBar Library Professional Edition
Corporate License US $9990.00

Это не так уж дешево. Потом, я там не вижу чего-нибудь похожего на Objective Views из Stingray-я.



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[30]: Почему настоящие программисты избегают C++
От: Cyberax Марс  
Дата: 24.02.05 13:37
Оценка:
_Obelisk_ пишет:

> Хм..

> BCGControlBar Library Professional Edition
> Corporate License US $9990.00

Естественно. Смотри на обычные лицензии.

> Это не так уж дешево. Потом, я там не вижу чего-нибудь похожего на

> Objective Views из Stingray-я.

Просто немного другой тип библиотеки.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[13]: Почему настоящие программисты избегают C++
От: AlexEagle Украина http://www.vik.oil
Дата: 24.02.05 14:17
Оценка:
Здравствуйте, AlexEagle, Вы писали:

Ну а если кому понадобится — то вот рабочий код:

#define BEGIN_CHANGE_CONTROL_FONT(hDlg, nCtrlId)                \
    {    \
        HFONT hFont;    \
        LOGFONT lf;    \
        hFont = (HFONT)::SendDlgItemMessage(hDlg, nCtrlId, WM_GETFONT,0,0); \
        if (!hFont) \
            hFont = (HFONT)::GetStockObject(SYSTEM_FONT); \
        if(GetObject(hFont,sizeof(LOGFONT),(LPVOID)&lf)){ \

#define END_CHANGE_CONTROL_FONT(hDlg, nCtrlId)                \
            hFont = ::CreateFontIndirect(&lf);    \
            ::SendDlgItemMessage(hDlg, nCtrlId, WM_SETFONT, (WPARAM)hFont, 0L);    \
        }    \
    }    \


void CMyDialog::OnInitDialog()
{
...
    BEGIN_CHANGE_CONTROL_FONT(m_hWnd, IDOK)
        lf.lfWeight = FW_BOLD;
        lf.lfUnderline = TRUE;
    END_CHANGE_CONTROL_FONT(m_hWnd, IDOK)

    BEGIN_CHANGE_CONTROL_FONT(m_hWnd, IDCANCEL)
        lf.lfUnderline = TRUE;
    END_CHANGE_CONTROL_FONT(m_hWnd, IDCANCEL)
...
}
Re[14]: Почему настоящие программисты избегают C++
От: Кодт Россия  
Дата: 24.02.05 14:51
Оценка:
Здравствуйте, AlexEagle, Вы писали:

Монстр макропрограммирования!
class PatchFont : public LOGFONT
{
  HWND m_hwnd;
  UINT m_id;
public:
  PatchFont() {}

  bool take(HWND hwnd, UINT id)
  {
    m_hwnd = hwnd; m_id = id;
    HFONT hfont = (HFONT)::SendDlgItemMessage(m_hwnd, m_id, WM_GETFONT,0,0);
    if(!hfont) hfont = GetStockObject(SYSTEM_FONT);
    return GetObject(hfont, sizeof(LOGFONT), static_cast<LOGFONT*>(this)) != 0;
  }

  void give() const
  {
    HFONT hfont = CreateFontIndirectstatic_cast<const LOGFONT*>(this));
    SendDlgItemMessage(m_hwnd, m_id, WM_SETFONT, (WPARAM)hfont, 0);
  }
};

......

PatchFont pf;

pf.take(hDlg, ID_ONE);
  pf.lfWeight = FW_BOLD;
pf.give();

pf.take(hDlg, ID_TWO);
  pf.lfUnderline = TRUE;
pf.give();
Перекуём баги на фичи!
Re[14]: Почему настоящие программисты избегают C++
От: d Bratik  
Дата: 24.02.05 16:15
Оценка: :)
Здравствуйте, _Obelisk_, Вы писали:

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


_O_>>>Программа не на MFC. MFC глубоко похоронен в недрах Stingray-я + нашего собственного framework-а поверх Stingray-я. Потом GUI здесь отнюдь не самая

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

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


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


Туманно все как-то Через какой API этот собственный framework что-либо рисует? Через GDI, через MFC-шные классы-оболочки над GDI?

_O_>Во, скриншот для Linux-а, делал через Reflection. (на Solaris-е будет тоже самое).


Не-е-е, такой ответ не устраивает Пока сам воочию не увижу скриншот с солярки, не поверю Подозреваю, что программе Вашей требуется эмулятор Wine, которого на солярке нет. Я же не просто так спрашивал, сколько у Вас реальных пользователей на Solaris
Re[5]: Почему настоящие программисты избегают C++
От: Rebus83 Россия  
Дата: 24.02.05 17:04
Оценка: :)
Здравствуйте, VladD2, Вы писали:


P>>Сейчас оберонисты прибегут

VD>Цссс. А то ведь флэйм получится.
Аааа... так это был ещё не?..
... << RSDN@Home 1.1.4 beta 4 rev. 303>> Вокруг тишина
Какая странная планета! — подумал Маленький принц. — Совсем сухая,
вся в иглах и соленая. И у людей не хватает воображения. Они только
повторяют то, что им скажешь...
Re[15]: Почему настоящие программисты избегают C++
От: Kubera Россия  
Дата: 24.02.05 18:41
Оценка:
Здравствуйте, VladD2, Вы писали:

K>>Функция вычисления среднего арифметического не должна бросать исключений. Это нонсенс , если вместо среднего арифметического при определённых входных параметрах функция будет выкидывать ошибку! А вот её реализация обязана учитывать переполнение, точнее избегать его. Влад, с чем ты не согласен?


VD>Попробую более доходчиво:

VD>Функция не учитывающая переполенеие уже ошибочна.
В огороде бузина, а в Киеве дядька...

VD>Так понянее?

Нет, т.к. ты не ответил на мой вопрос. Я так и не понял в чём ты со мной не согласен. Спрошу по-другому:
Функция вычисления среднего арифметического не должна бросать исключений. Влад, ты согласен с этим утверждением? Да или нет?
Любая сложная технология неотличима от волшебства. (Артур Кларк)
Re[15]: Почему настоящие программисты избегают C++
От: _Obelisk_ Россия http://www.ibm.com
Дата: 25.02.05 06:45
Оценка:
Здравствуйте, d Bratik, Вы писали:

DB>Туманно все как-то Через какой API этот собственный framework что-либо рисует? Через GDI, через MFC-шные классы-оболочки над GDI?


Уфф. Рисуем используя Stingray + MFC. Дальше MainSoft все делает :
http://www.mainsoft.com/products/mainwin_howitworks.html

The Visual MainWin Runtime consists of the Windows Runtime on UNIX and Core Services. Together, they enable Windows applications to execute natively on UNIX.

The Windows Runtime on UNIX includes an extensive set of Microsoft technologies such as MSXML, SSL, MSHTML, WinSock, COM/DCOM and ATL. These are based on the original Microsoft implementation, tuned for UNIX by Mainsoft.

Visual MainWin Core Services for UNIX and Linux provide functionality such as synchronization objects, threads and low-level graphic functionality utilized by the Windows Runtime on UNIX. The Core Services also include the Mainsoft RPCSS and Registry services, which provide the robust infrastructure required to support huge numbers of Visual MainWin processes running concurrently on the same machine.

Visual MainWin creates native UNIX binaries requiring no virtual machine. No emulation or mapping is performed at runtime, guaranteeing maximum performance of the deployed application.


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


Сделаю, когда доберусь до SPARС-а.



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[13]: Почему настоящие программисты избегают C++
От: Demiurg  
Дата: 25.02.05 07:23
Оценка:
Здравствуйте, The Lex, Вы писали:

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


sc>>В Windows все элементы гуи, окна, это судя по названию...



TL>А теперь "фишка": а вот в Дельфи не все элементы гуи являются окнами Windows!


Кстати, я так и не понял почему борландовцы свой TLabel сделали не на основе STATIC'а... И не только его...
... << RSDN@Home 1.1.4 beta 4 303, 1995 — Tikhie Igry>>
Re[11]: Почему настоящие программисты избегают C++
От: Demiurg  
Дата: 25.02.05 07:31
Оценка:
Здравствуйте, Kh_Oleg, Вы писали:

G>>Смотря что ты подразумеваешь под "Артефактами".

K_O>Вот это (программа написана на Qt):
K_O>
K_O>Здесь я пытаюсь перетащить ToolBar. Одна рамка — это я его тащу, она и должна быть. А вторая — результат Qt-шной перерисовки, артефакт. Он так и останется, пока все окно не будет перерисовано.

Это ведь SIM? До ужаса кривая и глюкавая программа... Она бы и на VCL себя так же вела Ну или по-другому как-то глючила
... << RSDN@Home 1.1.4 beta 4 303, 1986 — Nasha Sem'ya>>
Re[7]: Почему настоящие программисты избегают C++
От: Awaken Украина  
Дата: 25.02.05 08:28
Оценка:
DB>И все же я пока не видел ни одной промышленной GUI бибилиотеки на С++, которая бы отдаленно приближалась по качеству к VCL и .NET >Framework. Обыскал весь Интернет — таковой в природе нет. Qt более-менее ничего, но когда основательно начинаешь пользовать, начинаешь >плеваться.

дался тебе этот ГУЙ! в любой мало мальски сложной программе гуй это 1-10% всей задачи.
я как-то участвовал в разработке музыкального редактора. это система распознавания и визуализации нотных записей , как положено
на линейках нотного стана, каждая нота на своей высоте. самое сложное тут это не нарисовать эти ноты — а алгоритмы как их представить
в виде векторной графики, масштабировать, сериализовать в двоичные файлы , и т.д.
писано все было на VC++ 6.0 и MFC, и впоследствие портировано на Макинтош.
это я к тому что в сложной задаче на первом месте алгоритмы, а не библиотеки примитивов (они сводятся к набору достаточно низкоуровневых функций, которые можно — и нужно — изолировать в отдельный слой и абстрагировать от основной логике)
Re[15]: Почему настоящие программисты избегают C++
От: Awaken Украина  
Дата: 25.02.05 08:37
Оценка:
K_O>Вот тут упоминали, что куча продуктов (Office, Adobe family, etc.) написана на С++. Написана, но в каждом
K_O>случае разработчикам приходилось писать свой framework конкретно под свой продукт (или семейство продуктов).

любая крупная софтверная фирма имеет собственные фреймворки и собственные солюшены. это удешевляет
разработку в промышленном масштабе, и позволяет максимально унифицировать семейства программных продуктов.
например так чтобы они выглядели одинаково на Windows и на Mac.
ну и еще и из-за политики лицензирования сторонних компонент.
Re[22]: Почему настоящие программисты избегают C++
От: Awaken Украина  
Дата: 25.02.05 08:41
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>Kh_Oleg пишет:


>> C>Сортировку, поиск и скроллинг должно делать само приложение — дерево

>> C>просто отображает результаты. Вставка и удаление в стандартном списке
>> C>работают достаточно быстро.
>> Ути-пути, само приложение!

C>Да. Само приложение, хотя 10^5 записей и дерево сможет отсортировать.


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