JaDS
На счет раздела - я про то, что здась как бы ожидалось обсуждние реализации, а не за/против

Chib777
Я с вами согласен. Макросы там очень мощные.

На мой взгляд - нету здесь флейма - обычное обсуждение нужен ООП в АСМ или нет. Легко понимаемый и легко используемый. Согласен, что есть примеры, но хотелось бы что-либо более совершенное.

Я согласен с JaDS - это нужно для повышения производительности написания кода и наверное полезно дла популяризации Ассемблера.

Как-то возникла у меня одна идейка, но было это давно...

Поскольку не хочется делать новый компилятор (слава Privalov-у!), может быть легче сделать генератор кода, переводящий текст (скрипт) в АСМ. Пример:

class TBase
	{
	vars {
		uiMsg:UINT
		wParam:WPARAM
		lParam:LPARAM
		}

	vmt {
		OnWmCreate
		OnWmPaint
		OnWmCommand
		}

	verbs {
		DoVerb1
		DoVerb2
		DoVerb3
		}
	}

; --- Inheritance
class TFrame:TBase
	{
	vars {
		rcClient:RECT	; In addition to 'vars' section of 'TBase'
		}

	vmt {
		OnWmCommand	; Overriden virtual entry
		OnWmSize	; New virtual entry
		}

	; In addition to 'verbs' section of 'TBase'
	verbs {
		FrameVerb1
		FrameVerb2
		}
	}

; --- Using it in some function:
proc foo
	{
	locals {
		frame:TFrame
		} ; Here all constructors called for 'locals' section

	frame.FrameVerb1	; Call 'TFrame' method
	frame.DoVerb1	; Call 'TBase' method
	} ; Here all destructors called for 'locals' section

После пропуска такого скрипта через генератор кода получаем все структуры объектов, все методы присоединены, и т.п. а 'голый' ASM код просто копируется как есть. Всё, где обьекты используются - сгенерировано.

Самое интересное, это если сделать генератор кода как Plug-In. Тогда из одного и того же скрипта получаем код на TASM, MASM, FASM, NASM, ... - и компилируем соответствующим компилятором.

Вот где можно добиться переносимости библиотек классов! Но идейка заглохла... а ведь неплохо было бы иметь один IDE с одним исходным кодом и иметь выход на любой АССЕМБЛЕР - всё что надо это написать Plug-In для нужного компилятора.

Ногами только не бейте!..

S_T_A_S_
Такой уже есть. Автор - Tomasz Grysztar aka Privalov.
И каковы результаты?
Можешь назвать критерии, по которым компиляторы вроде BC++/MSC++/IntelC++/VectorC генерируют код хуже?


JaDS
НАДО! По крайней мере мне, а разводить демагогию зачем и почему ... кроме как флеймом я это назвать не могу.
Демагогию говоришь, ну-ну.
До сих пор твои попытки сформулировать ответ на вопрос "Зачем?" я не могу назвать четкими/обоснованными.
Ты не хочешь макросов, т.е. нужен новый компилятор. Ты представляешь, во что это выливается?

на мой взгляд тема закрыта
С какими выводами?


AsmGuru62
Я согласен с JaDS - это нужно для повышения производительности написания кода
imho использование ООП не входит в лидеры по повышению производительность написания кода.

.. и наверное полезно дла популяризации Ассемблера
Докатились: Для популяризации Ассемблера к нему нужно прикрутить ООП!

может быть легче сделать генератор кода, переводящий текст (скрипт) в АСМ.
И скрипт-программист автоматически станет асмером да еще с приставкой ООП?

AsmGuru62
может быть легче сделать генератор кода, переводящий текст (скрипт) в АСМ..

Слава Privalov-у! Такое в FASM можно возложить на макросы.
Некоторые (пока требующие доработок / изминений) успехи уже есть.

Получается достаточно компактный листинг на асме, с возможностью использовать такие вот вставки:
frame.FrameVerb1 ; Call 'TFrame' method



q_q
И каковы результаты?

В результате имеем для начала "чистый" ассемблер лишенный неоднозначности в синтаксисе.
Далее - этот ассемблер имеет мощное средство управления препроцессором - макросы.
Возможности этих макросов выходят за узкие рамки MS философии.
В частности: macro, struc, даже equ и (новая) fix - всё это директивы для определения макроинструкций.
Посредством макросов можно делать что угодно, от переопределения мнемоник ассемблера до создания новых макросов.

