216
edits
(→Release process of Octave 7.1: Update notes) |
(→C++17 features in Octave API?: Add experiment on MXE Octave) |
||
(One intermediate revision by the same user not shown) | |||
Line 14: | Line 14: | ||
** bug {{bug|61813}}: memory management bug when calling MEX that returns an output | ** bug {{bug|61813}}: memory management bug when calling MEX that returns an output | ||
*** Probably caused by changes for more efficient data interface for .mex files. @jwe will check this. | *** Probably caused by changes for more efficient data interface for .mex files. @jwe will check this. | ||
** Possible issues if Octave is compiled with C++17 (<code>--enable-pmr-polymorphic- | ** Possible issues if Octave is compiled with C++17 (<code>--enable-pmr-polymorphic-allocator</code>), while .oct files are not. | ||
*** Maybe change the API string if Octave is configured with polymorphic allocators? | *** Maybe change the API string if Octave is configured with polymorphic allocators? | ||
*** Leave that option in. But disable it by default. (That is already the current state.) | *** Leave that option in. But disable it by default. (That is already the current state.) | ||
Line 36: | Line 36: | ||
* Should we announce that possible requirement for some time in the future with the release of Octave 7? | * Should we announce that possible requirement for some time in the future with the release of Octave 7? | ||
* See also: [https://octave.discourse.group/t/should-octave-switch-to-c-17-if-so-when/2114 Should Octave switch to C++17? If so, when?] on Discourse. | * See also: [https://octave.discourse.group/t/should-octave-switch-to-c-17-if-so-when/2114 Should Octave switch to C++17? If so, when?] on Discourse. | ||
* We'll start an experiment by enabling polymorphic allocators for default Octave on the default branch of MXE Octave. We'll evaluate if the necessary changes to dependent packages are trivial. | |||
=== GSOC 2022 opening soon === | === GSOC 2022 opening soon === |
edits