Re: Creating a standalone executable

[JD Cole]

Thanks Paul and John,
 That tied some things together for me. And to answer question John, 
yes, I've been doing a little work on a Octave to C++ translator. I 
don't have much to show yet, so I haven't been very vocal about it. As 
Paul and I had previously discussed, I am attempting to use the 
tree_walker interface to emit code (I called it tree_emit_cplusplus). My 
inquiry, and patches, for tree_checker were are related to this effort. 
I would like to run tree_checker prior to emitting code so I don't have 
to worry about bad trees when I go to emit code. For testing right now I 
am implementing tree_emit_cplusplus in an oct-file because  the compile 
overhead is so much less, however, if proven useful, we may want to 
integrate the functionality into Octave itself, similar to the way GNU 
Emacs has a built-in Lisp compiler.

Some of the issues/ideas I have been kicking around:
1. This is a function compiler.
2. I have implemented a function interface, right now the following 
function script:
------------ mysum.m -------------------
function [a,this,b] = mysum (this, that, those)
 a=[1 2 3 4 5];

 res= 0;
   
 for i=1:5
   res= res + a(i);
 end
 b
 res
endfunction
----------------------------------------
tranlates to this:
---------------- mysum.cc ----------------
#include <octave/oct.h>

extern void
mysum (octave_value& this, const octave_value& that, const octave_value& 
those,
      octave_value& a, octave_value& b)
{
.......
}
where input only parameters are marked as const and input/output pairs 
are used to alter return values.
3. I am currently educating myself about range values so I can implement 
simple looping.
4. One major sticking point right now is the setting of constant 
vector/matrix values. I noticed that the constructors which use 
pointer-based initialization are private. Still not sure on a "clean" 
method of doing this. I would like to do something like this:
------------
double init_data[10]={1,2,3,4,5,6,7,8,9,0};

octave_matrix m(init_data,2,5);
------------
to try to keep things clean.
5. I'm using a simple hash table to keep track of valid symbol/variable 
names.
6. Perhaps after single functions can be translated, a recursive 
translator can be created which will produce a directory containing all 
the code, .oct and tranlated C++, to created a complete working executable.

JD

John W. Eaton wrote:

> On 18-Dec-2002, Paul Kienzle <address@hidden> wrote:
>
> | octave_value is part of liboctinterp.  Many of the classes on which the
> | octave_value types are based are defined in liboctave.  E.g., liboctave
> | defines Matrix, which is wrapped by octave_matrix.
> | 
> | octave_value implements dynamic typing, so all operations must be looked
> | up at run time every time they are invoked.  
> | 
> | Things like the * operator for the Matrix class, however, are resolvable
> | at compile time.
> | 
> | Most of the code in e.g., src/DLD-FUNCTIONS, operates directly on values
> | of the underlying type rather than on the octave_value item.
>
> Right.  I'm not sure why you would want to operate directly on
> octave_value objects unless you were working on a simple Octave to C++
> translator or if you are trying to write some generic functions in C++.
> (For example, C++ code that can do the equivalent of something like:
>
>  function result = add (a, b)
>    result = a + b;
>
> and not have to do any type checking/value extraction before
> attempting the addition.)
>
> If you are writing generic functions, why not just write them in the
> scripting language?
>
> If you are working on a translator, then it might be useful to share
> some of your ideas on the list.
>
> Thanks,
>
> jwe
>
>