Если вас интересуют результаты непосредственно в ООП, то скажу, что Privalov свою задачу выполнил. Реализация же всяких HLL наворотов (коими являются также INVOKE, ADDR, .IF, PROC, etc) - дело рук пользователя.

Можешь назвать критерии, по которым компиляторы вроде BC++/MSC++/IntelC++/VectorC генерируют код хуже?

Для начала стоит уточнить, а не кроется ли в этом очень обширном вопросе сомнительное УТВЕРЖДЕНИЕ, что эти ^^ компиляторы производят ОДИНАКОВО эфииктивный код? ;-)

Еще хочу повторить, что если в VTable хранится "указатель на метод", то в асме я в этот DWORD смогу еще кое-какую информацию добавить. Как в си без извращений реализовать мой пример на предыдущей странице с "proc foo" ??

Еще, мне непонятно, к чему в этом топике ВООБЩЕ СС+?
Я видел и флейм Вирт vs Страуструп - такие жа пустые аргументы там. Я думаю мы тут про асм говорим ;-)

S_T_A_S_
В результате имеем ...
Опять аргументы, которые мне говорят только, что проект реализован ради проекта. Где примеры кода генерируемого этим ассемблером для ООП и их сравнение с кодом, например, С++ компилятора.

Для начала стоит уточнить, а не кроется ли в этом очень обширном вопросе сомнительное УТВЕРЖДЕНИЕ, что эти ^^ компиляторы производят ОДИНАКОВО эфииктивный код?
Все мои вопросы - попытка выяснить зачем ассемблеру (программистам на ассемблере) ООП если есть компиляторы С++, которые генерируют код лучше, чем большей части людей называющих себя программистами на ассемблере.
Перефразирую вопрос: "Насколько (и по каким критериям) эффективно использовать указанный тобою ассемблер, чем указанные мною С++ компиляторы?"

мне непонятно, к чему в этом топике ВООБЩЕ СС+? ... Я думаю мы тут про асм говорим
afik ООП и ассемблер.

q_q

Где примеры кода генерируемого этим ассемблером для ООП и их сравнение с кодом, например, С++ компилятора.
Какие примеры?? AFAIK, пытались обсуждать как это реализовать..

попытка выяснить зачем ассемблеру (программистам на ассемблере) ООП если есть компиляторы С++, которые..
Зачем обобщать всех людей называющих себя программистами на ассемблере?
Вам не надо - кому-то другому надо.
Зачем надо лично мне - повторю - см. пример с "proc foo" - и это лишь видимая мною вершина айсберга.
А самому языку ассемблера, IMHO, совершенно все равно для каких целей его используют - лишь бы в печь не ставили.

"Насколько (и по каким критериям) эффективно использовать указанный тобою ассемблер, чем указанные мною С++ компиляторы?"
Лично для меня - это вопрос предпочтений.
Никак не могу дорасти использовать DWORD в случае, когла мне хватает флага C.
И все не могу толком понять философию этого языка 70х.
А по поводу эффективности - сравните для начала хоть BC++ & IntelC++ ;-)

afik ООП и ассемблер.
Вы утверждаете, что ООП == С++??

S_T_A_S_
Какие примеры??
Т.е. ассемблера с ООП нет? Не удивляет почему?

Зачем обобщать всех людей называющих себя программистами на ассемблере?
Какая из моих фраз создала такое впечатление?

Зачем надо лично мне - повторю - см. пример с "proc foo" ...
Так это пример иллюстрирующий необходимость ООП, а полагал, что это иллюстрация реализации ООП.

Никак не могу дорасти использовать DWORD в случае, когла мне хватает флага C.
Лет 10-12 назад у меня тоже чесались руки, когда я видел код генерируемый Си'шным компилятором, и понимал, что способен написать более эффективный (по размеру и быстродействию). С тех пор процессоры доросли до PIV (тогда завидовали 386'ым, а если был сопроцессор, то ...) появилась и поучила распространение windows, появился и стал доступным на PC unix'а - linux, с возрастом приходит понимание, что готовить для работы инструменты можно всю жизнь и может не остаться времени на их использование.

