C Porting tips ?

[Erwin van de Wiel]

I'm currently porting some C code to PB and got two questions about it. I just started programming C and PB so maybe the questions are very easy.

1. What to do with function calls ? C calls it's functions most
of the time with a pointer from a variable. PB passes
variables byreference so I don't need to use pointers, but is
it faster to use them ?
2. Is there a way to directly give a PB variable a value at
declaration ? dim lngVal as long = 3 ?

Also debugging in PB goes very slowly if I want to watch variables. If I enter a variable in the watch window it takes about 5 sec before it can be seen in the list of watches. Is this normal on a P166 ?

Thanks
Erwin van de Wiel

[Lance Edmonds]

BYVAL is usually always slightly faster than BYREF passing. PB uses BYREF as the default, as it is "traditional" (for lack of a better word).

You cannot DIM and assign at the same time, sorry.

Comments on the speed of the debugger have been raised before a few times. The 'answer' is that the IDE uses the Windows built-in debugging API's, and these operate at a less than optimal speed. Improving the speed is on the wish list for the IDE, but as I understand it, it a *major* because it involves replacing core API functions with native code in the debugger itself.

Interestingly, the debugger runs quite a bit faster for me (esp in animate mode) since I began running Windows 2000 (I was using Win95a). It could just be me I guess, but it certainly feels much faster! Anyone else notice this?

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Ian Cairns]

Erwin,

Debugging in the IDE can be a frustrating experience. Some wise person on this BBS (I forget exactly who) once made a very valuable suggestion: try using MSGBOX to display the values of variables at critical points in your program. But be careful not to put one in a PAINT loop.

Regards, Ian

------------------
[email protected]

[Colin Schmidt]

Another common suggestion for debugging in loops is to just dump the data to a text file.

open "c:\out.txt" for output as #1
    for i = 1 to 1000
        mydata(i) = myotherdata(i) * .123
        print# 1, mydata(i)
    next i
close #1

This of course is much easier to look at that 1000 message boxes or than making 1000 steps in a debugger! I actually find that mixing text files and message boxes to be a much better approach than using traditional debugging. It just takes some thought sometimes on how to test for things.

Colin Schmidt

------------------
Colin Schmidt & James Duffy, Praxis Enterprises, Canada

[K Peel]

One of the ways to debug programs is to set a constant "%DEBUG" in a program and then use the code:

[b]
$IF %DEBUG
 BugMsg "This is a test value"
$ENDIF
[/b]

The BugMsg function can be either display a message box with that value, or write it to a disk file.


------------------
Kev G Peel
KGP Software
Bridgwater, UK.
mailto:[email protected][email protected]eeserve.co.uk</A>

[This message has been edited by K Peel (edited April 04, 2000).]

[Lance Edmonds]

While we are this subject, don't overlook #DEBUG PRINT - it is only used when debugging - the "normal" code compilation process ignores #DEBUG PRINT statements as is they were not in your code. Very useful.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>