Hi everybody!
Is there a macro function or some other means to determine the name of ancestor class for given class in compile time?
Also, i have a question about such a feature in HLA as optimization of strings. (@optstrings)
I can write a procedure such
  procedure tst_proc(param: string);
and call it in such a manner
  tst_proc("blablabla")
Why I cant write mov("blablabla",eax)?
Also can i imitate @optstrings with macros?
Can i determine if the string of characters already defined somewhere?
Posted on 2005-04-28 11:07:36 by Elohim Meth

Hi everybody!
Is there a macro function or some other means to determine the name of ancestor class for given class in compile time?
Also, i have a question about such a feature in HLA as optimization of strings. (@optstrings)
I can write a procedure such
? procedure tst_proc(param: string);
and call it in such a manner
? tst_proc("blablabla")
Why I cant write mov("blablabla",eax)?
Also can i imitate @optstrings with macros?
Can i determine if the string of characters already defined somewhere?


No, there is not. But this sounds like a good feature to add to HLA v2.0.
Cheers,
Randy Hyde
Posted on 2005-05-07 21:01:46 by rhyde
May i suggest also some extention to existing class model.
Include in VMT a field with size of class record, and field with pointer to ancestor VMT.
With help of determining acestor class name with some macro function this improvements can help to implement virtual constructors, such function as inheritsfrom(classaname) and proper call to inherited methods.
I already implement this in my class library by overriding default VMT statement with my own.
But because i didn't find macrofunc to determine ancestor name i had to put each class implementation to
different file and to define in each file constant ?_ancestor_class_: string := "<<ancestor_name>>";? :sad:
Posted on 2005-05-08 02:23:37 by Elohim Meth

May i suggest also some extention to existing class model.
Include in VMT a field with size of class record, and field with pointer to ancestor VMT.
With help of determining acestor class name with some macro function this improvements can help to implement virtual constructors, such function as inheritsfrom(classaname) and proper call to inherited methods.
I already implement this in my class library by overriding default VMT statement with my own.
But because i didn't find macrofunc to determine ancestor name i had to put each class implementation to
different file and to define in each file constant ?_ancestor_class_: string := "<<ancestor_name>>";? :sad:

Sounds like a plan. There are many changes that need to be made to the class structure. For example, statics are handled quite right in the current model. And I'm still trying to figure out a way to avoid linking in all the class' methods when you create the VMT. At one time I was tempted to emit VMTs for a class in each module (thus only having to emit the VMT entries that were actually referenced). Alas, I'd forgotten about the trick in the HLA manual for determining RTTI (which would break if I did this).

Oh well, I'll keep thinking about it.
Cheers,
Randy Hyde
Posted on 2005-05-12 00:00:58 by rhyde
I thought about optimizing VMT and now i can see no way of removing unused virtual methods from VMT
just because i can see no way to determine at compile time if they are used or not.

About static procedures:
There is another problem. I use HLA with MASM to compile my class library into lib file.
As mentioned before i put each class implementation in separate file. When i link some program with this library and use some class,
code of all static procedures that contained in this class is linked into exe. I undestand that this is MASM issure but putting each
procedure in separate file is too much pain for me :-( May be i should try other assembler (FASM) instead of MASM to compile my HLA
programs? Any suggestions?
Posted on 2005-05-12 07:36:36 by Elohim Meth
No, I believe that's a link issue.  HLA generates an ".obj" file for each "unit" and a library is an archive of object files.  The linker grabs the entire object file of the imported function.

Having separate procedures may be a pain, but if you look at the standard library sources, you'll notice that is how they are set up.
Posted on 2005-07-30 02:08:08 by Kain