философию этого языка 70х
Грубо.

А по поводу эффективности - сравните для начала хоть BC++ & IntelC++ ... Вы утверждаете, что ООП == С++??
Ни в каком из своих сообщений я не агитировал за С/С++, не пытался завести диспут за или против ООП. Я пытаюсь понять какие усилия необходимо приложить для получения удобного (какие критерии удобства? кому-то достаточно макросов, JaDS не формулирует свои критерии) союза ООП и ассемблера и какие выгоды сулит этот союз, а С++ указываю для сравнения, т.к. считаю его наиболее близким (из ООП) по духу к ассемблеру.

q_q
Т.е. ассемблера с ООП нет? Не удивляет почему?

Асм с ООП есть. Но существующие модели заимствованы из HLL без адаптации к низкоуровневости ассемблера.
Я имею ввиду, что нет смысла копировать. Взять то, что действительно полезно, а что-то и выкинуть.

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

с возрастом приходит понимание, что готовить для работы инструменты можно всю жизнь и может не остаться времени на их использование.
Когда завидовали 386'ым и ковырялись в 16битных сегментах ДОСа, а более счастливая часть человечества писало на асме под нормальные процы применяемые в баллистических ракетах, я делал одну демку для Speccy и для ее успешной реализации мне пришлось написать свой музыкальный редактор (поскольку существующие не устраивали).
Безусловно, вторая задача была на порядок сложнее первой и заняла приличное количество времени.
Однако пользы (мне) принесла заметно больше.
Так что и в данном случае я просто считаю, что это хорошая школа программирования для меня (!)
К тому же, те макросы, которые я делаю, возможно, окажутся полезными другим людям для других целей.

Я пытаюсь понять какие усилия необходимо приложить для получения удобного (какие критерии удобства? кому-то достаточно..
Вот это, я думаю ключевой момент. Прелесть ассемблера, IMHO - отсутствие стереотипов.
Поэтому я не считаю, что будет толк от "внедрения ОБЩЕЙ модели ООП".
Для конкретных категорий задач могут оказаться полезными какие-то конкретные приемы реализации..
Для других - полное отсутствие и тени ООП.
А если делать "универсальный инструмент", то мы опять придем к С.

А вот какие усилия затритить.. Для меня - избавиться от остатков МАСМовской модели макросов в памяти, поскольку она порой все еще мешает пользоваться совершенно другой идеологией. Новый ассемблер создавать не надо :)

FASM дает возможность использовать в полях структур не только DD/DB, но так же и макросы (!).
Грамотно написанные макросы struc - позволят создавать "объекты" на базе этих структур.
С возможностью наследовать / изменять заданные по умолчанию свойства полей.
А так же избавиться от типичных ограничений для структур в МАСМ.
Моя цель сейчас - решить некоторые существующие еще проблемы с этим
А вот с постами сюда, я вероятно поторопился..

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

JaDS не формулирует свои критерии
Вот это и плохо.. Я не начинал эту тему, а предложил кое-какие наброски которые у меня имелись (у него тоже FASM) - но он что-то быстро охладел..

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

А какие там ограничения?
Да они не только там. Синтаксис FASM:

struc	foo
{	.first	dd ?
	.second	dd ?	}

struc	bar
{	.old	foo
	.new	dd ?	}

data	bar
mov	eax,[data.old.second]

А я хочу:
struc	bar2
{	old	foo	;; 
	new	dd ?	}

data2	bar2
mov	eax,[data.second]

Последний вариант, нереален стандартными средствами (если не считать COPY/PASTE)
Поэтому я делаю макрос, способный мне заменить стандартный struc и справиться с этой задачей.
В DD, конечно, можно задавать и реальные данные, а не ?

А вот в использование макроса в качестве поля структуры - интересная штука - только в FASM:
data2.GetFromFile

Ну, я так делаю

struc bar2
old foo<> 
new dd ?
ends
...
lea eax, bar2
mov edx, [eax].bar2.foo.second

S_T_A_S_
Для других - полное отсутствие и тени ООП
Наконец-то. А то тема начиналась с того, что ООП - панацея от всех бед, а ассемблер с ним не дружит.

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

