octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Eliminating some macros


From: John W. Eaton
Subject: Eliminating some macros
Date: Wed, 2 Nov 2016 20:37:35 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0

I'm working on eliminating the macros that are generated by liboctave/operators/mk-ops.awk.

Currently, this script generates a set of header files that contain things like this

  // DO NOT EDIT -- generated by mk-ops.awk
  #if ! defined (octave_mx_cm_m_h)
  #define octave_mx_cm_m_h 1
  #include "octave-config.h"
  #include "CMatrix.h"
  #include "dMatrix.h"
  #include "mx-op-decl.h"
  MM_BIN_OP_DECLS (ComplexMatrix, ComplexMatrix, Matrix, OCTAVE_API)
  MM_CMP_OP_DECLS (ComplexMatrix, Matrix, OCTAVE_API)
  MM_BOOL_OP_DECLS (ComplexMatrix, Matrix, OCTAVE_API)
  #endif

to provide declarations of operators for mixed-type operations on nd-array/matrix/sparse-matrix/vector/scalar objects of various types (complex, real, integer). It also generates a corresponding set of source files that look like this

  // DO NOT EDIT -- generated by mk-ops.awk
  #if defined (HAVE_CONFIG_H)
  #  include "config.h"
  #endif
  #include "Array-util.h"
  #include "mx-cm-m.h"
  #include "mx-op-defs.h"
  #include "boolMatrix.h"
  #include "boolNDArray.h"
  #include "CMatrix.h"
  MM_BIN_OPS (ComplexMatrix, ComplexMatrix, Matrix)
  MM_CMP_OPS (ComplexMatrix, Matrix)
  MM_BOOL_OPS (ComplexMatrix, Matrix)

to provide the actual function definitions.  My plan is to

  * Use templates instead of macros to define the functions.

* Change the script to generate the declarations directly instead of using macros.

* Preserve the non-template function signatures using inline functions in the header files. These can be deprecated and eventually removed. Octave itself will be fixed to use the templates directly.

  * Wrap all the functions in the octave::numeric namespace.

Questions:

* Should the header file that declares the templates also provide the template definitions, or should we hide those and only instantiate these templates for the types we care about? Will the build be faster if we use extern templates and explicit instantiation of just the templates we need?

* If we choose explicit instantiation for only the types we need, should we continue to use a script to generate these files or should we just move a copy of the generated sources to the source tree and eliminate the script, adding new variants by hand? (If the definitions are all in the header and we don't use explicit instantiation, then we can just eliminate the source files and script, but compiling/linking might be slower).

Comments?

jwe




reply via email to

[Prev in Thread] Current Thread [Next in Thread]