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

E>Ты — нет. WindowProc — процедурная переменная.

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

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Граф импорта модулей друг другом ацикличен — вот Вам иерархическая структура. Модули ВСЕГДА организованы иерархически.

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

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

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

E>>Ты — нет. WindowProc — процедурная переменная.

Д>покажи мне, в каком месте нужно создавать в своей программе процедурную переменную, когда вызываешь SendMessage или PostMessage
Я же давал ссылку на msdn. Там всё написано.
Для посылки сообщений она конечно не обязательна, а вот для приема — да. Или ты свои классы окон ни разу не писал?

Д>или твоя гипотетическая процедурная переменная — это универсальный ответ на все случаи жизни, которым можно назвать любой вариант косвенного вызова?
ты сказал (см. выделенное):

Вот еще один интересный вопрос. Каким образом ухитряется работать UI в Windows? Окна обмениваются какими-то мистическими сообщениями, и нигде нет ни одного указателся на функцию!

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

Может хватит флудить, а?

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

VD> Я правильно понимаю, что ты оссоциируешь модуль с исходным файлом?

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

MODULE MyModule;

(* код модуля *)

END MyModule.

1 файл компилится в одну исполнимую единицу (читай в аналог DLL). Потом подправил чего-нибудь в этом файле — только его перекомпилил и только его бинарник заменил в системе. Ну не натурально ли?

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

E>Для посылки сообщений она конечно не обязательна, а вот для приема — да. Или ты свои классы окон ни разу не писал?

За ничем не обоснованную клевету — минус.
Я то всегда думал, что WindowProc — это функция. А оказывается, это на самом деле процедурная переменная
Покажи мне ЗДЕСЬ хоть один указатель на функцию.

// CMfcApp1Dlg dialog
class CMfcApp1Dlg : public CDialog
{
// Construction
public:
    CMfcApp1Dlg(CWnd* pParent = NULL);    // standard constructor

// Dialog Data
    enum { IDD = IDD_MFCAPP1_DIALOG };

    protected:
    virtual void DoDataExchange(CDataExchange* pDX);    // DDX/DDV support


// Implementation
protected:
    HICON m_hIcon;

    // Generated message map functions
    virtual BOOL OnInitDialog();
    afx_msg void OnPaint();
    afx_msg HCURSOR OnQueryDragIcon();
    DECLARE_MESSAGE_MAP()
};
//////////////////////////////////////////////////////////////////
CMfcApp1Dlg::CMfcApp1Dlg(CWnd* pParent /*=NULL*/)
    : CDialog(CMfcApp1Dlg::IDD, pParent)
{
    m_hIcon = AfxGetApp()->LoadIcon(IDR_MAINFRAME);
}

void CMfcApp1Dlg::DoDataExchange(CDataExchange* pDX)
{
    CDialog::DoDataExchange(pDX);
}

BEGIN_MESSAGE_MAP(CMfcApp1Dlg, CDialog)
    ON_WM_PAINT()
    ON_WM_QUERYDRAGICON()
    //}}AFX_MSG_MAP
END_MESSAGE_MAP()


// CMfcApp1Dlg message handlers

BOOL CMfcApp1Dlg::OnInitDialog()
{
    CDialog::OnInitDialog();

    // Set the icon for this dialog.  The framework does this automatically
    //  when the application's main window is not a dialog
    SetIcon(m_hIcon, TRUE);            // Set big icon
    SetIcon(m_hIcon, FALSE);        // Set small icon

    // TODO: Add extra initialization here
    
    return TRUE;  // return TRUE  unless you set the focus to a control
}

// If you add a minimize button to your dialog, you will need the code below
//  to draw the icon.  For MFC applications using the document/view model,
//  this is automatically done for you by the framework.

