C++ COMPILER
Darrell Edgett
foxpro code into a compiled version using C++. I need the fox app to
run faster so I'm exploring this option. Does anyone have some info
that could help me out. Please reply I'm in dire straits....
ded...@connect.reach.net
Darrell Edgett
Mike Chalk
>Hello there, I would like some info on a compiler that can change
>foxpro code into a compiled version using C++. I need the fox app to
>run faster so I'm exploring this option. Does anyone have some info
>that could help me out. Please reply I'm in dire straits....
>
There aint no such beast :-(
Nor is there ever likely to be one unless MS produces a new breed of
foxpro deliberately designed from the bottom up to be compilable. When you
write your source code it mostly consists of calls to powerful routines
which exist in library form (for example BROWSE). These routines are
already compiled and unless you could manage to convert them somehow to
more efficient code then you are on to a loser even looking at them.
Remember also that (assuming you are running in windows) these library
routines heavily rely on other library routines provided as part of the
windows API - messing about with these is a recipe for chaos. OK, so what
can you compile. Well the glue that holds your Foxpro calls together in
theory could be compilable as C++ code. By that I mean where you have DO
WHILE loops, IF statements, DO CASE, assignments like X=Y+24 etc. You
will find plenty of similar constructs in C++ but of course no routine
such as BROWSE (unless, like VFP it is library routine called by your
code).
There is a fairly vigourous debate as to whether future generations of
foxpro should be compilable (in the sense that Delphi is). The main
arguments are firstly that you could have more compact code (less disks to
install) and that secondly the code would run faster. If you only linked
into your compiled code the routines you actually called then in theory
the final _total_ executable would be smaller. The main counter arguments
to this is that then we would have to give up macros (macros could call
_any_ foxpro function at runtime so all functions would have to be
included with the library so none could be left off). Also some may say
that who gives a damn saving a megabyte or two, everything else is so
large now anyway.
The second point is the one that interests you. In theory the compiled
code could run faster. The counter is that, assuming the library routines
are optimally written (a big assumption that), then the only speed up
would be for those other, glue statements. The argument runs that with
the vast majority of database applications (for which foxpro has evolved)
the time spent in loops etc. is minimal compared with the time spent
generating graphics and manipulating the data environment (all from
library routines).
My purpose was not to fuel the compile / not compile debate (fun though it
is) but to maybe get you to look again at your speed problem.
Reality check time. There is no magic speed up compiler so what can you
do to help yourself. The first principal should always be to isolate what
part of the program is taking the most time during the slow bits. I have
seen any number of hackers fiddling about with a bit of code to speed it
up by a factor of two but, since it only contributed to 5% of run time,
finding out that the overall speed improvement was negligible.
So what is giving you the speed problems. Is it graphics? If it is then
the obvious options are to improve the graphics environment (faster
computer, better graphics card, lower number of colours displayed) or
reduce the complexity of the graphics (fewer controls displayed on your
forms, fewer forms displayed). Is it the data handling? If it is then
you must isolate the areas of data handling which are slow and address
them. Is it a network problem or local. Is it something which can be
improved by redesigning your database? - added indexes or perhaps
normalising the structure into a more speed efficient form. Is it in the
glue areas, could your program be restructured or redesigned in a more
speed efficient form?
Finally - though perhaps it should be firstly - put your systems analysts
hat on. Step back and think of your program as a system. Could you
remove whole steps, simplify the algorithms? Any number of times I have
solved a speed problem not by speeding up the program but just doing it in
a completely different way. The fastest code is code which is just not
run at all :-)
Cheers
Mike
----------------------------------------------------------------------
Mike Chalk ASAD SYSTEMS Ltd. C/Foxpro26/VFP/Delphi
Tonbridge, England mike...@dial.pipex.com
----------------------------------------------------------------------
M Darrin Chaney
>
>Hello there, I would like some info on a compiler that can change
>foxpro code into a compiled version using C++. I need the fox app to
>run faster so I'm exploring this option. Does anyone have some info
>that could help me out. Please reply I'm in dire straits....
Mike Chalk has an excellent followup to this post, so I'll not repeat
his points. But, there are others to be made.
Like Visual Basic, FoxPro is interpreted simply because there is no need
to compile. They are designed to be used to create interactive user
interfaces. There, regardless of code speed, most of the time is spent
waiting for the user to type in data, press buttons, etc. The speed of
your code is irrelevent as long as you're doing basic things (save data
in a table, load from a table, etc.)
Let's be honest, if you're using Fox (or VB) to compute the value of pi
to 1,000,000 decimal places, you're wasting your time and using the
wrong language. Even if you're not doing something so dramatic, you
may still be better off rewriting some computationally intensive sections
in C, as an fll, a dll, or an OLE control. (I'm personally familiar with
the last two options; call me if you wish)
Since your post was quite vague, I can't answer that question. Post more
details about the section that needs to be faster and maybe I can make
a better judgement.
One other point: what environment are you running your app in. If you're
using VFP on a 486 with 8MB memory, all the C code in the world won't
help.
Darrin
--
Michael Darrin Chaney FoxPro, Visual FoxPro, & Visual Basic Consulting
E-mail: mdch...@intersource.com Web: http://www.intersource.com/~mdchaney
Phone: (812)333-6311 & (800)711-4240 Fax: (812)333-1894
Paul Lee
: So what is giving you the speed problems. Is it graphics? If it is then
: the obvious options are to improve the graphics environment (faster
: computer, better graphics card, lower number of colours displayed) or
For some graphics and similar problems you could supplement Foxpro
with small C/C++ programs to do the job - remember that you can call
other EXE programs from withing FoxPro - which can ofter be seamlesly
integrated into FoxPro apps.
=============================================================
Abri Technologies - the problem solutions provider
Web Page http://ourworld.compuserve.com/homepages/abri
=============================================================
Mike Chalk
>Mike Chalk (mike...@dial.pipex.com) wrote:
>
>: So what is giving you the speed problems. Is it graphics? If it is then
>: the obvious options are to improve the graphics environment (faster
>: computer, better graphics card, lower number of colours displayed) or
>
>For some graphics and similar problems you could supplement Foxpro
>with small C/C++ programs to do the job - remember that you can call
>other EXE programs from withing FoxPro - which can ofter be seamlesly
>integrated into FoxPro apps.
>
I am not sure I fancy that Paul. When you run an exe you are running a
shell process which has a pretty heavy environmental and speed overhead.
Also message passing between the app and the exe would be crude (I suppose
you could pass a few parameters as a command line parameters to the exe).
At the end of the day all you could really do would be some stand alone
graphics task and maybe pass a pointer to some data you have saved as a
temporary file - that tends to be an addition to whatever database
activities you are doing rather than replacing the day to day activities
like refreshing screens etc.
If you want to use C/C++ for modules then don't use exe's but write plb's
for foxpro dos, fll's for foxpro windows or dll's (or OCX's for VFP).
Lots of luck though Paul. Not a lot have been written to produce
graphics effects - either the world is pretty dumb or maybe the benefits
of second guessing Microsoft and to produce faster graphics are outweighed
by the horrible complexity of it all :-) Interfacing to the API's of the
various foxpro versions is black belt stuff and I bow to all gurus who
actually manage to produce something worthwhile before Bill Gates changes
the rules and invents a newer version of foxpro or windows which makes
your current efforts redundant.
Nah, steer clear of fiddling about with C or C++ to build go faster
modules for foxpro - there are more fruitful avenues to explore.
Dave Ballard
have an Xbase code translator for $150.00.
So how's that....
In article <316f9c4d...@newnews.dial.pipex.com>,
mike...@dial.pipex.com says...
Mike Chalk
>Try CodeBase from Sequiter for C++ compatible DBF access. They also
>have an Xbase code translator for $150.00.
>
>So how's that....
<SNIP>
Pretty limited by all accounts David.
I may be wrong - I often am :-) - but I understand their prg code
translator hits a subset of Foxpro DOS commands with marginal speed
improvement in some areas. I still believe (but then I am stubborn)
getting a speed improvement by translating foxpro to C++ depends on
someone being able to manage the Windows API more efficiently than MS,
writing a more efficient/faster database engine compatible with foxpro
file structure or the candidate program for translation containing a
disproportionate amount of code which lends itself to conversion
(calculation routines, iterations etc.)
Nope David - as far as I know there is still no magic holy grail :-(