Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++26 is done: ISO C++ standards meeting Trip Report

herbsutter.com

Post reply on HN
Print view View original

341–350 of 437 posts

Re: C++26 is done: ISO C++ standards meeting Trip Report

#341

Post by nickelpro »

duped wrote: post #302
bluGill wrote: post #297

Earlier quoted context omitted.

Modules are not simple. They sound simple only to people who have never digged into them.

I've worked extensively on module/import semantics for multiple products in my life. It is complex. However this complexity is on the implementer and not the user. If "best practices" need to be refined over years, it is poorly designed. This is not untrodden ground, other languages and ecosystems do sane things.

This was considered during standardization. The feeling among tool developers at the time was it was "close enough" to Fortran modules to be mostly solvable.

This was wrong, mostly because C++ compiler flag semantics are far more complicated than in Fortran, you live and you learn. The bones of most implementations is identical to Fortran though, we got a ~3 year head start on the work because of that.

Ninja already had the dyndep patch ready to go from Fortran, CMake knew basically how to use scanners in build steps. However, it took longer than expected to get scanner support into the compilers, which then delayed everything downstream. Understanding when BMIs need to be rebuilt is still tricky. Packaging formats needed to be updated to understand module maps, etc, etc.

Each step took a little longer than was initially hoped, and delays snowballed a bit. We'll get there.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#342

Post by bluGill »

tialaramex wrote: post #308
bluGill wrote: post #260

Earlier quoted context omitted.

NULL exists on real CPUs. Maybe you meant nullptr which is a very different thing, don't confuse the two.

I don't agree. Null is an artefact of the type system and the type system evaporates at runtime. Even C's NULL macro just expands to zero which is defined in the type system as the null pointer. Address zero exists in the CPU, but that's not the null pointer, that's an embarrassment if you happen to need to talk about address zero in a language where that has the same spelling as a null pointer because you can't say…

Null doesn't expand to zero on some weird systems. tese days zero is special on most hardware so having zero and nullptr be the same is importnt - even though on some of them zero is also legal.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#343

Post by nickelpro »

FrostKiwi wrote: post #141
duped wrote: post #131

Earlier quoted context omitted.

I have yet to see modules in the wild. What I have seen extensively are header-only projects.

It's the fault of built systems. CMake still doesn't support `import std` officially and undocumented things are done in the ecosystem [1] But once it works and you setup the new stuff, having started a new CPP26 Project with modules now, it's kinda awesome. I'm certainly never going back. The big compilers are also retroactively adding `import std` to CPP20, so support is widening. [1] https://gitlab.kitware.com/cma…

I wanted to ship import std in 4.3 but there are some major disagreements over where the std.o symbols are supposed to come from.

Clang says "we don't need them", GCC says "we'll ship them in libstdc++", and MSVC says "you are supposed to provide them".

I didn't know about that when I was working on finishing import std for CMake and accidentally broke a lot of code in the move to a native implementation of the module manifest format, so everything got reverted and put back into experimental.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#344

Post by menaerus »

rienbdj wrote: post #188
jandrewrogers wrote: post #171

Earlier quoted context omitted.

Many of the recent C++ standards have been focused on expanding and cleaning up its powerful compile-time and metaprogramming capabilities, which it initially inherited by accident decades ago. It is difficult to overstate just how important these features are for high-performance and high-reliability systems software. These features greatly expand the kinds of safety guarantees that are possible to automate and the…

> One of the biggest knocks against Rust as a systems programming language is that it has weak compile-time and metaprogramming capabilities compared to Zig and C++. Aren’t Rust macros more powerful than C++ template metaprogramming in practice?

No, they are not.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#345

Post by Conscat »

aw1621107 wrote: post #332
germandiago wrote: post #295

Earlier quoted context omitted.

