[Octave-bug-tracker] [bug #60567] oct-file has an undefined symbol

[John W. Eaton]

Follow-up Comment #7, bug #60567 (project octave):

Prior to 3e8bc8bee8e9, the function ComplexRowVector::extract was also not
tagged individually but I was able to modify the source for the .oct file as
follows and executing the resulting .oct file works for me:


--- complex_matrix.cc.orig      2021-05-11 09:01:33.130956833 -0400
+++ complex_matrix.cc   2021-05-11 09:00:52.691481265 -0400
@@ -59,8 +59,14 @@
       argval(0)=zIminusA;
       Rval=octave::feval("inv",argval,1);
       ComplexMatrix R=Rval(0).complex_matrix_value();
-  
-      ComplexRowVector cR(c*R);
+
+      ComplexRowVector cR (R.columns ());
+      for (octave_idx_type ii = 0; ii < cR.numel (); ii++)
+        cR(ii) = Complex (ii, ii+10);
+      ComplexRowVector tmp = cR.extract (0, 1);
+      octave_stdout << "cR.numel (): " << cR.numel () << std::endl;
+      octave_stdout << "tmp(0): " << tmp(0) << std::endl;
+      octave_stdout << "tmp(1): " << tmp(1) << ---
complex_matrix.cc.orig  2021-05-11 09:01:33.130956833 -0400
+++ complex_matrix.cc   2021-05-11 09:00:52.691481265 -0400
@@ -59,8 +59,14 @@
       argval(0)=zIminusA;
       Rval=octave::feval("inv",argval,1);
       ComplexMatrix R=Rval(0).complex_matrix_value();
-  
-      ComplexRowVector cR(c*R);
+
+      ComplexRowVector cR (R.columns ());
+      for (octave_idx_type ii = 0; ii < cR.numel (); ii++)
+        cR(ii) = Complex (ii, ii+10);
+      ComplexRowVector tmp = cR.extract (0, 1);
+      octave_stdout << "cR.numel (): " << cR.numel () << std::endl;
+      octave_stdout << "tmp(0): " << tmp(0) << std::endl;
+      octave_stdout << "tmp(1): " << tmp(1) << std::endl;
       Complex cRb(cR*b);
       H(l)=cRb+d;
     }
std::endl;
       Complex cRb(cR*b);
       H(l)=cRb+d;
     }


Is the real problem with the friend function declaration?  If I understand
correctly, that just declares that the function is a friend of the class (and
can access private class data) but there should also be a declaration outside
the class definition.  And there, we would need an API tag.  But member
functions should be visible because of the API tag on the class itself.

I suspect that most of these friend operator functions don't really need to be
declared as friends (they probably don't need access to private class data or
functions) and we could just have extern declarations outside the class scope.
 And if we had them all in namespaces, then I think we could just apply the
visibility tag to the namespace in the header file and not have to repeat the
visibility tag on each declaration.

If we should discuss further I can open a discourse topic.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?60567>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/