masquer
Во.. так любой может. А вот так: mov edx, [eax].bar2.second ?



q_q

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

Т.е. хочешь избавиться от промежуточного поля old, выполняющего роль "базового класса"?
Уже избавился. Не для всех случаев пока нормально оттестировано и/или работает.

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

FASM дает возможность использовать в полях структур не только DD/DB, но так же и макросы (!). - кинь пример, а то я чтото этого не догнал, я то без struc делал:

macro TForm [name, caption ...]
{
  name#.caption=caption; не проверял но чтото типа того
}

Твой пример я делал примерно так:

macro	foo, [name]
{	name#.first	dd ?
	name#.second	dd ?	}

macro	bar, [name]
{	foo		bar
	name#.new	dd ?	}

bar	data
mov	eax,[data.second]

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

macro TForm_Create, [name, tmp]
{
  name#.tmp  db tmp
}

macro TForm_Create, [name, tmp]
{
  name#.tmp  dd tmp
}

Но было неудобно что приходилось делать так: <макрос> <имя объекта>, <[параметры]> Хотелось бы <имя объекта>.<переменные> - походу со структурами так можно будет сделать, так что кинь пример (попрощеее, твой первый пример я не догнал :( )

2q_q:
Я пытаюсь понять какие усилия необходимо приложить для получения удобного (какие критерии удобства? кому-то достаточно макросов, JaDS не формулирует свои критерии) союза ООП и ассемблера и какие выгоды сулит этот союз
ну вообщето я их уже не раз тут высказал, но ещё раз повторю:

Мои критерии удобного союза:
в идеале чтоб в препроцессор были встроены дерективы описания сложных структур данных (классов короче, про шаблоны не знаю, я с ними толком не знаком, вообще помоему шаблоны - это классы с абстрактными полями данных, зачем название новое придумали? - но это я в сторону ушёл). Впринцыпе похожие вещи можно и макросами сделать - но если это будет встроенно в препроцессор, то это сделает код более стандартным, а не так что у каждого своё.

Выгоды от союза:
опять двадцать пять:( ну скока можно??? ладно, повторенье мать ученья:
1) скорость разработки продукта
2) не требуется знать как устроен объект для работы с ним, достаточно знать его интерфейс - легче разбираться с чужим кодом
3) вложенность названий: MainForm.ButtonCancel.Handle - более понятно чем h307
4) ну куча ещё чего...

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

Т.е. хочешь избавиться от промежуточного поля old, выполняющего роль "базового класса"?
В данном примере от лишнего слова в названии (data.old.second). Но зачастую под этим кроется лишний код, от которого и надо избавляться. (в этом беда VCL и MFC)

Наконец-то. А то тема начиналась с того, что ООП - панацея от всех бед, а ассемблер с ним не дружит.
Начинал я, значит намек на меня? я прально понял? - и где это я такую глупость спорол? я вроде бы говорил "идиально...многоуровневый язык". Чтоб где надо - ООП юзаешь, где надо - опкоды, по середине на асме, НО ГЛАВНОЕ в одной среде, в одном языке, чтоб не учить десяток языков и библиотек, и чтоб программисты всего мира работали друг на дружку (вот это точно агитация:) - а то какой мне толк от всего что написано на си, если я в асме пишу (верней пытаюсь).

S_T_A_S_
А мне не в лом набрать первые буквы, а там ИДЕ достроит :)

JaDS
По поводу выгод:
1. По поводу скорости - спорный вопрос. Получается, что мне не только написать десяток процедур нужно, а и распихать их по классам и держать в голове кроме самой задачи еще кучу лишних данных? Вообще, на ассеблере, как правило, крупные проекты не пишутся (хотя исключения есть :)), а в мелочевке ООП ну 100% не нужно. Имхо, даже сама идея утопична.
2. Это на высокоуровненых языках так, я на асме почему и пишу - мне гибкость нужна и отсутствие ограничений - я сам себе и оптимизатор, и компилятор и еще Бог знает кто :) И потом - у меня своих глюков хватает, чем чужие вылавливать :)
3. Покажи мне хоть одно ИДЕ которое будет такое поддерживать для ассемблера.

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