On 2-Aug-2012, Rik wrote:
| I think the reasoning to divide up core library code from DEFUN code is
| good. In addition, I would like to make one more division between
| interpreter-related functions (load, save, dbstop, etc.) and math-related
| functions (pinv, chol, etc.). I find this grouping easier to understand
| than one based on whether or not there is a header file and I think it will
| help prevent corefcn from becoming too large and ungainly. So, my proposed
| structure would be:
|
| parse-tree/
| lexer, parser, and all parse-tree pt* code
| octave-value/
| All octave_value related code ov*
| operators/
| All operator related code
| template-inst/
| Not sure about this one
| core-interp/ (Name open to change)
| C++ code in liboctinterp which is called directly rather than through a
| DEFUN.
| interpfcn/ (Name open to change)
| DEFUN C++ code for interpreter functions such as load, save, dbstop.
| corefcn/
| DEFUN C++ code for mathematical core functions such as pinv, chol.
| dldfcn/
| Dynamically loaded functions
|
| src/
| Remaining code files, mostly for octave itself such as main.c, octave.cc.
| Would also potentially contain a few scripts like mkbuiltins.
I'm OK with this change.
Code for load and save is also included in the octave_value objects.
the ls-*.{h,cc} files are for file formats that are limited to
specific data types, like the Matlab MAT file format.
Would corefcn, interpfcn, and dldfcn contain any header files to
export functions that are called directly?
If we split files apart, what should we do about copyright info when
there are multiple people claiming copyright?
I think template-inst should be removed, if that is now possible. It
is a holdover from when we needed to instantiate templates manually.
Now we mostly don't seem to need to do that, but I'm not sure what the
rules are for instantiation now.
In addition to the src/template-inst directory, we also have some
template instantiation files in liboctave. For example:
Array-b.cc Array-C.cc Array-ch.cc Array-d.cc
Array-f.cc Array-fC.cc Array-i.cc Array-idx-vec.cc
Array-s.cc Array-str.cc Array-voidp.cc MArray-C.cc
MArray-d.cc MArray-f.cc MArray-fC.cc MArray-i.cc
MArray-s.cc MSparse-C.cc MSparse-d.cc Sparse-b.cc
Sparse-C.cc Sparse-d.cc
AFAIK the reason for having manual instantiation is because part of the template code is not in the header files. I'm not sure what's the reason to have part of the template codes in .cc, maybe to make compilation lighter?
Michael.