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

А если ввести в язык azma такие встроенные типы данных как

стек, дек, лист, дерево поиска, вектор, ассоциативный массив, массивы хешей )). Реализация данного чуда с помощью макросов , я согласен c S_T_A_S на 100%, гимор как для разработчика, так и пользователя.

 

Лучше что-то, чем ничего, а на счет гимора для пользователя я с вами не соглашусь.

Спасибо за внимание!

 

Для пользователя действительно гимора никокого нет - он не будет использовать подобные макросы, вот и всё. Проверено.



Подобное можно реализовать на макросах fasm, но сложность сравнима с написанием несложного компилятора. Да и в результате пролучится некоторый другой язык, а не ассемблер.

 

... и это скорее хорошо, чем плохо...

Макроопределения - одна из самых сильных сторон [макро]ассемблеров. К сожелению, макроопределения используют в основном для упрощения написания кода, но... возможности макроопределений гораздо шире. И [существенно] большую пользу можно получить от макроопределений, позволяющих настраивать язык на определенную предметную область. То есть, воспользоваться тем самым явлением, о котором Вы пишите: возможность достаточно просто создавать "некий другой язык" (реально некое множество языков). Это весьма удобно при решении больших (многоплановых задач).

 

Имхо ООП на ассемблере это избыточность. В Delphi многое и ООП-core реализованно на ассемблере, но с производительностью это не многое улучшает: компилятор то убогий. Множество проблем в данной области возникает как правило не из-за выбора конкретного языка, а не правильного проектирования. Результатом такого проектирования, является мало того что непроизводительный , но еще и малоуправляемый код (стоит лишь немного перебдеть с инкапсуляцией...). Поэтому и появляются на свет такие библиотеки, как VCL и MFC, которые в сущности решают только одну часть задачи - упрощение решения задачи. И как следствие для многих людей (обитателей wasm в том числе ) ООП становится ересью.

Возможно в ближайшем будущем, появится более развитая концепция ООП, которая позволит делать легко расширяемые, и управляемые библиотеки классов.

 

Почему?..

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

... и даже с упрощением решения задачи они справляются только... иногда

 

Проблема ассемблера очень проста. Кто-то кричит "в топку макросы!", кто-то - "макросы рулят, но только мои". А ещё существует 68 несовместимых компиляторов...



Неличие же какой-то библиотеки предполагает, что ею будут пользоваться более, чем один человек. Однако учитывая разнообразие мнений, все кроме автора будут смотреть на обилие макросов как на новые ворота ;(

 

Нет, не предполагает. Всегда, наряду с публичными библиотеками существовали и частные (приватные).

"Стандартизация" (лучше, если на основе классификации) должна стать заботой либо автора (авторов) языка (диалекта), либо "группы поддержки". (Еще лучше, если процесс стандартизации будет поэтапным, сначала "группа поддержки фильтрует и классифицирует макроопределения, предлагает этапность внедрения в язык новых макроопределений, а затем авторский коллектив вводит их в язык)... Конечно, это утопия, но... полезная

 

С приватными библами всё понятно. Но кто их обсуждает на форуме? И менно поэтому, я и утверждаю, что предполагает...

 

Ассемблер превратиться после этого в лучшем случае в C++, а это сведет на нет его преимущества.

Но вся эстетика ассембелера, скорее всего, именно в том, что он "чистый".

 

Ассемблер - это средство разработки программного обеспечения. И он полезен ровно настолько, насколько соответствует своему назначению. Макроопределения не способны превратить ассемблер в C++, но способны облегчить разработку программ для конкретной предметной области.

Как я понимаю, наивысшая "чистота" достигается при написании двоичного кода непосредственно на носитель информации (оперативную или внешнюю память)...

 

Как правило, такие вот "эстеты" и ревнители чистоты ассемблера программы больше чем на 100-200 строчек не писали, но при этом уже готовы в праведном гневе глотки рвать тем, кто даже мысль допускает, что можно invoke, или, о ужас, .if/.while использовать...

 

А зачем использовать .if/.while ?

Что бы увеличить количесво строк и ухудьшить качество получаемого кода?

 

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

 

Код (Text):

1.         test eax, eax
2.         jz invalid_argument
3.         ; код
4. invalid_argument:

Код (Text):

1.         ; проверяем агумент на валидость
2.         .if eax
3.            ; код
4.         .endif

комменты тут естесственно высосаны из пальца, но один из вариантов можно называть "самодукументированный код", а другой - нет

 

S_T_A_S_

как правило в реальной жизни посложнее кострукции получаются, в примерах, подобных твоему, можно и не комментировать особо - обычно на 2-3 строки выше глянуть и все понятно. Мне лично сильно лениво названия меток придумывать, да и не всегда это можно сделать так, чтоб потом через год не вспоминать - что это за название такое и откуда оно взялось.

 

имхо давить все эти ифы вхайлы с инвоками и прочуюю херь! мусор блин! как глянеш сорцы и не поймеш сразу на чем написано. какаято херь нечитаемая... блин бейсик асмом разбавляют и еще имеют наглость называть это асмом... какой нахрен асм! венигрет блин какойто! фтопку!

 

masquer

Вот именно. И когда идёт длинная вереница .if то там совсем ничего не поймешь Тут только специальные макросы могут помочь (которые опять же никому другому непонятны). А названия, да, сложно придумывать, как впрочем и комменты писать грамотные...

 

имхо, наоборот но, может это у меня с головой уже что-то не то )

 

А надо ли спорить? Макроассемблеры тем и хороши, что дают каждому "свободу волеизъявления"

Хочешь пользуйся макроопределениями, не хочешь - не пользуйся. О вкусах не спорят, их имеют...