LclIntf.pas using winapih.inc without defining IF_BASE_MEMBER.

Using include files twice in this way is not very nice, if you ask me.

More code reduction than speed actually. The global 'stubs' can be removed, and the compiler doesn't have to generate code for pusing the 'self' parameter. Not much each call, but there are quite some calls. As the lcl is very big, we should strive for code reduction where possible, IMHO.

Micha.

Hi,

As the code is, currently, we can remove the interface class. The global interface functions will stay and be pointers and the interfacebase will implement them as it does now. The platform interfaces can rewrite the functions as needed, and the private variables can be global variables private to the unit (as there is only one instance of the interface class). Advantages:

1) possibly remove IF_BASE_MEMBER stuff because only one global declaration of each interface function
2) speedup and code reduction, because the self pointer doesn't have to be passed anymore.

What do you think?

Micha.

What do you mean by interface class: the TGTKObject and TWin32Object classes?
What are the global interface functions?

Advantages: 1) possibly remove IF_BASE_MEMBER stuff because only one global declaration of each interface function

That is why we have an api wizard.

2) speedup and code reduction, because the self pointer doesn't have to be passed anymore.

I think these are minor issues. I don't think it speeds up very much. But I haven't done any profiling.

What do you think? Micha.

+ From: Micha Nelissen
+ Sent: donderdag 18 december 2003 10:00
+
+ Hi,
+
+ As the code is, currently, we can remove the interface class.
+ The global interface functions will stay and be pointers and
+ the interfacebase will implement them as it does now. The
+ platform interfaces can rewrite the functions as needed, and
+ the private variables can be global variables private to the
+ unit (as there is only one instance of the interface
+ class). Advantages:
+
+ 1) possibly remove IF_BASE_MEMBER stuff because only one global
+ declaration of each interface function
+ 2) speedup and code reduction, because the self pointer doesn't have to
+ be passed anymore.
+
+ What do you think?

When implementing parts of the GTKObject I was thinking several times of this. If you compare a unit to a single instance of an object then there aren't mucht differences (at first sight)

Sure we can get rid of all wrappers and objects by declaring all functions/procedures as variables with function/procedure pointers. Then for every function we need to declare a function/procedural type.

Now some functions are implemented by default in the base class and if the interface had a better implementation it should be overridden. So if we use function pointers the interface initialisation should take this into account. And also when some functions need to call "inherited". In fact, this way, you are implementing your own VMT.

Indeed this way you can get rid of some ifdefs (you can also get rid of them by introducing another .inc file. the reason why the ifdefs are used is 1. lazynes on my side, 2. force that both headers are the same)

Also indeed you can reduce some calls, since you don't need the wrapper functions anymore.

What would I think... It has some advantages, but I don't expect that there is much speed to gain. (passing self for instance is peanuts compared to the actual function implementation)
One major thing I see is the awful lot of work of rewriting things. Besides that, I don't think that something as gtkobject.inc would become much easier to understand.

Marc

Indeed, this is true. Another idea is to make the functions class functions (if this is supported), so we keep the OOP-ness.

Micha.

We did the same decision for FPC: the code generator in FPC is also OOP (base class contains stuff used by all CPUs and a child class implements the CPU specific stuff) thought it would be possible to do it via units because never one executable supports different CPUs. However, we decided to use the OOP approach because it's less error prone.

The idea of pointers sometimes results in bugs. For example, I had problems with InputBox (nothing was done). After manipulations with the order of dialogs unit, problem dissapeared.

Presently lazarus compiles with fpc-1.9.1, but crashes with access violations early in forms.pp.