JaDS
представь что у тебя около сотни контролов (ну или тысячи), с десяток форм, вот и будешь сидеть и думать, List1 - это на какой форме?
List1 был взят для примера. Имя конкретного элемента задаётся при объявлении.
(хотя я не знаю как у тя реализованны макросы)
Скоро я закончу таки статью описывающую данный элемент управления.

"...Давно существует OOP by Nan & Thomas для MASM..."

Этот тип ООП имеет неверные подходы в принципе. Например, адреса методов находятся внутри самого объекта (!). А если есть (как было упомянуто) сотни элементов на форме - тогда таблица методов будет бесполезно занимать место. К тому же: как наследовать от такого класса добавляя другие методы - смещение к данным объкта будет нарушено. Кроме этого, каждый раз вызывая конструктор объкта надо инициализировать таблицу таким количеством MOVs, сколько есть методов. И ещё: нет нормальных (не виртуальных) методов - все методы вызываются через CALL DWORD PTR [EBX+...]- не всегда оправдано.

Кстати, на моём сайте выложена неплохая статья по ООП - но на английском:

http://www.codexxi.com/Oop.html

masquer
Я с подозрением отношусь ко всему, что что-то делается "автоматом". У меня это вызывает комплекс неполноценности смешанный с паранойей :)

Дык это я так выражаюсь - "автоматом". Макрос этот пишем сами, так что паранойи места не должно быть.
FASM дает стандартные средства позволяющие проверить, например, задана ли метка где-либо и использовалась ли она где-либо в другом месте.
Т.е. позволяет, в принципе, построить библиотеку, где есть 500 подпрограмм, засунуть ее в один include, а при компиляции из нее в экзешник пойдут, ТОЛЬКО реально используемые, скажем 20 шт. И не надо линкер даже!
По такому принципу, например, построен весь FRESH.

Да что говорить - FASM может и другие интересные штуки:
Draw.SetCooperativeLevel [.EBX],DDSCL_NORMAL ;; вызываем COM метод (прям так, без invoke).
Макросы такие "автоматически" можно создать при включении подправленных Сишных хидеров (ну, то есть посредством других макросов)
А скоро Privalov обещает добавить еще одну новую директиву - проект развивается и это радует :-)

AsmGuru62
Я с вашими замечаниями согласен, но ведь та модель очень старая еще времен MASM v7.. зачем же ее повторять?

ЗЫ
А статья хорошая, как раз для таких как я, кто не понимает слово абстракция. Только я за EBP :-)

JaDS
Ваши речи знакомы до боли - флейм
Флейм в ответ на твой флейм.
Как иначе можно назвать твои аргументы в Для чего это надо ... и твои ответы на детский лепет в Что обычно говорят противники ....

Я хотел узнать о вашем отношении к ооп и всё.
У меня сложилось впечатление, что об ООП применительно к ассемблеру. Или я не прав?
Мое мнение: Всему свое место.

ну очень охота асм с нормальным ООП ... я щас говорю ... о наследовании, полиморфизме и инкапсулировании.
1) Твои критерии нормального ООП?
2) Ты хочешь написать новый ассемблер?

S_T_A_S_
что-то сделать самому или хотя бы подумать, последнее время мало кто хочет ...
imho делать-то - делают, но не думают.

У меня сложилось впечатление, что об ООП применительно к ассемблеру. Или я не прав?
Абсолютно прав.

Твои критерии нормального ООП?
Я не спец в теории ООП, но из практики - очень бы хотелось видеть абстрактные типы данных, переопределяемые в потомках, это первое, а вообще в данном случае я говорил что реализация ООП в TASM'е убогая, в MASM'е и FASM'е её вообще нет, про другие компиляторы не знаю.