void CMfcApp1Dlg::OnPaint() 
{
    if (IsIconic())
    {
        CPaintDC dc(this); // device context for painting

        SendMessage(WM_ICONERASEBKGND, reinterpret_cast<WPARAM>(dc.GetSafeHdc()), 0);

        // Center icon in client rectangle
        int cxIcon = GetSystemMetrics(SM_CXICON);
        int cyIcon = GetSystemMetrics(SM_CYICON);
        CRect rect;
        GetClientRect(&rect);
        int x = (rect.Width() - cxIcon + 1) / 2;
        int y = (rect.Height() - cyIcon + 1) / 2;

        // Draw the icon
        dc.DrawIcon(x, y, m_hIcon);
    }
    else
    {
        CDialog::OnPaint();
    }
}

// The system calls this function to obtain the cursor to display while the user drags
//  the minimized window.
HCURSOR CMfcApp1Dlg::OnQueryDragIcon()
{
    return static_cast<HCURSOR>(m_hIcon);
}

E>Я тебе напомнил, что для самой организации обмена сообшениями (для регистрации обработчиков событий) указатели на функции таки используются.

разделение реализации и интерфейса. основы программирования. срочно RTFM

E>Может хватит флудить, а?

не груби.
Как нетрудно убедиться, для любого UI приложения в Win32 необходимы и достаточны две основные вещи:
1. Экспортировать свои оконные процедуры. Существующая реализация делает это с помощью указателей на функции, но для самого ЯВУ знать это необязательно.
2. Использовать PostMessage/SendMessage для косвенного вызова чужих методов
Таким образом реализуются как косвенные вызовы функций, так и некоторый вариант полиморфизма, наследование объектов в рантайме AKA субклассирование, обратные вызовы и некоторые другие вещи.

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

VD>Опыта у Оберона нет и быть не может, так как он никогда не использовался в широкой практике. Полезные идеи Оберона (а вернее еще Паскаля) были включены во множество современных языков. В том числе и в Шарп. При этом языки вроде Шарпа и Явы проверены вренменем, обладают как минимум не меньшей безопасностью, и значительно более гибки, удобны и функциональны. По этому, учить нужно именно им. А Оберон вообне не нужен в этом мире. Для старта достаточно Паскля, а то и какого-нибудь Руби с Питоном. Ну, а современному ООП нужно обучать именно на Шарпе или Яве.

Сейчас я использую старый добрый прием в полемике межъязыковой борьбы (раньше этот прием использовался в войне Си против Паскаля). И так, пожалуйста:

C# и Java Оберонам не конкуренты, потому что на Оберонах пишут операционные системы, а на C# и Java — нет.

OS (Native) Oberon, Aos Bluebottle, XO/2 (реального времени), чего-то там для беспилотных летательных аппаратов было на OLGA,....

Здравствуйте, Сергей Губанов, Вы писали:

СГ>C# и Java Оберонам не конкуренты, потому что на Оберонах пишут операционные системы, а на C# и Java — нет.

На Яве пытались — сейчас эта идея кажется канула в Лету (что и неудивительно )
На C# таки пишут — это Longhorn. Хотя не всю ОС на 100%, конечно.

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

Д>На C# таки пишут — это Longhorn. Хотя не всю ОС на 100%, конечно.
Откуда информация? Поделись ссылками.

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

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

E>>Для посылки сообщений она конечно не обязательна, а вот для приема — да. Или ты свои классы окон ни разу не писал?

Д>За ничем не обоснованную клевету — минус.
А за обоснованную клевету ты плюсы ставишь?

Д>Я то всегда думал, что WindowProc — это функция. А оказывается, это на самом деле процедурная переменная
Процедурная перменная — термин СГ. Называй как хочешь. Нравится "указатель на функцию" — пожалуйста.

Д>Покажи мне ЗДЕСЬ хоть один указатель на функцию.
А покажи мне в своей этой фразе:

Вот еще один интересный вопрос. Каким образом ухитряется работать UI в Windows? Окна обмениваются какими-то мистическими сообщениями, и нигде нет ни одного указателся на функцию!

