[Octave-bug-tracker] [bug #61784] builtins deprecated warning problem

[Markus Mützel]

Follow-up Comment #5, bug #61784 (project octave):

I played around with this a while. It looks like function templates can't be
deprecated. Template functions can. But the warning is only shown if they are
used at least twice(?).

The following change in `builtin-defun-decls.h` makes the deprecation warning
show for me. But only if the wrapper template is creating a pointer to that
function first. Is this a compiler bug?


template <typename T>
octave_value_list
F__dump_load_path__ (T& interp, const octave_value_list& args =
octave_value_list (), int nargout = 0)
{
  octave_value_list (*f_ptr) (T&, const octave_value_list&, int);
  f_ptr = &F__dump_load_path__<T>;

  return octave::F__dump_load_path__ (interp, args, nargout);
}

template
octave_value_list
OCTAVE_DEPRECATED (7, "use 'octave::F__dump_load_path__' instead")
F__dump_load_path__<octave::interpreter> (octave::interpreter& interp, const
octave_value_list& args = octave_value_list (), int nargout = 0); 


While playing around with this, I noticed the following:

>> mkoctfile -std=c++11 lpath.cc
[...]
d:\svn\octave\test\octave-2022-01-11-20-55-w64
of-general\octave-2022-01-11-20-55-w64\mingw64\include\octave-8.0.0\octave\oct-cmplx.h:
In function 'bool operator>=(T, const std::complex<_Tp>&)':
d:\svn\octave\test\octave-2022-01-11-20-55-w64
of-general\octave-2022-01-11-20-55-w64\mingw64\include\octave-8.0.0\octave\oct-cmplx.h:99:39:
error: 'M_PI' was not declared in this scope
   99 |            if (by == static_cast<T> (-M_PI))                          
      \
      |                                       ^~~~
d:\svn\octave\test\octave-2022-01-11-20-55-w64
of-general\octave-2022-01-11-20-55-w64\mingw64\include\octave-8.0.0\octave\oct-cmplx.h:236:1:
note: in expansion of macro 'DEF_COMPLEXR_COMP'
  236 | DEF_COMPLEXR_COMP (>=, >)
      | ^~~~~~~~~~~~~~~~~
[...]
error: mkoctfile: building exited with failure status


It only compiles if I enable GNU extensions (e.g. -std=gnu++14).
Should we support compiling without GNU extensions?

    _______________________________________________________

Reply to this item at:

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

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