Ты хочешь написать новый ассемблер?
Да я бы с удовольствием, но пока это мне не по силам:(

А и вот ещё что:

Как иначе можно назвать твои аргументы в Для чего это надо ... и твои ответы на детский лепет в Что обычно говорят противники ....
Это не флейм, это моё мнение, я интересовался вашим, и высказал своё. Просто у меня обычно мнения не бинарного типа (да/нет, надо/ненадо), вот я его развёрнуто и высказал, а то что это агитация - агитация первого мая будет

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

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

Это не флейм, это моё мнение
imho это не мнение, а диалог с воображаемым противником ООП, которому ты доказываешь полезность/перспективность ООП, но доводы за (и против) ООП - дилетантские.

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

Например, адреса методов находятся внутри самого объекта
Я думаю, в некоторых случаях это оправданно на ассемблере.

Every class must have its own VMT
Здесь я думаю - should have. При аккуратном использовании это может принести определенную выгоду.

Таким образом, я планирую реализовать (возможно, только в какой-то мере) все 4 возможных варианта.
Так же, надеюсь, в некоторых случаях, можно будет обойтись без явно определенных деструкторов.
Теперь собственно сам вопрос : Как, назвать такие методы ^^ . Положим есть "нормальные" и "виртуальные", а вот эти 2 - ?
По первому приходит на ум - indirect (тогда нормальные - direct), по второму - пока ничего..
(в терминологии я не силен, так что если что - сорри)



q_q
2) Ты хочешь написать новый ассемблер?

Зачем изобретать колесо?
Такой уже есть. Автор - Tomasz Grysztar aka Privalov.


Да еще добавлю. Тему лучше бы назвать Асм и ооп.
Так будут более явно расставлены приоритеты.


JaDS
очень бы хотелось видеть абстрактные типы данных, переопределяемые в потомках, это первое,

А вот, собственно, и ОНО.
Свежий результат 2х дневной медитации - пока в зачаточном состоянии, определяются только данные (методами займусь в ближайшее время).
Макросы CLASS/ENDC создают одноименные стуктуру и макрос для дальнейшего использования / наследования.
Пока не могу уйти от $ в начале имени (см. как пример, последнюю строку) из-за конфликтов имен с зарезервированными операторами FASM'а, но думаю это не так важно для ООП - с объектами все ОК.

Самое главное - работает наследование данных, с возможностью переопределения (см. CLASS WORD2).
Для указания, что структура наследуется, используется знак "!". Есть ли другие предложения?

Как будет готовый рабочий пример - покажу,
а пока жду bug reports, если таковые будут..

;;==================================================================== =======
;;  ..\#A+\class.inc
;;  version 0.2 alpha
;;
;;  Based on Privalov's "struct" macro.
;;  by mythrillus	mailto: s_t_a_s_<SHIFT+2>inbox.ru
;;==================================================================== =======

FALSE = 0
TRUE = 1

macro	CLASS	name
 {	__class.name	fix name
	__class.size	fix sizeof.#name
	__class.fields	fix	
	__class.macro = TRUE	 }

macro	ENDC
 {	__class.macro = FALSE
	__class.define	__class.name, __class.fields	 }

macro	__class.define  name, dummy, [type,field,default,inherited]
 {	forward	local	arg
	common
	struc	name	arg		_%
		forward	if	field eq
				if	arg eq & default eq
					type	inherited
				else if	arg eq
					type	default
				else
					type	arg
				end if			
			else
				if	arg eq & default eq
				.#field	type	inherited
				else if	arg eq
				.#field	type	default
				else
				.#field	type	arg
				end if			
			end if
	common				%_
;;  used internally by CLASS macro
	struc	__#name	arg		_%
		forward	if	field eq
				if	arg eq
					type	default
				else
					type	arg
				end if
			else
				if	arg eq
				.#field	type	default
				else
				.#field	type	arg
				end if
			end if
	common				%_
	virtual	at 0
		$#name	name
		__class.size	= $
	end virtual
	macro	name	arg,extra	_%
	TAICHI	__#name,arg,extra
		forward	
		if	__class.macro = FALSE
			if	~ extra eq
		'error: too many macro arguments.'
			end if
			if	arg eq & default eq
					type	inherited
			else if	arg eq
					type	default
			else
					type	arg
			end if			
		end if
	common				%_
;;  used internally by CLASS macro
	macro	__#name	arg		_%
		forward	
			if	arg eq 
					type	default
			else
					type	arg
			end if			
	common				%_
;;  inherit
	macro	!#name	arg		_%
		forward	!TAICHI	type
			!TAICHI	field
			!TAICHI	arg
			!TAICHI	default
	common				%_	 }

_% fix {
%_ fix }

macro	!TAICHI [arg]
 {	common	__class.fields	fix __class.fields,<arg> }

