Homer can you provide an example of inline method usage?
I can't seem to find any in the OA32 package
Posted on 2010-01-28 16:26:54 by rags
Sure.
In the class definition, define a method using "InlineMethod Name, Args", as you would normally.
But when you write the method code itself, write instead a macro whose name is ClassName__MethodName... two underscores.
Now you can OCall this inline method as normal.

As you can see, inline methods are just macros, theres no real benefit from using them except that this scheme allows us to associate a macro with a class in our sourcecode.. theres no placeholder in the class VMT or anything, its all fake, smoke and mirrors..

Posted on 2010-01-28 16:51:44 by Homer
Was that enough or do you need a solid example?

We decided to implement this for two reasons.
#1 is that it allows the programmer to indicate that a macro is strongly associated with a particular class, and is not just some generic macro.
#2 is that this approach is more consistent with C++.

In C++, an inline method is just a macro which describes a small block of code.
But in ObjAsm, its a true macro, with the full support of the macro engine, and so can emit different code depending on the input arguments ('parameters' of the inline method), on top of what C++ inline methods can do.
That is to say, each time you 'call' an inline method (typically from a regular class method), it can be expanded into the same, slightly different, or wildly different code, depending on how good you are at writing macros :)
And note that all this happens at build time, NOT at runtime ... no such 'call' actually takes place, its a macro after all.

This is the preferable way to write methods which typically have no parameters, and are not often referenced.
Having said all of that, if you DO require parameters, be careful how you pass them... pushing them onto the stack won't work, because no call is being made, because no procedure exists.




Posted on 2010-01-29 08:06:33 by Homer
Thanks Homer. That is sufficient.
I don't have plans to use them at this time.
It was more of a curiosity thing.
I saw them in the OA package, and saw you mention them
in your posts, but I didn't see any example of their creation or usage in the package examples.

If I understood you correctly I would do this first:

Object MyObject,  MyObjectID, Primer
    InlineMethod    MyMethod
ObjectEnd


Then code the method as follows:

MyObject__MyMethod MACRO
    .........some code...
ENDM


And finally to use the inline method:

OCall pMyObject::MyObject.MyObject__MyMethod


Homer is this correct?
Posted on 2010-01-29 18:04:05 by rags
All except the last part.
You just OCall pMyObject::MyObject.MyMethod as normal.

The double underscore thing is how OA internally names your methods.
Say you had an Object "MyObject", and it has a method "MyMethod".
When ObjAsm sees the "MethodEnd" (macro), it generates a procedure called "MyObject__MyMethod".
You don't really need to know about that usually its hidden from you, but thats the naming convention that OCall macro is expecting, the same applies to inline methods, except we literally need to follow the naming convention when we write a macro for an inline method.
Theoretically, we could in future extend the MethodEnd macro to handle this in a similar way, but since inline methods are relatively new (were only tacked on to the OCall as a result of a personal request I made in regard to inlining Get-style methods) and since there has been little interest, this simply has not been a priority for Biterider.
As I say, this could change, and if it does, it won't affect existing sourcecode, it will just be one more thing that OA does for you behind the scenes.
Posted on 2010-01-29 19:09:12 by Homer
In C++, an inline method is just a macro which describes a small block of code.
That's a bit of a stretch :)

Sorry if this is a bit pedantic, but... Macros are normally separate from the "main" language, and work by "simple" text substitution. C++ inline methods might be inserted at the call site, but it's not done by simple text substitution. Even C++ templates, which feel more "macro-like" than inline methods, aren't treated this way :)
Posted on 2010-01-31 11:44:02 by f0dder
Sure, my description is simplistic, that was deliberate.
Detailed discussions of the nature of C++ inline methods and macros are not relevant to the question posed.
And regardless of implementation nuances, I'd have to say that ObjAsm's inline methods achieve the desired result - inline code is dropped in-situ.. in fact, our implementation is perhaps a little more flexible, given that we can emit variations of the same inline method by leveraging the macro engine.
We weren't trying to reproduce C++ semantics precisely, just adopting what we believe are the most useful paradigms (on a need-it-now basis).
This is exactly why I got involved in the development of OA - if I don't like something about C++, tough titties, I'm stuck with it. But I can influence the OA language at every level through direct and indirect involvement, with the approval of its key author (for public works), or without (for private projects).

Posted on 2010-01-31 23:35:27 by Homer
Detailed discussions of the nature of C++ inline methods and macros are not relevant to the question posed.
Perhaps not, but you don't need a detailed discussion to not call them macros :)

in fact, our implementation is perhaps a little more flexible, given that we can emit variations of the same inline method by leveraging the macro engine.
And this is genuinely useful - possibly even more powerful than C++ templates.
Posted on 2010-02-01 03:29:03 by f0dder