4 ms·

GCC 14 Adds Initial “-std=C++26” Plumbing

26 points by mfiguiere 3y ago

mike_hock 3y ago
Which version will come with complete "-std=c++20" support, including standard library?
jb1991 3y ago
I've been using the GCC 15 alpha with -std=C++32 options, which has been interesting. All the new borrow checking features and even support for fully dynamically typed programs, but it's the garbage collection that is really an enjoyable step into the future. Also glad to see C++ finally ditch inheritance and go all-in on interfaces and protocols, it's about time.
- setheron 3y ago
  Wow. Neve heard of these features. Would love a link to a great write up.
  - 26fingies 3y ago
    i think this was a joke lol
    - cuteboy19 3y ago
      I was already picturing what arcane invocation we would need to do to summon GC in a backwards compatible nin GC language
W4RH4WK55 3y ago
I wonder when support for modules lands so we can see that the design doesn't work out and deprecate them. Sorry if I am too salty here, but really, it's more of a joke at this point, isn't it?
- dataflow 3y ago
  What's wrong with their design?
  - 112233 3y ago
    https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1300r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p13...
    - dataflow 3y ago
      The problems that paper points out are certainly real, but: - They're not specific to modules (the codegen dependency issue is there even right now) - They're not specific to C++ (Java faces a similar problem) - They all have solutions: either you have to tell the build system what the dependencies are directly, or your compiler has to be able to build the dependencies too. Bazel and gradle already handle these, just in a different context than C++20 modules. So while C++20 modules are harder to use, and they very well might not get adopted, it's not really a design problem, nor an unsolved one - it's just a fundamental impedance mismatch that occurs in any language where the dependencies are specified in the same file that's being compiled. i.e. It's a problem for the build system to solve, and ones do exist that have solved other forms of it in the past.
  - w4rh4wk5 3y ago
    For instance, last time I checked them out (in MSVC) it was perfectly fine to expose an un-exported type via an exported function. Apparently this is by design. In Rust, such a thing is an error. https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=16a67062304ba6856b9a924a75ea96d1 https://play.rust-lang.org/?version=stable&mode=debug&editio...
- pjmlp 3y ago
  Visual C++

26 points by mfiguiere 3y ago

Which version will come with complete "-std=c++20" support, including standard library?

jb1991 3y ago

I've been using the GCC 15 alpha with -std=C++32 options, which has been interesting. All the new borrow checking features and even support for fully dynamically typed programs, but it's the garbage collection that is really an enjoyable step into the future. Also glad to see C++ finally ditch inheritance and go all-in on interfaces and protocols, it's about time.

setheron 3y ago
Wow. Neve heard of these features. Would love a link to a great write up.
- 26fingies 3y ago
  i think this was a joke lol
  - cuteboy19 3y ago
    I was already picturing what arcane invocation we would need to do to summon GC in a backwards compatible nin GC language

W4RH4WK55 3y ago

I wonder when support for modules lands so we can see that the design doesn't work out and deprecate them. Sorry if I am too salty here, but really, it's more of a joke at this point, isn't it?

dataflow 3y ago
What's wrong with their design?
- 112233 3y ago
  https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1300r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p13...
  - dataflow 3y ago
    The problems that paper points out are certainly real, but: - They're not specific to modules (the codegen dependency issue is there even right now) - They're not specific to C++ (Java faces a similar problem) - They all have solutions: either you have to tell the build system what the dependencies are directly, or your compiler has to be able to build the dependencies too. Bazel and gradle already handle these, just in a different context than C++20 modules. So while C++20 modules are harder to use, and they very well might not get adopted, it's not really a design problem, nor an unsolved one - it's just a fundamental impedance mismatch that occurs in any language where the dependencies are specified in the same file that's being compiled. i.e. It's a problem for the build system to solve, and ones do exist that have solved other forms of it in the past.
- w4rh4wk5 3y ago
  For instance, last time I checked them out (in MSVC) it was perfectly fine to expose an un-exported type via an exported function. Apparently this is by design. In Rust, such a thing is an error. https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=16a67062304ba6856b9a924a75ea96d1 https://play.rust-lang.org/?version=stable&mode=debug&editio...
pjmlp 3y ago
Visual C++