Quantum
Нет. Оно меняет местами причину и следствие.
Утверждение повторное использование - это признак ООП я трактую, как "повторное использование невозможно без ООП", а это не верно.
Если ты дашь свое определение повторного использования, то возможно ясность наступит и тут.

q_q
Вот вы все говорите - шаблоны мышления.

Хорошо.
Вот такая абстрактно-дзенная задачка: реализовать GUI.
Дано: ничего нет.
Нет ни MFC, не C++, тем более нет [censored]. Нет WinAPI.
Есть только: экранная память, данные от мыши и клавиатуры.
Этого не достаточно? Конечно, можно использовать еще 2 вещи.
Какие? Выбирать вам, мне просто интересны мясли по этому поводу.


HINT:
[ The Svin :
Дык таблицы указателей на функции.
Это что как то за ОПП кто-то пытается закрепить :)
Тогда таблица векторов прерываний тоже ОПП :)) ]

S_T_A_S_
Вот вы все говорите - шаблоны мышления.
Цитату пожалуйста.

Дано: ничего нет ... Есть только ...
Противоречие.

можно использовать еще 2 вещи
Зачем и почему именно две?

q_q
Вы любите придираться к мелочам?

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

Дано: ничего нет ... Есть только ...
Нет ГОТОВЫХ решений и библиотек. Есть только ресурсы. Так пойдет?

S_T_A_S_
Вы любите придираться к мелочам?
Imho это попытка опровергнуть невинное (или преднамеренное) неверное толкование своих слов.

Можете использовать сколько хотите. ... Нет ГОТОВЫХ решений и библиотек.
Начну связывать ассемблер с ООП, это гораздо интереснее, чем заниматься решением поставленной задачи. ;-)

q_q
Начну связывать ассемблер с ООП, это гораздо интереснее, чем заниматься решением поставленной задачи. ;-)

Вот когда свяжете, то сможете ее решить. Без MFC, etc
И найдете ответ на вопрос: Зачем и почему именно две? ;-)

S_T_A_S_
В своих программах MFC не использую.

И найдете ответ на вопрос ...
Зачем?

q_q
Зачем?

Странный вопрос, IMHO
Если вас не интересует асм и ООП, то смысл писать здась?..

S_T_A_S_
смысл писать здась?
Я уже писал (пару раз в этой ветке), что хотелось бы узнать о мотивации создания связки ассемблер + ООП кроме утехи своего самолюбия.

Так что там еще надо для GUI? CPU и RAM?

q_q

А вы никогда не задумывались откуда и зачем вообще возникло ООП?
(Я имею ввиду не коммерциализацию этой идеи и "решения" предлагаемые с целью обогощения небезызвестных монстров)

Я имею ввиду ответ на мой вопрос выше.
(CPU и RAM - не угадали - это тоже ресурсы. Я о способах/инструментах реализации )

2S_T_A_S_: 1) модули - не в одном же файле винду делать 2) ООП - так проще реализовать, и проще потом будет под такие "окна" писать.

Кстати почитал я тут про КОП - гы, примеры надо, так я ничего не понял, впринцыпе ограничение на полиморфизм в рамках одного модуля - так похожее в делфях есть (protected секция), только я думал это ООП.

q_q
"..о мотивации создания связки ассемблер + ООП кроме утехи своего самолюбия..."

Замечательно сказано!
В точности причина зарождения AsmDev32.
Только потом мне подумалось: "...а может это не только мне надо?.."

Что такое ООП? (с моей точки зрения, разумеется)
Не будет никаких private, protected, public, friends, overloaded operators, and stuff like that...

Мне лично для счастья надо следующее:
1. Простое наследование
2. Перекрытие виртуальных методов
3. Автоматическая инициализация и де-инициализация объектов

Причём: не хочется иметь такие конструкции (при пользовании классом, наследованным от большого количества классов-родителей.):

mov object.base3.base2.base1.member, eax

или

call object.base3.base2.base1.foo

А хочется наследовать класс от скольких угодно родителей и нормально пользоваться:

mov object.member_for_a_first_base_class, eax
mov object.member_for_a_last_base_class, edx

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

А как вы это реализовать хотите, если не секрет?
MASM такое не позволит стандартными средствами (TASM тоже?)

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


В FASM'е я написал набор макросов, который позволяет это делать для структур
подобным образом:

CLASS  FOO
      DWORD  some
      METHOD  do,  FOO.dosomething  ;;  здесь можно будет и убрать FOO, но см. ниже
      METHOD  do2,  ANOTHER_FOO.do  ;;  можно явно указывать "чужие методы"
ENDC

CLASS  BAR
  !FOO       ;;  наследуем, можно перекрыть метод
     DWORD  field
     METHOD  new, ExitProcess
ENDS

Создаются структуры (такие же как и при использовании STRUC)
Теперь можно:

mov  eax, [ebx+BAR.some]
call  BAR.do      ;;  call  FOO.dosomething
call  BAR.do2     ;;  call  ANOTHER_FOO.do
invoke BAR.new,0  ;;  invoke ExitProcess,0
...... 

Пока это реализовано для статических методов, но возможности макросов еще далеко не исчерпаны.
Хотя сейчас эту затею приостановил. (Не знаю нужно ли мне будет 28 предков)


Тут еще одна проблема появляется:
Многие пользуют MASM, а в общем-то ассемблер этот бесперспективный (в плане развития)

FASM же развивается и достаточно быстро. Возможности его в общем-то выходжят за рамки "обычшого" ассемблера.
Начиная от создания секций импорта/експорта посредством макросов и.. даже для перекодировки KOI8->CP866 подходит :)

S_T_A_S_
"...Я так понял IDE будет обрабатывать скрипт и создавать на его основе .inc файл?.."

Что-то в этом роде...