ООП на ассемблере

А в чем преимущества ООП именно в ассемблере?



Ведь технически все ООП сводится:

1)к передачи еще одним параметром указателя на экземпляр класса во все методы класса

2)Создании в структуре (классе) таблицы виртуальных функций



Асм никогда не будет обладать такойже силй ООП, как С++.

А если кто-то хлчет повторно использовать код, то почему бы не использовать процедуры и не лезть в ООП.

 

HitmaN85

Полностью согласен!

ООП не место в дзене

По моему, это не сила, а всего лишь страх...

 

OlegA11

Обсуждать вкус устриц лучше всего с тем, кто их пробовал.

 

Даже при собирательстве все равно думать призотся алгоритмичкски чоть ты что будешь делать! Ксатти и зада у ООП языкка другие нежели чем у языка допустим низкого уровня!

 

Даже при собирательстве все равно думать призотся алгоритмичкски чоть ты что будешь делать! Ксатти и зада у ООП языкка другие нежели чем у языка допустим низкого уровня!

 

Пробовал, поэтому и перешел на АСМ(В часности MASM32)

 

Уж, если заглядываете в историю, то... хотя бы открывайте глаза... "Собирательство" началось с библиотек, а не с ООП. Благодаря внедрению в сознание программистов парадигмы структурного программирования началась структуризация кода, разделения больших программ на подпрограммы (процедуры и функции). Достаточно быстро пришло понимание того, что многие процедуры и функции неоднократно используются не только в одной программе, но во многих программах. Их стали выделять в отдельные библиотеки, которые собирались линкером...

Следующий этап эволюции - это появление модульного программирования. Модули в отличие от библиотек могли содержать не только подпрограммы, но и данные, обрабатываемые этими подпрограммами. Почти сразу возникли вопросы с защитой данных, размещаемых в модулях, что привело к развитию структуры самого модуля (появлению интерфейсной зоны, зоны реализации, инициализации, финализации...). Собственно, модуль может считаться прототипом объекта (экземпляра класса).

Параллельно шло развитие объектно-ориентированного подхода к разработке программного обеспечения, основанного на классификации, инкапсуляции и полиморфизме. В т.н. объектно-ориентированных языках произошло слияние модульного и объектно-ориентированного подходов.

Это не вывод... Вывод подразумевает некое логическое заключение, а у Вас пустые утверждения, неподкрепленные какой-либо логикой.

 

Который использует высокоуровневые прибамбасы типо invoke!)))

 

invoke - не высокоуровневый прибамбас, а обычный макрос.

 

Это метод которым он выполнен, по сути даже, если это макрос

то высокоуровневой прибамбас!

 

Ещё в старом досовом TASM были объекты. Таблицы виртуальных функций и т.д. Просто мануал где попало не валялся, поэтому под него не особо писали. Да и недоразвитый он был немного. Тот что в си немного помощнее. Да и сами объекты из себя ничего особого не представляют, просто таблицы с адресами функций + наследование и прочая мура. Это всё можно реализовать руками или макросами, при небольшом желании.... Хотя они там и не нужны никому.

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

 

Да нет смысла в ООП кроме как ограничивать свободу пользователей. Гораздо удобнее конструкция:

push [параметр 1]

...

push [параметр n]

push [структура]

call функция

Которой в изобилии в Win32API. А не повторять опыт VCL Delphi и MFC Visual C++, которые только позорят эти два IDE (а также язык Delphi и язык C++)

 

До чего люди дошли: ООП в ассемблере.

Асм и ООП - вещи не совместимые!

 

Microedition
Ну кто вам сказал то?
http://www.wasm.ru/srclist.php?list=8

 

Microedition
Я долгое время делаю среду разработки - Объектно-Ориентированный Ассемблер. Неплохо, но работа застопорилась на некоторое время.

 

Microedition

Почему ж несовместимые? Вполне даже совместимые. Вопрос в другом: а надо ли везде и всегда ООП использовать? Но к языку программирования сей вопрос прямого отношения не имеет.