Сразу оговорюсь, не надо кричать юзай си, ну а теперь продолжу:

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

Для чего это надо:
1) Дополнительная защита вашего же кода от вас же самих.
2) При наличие исходных библиотек, многие вещи можно делать очень быстро, а внимание уделять только сути.
3) Один раз хорошо написанный класс, потом сто раз оттестированный вами же - вероятность ошибки ниже, как следствие более надежный код.

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

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

3) Мне нравиться чтоб даже без макросов, не говоря уж о всяких там объектах - сорри но это глупо! с таким же успехом можно загнаться до того что: процедуры это глупо, структуры это сакс, модули это для ламеров, и вообще hex рулит.

Вобщем очень интересно ваше мнение.

PS:
не пойму никак толи одного меня на эту тему колбасит, или просто народ молчит, или может не догоняет?

Ну вот и ещё одна больная тема.
Когда я взялся за постановку задачи для AsmDev32 (IDE, который сейчас находится у меня в разработке) - эта самая мысль как-раз была основной. Почему так много времени занимает разработка большого проекта на ассемблере? Ответ: нет того code reuse, который есть в С++ и других обьектно-ориентированных языках.

Есть по меньшей мере два решения:

1. Генератор кода для существующих АССЕМБЛЕРОВ - просто GUI, позволяющий создавать/заимствовать классы, добавлять/перекрывать методы и т.п.

2. Новый АССЕМБЛЕР - с уникальным синтаксисом, позволяющий писать легко понимаемый код. Здесь придётся делать новый компилятор со всеми, так сказать, 'причиндалами'.

В моём AsmDev32 я пошёл по пути #1.
Кстати, почему бы WASM.RU не заняться путём #2?
Собрать команду желающих энтузиастов и вперёд!

P.S. Может быть третий путь - это библиотека макросов, которая позволит ООП, например, FASM сейчас развивающийся компилятор - может кто-нибудь займётся?

JaDS

А что плохого в юзании собственоручно единожды написанных процедур и оформленных в виде инклудов? ;-)

JaDS
Сразу оговорюсь, не надо кричать юзай си
Юзай "поиск по форуму" :-)

JaDS
Объявдение двух контролов (в секции данных):
CheckListBox 10,List1,11,List2
Создание контрола (секция данных)
List1.Create 10,10,150,70,[hwnd],[hinstance]
List2.Create 10,10,150,70,[hwnd],[hinstance]
и т.д.
Это Вас не устраивает?

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

2Asterix: ничего плохого в этом нет, но на мой взгляд будет удобнее юзать инклуды оформленные в классах.

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

2pas: представь что у тебя около сотни контролов (ну или тысячи), с десяток форм, вот и будешь сидеть и думать, List1 - это на какой форме? Да и нет тут полиморфизма и инкапсулирования (хотя я не знаю как у тя реализованны макросы). Это я так понимаю ты в FASM'е пишешь, я там сам делаю похожим образом, но это не жизнь, это выживание.

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

JaDS

В общем-то тема эта совсем не нова и уже обсуждалась на форуме..
Давно существует OOP by Nan & Thomas для MASM.. на board32 есть другие варианты..

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

На мой взгляд, FASM - подходящий инструмент для реализации.
Надо только как следует разобраться с макросами ;-)

Такие "невозможные" для МАСМ вещи, как создание библиотек на основе исходников (т.е компилирование/некомпилирование участков исходников в зависимости от их использования, а не LIB) - в FASM абсолютно реально, это уже используется..
А это уже важный шаг.
Дальше идем на форум Privalov'а ищем макрос "struct" - осталось его "маленько" подправить/доработать..
Точнее - написать подобный, лишенный некоторых недостатков и имеющий дополнительные возможности.

Если у вас есть конкретные идеи, а не просто очень охота асм с нормальным ООП буду рад, если вы поделитесь ими здесь - это будет еще один важный шаг.

А пока я буду продолжать медитацию над возможностью FASM создавать макросы, которые создают макросы, которые.. Пока меня это не достанет окончательно ;-)


pas, похоже, сделал уже несколько успешных шагов в таком направлении ;-)

Такие "невозможные" для МАСМ вещи, как создание библиотек на основе исходников (т.е компилирование/некомпилирование участков исходников в зависимости от их использования, а не LIB) - в FASM абсолютно реально, это уже используется..
Может, просто вместо includelib include писать :) Или я чего-то не понял?

