ByCopy

[Robert E. Carneal]

Hello. Can someone please re-explain when, where, and how to use
ByCopy? When I compile DemoScrn.bas (which has a INC of PB35.inc.),
it compiles and runs just fine.

When I try to include in another program I have written, it informs
I need ByCopy due to "Parameter mismatch - may need ByCopy:"

Please advise on how to resolve this.

Lance, I still have my PowerBasic User's Guide. However, the
Reference Guide is nowhere to be seen. Can the books be
purchased?

Thank you.

Robert Carneal

------------------

[Michael Mattias]

When it says "may need BYCOPY" that's only correct about one time in two hundred.

You probably mistyped something: an extra comma here, forgot a comma or a parameter somewhere else, flipped the position of two parameters around, something like that.

Check your line of source code versus either the DECLARE or procedure header (the SUB or FUNCTION line) for the function you are calling.

If all looks correct there, BYCOPY "may" be the correct thing to do, but we couldn't tell without seeing the line of code and the DECLARE or procedure header).

IMNSHO, one should NEVER change to "BYCOPY" unless you really want BYCOPY; never do it just to get past this particular compile-time error.

[Roger Garstang]

Most of the time when I get this error it is because the declare
in the Win API INC file wants a value ByRef, like an ASCIIZ variable
or something. Usually it is a goofy thing like passing it a String
and not STRPTR, or I pass it 0 when it wants ByVal 0, etc.

I imagine the same thing applies in DOS compilers although less
since there you usually create your own functions and know the
type of passing required.

------------------
If you aim at nothing...you will hit it.

If something I say can be taken 2 ways and 1 of them ticks you off...I meant the other one.

[This message has been edited by Roger Garstang (edited February 08, 2005).]

[Jerry Mason]

Robert:

The manuals are still available; click the link below and scroll
down about 2/3 of the way down the page:

https://www.powerbasic.com/shop/

------------------

[Michael K. Dealey]

I don't know if your error is in calling a SUB or FUNTION but if
you are calling a FUNCTION like I do sometimes (because I program
sporadicaly and forget) this will also cause that error message:

DECLARE FUNCTION HowOld (iAge1 AS LONG, iAge2 AS LONG) AS LONG

FUNCTION PBMAIN() AS LONG
   
   DIM iAge1 AS LONG
   DIM iAge2 AS LONG
   DIM iAgeOld AS LONG
      
   iAge1 = 30
   iAge2 = 16
   
   iAgeOld = HowOld (iAge1 AS LONG, iAge2 AS LONG)'[b]<-Error. Paramater mismatch. May need "ByCopy"[/b]
   
   'it should be called as: [b]
   iAgeOld = HowOld (iAge1, iAge2)[/b]
   '
   CLS
   PRINT STR$(iAgeOld)
   WAITKEY$

END FUNCTION

FUNCTION HowOld (iAge1 AS LONG, iAge2 AS LONG) AS LONG
   LOCAL iNewAge AS LONG
   iNewAge = iAge1 + iAge2
   FUNCTION = iNewAge
END FUNCTION

I think it's an odd error code because in fact, I have not "mismatched" parameters. If anything, I've just made a redundant statement but still, it will raise this error. I think "Duplicate Definition" or something to that effect would be more accurate.



[This message has been edited by Michael K. Dealey (edited February 08, 2005).]

[Mark Hunter]

You only need to pass by reference (the default alternative to ByCopy)
[no -- ByVal] ...


[This message has been edited by Mark Hunter (edited February 10, 2005).]

[Michael Mattias]

>Say if you really want to have faster code or less code in the executable [then pass BYCOPY]

That is not an 'always true' statement; with string parameter, it's never true.

It 'can' be true with numeric values, but it depends on how many times and in what fashion that parameter is accessed in that procedure.

As a rule (my rule, I have precisely zero empirical data to support this), BYVAL and/or BYCOPY offer no measurable performance increases. (Bycopy never offers performance increases, not even theoretical ones).

[Mark Hunter]

I was thinking of ByVal, not ByCopy
(if ByCopy exists I've never seen it)
and then I was only half right. For
numeric parameters ByVal decreases the
execution time slightly but increases
the executable file size slightly.

Passing "by copy" by enclosing the
numeric parameter in parenthesis
increases execution time and executable
file size.

[Donald Darden]

The most common problem is with passing the wrong numeric or string
type. For instance, trying to pass an integer when the parameter
is declared to be a long, or vice versa. Or trying to pass a
regular string when the parameter is suppose to be an ASCIIZ
string. The compiler is warning you that either the number of
bytes on the stack will be wrong, which can crash your system, or
the procedure you are calling is not going to handle the reference
correctly, and that will cause unexpected results.

BYCOPY takes the original parameter and converts it to the format
that the procedure needs. If you put parenthese around a numeric
type when passing it, you are implicitly asking for it to be
processed numerically, and the result will automatically be
converted to the proper form - sort of a sneaky way of doing
something like BYCOPY.

BYCOPY just gives you one more way of being able to call some
procedures without having to adopt another temporary variable
to act as the intermediate form if the parameter is in the wrong
format.

------------------
Old Navy Chief, Systems Engineer, Systems Analyst, now semi-retired