хоть слово про MFC или про любую другую библиотеку. Ты сказал про WinUI вообще, а оно реализуется вполне конкретно, через WNDCLASS-ы, которые основаны на указателях на WindowProc-ы.
То, что МФЦ научился прятать её за виртуальными функциями — частность. Кстати, насколько я помню СГ и это решение (связывание через VMT) называл процедурными переменными, так что мимо кассы.

E>>Может хватит флудить, а?
Д>не груби.
Не буду. Но и участвовать в этом флуде тоже не намерен, так что ты дальше как-нибудь без меня...

Д>Как нетрудно убедиться, для любого UI приложения в Win32 необходимы и достаточны две основные вещи:
1. Прочитать МСДН и узнать что собой представляет UI в Win32.
2. Ещё раз перечитать МСДН, потому как одного раза некоторым явно не хватает...

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

K_O>Откуда информация? Поделись ссылками.

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

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

Д>Покажи мне ЗДЕСЬ хоть один указатель на функцию.

Да сколько угодно!

1) виртуальная функция твоего класса. Ну ладно, потроха виртуального вызова мы не станем изучать...
2) сам фреймворк MFC регистрирует собственные оконные классы, указывая в них адрес оконной процедуры
3) а также субклассирует окна базовых классов, также указывая адреса оконных процедур.

Д>Как нетрудно убедиться, для любого UI приложения в Win32 необходимы и достаточны две основные вещи:
Д>1. Экспортировать свои оконные процедуры. Существующая реализация делает это с помощью указателей на функции, но для самого ЯВУ знать это необязательно.

Вот экспортирование оконных процедур и есть работа с указателями на эти процедуры.
Ты же их не линкером экспортируешь, правильно?

Тем более, что упомянутый тобой ЯВУ — а именно, С++, — таки обязательно знает.
Это если бы VB был... да и то с оговорками.

Д>2. Использовать PostMessage/SendMessage для косвенного вызова чужих методов
Д>Таким образом реализуются как косвенные вызовы функций, так и некоторый вариант полиморфизма, наследование объектов в рантайме AKA субклассирование, обратные вызовы и некоторые другие вещи.

Это a.k.a. основано на указателях на функции.
Следовательно, твой пример неуместен.

Д>>Покажи мне ЗДЕСЬ хоть один указатель на функцию.

К>Да сколько угодно!

К>1) виртуальная функция твоего класса. Ну ладно, потроха виртуального вызова мы не станем изучать...
К>2) сам фреймворк MFC регистрирует собственные оконные классы, указывая в них адрес оконной процедуры
К>3) а также субклассирует окна базовых классов, также указывая адреса оконных процедур.
4) А ты видел, как устроена MESSAGE_MAP? Так посмотри.

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

E>А за обоснованную клевету ты плюсы ставишь?

Я всегда готов рассмотреть конструктивную критику в мой адрес.

E>То, что МФЦ научился прятать её за виртуальными функциями — частность. Кстати, насколько я помню СГ и это решение (связывание через VMT) называл процедурными переменными, так что мимо кассы.

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

E>Не буду. Но и участвовать в этом флуде тоже не намерен, так что ты дальше как-нибудь без меня...

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

E>1. Прочитать МСДН и узнать что собой представляет UI в Win32.

И снова оскорбления. Про оконную подсистему в Wnd я и так знаю куда больше, чем мне бы хотелось.

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

К>1) виртуальная функция твоего класса. Ну ладно, потроха виртуального вызова мы не станем изучать...

единственная виртуальная функция — это OnInitDialog, да и это тоже не является обязательным

К>2) сам фреймворк MFC регистрирует собственные оконные классы, указывая в них адрес оконной процедуры
К>3) а также субклассирует окна базовых классов, также указывая адреса оконных процедур.

Это всё вопросы реализации. Предположим, что мы ничего не знаем о потрохах MFC и нам доступны только не-виртуальные функции обработки сообщений, а также макросы в карте сообщений. Этого уже достаточно для того, чтобы сделать косвенный вызов.

К>Ты же их не линкером экспортируешь, правильно?

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