macro	TAICHI	type,field,[arg]
 {	common	__class.fields	fix __class.fields,type,field,<arg>, }

;;  EOF
;;==================================================================== =======

;;==================================================================== =======
;;  Пример использования

CLASS	BYTE
TAICHI	db,,?
ENDC

foo	BYTE 2
BYTE	22h

CLASS	WORD
BYTE	lobyte,	77h
BYTE	hibyte,	88h
ENDC

CLASS	WORD5
BYTE	;,	77h
BYTE	,	88h
ENDC

bar2	WORD5
WORD5	77h,78h

bar	WORD	55h,66h
WORD 5,6

CLASS	DWORD
WORD	loword,	67h,68h
WORD	hiword,	06h,66h
ENDC

some DWORD <25h,>,<,28h>
DWORD <56h,57h>,<58h,60h>

CLASS	WORD2
!WORD	82h;, 82h
ENDC

another	WORD2 2,7
WORD2	

end_file:	db 255

mov al,[foo]
mov al,[some.hiword.lobyte]
mov al,[bar.lobyte]
mov al,[another.hibyte]
mov al,sizeof.DWORD
mov al,[ebx+$DWORD.hiword.hibyte]

2q_q:
Для чего в язык низкого уровня добавлять высокоуровневые понятия?
ну как видишь нужны

Т.е. ты создал тему в надежде, что есть готовые решения?
а) надежда умирает последней, б) а вдруг я, ломо, живу и не знаю что это уже есть? Да и, как ктото верно заметил, зачем велосипед изобретать? в) а вообще я тему создал чтоб понять, одного меня так плющит или единомышленники имеются - имеются.

И раз уж тебя так эта тема завела, выскажу своё мнение для чего мне, ну или комуто ещё может быть, нужен объектный асм:
1) Как ктото тут писал: большинство не умеют формализовать алгоритмы в асме, и поэтому юзают или си или масмовский изврат.
2) Большинство программистов (это я только про ассемблерщиков говорю) на работе пишут в сях, а асм - это скорее хобби, так чисто для расширения "кругозора".

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

Это дает две схемы поведения:
1) Используя высокоуровневые конструкции быстро разрабатывается алгоритм или приложение. Первое нужно в образовательных целях (а то эта схема бейсик->паскаль->си->асм меня лично добивает, а так будет один язык только "многоуровневый"). Второе нужно для практического применения. Так же это может пригодиться для проверки чего-нибудь - накидал вкратце задачку, проверил, если пашет, то переделываешь в асме (лично я так щас и делаю, тока приходиться для этих целей делфю юзать - сакс) - и это точно нужно! не все ж родились с профессиональным знанием асма! И эти высокоуровневые конструкции помогли бы начинающим писать проги, постепенно углублясь...
2) Значит эти самые "углубившиеся" начинают писать на асме. Причем например загрузчик какой-нить, тогда вообще на голом асме.

Вобщем это ломает стандартную схему "си с ассемблерными вставками" на схему "асм с высокоуровневыми конструкциями". Что довольно выгодно, не надо учить с десяток языков, а можно ограничиться только одним.

По поводу консервативности, тут всё двойственно, особо консервативные утверждают примерно следующее:
q_q: Для чего в язык низкого уровня добавлять высокоуровневые понятия? - но ведь добавлены они уже! Процедуры, макросы, структуры, масмовские приколы - это элементы ЯВУ. Менее консервативные (и более правильно поступающие) используют всё это дело, и как мы видим пишут макросы для квазиобъектности. Но первых повидимому уже не переделать, а почему из-за них должны страдать вторые? - да если честно они и не страдают, просто приходиться постить такую вот лабуду как я щас, хотя заранее знаю что те кому это надо они и так это делают, а те кому это не надо - будут всю жизнь утвержадть что асм должен быть голым - хз почему так, это уже глубины психики, своего рода садомазо. Вобщем надоело спорить на тему надо не надо, НАДО! По крайней мере мне, а разводить демагогию зачем и почему - тоже самое что спорить о сущьности бытия, кроме как флеймом я это назвать не могу. А проза жизни показывает, что чем легче программировать, тем больше людей этим занимаются, а таланты они ж в процентах на душу населения, да ламаков пишущих на асме станет толпа, особенно если иде визуальное сделать, но глядишь очередная домохозяйка занявшись таким асмом и поняв что он ей по силам, станет лет через десять толковым программистом - кто от этого потеряет? А так, погнавшись за легкостью разработки, многие (как и ваш покорный слуга) поподают под сильное влияние vcl и mfc. И сколько талантливых программистов пишут в этой гадости? Прально, а ведь они могли бы писать на асме. Скажем так:
утечка мозгов

