variable numbers of parameters in function

[ALAN-MHz]

I'll try to explain my question with some examples:

Code: Select all

Procedure Test ( *a = #Null , *b = #Null )
 If *a
  Debug *a
 EndIf
 If *b
  Debug *b
 EndIf
EndProcedure

Test ( 1 , 2 )
Test ( 3 )
Test ()

This code works good in debug, so seems that is possible to pass different number of parameters to a function, now the problem:

Code: Select all

ProcedureDLL Test ( *P1 = #Null , *P2 = #Null , *P3 = #Null , *P4 = #Null , *P5 = #Null )
 
 If *P1
  MessageRequester ( "Test 1" , Str ( *P1 ) )
 EndIf
 If *P2
  MessageRequester ( "Test 2" , Str ( *P2 ) )
 EndIf
 If *P3
  MessageRequester ( "Test 3" , Str ( *P3 ) )
 EndIf
 If *P4
  MessageRequester ( "Test 4" , Str ( *P4 ) )
 EndIf
 If *P5
  MessageRequester ( "Test 5" , Str ( *P5 ) )
 EndIf
 
 ProcedureReturn #true

EndProcedure

I compile this code as a standalone DLL, now if i try to use inside purebasic ide in debug with CallFunction/CallCFunction/CallFunctionFast/CallCFunctionFast if i try to pass less parameters to function (example 3) i corrupt the stack because seems that function run anyway with all 5 parameters inizializated (MessageRequester 4 and 5 are showed), the proof is that if i add to code:

Code: Select all

 EnableASM
  PUSH EAX
  PUSH EAX
 DisableASM

To startup of function the parameters are shifted and the stack is not more corrupt.

My problem is:

1) I need to compile a DLL with more function all with variable parameters
2) Every function works different in dependency of number of parameters
3) I cannot pass number of parameters to function as parameter as workaround

Any help to solve this problem if exist a possible solution ?

[netmaestro]

CallFunction/CallFunctionFast etc. are limited and shouldn't be used. Having been deprecated some years ago they're only there for backward compatibility. Prototypes were made for exactly this purpose and they will work correctly:

Code: Select all

OpenLibrary(0, "testdll.dll")