К>Тем более, что упомянутый тобой ЯВУ — а именно, С++, — таки обязательно знает.

C# например не знает. Но делегаты — это ведь тоже на самом деле где-то глубоко внутри указатели на функцию.... сказка про белого бычка. Начинаем все сначала.

К>Это если бы VB был... да и то с оговорками.

Вот-вот. Жаль, что я сразу про него не подумал. А что за оговорки, интересно? Что там тоже есть процедурные переменные где-то внутри?

К>Следовательно, твой пример неуместен.

Ну зачем все время валить интерфейс и реализацию в одну кучу?
Я уже скоро начну биться головой об клавиатуру.

Сергей, я уже не в первый раз вижу: операционная система, ПО для
роботов, для космических кораблей...

Так ведь всегда есть [микро]ядро, написанное на ассемблере и/или C.
Просто потому, что Оберон ничего не знает про железо. Я не прав? То же
самое можно сказать про Аду, Смоллток (и на нём пишут ПО для роботов) и т.д.

И почему Вы, кстати, считаете, что софт для космических кораблей —
вершина искусства программирования? Он (сравнительно) невелик по объёму,
пишется высококвалифицированными специалистами по жёстким спецификациям,
верифицируется, имеет (если имеет вообще) крайне простой
пользовательский интерфейс. В него вкладываются бешеные деньги (в
пересчёте на строчку кода или машинную команду). ИМХО, ОС общего
назначения или большие СУБД намного сложнее в разработке.

Сергей Губанов wrote:

> Сейчас я использую старый добрый прием в полемике межъязыковой борьбы
> (раньше этот прием использовался в войне Си против Паскаля). И так,
> пожалуйста:

>

> C# и Java Оберонам не конкуренты, потому что на Оберонах пишут
> операционные системы, а на C# и Java — нет.

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

К>Но следует заметить, что ничего нового здесь не сказано. Многие системы так поступают — да вот хотя бы Lisp, Forth, вроде бы Smalltalk (пусть меня поправят насчёт смолтока).
Да, в Смолтоке все модули равны.

К>А есть ещё "жёсткая" модульность, где всегда можно провести границу: вот это системные библиотеки, а вот сторонние, а вот мои собственные — причём библиотеки из разных пакетов нормально сосуществуют, не заползая в область видимости друг друга.
А как такую границу провести? Можно пример?

Здравствуйте, Кодт, Вы писали:
Ну, вообще-то мы вроде бы можем банально выгребать очередь сообщений и без помощи DispatchMessage, которая собственно и использует зарегистрированные ранее оконные процедуры. .

Здравствуйте, Сергей Губанов, Вы писали:

Вот это и ужасно. Это приведет и к невероятно огромным листингам в одном файле. И к появлению туевы хучи мелкий длл-ек.

Вот, к примеру в проекте Янус (RSDN@Home) сейчас 33 модуля общим объемом ~ 4 мегабайта.

При этом проект состоит из 325 файлов C# (около 2-х мег.) и кучи других файлов. Думаю, на обероне его вообще сделать было бы невозможно.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Сейчас я использую старый добрый прием в полемике межъязыковой борьбы (раньше этот прием использовался в войне Си против Паскаля). И так, пожалуйста:
СГ>

СГ>C# и Java Оберонам не конкуренты, потому что на Оберонах пишут операционные системы, а на C# и Java — нет.

СГ>OS (Native) Oberon, Aos Bluebottle, XO/2 (реального времени), чего-то там для беспилотных летательных аппаратов было на OLGA,....

Гы. Аргумент... ОС на обероне никто в глаза не видел (представляю себе это убожество). А вот сотовыее телефоны с Явой у каждого второго. И Ява-ос есть.

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

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

Д>>На C# таки пишут — это Longhorn. Хотя не всю ОС на 100%, конечно.
K_O>Откуда информация? Поделись ссылками.

longhorn.msdn.microsoft.com
http://longhorn.msdn.microsoft.com/lhsdk/longhornoverview/loconExploringNewPlatform.aspx