octave-bug-tracker
[Top][All Lists]
Advanced

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

[Octave-bug-tracker] [bug #65034] Enable polymorphic allocators in API b


From: Markus Mützel
Subject: [Octave-bug-tracker] [bug #65034] Enable polymorphic allocators in API by default (for .mex)
Date: Thu, 14 Dec 2023 11:58:50 -0500 (EST)

URL:
  <https://savannah.gnu.org/bugs/?65034>

                 Summary: Enable polymorphic allocators in API by default (for
.mex)
                   Group: GNU Octave
               Submitter: mmuetzel
               Submitted: Thu 14 Dec 2023 05:58:48 PM CET
                Category: Configuration and Build System
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: None
                  Status: None
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
                 Release: dev
         Discussion Lock: Any
        Operating System: Any
           Fixed Release: None
         Planned Release: None


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Thu 14 Dec 2023 05:58:48 PM CET By: Markus Mützel <mmuetzel>
During last developer meeting, we talked about enabling
std::pmr::polymorphic_allocator in Octave's API by default.
I'm having seconds thoughts about doing that on the stable branch shortly
before a release.

These polymorphic allocators are a new feature of the STL in C++17. Most
common compilers and the corresponding STL implementations should be
supporting that feature by now. However, that would require that all Octave
packages (or other binaries that include Octave headers in their sources)
would need to support at least C++17.
That might not be the case.

Most packages (or other sources) that would fail to compile would probably
just need to remove flags like "-std=gnu++14". Probably, only few would
actually need to adapt their code.

Nevertheless, it might be better to switch the default for that configure flag
first only on the default branch. And maybe announce in the NEWS for Octave 9
that this change is imminent.
That might give package developers and users a head start when it comes to
checking their build flags.

What do you think?








    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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