Prototype tester( *P1 = #Null , *P2 = #Null , *P3 = #Null , *P4 = #Null , *P5 = #Null )

Global Test.tester = GetFunction(0, "Test")

Test(1,2,3)

With this code you get three messagerequesters and that's all. No corrupted stacks or unexpected results.

[Josh]

Having been deprecated some years ago they're only there for backward compatibility.

Do you have a link to an official statement of this?

[Olli]

It has not been deprecated, but for facultative arguments in DLLs, the prototypes are required as the example of netmaestro.

An other positive point when we use macro versus CallFunctionFast() is the availability to insert a level between caller level and called level, without change the code, except a little head preset. That is absolutely unable with CallFunctionFast().

[Josh]

It has not been deprecated, ...

Yeah, I know. It's just annoying that for at least 10 years, claims have been made again and again, which only become 'true' because they are repeated over and over again:

- CallFunctionFast() is deprecated
- Define is not allowed in procedures
- Goto is deprecated

These are all official Pb commands that are still valid and where nobody could tell me where they were officially deprecated. All these functions have their right, if they are used correctly. For example, CallFunctionFast() is simply to use and perfect for jumplists.


@Olli: Ask Fred to reset your old account. He did it to me once too.

[netmaestro]

This one is tricky. CallCFunction() uses 'Any' as parameter type, which means than the type of the parameter is determined by the result of the expression. As Val() returns a 'quad', the whole expression is handled as quad, and then a quad is passed to the function.

I'm not sure how to fix this. We have several possibilities:

- We replace all the parameter types from 'Any' to 'Integer', so we couldn't pass quad, double, float parameters anymore.
- We remove these functions which aren't useful anymore, thanks to prototypes.
- We don't change a thing, and probably someone else will fall in the same trap.

In the end they weren't removed to retain backward compatibility. But as you can see Fred calls them useless, they aren't maintained and updated anymore, that's the very definition of deprecated. Whether they're left in the compiler or not is irrelevant.

[Paul]

These are all official Pb commands that are still valid and where nobody could tell me where they were officially deprecated.

Well, the definition of "depreciate" is "to express disapproval of"
and if you look in the PureBasic Help file you will find remarks like...

GetFunction() ... The function can be called by its address using prototypes. The functions CallFunctionFast() and CallCFunctionFast() can also be used for that, but prototypes are the recommended method as they are more flexible

CallFunction() ... Note: This function is not very flexible and does not handle string/float/double/quad parameters or string/float/double/quad returns. The use of prototypes is now strongly recommended.

The wording in the Official Help File certainly shows a disapproval of using these commands, therefore making these commands "depreciated"

No one said the commands were discontinued, obsolete or not still valid, just depreciated, and that other commands were preferred.

[Olli]

@Josh

I created a off-topic subject to answer you about lightly changes of my account.

It is simpler when a reader will come and will read this subject.

CallFunctionFast() keeps a good future, but the prototypes allows us to treat easily and confortably the DLLs, and exactly in the way where one or more facultative arguments are used in a DLL function.

[Josh]

This one is tricky. CallCFunction() uses 'Any' as parameter type, which means than the type of the parameter is determined by the result of the expression. As Val() returns a 'quad', the whole expression is handled as quad, and then a quad is passed to the function.

I'm not sure how to fix this. We have several possibilities:

- We replace all the parameter types from 'Any' to 'Integer', so we couldn't pass quad, double, float parameters anymore.
- We remove these functions which aren't useful anymore, thanks to prototypes.
- We don't change a thing, and probably someone else will fall in the same trap.

Unfortunately you did not give a link to the text you quoted and I could not find it.

In the end they weren't removed to retain backward compatibility. But as you can see Fred calls them useless, ...

You have to read what is written and not what you want to read. You can't just pick out any point, mark it red and build an argumentation on it. Look at the help:

1st December 2009 : Version 4.40
....
- Changed: Call(C)Function(Fast) parameters have been changed from 'Any' to 'Integer'.

So you can see that your red marking is wrong, you should have marked the first point. So your argumentation is invalid.

... they aren't maintained and updated anymore, ...

Where does it say that these functions are no longer maintained and updated? Once again, you have to read what is written and not what you want to read.

... that's the very definition of deprecated.

I did not see anywhere that Fred used the expression 'deprecated' in this context. Deprecated is used by you and this can mean a lot more:

It can also imply that a feature, design, or practice will be removed or discontinued entirely in the future.

Nothing becomes true just because a false representation is repeated over and over again.

[Olli]

After a short read of a 1964-aged word book, a could see that deprecate is well advise someone against something. It is according Paul's definition.

The title of the subject being "variable numbers of parameters in function";

According that CallFunctionFast() requires this:

Code: Select all

Select ParameterQuantity
   Case 0: CallFunctionFast(*Proc)
   Case 1: CallFunctionFast(*Proc, Arg1)
   Case 2: CallFunctionFast(*Proc, Arg1, Arg2)
   Case 3: CallFunctionFast(*Proc, Arg1, Arg2, Arg3)
   Case 4: CallFunctionFast(*Proc, Arg1, Arg2, Arg3, Arg4)
   Default: Debug "Etc..."
EndSelect

According that a prototype advised above by netmaestro, requires just one source code line,

CallFunctionFast is well deprecated in this way.

Fairly, we won't repeat again and again (else I abort !) that in the general way, CallFunctionFast() is not deprecated !

Yea!

[skywalk]

I think "deprecate" has changed over the years.
When I first heard the term, it meant the target was dropped and/or not advised for use.
Now I see this definition more and more:
"In current technical usage, for one to state that a feature is deprecated is merely a recommendation against using it."

I use Prototypes over CallFunctionFast().

[Josh]

As far as I know, functions are marked as deprecated by the Pb-Team and not by any forum members. Or could I be wrong about this?

Deprecated functions are specially marked in the help. Examples:
ChangeListIconGadgetDisplay()
ClearGadgetItemList()
CreateGadgetList()
WebGadgetPath()
CountList()

I can't see this marking anywhere in connection with CallFunctionFast() & Co. in the help.

It is like often in programming, that many ways lead to the same result, whereby some ways are better than others in certain situations. I have never claimed that prototypes don't have their advantages but there are situations where CallFunctionFast() is unbeatable, like creating JumpTables.

Fact is that CallFunctionFast() has never been marked as deprecated (no matter what exactly is meant by that) and all forum posts that claim otherwise are nothing but fairy tales that are passed on again and again. But no matter how often they are told and no matter how often people try to make it look good because they have a very one-sided view to this, fairy tales don't come true.

[Olli]

Why not. But do you think it is important to me, in example, knowing it is strongly deprecated to push the red button ?

No ! It will be ever useless for me. As anybody will ever use the way of the prototypes.

A minimum of things should be in their context. I think what you say should be in a other whole subject, that you can create.

[Josh]

Why not. But do you think it is important to me, in example, knowing it is strongly deprecated to push the red button ?

No ! It will be ever useless for me. As anybody will ever use the way of the prototypes.

A minimum of things should be in their context. I think what you say should be in a other whole subject, that you can create.

I really thought long about what those words should tell to me.

• I have thought about what is meant by that "Why not". Is this a question where the question mark was forgotten or is it a statement that he determines which functions are deprecated and not the Pb team?
• I have thought about what a 'No!' at the beginning of a paragraph can mean.
• I have though if this person hasn't noticed that this here is not about Prototypes vs CallFunctionFast(), but only about the fact that CallFunctionFast() is not deprecated.
• I have thought if he just wanted to announce that he uses prototypes instead of CallFunctionFast(). But this listing of words would not have been necessary for that.
• I have thought if he thinks I recommended that he should use CallFunctionFast() instead of prototypes, although I didn't even say anything like that. In this case someone has a problem checking things that go beyond a half sentence.
• I have thought about why this person always writes about himself, even it is a general topic. Is this some kind of complex?

Questions about questions. In the end, I have now classified these words for what they are. A babble of a person who doesn't know what to write but who absolutely has to write something. So I will ignore it and don't worry about this arrangement of uncoordinated half sentences.

[netmaestro]

"It depends on what your definition of 'is' is." - William Jefferson Clinton, 1998

I guess this subject has been pretty much talked to death by now. Hope no one's taking offense, I sure didn't mean to give any. For those of you who still find CallFunction etc. useful, I don't think the team has any plans to remove them. Not that I have any inside knowledge, I don't. It's just my belief.