PS:
на мой взгляд тема закрыта.

1) Как ктото тут писал: большинство не умеют формализовать алгоритмы в асме, и поэтому юзают или си или масмовский изврат.
А те, кто умеют - кодят в бинари? :)

2) Большинство программистов (это я только про ассемблерщиков говорю) на работе пишут в сях, а асм - это скорее хобби, так чисто для расширения "кругозора".
Я по работе вообще не программист, и асм для меня отнюдь не хобби.

Резюме - я пока для себя не увидел пользы в ООП (особенно в асм.)

"асм с высокоуровневыми конструкциями"
Например? for, while, if?

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

а ведь они могли бы писать на асме
Упаси Господь! :)

очередная домохозяйка занявшись таким асмом и поняв что он ей по силам, станет лет через десять толковым программистом
За такими домохозяками-ассемблерщиками особенно забавно на форумах наблюдать - они разбавляют сухость тем, так сказать :)) Я только ЗА!
Но первых повидимому уже не переделать
Ну, в общем, понятно - по весне и осени, когда обострения идут, всегда появляется кто-то, кто хочет все разломать и все переделать, тут уже, действительно, тему закрывать надо...

JaDS
Высокоуровневый ассемблер HLA.

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

Поэтому я несколько озадачен вашими постами. Если вас действительно интересует вопрос, то стоит IMHO:
- посмотреть линк выше
- сделать поиск по форуму
- сходить на _http://board.win32asmcommunity.net/ - там много по теме было постов
- не устраивать здесь флейм.

Учитывая, что всего этого не было, прихожу к выводу, что q_q & masquer делали объективные замачания в вашу сторону:
Т.е. ты создал тему в надежде, что есть готовые решения

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


А вот по поводу такого:
Было бы идиально создать такой ассемблер, чтобы он позволял писать программу на голом асме (или вообще в опкоды удариться) с одной стороны, а с другой, можно было бы с легкостью использовать высокоуровневые структуры для быстрой разработки.

Еще Козьма Прутков говорил: "Никому не объять.."

И от чистого ООП/HLL в ассемблере начинающим (да и ассемблеру - а будет ли это ассемблер?) пользы не будет никакой, так же как и от IF/ELSE etc..

Я например, пытаюсь что-то делать в этом направлении, не потому, что мне нравится концепция ООП (я вообще слабо понимаю абстракцию и т.п.) - просто потому, что кое-какие идеи из этого я использую и так, причем по-своему (кроме этого - это хорошая практика макросов). А то что мне не надо - я и не буду заимствовать.
Например, CALL LABEL занимает больше места, чем CALL [EBX+8].

Вот еще пример:

align 16
proc foo
  ret
  some useful code
endp

Выглядит странно? Теперь положим где-то в таблице хранится указатель на эту ф-цию (DWORD) и вызывается он так: CALL [ptr_to_foo]. Что будет в таком случае делать ф-ция? На первый взгляд ничего. А где-то есть еще
OR [ptr_to_foo],1 и AND [ptr_to_foo],#FFFFFFFE. После выполнения OR ф-ция делает some useful code, а после AND - ret.
Такие приемы позволяют упрощать логику работы программы.
Вот для удобства таких вещей я и делаю макросы подобные ^^

А доказывать что-то или спорить - есть раздел HEAP и топик captain cobalt'а.
Я надеялся от вас что-то по делу услышать все же :(


pas
Там еще букву "м" надо добавить ;-)

По мойму реализация OOP на MASM32 это полный бред, хороших результатов не добиться, это должно быть реализовано в самом компиляторе. А вот у FASM в этом плане по мойму есть будущее.

есть раздел HEAP и топик captain cobalt'а
топик читал, а насчет раздела - сорри, я пока не разобрался со структурой форума.