JaDS
по пунктам плиз ...
Пожалуйста.

1) Дополнительная защита вашего же кода от вас же самих.
В чем выражается защищенность кода вообще, и какое дополнение привносит использование ООП?

2) При наличие исходных библиотек, многие вещи можно делать очень быстро, а внимание уделять только сути.
По-твоему библиотеки можно создавать только используя ООП?

3) Один раз хорошо написанный класс, потом сто раз оттестированный вами же - вероятность ошибки ниже, как следствие более надежный код.
Замени слово класс на слово код и предложение ни сколько не потеряет смысл и не изменит лозунгового стиля.

приходиться помнить названия переменных и констант, а почему бы это не оформить как класс и не путаться с именами
У методов и членов класса нет названий?

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

как пример - KOL
Imho KOL - это попытка создать оптимизированную VCL.
А по большому счету библиотека ради библиотеки.

3) Мне нравиться чтоб даже без макросов ... hex рулит
Крайности есть везде.

Я понимаю программисты на низком - консервативны, но может быть уже пора?
Глядя на вопросы ООП'шников (чаще BC++B, MSC++, Delphi реже Java), на их упорное нежелание (или нехватку ума) заглянуть в документацию, исходные тексты, используемых ими классов думаю, что не пора.

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

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

И ведь при переходе многие "старички" кричали - нафига нам этот асм, hex удобней, контроль кода опят таки же выше.
Про это The Svin лучше расскажет :) И потом - не вижу никакой связи между переходом от binary coding на asm и с asm на ООП.

Я понимаю программисты на низком - консервативны, но может быть уже пора?
А консервативность тут при чем?

2S_T_A_S_: я тоже в этой области пытаюсь "медитировать", но пока не очено получается. Кстати фраза "макросы, которые создают макросы, которые.." - чтото уж больно знакомо:) А насчет идей: создать под фасм библиотеку. Хотя как я уже писал, это скорее выживание, чем жизнь.

2q_q&masquer: Ваши речи знакомы до боли - флейм, не надо меня убеждать в полезности бесполезности, я за ооп и имхо! Я хотел узнать о вашем отношении к ооп и всё. А плюсы минусы - всему найдется своё преминение.

Я хотел узнать о вашем отношении к ооп и всё.
Ну дык и спросил бы типа "ребята, что вы думаете об ооп", а ты агитировать начал - нехорошо... Хотя нет, вначале был вопрос, а потом агитация :)
И я, например, убеждать точно никого не собираюсь.

А плюсы минусы - всему найдется своё преминение
Мне это анекдот про комсомольца напомнило - если трахаться, то только в противогазе и в гамаке...

masquer
Может, просто вместо includelib include писать :) Или я чего-то не понял?

Ну если написать include, то потом надо еще вокруг каждой PROC ставить IF/END IF и флаги какие-то вводить, а в FASM - просто используется макрос PROC, который автоматом смотрит, используется код внутри или нет: "if used name.." - красота :-)


q_q
упорное нежелание (или нехватку ума) заглянуть в документацию, исходные тексты, используемых ими классов думаю, что не пора

Это сильный аргумент, но думаю таких людей везде хватает. Тут дело IMHO не в ООП, а в том, что что-то сделать самому или хотя бы подумать, последнее время мало кто хочет - а ведь спросить проще.. так может и до старости доживет ;-)


JaDS
А насчет идей: создать под фасм библиотеку

Библиотеку ЧЕГО?
Для начала IMHO, надо хотя бы создать макросы, которые позволят просто строить мощные структуры даных с возможностью наследования/переопределения этих самых данных при создании новых структур, т.е. автоматически создавать новые macro & struc, которые потом тоже будут создавать новые macro & struc итд..
Privalov приводил пример подобного макорса, но он требует доработки, поскольку не для всех случаев работает.
Сначала он меня устраивал, но теперь попробую написать свой подобный.. Если время хватит


А что до понятия ООП - так мне по большому счету оно по барабану и "библиотека классов" мне мало нужна.. Те же VTable были и до его "возникновения", а потом их извратили, как и много других вещей..

На асме из них можно выжать некоторые интересные вещи.. Например использовать до 6-7ми "бесполезных" бит в адресе "метода" для разных целей ;-) Да мало ли что еще..

Но топик начал плавно перерастать во флейм..
Никто ничего конкретного не говорит пока, все только ругаются ;-)

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