Yet another basic 'OOP Class' utility!

[skywalk]

I am not a huge consumer of com. For functions of that nature, I use scripting or native DotNet code.

LilClass offers the following:
Very simple syntax
Simple inheritance
Method over-riding
Class constructor and destructor
No need to deal with vTables

You mentioned prototypes. Why did you shy away from a Prototypes in Structures approach?
I find it truly bare bones syntax and without macro's or Interface table.
Yes, I have to hardcode the Prototype functions, but that is code that must be written anyway.
And there is the small overhead of the ASM macro to get the caller.

Code: Select all

Macro GetCaller(me) ; Get struct pointer from caller
  CompilerIf #PB_Compiler_Processor = #PB_Processor_x64
    !mov [p.p_me], rbp
  CompilerElse
    !mov [p.p_me], ebp
  CompilerEndIf 
EndMacro

[srod]

For one thing, extending a base 'class' based on prototypes in structures renders the inheritance invalid because the underlying class structure is no longer an extended version of the base class structure. No such problem with interfaces because the vTable keeps the method pointers completely separate. What I mean is that with this prototype set-up, you would not be able to call the base class methods on an extended object. You'd have to over-ride ALL base class methods which kind of defeats the point of inheritance. You can get around this of course with prototypes, but you'd either end up with something akin to vTables and interfaces or something likely to be quite messy!

Nope, interfaces all round for me. Far neater and, well, it is what they were designed for.

**EDIT : sorry, didn't realise you had posted a link to an example of 'classes' using prototypes in structures and, yes, inheritance no problem with that implementation. I am so 'ingrained' with placing method pointers at the beginning of a class structure (with or without vTables) that I overlooked the obvious! Anyhow, I have to say that inmo, the prototype method is rather messy as you can end up with an extended class structure containing base-class properties followed by base-class prototyped method pointers followed by extended-class properties followed by extended class prototyped method pointers... You cannot re-organise this structure without breaking the inheritance aspect. Interfaces based class structures, on the other hand, just have a single vTable pointer followed by all class properties (base-class and extended-class). Much nicer to look at and much easier to maintain.

[skywalk]

Interesting, I will have to build a few examples in both approaches. I rarely go past my base class. Not a total oop proponent.

[mk-soft]

Here you also have to make a difference between object oriented programming languages (like .Net and C++)
and object oriented programming (like Purebasic and C Standard).

This must not be forgotten.

[Kwai chang caine]

Hello SROD happy to read you

I'm on W10 X64 / v5.70 x86
It's normal, i'm again alone to have IMA on "Demo - embed one class object inside another" at line

Code: Select all

EndProcedure AsClassMethod(Box, InitObject)

[srod]

Confirmed. That is odd.

*EDIT : doh! I'm an idiot! Will upload a fix soon.

[Kwai chang caine]

Thanks a lot GREAT MASTER that works now
I like the RED, but without it's not bad too

doh! I'm an idiot!

You ???? It's the sentence the most funny i have never read

You have take the wrong role in the forum, remember it's me the permanently idiot and it's my place for the life
You ...you always be the "GREAT MASTER" at my eyes.
Even if a day, by miracle, you made a little fault...it's a nice GREAT MASTER fault

[srod]

All fixed Kwai. Not sure how you got it working because I hadn't uploaded the fix before your post! Mind you, it was the sort of bug that would some times remain hidden and not cause a problem.

7th Feb 2020.
Bugs fixed.

Added an alternative way of creating a class object. For example, suppose you have defined a 'Box' class then you can simply use NewBox() to instantiate a class object of this type for convenience.

This does have a couple of limitations mind (due to limitations with PB's macros) in that it can fail if you try to use it without defining any class methods for example. If you lay your class definitions out logically (see the demos) then the compiler shouldn't complain. If it does then add the class name to EndClassProperties(). That is use EndClassProperties(Box) instead. If this doesn't stop PB complaining then simply use NewClassObject(Box) together with InitClassObject() instead of NewBox().

[FlatEarth]

Hi srod,
Excuse me for my amateur question, whether this useful for call c++ .dll functions?

[Kwai chang caine]

All fixed Kwai. Not sure how you got it working because I hadn't uploaded the fix before your post! Mind you, it was the sort of bug that would some times remain hidden and not cause a problem

Yes you have again right, because when I tried it worked
That remember me my history of DLL calling , when you have found my problem, there are a long time
So it's a thank in advance then, but when even merited

[srod]

Hi srod,
Excuse me for my amateur question, whether this useful for call c++ .dll functions?

Not really no. The purpose of this little utility is to provide a 'convenience' wrapper around simple interface based classes and vTables etc, nothing more. That is, it can make the task of creating an interface based class in PB a bit easier (a matter of opinion though!) I find it useful.

If a dll function is returning an instantiated interface pointer then, well there really is little need for anything but the definition of the interface in question and for that this utility will not offer much help as there is no class structure for you to create or a vTable etc. The dll would have seen to that.
It could help if you are required to implement an interface yourself and pass it back to the dll as a parameter to a function etc, but that is a different matter. Similar to creating a COM component really.

So, unless you need (or want) to create interface based objects in your PB program, then no, this utility (and similar utilities) will offer nothing.

As for c++ dll's. Always a bit of a mare what with possible 'name mangling' and the like, especially it if is exporting OOP classes and not using 'c linkage' with its exports. Sorry, no help on that score with my little utility.

[FlatEarth]

@srod : Okay, thanks for your complete reply.

[Kwai chang caine]

It's a pity, i don't know if using all the C++ dll in PB is really possible, but imagine the power that can adding to PB
Break this devil frontier between the procedural and OOP
The same style of power you adding to PB with your amazing COMATE

[srod]

It's a pity, i don't know if using all the C++ dll in PB is really possible, but imagine the power that can adding to PB
Break this devil frontier between the procedural and OOP
The same style of power you adding to PB with your amazing COMATE

Keep dreaming Kwai.

Best off using the same C++ development tools as was used to create the DLL because of all the name mangling afoot with class-based dlls. Straight forward c++ dll's with c-linkage are generally fine.

[srod]

8th Feb 2020.
Added an OverrideClassMethodForIndividualObject() macro which would only be useful for certain esoteric applications (such as my own!)

This can be used on an individually instantiated object to override the given method without altering the underlying class or other objects of the same class. That is, all other class objects will still use the original class method (unless otherwise over-ridden themselves!)
Once this has been used on an individual object, any changes to the underlying class methods will not be reflected in the given object and so this should only be used after all class methods have been defined.

By way of an example, imagine two objects of the same class. Both will, at the outset at least, expose the same class methods. If we use this new macro on one of the objects to alter one of the class methods, say a \GetWidth() method for example, then the two objects will still expose the same class methods, but one of these objects will use the new \GetWidth() method implementation whilst the other will defer to the original \GetWidth(). All new objects of this same class will continue to use the original \GetWidth().
This is of course in addition to the ability to switch all class methods for an individual object when creating the object (by substituting an alternative vTable pointer).

I admit this is a somewhat 'specialised' facility and most people would not have need for it - only complete nutters like myself and fangbeast!