Just in time for language deprecation
C++26 is done: ISO C++ standards meeting Trip Report
351–360 of 437 posts
Re: C++26 is done: ISO C++ standards meeting Trip Report
#352Finally, reflection has arrived, five years after I last touched a line in c++. I wonder how long would it take the committee, if ever, to introduce destructing move.
C++26 adds destructive moves. They are called relocatable types. There are edge cases where destructive moves are not safe and it is impossible for the compiler to know they aren't safe. C++ uses non-destructive moves when it can't prove the safety of destructive moves, even if destructive moves may in fact be safe. C++26 adds a type annotation that guarantees destructive moves are safe in cases where you can't prove…
From the proposal, I see a bunch of new keywords and rules - alright given the language's heritage. But what happens if I "relocate" a variable value - would a "shell" remain or how exactly C++ is supposed to handle this:
auto value = create_value();
if (some_cond) {
consume_value(std::move(value)); // not sure whether it's move here, but I guess my point is clear
}
use_value(value);Re: C++26 is done: ISO C++ standards meeting Trip Report
#353Earlier quoted context omitted.
Neither "ODR violations" nor IFNDR exist in C. Incompatibility across translation units can cause undefined behavior in C, but this can easily be avoided.
C simply has less wording for it because less work has been put into it. The same problems exist.
The ODR problem is much more benign in C. Undefined behavior at translation time (~ IFNDR) still exists in C but for C2y we have removed most of it already.
Re: C++26 is done: ISO C++ standards meeting Trip Report
#354Earlier 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 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.
I had always thought expression templates at the very least needed the optimizer to inline/flatten the tree of function calls that are built up. For instance, for something like x + y * z I'd expect an expression template type like sum> where sum would effectively have:
vector l;
product& r;
auto operator[](size_t i) {
return l[i] + r[i];
}
vector l;
vector r;
auto operator[](size_t i) {
return l[i] * r[i];
}
Re: C++26 is done: ISO C++ standards meeting Trip Report
#355Earlier quoted context omitted.
> 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.
They are both; there are things that Rust's macros can do metaprogramming-wise that C++ templates cannot do and vice-versa.
Rust's macros work on a syntactic level, so they are more powerful in that they can work with "normally" invalid code and perform token-to-token transformations (and in the case of proc macros effectively function as compiler extensions/plugins) and less powerful in that they don't have access to semantic information.
Re: C++26 is done: ISO C++ standards meeting Trip Report
#356> C++26 is done
Now do C++27. Why do we need every year a standard ? CADT ?
Re: C++26 is done: ISO C++ standards meeting Trip Report
#357Earlier quoted context omitted.
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.
Used by programming languages FOSS projects.
Re: C++26 is done: ISO C++ standards meeting Trip Report
#358Earlier quoted context omitted.
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++ In the space of language design, everything "more powerful" is not necessary good. Sometimes less power is better because it leads to more optimisable code, less implementation complexity, less abstraction, better LSP support. TL;DR More flexibility and com…
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.
> And not only for performance but also for thread safety
This is already built-in to the language as a facet of the affine type system. I'm curious as to how familiar you actually are with Rust?
> Rust is just less powerful.
On the contrary. Zig and C++ have nothing even remotely close to proc macros. And both languages have to defer things like thread safety into haphazard metaprogramming instead of baking them into the language as a basic semantic guarantee. That's not a good thing.
Re: C++26 is done: ISO C++ standards meeting Trip Report
#359Earlier quoted context omitted.
returning "impl Trait". async/await unpin/pin/waker. catch_unwind. procedural macros. "auto impl trait for type that implements other trait". I understand some of these kinds of features are because Rust is Rust but it still feels useless to learn. I'm not following rust development since about 2 years so don't know what the newest things are.
Returning impl trait is useful when you can't name the type you're trying to return (e.g. a closure), types which are annoyingly long (e.g. a long iterator chain), and avoids the heap overhead of returning a `Box `. Async/await is just fundamental to making efficient programs, I'm not sure what to mention here. Reading a file from disk, waiting for network I/O, etc are all catastrophically slow in CPU time and having…
> Reading a file from disk, waiting for network I/O, etc are all catastrophically slow in CPU time and having a mechanism to keep a thread doing useful other work is important.
curious if you have benchmarks of "catastrofically slow".
Also, on linux, mainstream implementation translates async calls to blocked logic with thread pool on kernel level anyway.
Re: C++26 is done: ISO C++ standards meeting Trip Report
#360As more of a C# and Java guy, I'm curious to understand something - what sort of apps do folks here build? I am very interested to hear what problems get solved with these languages today. I know there must be many use-cases, but I don't hear about them too much.