We can make sort-of objects by making a structure with built-in pointers to the procedures, by having a pointer to the procedures, in a struc, but is this very practical? We would probably have to have a bit of macro-programming to say the least, to keep track of which objects are stored at what location, since procedures have variable size. OOP in asm- hard to imagine. Has anyone tried this? And would it be practical? I noticed this here:

http://board.flatassembler.net/topic.php?t=2516

it is pretty interesting, but I wonder about the practicality, let alone the ethics (of destroying all that asm and especially FASM stands for, by making it into OOP) of this type of thing. Just curious what others think about it.

Strange, but almost everyone, when learn enough FASM macro system, tries to implement OOP or some other type of HLL using macroses. It is not bad as a good exercise, but actually it is not very practical for real life applications IMHO.
Actually the nature of the assembler is "procedural" and to try to make it "object oriented" means a lot of code and data overbloat and slower execution.
Macro features have to be used extreamly carefully in minimal usefull quantity, because macro solutions have advantages (smaller and compact code), but have disadvantages too (less clear code - especially for very complex macroses) and the best approach is "modest" one.

Regards

JohnFound, FASM macro system let implement OOP without slower execution. I have made a RadASM template for COM inproc server using my OOP macroses (but I have not implemented multiply inheritance yet, so it generates VTable only for one class). It generates only fields and VTable (you can declare any static methods too). As for me, it is very good solution, because you have no need to write VTable manually. And of course speed and size with FASM are the best (3K for server, which do something, with registration and deregistration from registry).
I think that OOP macroses with careful attention can do the best with FASM.
Regards.

I don't think it's very practical either; however, as Privalov mentioned, with careful attention it can become a great asset and tool, and would not necessarily bloat code unneedingly. Macros are, after all, a very powerful feature of FASM, and of other languages which support them. However, it would take an experienced macro-programmer (I'm not one) to do this sort of thing... maybe someone should make an open-source FASM macro-library for OOP, that anyone can use. Once again, though, must applications probably would be more simple to program in some ways, using normal "traditional" assembly language- I mean, FASM is a procedural assembly language, after all, and not an HLL. Let us try to remember this, but at the same time, try to use OOP if it would make programming easier, more inuitive, etc. There are many advantages and disadvantages to using OOP - I wonder if FASM Macro OOP is true OOP...

There is a interesting topic somewere in to win32 community about OO and ASM , cant find it, but is there .

problem with assembly-newbies is that they try to code assembly way they are used with previous HLL languages. But coding in assembly is another approach, just like Pascal (procedural) <--> Java (object-oriented)

I agree, I prefer traditional assembly. I say to any newbie who wants certain features that are from HLL's, "Why did you switch to ASM if you want that? Go back to your HLL if you really want to." However, there are certain features that can make the programming easier and faster, without making it slow. OOP is one such feature. If used properly, it can be very helpful, and not slow the program down much if at all. Other than the fact that it's against traditional assembly, what is wrong with using OOP or OOP-like structures? We have macros, structures, and other things, which make programming easier without making the program slower. Let's not try to write programs in machine language or debug... FASM is constantly evolving, in good ways. We have no built-in procedures, such as "PRINT" (BASIC) or "scanf" (C), or similar things, but we do have macros, structures, and other things. The goal is to make the task of the programmer easier without impairing speed of the output program. Am I mistaken, or isn't this what FASM is all about?

When you read such topic, pheraphs and I hope that point of view that a hll is equivalent to a paradigm change ....

OK, the OOP forum is that one the thread Im refering to
http://217.160.247.193/index.php?topic=20682.0

Hope that one help a little .

HLL is diferent than a paradigm one dosent implicate the other.

The point is that a programmer only think in a paradigm in terms of HLL and not the paradigm itself.

I think THEWizardGenius got the point for OOP.

FASM is a bit more high level than HLL in some aspects, for me the fact that statements are the real machine instructions is detail. It already provides a macro system, so why worry with data definitions if you don't need? I can't see why the proc/stdcall macro is better than OOP. OOP hides the burden of definining and initializing data. With OOP overall performance and coding speed can be faster, as you program in a more natural way(I feel this), and avoids that fat case statements. Also it provides a modular, component-based approach. Is obvious the beneficts. More understandable, mantainable code.

In my opinion, the current trend among FASM users, i.e. stdcall, is that generates fat, slow code. This was the reason why I researched a way to provide alternatives to that. I not applied on AsmOO yet(may take a long time till there), but the results was posted here. Very good, btw.

So, OOP IS very pratical. At first, OOP in asm seems impossible, mainly because it needs some compiler-feeded information, but FASM macro system does that job.

OOP in asm? Why? Because OOP provides more abstraction and that makes programming easier?
It is true. Objects do provide abstraction. Sometimes they give more abstraction than what you bargained for and workaround are always annoying.

And why oh why... OOP == C++ Java etc...???
Aren't CLOS, Dylan, Smalltalk, etc. OOP?

"a structure with built-in pointers to the procedures"
Why should a procedure belong to datatype? Why not bundle procedures under generic functions?

What I'm trying to say that OOP isn't a well-defined target and its not the only way to get more abstraction. There are a lot more paradigms in programming that just hardware-oriented, object-oriented and procedural... There are more than just one way to use function pointers after all.

So... has anyone succeeded in writing decent OO code with asm?
With multiple inheritance?

The only thing I ask for is that, should there be any improvements on this, please distribute to other users.

Use:
For each class, you SHOULD create an .inc and an .asm file.
This OO INCLUDES INHERITANCE.

For the .inc:



For the .asm file:


Now, some considerations:
I intend to create classes that I might use with COM in the future. Thus, I intend to the methods Constructor,Destructor,ToString as negative offsets in the function table; this is not implemented yet.
Error handling for Win32 is not implemented yet (in my idea, a MUST HAVE). I have already implemented it in another library, but I must reimplement it in this one.
I had implemented the begining of a library exactly like this in Nasm. The problem is, since I couldn't have the function table (with inheritance), I had a very high development cost in time due to misplacements in the function table. I think this is the main thing in a library like this.
Hope everybody enjoys.

well, OOP seems good in general but there are some special cases where result is really unclear and unpredictable, depending only on imptementation of basic OOP paradigms, and this implementation can differ. Also it IS abstraction and thus overbloat, processor doesn't work with object, it works with linera code and stack. Just like structured programming is overbloat, but not that ugly.

Also you cannot always have clear hierarchy, even if you are anyhow good, in real big project there isn't such thing, sometimes you really need to access something which is at-first-sight not releated. Then if you want to solve this in OO manner, solution is ugliest possible, and other things like objects which have no "real" represantion in resulting program (designed just to workaround OOP restictions) or "friends" are ugly and hard-to-understand too. It is nice idea but not always working, unlike our style of linear/procedural programming.

Hmmm procedural programming, yeah I kinda agree
I'd forsake oop if it wasn't used in c++ and other languages

But for the oop side ...why don't we port this to fasm

http://objasm32.tripod.com/index.htm