(Closed)-SERIALIZED keyword for parameters of functions wish list!

[jamie]

Would be nice if I could ensure the function would process a single function source of data for various parameters in the protocol header.

 Currently the compiler will not guarantee this using the same function as the source of data in the order as indicated.

 
 Just a wish !

[BildatBoffin]

User attributes and introspection (reflection on these attributes) could solve that.

[PascalDragon]

Would be nice if I could ensure the function would process a single function source of data for various parameters in the protocol header.

 Currently the compiler will not guarantee this using the same function as the source of data in the order as indicated.

I don't get what it is exactly that you want?

[jamie]

 I need to force the compiler to build the parameters from functions in order.

 Currently it seems the compiler may call these functions in random order and then populate the parameters for the final function header.

  These functions need to be called in order in the background, at times they are not.

 FucName(Fun1, Fun2, Fun3,..);

 in the background, the compiler may call fun2 first or even fun3

I have a couple of apps written in Delphi 32 using a PASCAL call that seems to follow the order correctly.

[Thaddy]

You mean function chaining? That is already possible. KOL is built around that.

[ASerge]

These functions need to be called in order in the background, at times they are not.
 FucName(Fun1, Fun2, Fun3,..);
 in the background, the compiler may call fun2 first or even fun3

Code: Pascal  [Select][+][-]

1. V1 := Fun1;
2. V2 := Fun2;
3. V3 := Fun3;
4. FunName(V1, V2, V3...)

And there is no need to change the language.

[jamie]

Ok, this is going nowhere.

Doing such things only bloats the code and slows down the process.

As I stated before, time is everything. it's a major overhaul to get fpc to perform as needed in these apps.

I'll keep these apps in Delphi as it works as expected there.

I've already tried doing all of that which does work but, in the end, the code gets bloated and slows down.

This code runs on low power units where memory and process speeds aren't the greatest and response time to hardware is important.

[Thaddy]

If the functions depend on each other, they are executed in-order.
I checked with some audio buffers (delay-reverb-modulation-compression, where the delay must execute before the reverb and the compression must execute last otherwise you get different results).
So I wonder where the original question came from? As far as I can see the execution is always in-order.
Looks like there is no issue at all. There can only be an issue if the functions run in different threads, but that should also be an issue with Delphi. In my code  - as threads - delay will return almost always first from a thread since it is the shortest, simplest code, wherever I put it in the effects chain.
But you did not mention threads.
Like PascalDragon I am curious what exactly is your problem?
So it may be marked as solved, but I am intrigued by your issue, so please expand a little further.

Maybe just a matter of using QueueAsyncCall? That also guarantees that the compiler executes the functions in-order, sequentially.

[PascalDragon]

Currently it seems the compiler may call these functions in random order and then populate the parameters for the final function header.

Correct and this is not intended to change as it allows the compiler to better optimize the code.

I have a couple of apps written in Delphi 32 using a PASCAL call that seems to follow the order correctly.

A calling convention does not describe in what order the parameters are evaluated only in what order they are passed. If you see a specific behavior this will simply be how the compiler is implemented. E.g. a C compiler (the pascal] calling convention is supported there as well) might do it completely different to Delphi.