But compile-time processing is certainly useful in a performance-oriented language. And not only for performance but also for thread safety (eliminates initialization races, for example, for non-trivial objects). Rust is just less powerful. For example you cannot design something that comes evwn close to expression templates libraries.

> For example you cannot design something that comes evwn close to expression templates libraries. You keep saying this and it's still wrong. Rust is quite capable of expression templates, as its iterator adapters prove. What it isn't capable of (yet) is specialization, which is an orthogonal feature.

Rust cannot take a const function and evaluate that into the argument of a const generic or a proc macro. As far as I can tell, the reasons are deeply fundamental to the architecture of rustc. It's difficult to express HOW FUNDAMENTAL this is to strongly typed zero overhead abstractions, and we see where Rust is lacking here in cases like `Option` and bitset implementations.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#346

Post by nutjob2 »

Milner08 wrote: post #244

Quite unrelated to the main topic, but shouldn't it be Croydon, London? I have never heard anyone called it London Croydon before. Generally addresses/places go from most specific to least and given Croydon is an area of London it should go first.

Like London Gatwick Airport?

Addresses are one thing, but the inverse has its own logic. In terms of (mental) planning you want to know that you need to go to the UK then London then Croydon, otherwise there's an element of "where's that?" as you read left to right.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#347

Post by einpoklum »

pjmlp wrote: post #286
einpoklum wrote: post #281

Earlier quoted context omitted.

> The C++ WG is like any other open source project, even when it doesn't look like it. In many ways, it isn't. > Someone has to bring a written spec to WG21 meetings and push it through. That is one way it is not like (most) other FOSS projects. In a typical FOSS project, there are bug reports and feature/change requests that people file. They don't have to write a full article merely for their idea to be given the t…

They kind of do, otherwise those RFC, PIP, TIP, PEP, JSR,... die out. A pull request isn't enough, even if online collaboration is simpler than with ISO related meetings.

Those are examples of standardization processes, not FOSS projects.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#348

Post by menaerus »

aw1621107 wrote: post #332
germandiago wrote: post #295

Earlier quoted context omitted.

But compile-time processing is certainly useful in a performance-oriented language. And not only for performance but also for thread safety (eliminates initialization races, for example, for non-trivial objects). Rust is just less powerful. For example you cannot design something that comes evwn close to expression templates libraries.

> For example you cannot design something that comes evwn close to expression templates libraries. You keep saying this and it's still wrong. Rust is quite capable of expression templates, as its iterator adapters prove. What it isn't capable of (yet) is specialization, which is an orthogonal feature.

> Rust is quite capable of expression templates, as its iterator adapters prove.

AFAIU iterator adapters are not quite what expression templates are because they rely on the compiler optimizations rather than the built-in feature of the language, which enable you to do this without relying on the compiler pipeline.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#349

Post by aw1621107 »

Conscat wrote: post #345
aw1621107 wrote: post #332

Earlier quoted context omitted.

> For example you cannot design something that comes evwn close to expression templates libraries. You keep saying this and it's still wrong. Rust is quite capable of expression templates, as its iterator adapters prove. What it isn't capable of (yet) is specialization, which is an orthogonal feature.

Rust cannot take a const function and evaluate that into the argument of a const generic or a proc macro. As far as I can tell, the reasons are deeply fundamental to the architecture of rustc. It's difficult to express HOW FUNDAMENTAL this is to strongly typed zero overhead abstractions, and we see where Rust is lacking here in cases like `Option` and bitset implementations.

> Rust cannot take a const function and evaluate that into the argument of a const generic

Assuming I'm interpreting what you're saying here correctly, this seems wrong? For example, this compiles [0]:

    const fn foo(n: usize) -> usize {
        n + 1
    }

    fn bar() -> usize {
        N + 1
    }

    pub fn baz() -> usize {
        bar::()
    }
In any case, I'm a little confused how this is relevant to what I said?

[0]: https://rust.godbolt.org/z/rrE1Wrx36

Post reply on HN