This is what modern C++23 looks like:

std::pair<int, double> getTwoReturnValues() {
int value1 = 32;
double value2 = 3.14;
return {value1, value2};
}

void executeThisF(std::invocable<int> auto f) {
std::print("{}\n", f(3));
}

std::expected<int, std::string> parseInt(std::string_view s) {
try {
return std::stoi(std::string(s));
} catch (const std::exception& e) {
return std::unexpected("Failed to parse int: " + std::string(s));
}
}

int main() {
auto [a, b] = getTwoReturnValues();
std::print("a = {}, b = {}\n", a, b);

executeThisF([](int x) { return x * 3; });

std::unordered_map<std::string, int> config {
{"Alice", 90},
{"Bob", 85},
};
for (const auto& [k, v] : config) {
std::print("{} = {}\n", k, v);
}

std::vector<int> v = {1, 2, 3, 4, 5};
auto results = v | std::views::filter([](int n) { return n % 2 == 0; });
for (const auto& n : results) {
std::print("{}\n", n);
}

std::string input = "42";
if (auto result = parse_int(input); result) {
std::print("Parsed int: {}\n", result.value());
} else {
std::print("Error: {}\n", result.error());
}
}


When full support for C++ modules lands on Clang and CMake, it's going to be over for rustranny, if you fell for rustroon meme and went troon, there's still time to turn back.

>>105831578 (OP)
why is it return {x,y} but auto [x,y] in LHS?

>>105831688
because it's implicit: return std::pair {x,y};

>>105831738
why can't the compiler infer int here?
executeThisF([](auto x) { return x * 3; })

>>105831578 (OP)
The problem with C++ isn't that it lacks features, the problem with C++ is that it has so many features nobody knows how to use it

>>105831578 (OP)
>Exceptions in 2025
Dropped.

>>105831750
it can

c++ drivers will be in linux any minute now 2025 is the year of c++ in the kernel

>>105831578 (OP)
>This is what modern C++23 looks like
Looks like shit.

>>105832073
looks better than rustroon by a mile

They're trying to compete with Rust by becoming just as bad. Except at least in C++ you have the option to use it as "C with classes" :^)

>>105831578 (OP)
Gross looking syntax. Like C's methhead cousin

>>105831578 (OP)
C++ is for gay baby retards
Real men learn ASM

>>105832212
you are the reason for those shitty C++ code bases that are C with extras
>>105832229
if you are not dealing with drivers and true low level stuff like firmwares, you are wasting your time

>>105831578 (OP)
Looking great. Can you point to major projects written in modern C++23 I can contribute to?

>>105831578 (OP)
>return std::unexpected("Failed to parse int: " + std::string(s));
return std::unexpected(std::format("Failed to parse int: {}", s));

In Beef, it's just
class Program
{
static (int, double) GetTwoReturnValues() => (32, 3.14);
static void ExecuteThisF(function int(int) f)
{
Console.WriteLine("{}", f(3));
}

public static void Main()
{
ExecuteThisF((x) => x * 2);
let config = scope Dictionary<String, int>()
{
("Alice", 90),
("Bob", 85)
};
for (let (k, v) in config)
{
Console.WriteLine("{} = {}", k, v);
}

let v = scope List<int>() { 1, 2, 3, 4, 5 };
let result = v.Where((x) => x % 2 == 0);
for (let n in result)
{
Console.WriteLine("{}", n);
}

let input = "42";
let parseResult = Int.Parse(input);
switch (parseResult) {
case .Ok(let val): Console.WriteLine("Parsed int: {}", val);
case .Err(let err): Console.WriteLine("Error: {}", err);
}
}
}

>>105832648
Ew

>>105832252
the fact that a huge chunk of people write in C+ is proof that C has warts but C++ is retarded and getting worse every year

>>105831578 (OP)
>class names still in snake_case
lol
lmao even

"Modern" C++ is completely unconcerned with making the language straightforward for anyone who hasn't already been using it for 10+ years. It's honestly kinda based.

>>105832869
can you point to modern C++23 code-bases developed by those with 10+ years of C++ experience?

>>105831578 (OP)
This looks nice af and no one actually takes rust trannies seriously

>>105831578 (OP)
>now as unreadable as Rust without any of the safety guarantees
How does C++ manage to keep getting worse

>>105832915
>lesbians and minorities are too retarded for C/C++

>>105832928
checks out

>>105832356
you won't find major projects in C++20 or later that is worth or contributions, just small projects.

the max you will find is C++17, C++20 is 5 years old, we only got full clang support in late 2022, targeting C++20 means that your project requires clang 15 or later.

>>105832922
if you think this code is unreadable, you are a non coder.

>>105833227
actually C++20 is not even fully supported by clang 15, only partial, modules are a feature of C++20, not C++23.

that means targeting C++20 makes your project require clang 20+, clang is shitting the bed here.

>>105831578 (OP)
Too verbose, it can be cut down to:
auto getTwoReturnValues() {
int value1 = 32;
double value2 = 3.14;
return std::pair{value1, value2};
}

void executeThisF(auto f) {
PRN "result: ", f(3);
}

#include <ranges>
int main() {
auto [a, b] = getTwoReturnValues();
PRN "a = ", a, ", b = ", b;

executeThisF(λx(x * 3));

struct {const char* a; int b;} config[] {
{"Alice", 90},
{"Bob", 85}
};
for (const auto& [a, b] : config) PRN a, " = ", b;

auto v = {1, 2, 3, 4, 5, 6};
auto results = v | std::views::filter(λx(~x & 1));
for (const auto& n : results) PRN n;
}


just with some helper code:
#define PRN OutputStreamWrapper{},
#define λx(...) [](const auto& x){return __VA_ARGS__;}

#include <iostream>
struct OutputStreamWrapper {
~OutputStreamWrapper(){ std::cout << '\n'; }
const OutputStreamWrapper& operator,(const auto& o) const {
return std::cout << o, *this;
}
};

>>105832648
based beef bro

>>105831578 (OP)
>string based error handling
Kek, lmao even.

>>105832869
They could have done it like JS, by just telling people to stop using legacy shit and come up with some better ways of doing things but boomers would never accept that.
Not that they would be able to do anything this complex even if they all band together. They can't even do modules.

>>105833227
>C++ Won
>you won't find major projects in C++20
>actually C++20 is not even fully supported by clang 15
>clang is shitting the bed here.
lmao.
this is what happens to people who believe in the nocoder shitting out standards for bureaucracy checks.

>>105833617
clang is shitting the bed because they are taking too long for the full module and coroutines support, it was expected for late 2025, but we are mid 2025 and it's not production ready yet, it's not C++ fault.

>>105831578 (OP)
c++ is gay
i say this as a full time c++ engineer
its gay
and u are 2

>>105831578 (OP)
Impressive, very nice. Now let's see carbon langs implementation

cniles will defend this.

>>105831578 (OP)
c++ modules are worthless.

>>105831578 (OP)
I have trouble finding a reliable source of Modern C++23/26 reference/reading materials

>>105833873
>C++ Won
>(continuing dichotomy between the bureaucrats lead by a literal nocoder shitting out "standards", and actual compiler developers)
>it's not C++ fault
lmao

For all the people making strong claims about modules, please tell me:
>how do you feel about current modules support?
>how do you feel about modules generally?
>what is bad about modules? Is it the spec or the implementation? Both? Will it get better?
>who is to blame for the state of modules?

why do people want modules so bad? objects/headers is not bad at all. i do like structured bindings a lot.

>>105833586
Telling the C++ committee to stop obsessing over legacy garbage is like telling Indians to not shit in public. It's their raison d'être.

>>105835502
Is there any reason they can't declare a "legacy" version of C++ that can be used to compile older code, and start working on a new branch with breaking changes? It's not like the C++ most people are using is up-to-date anyway. Sure it's a bit more work for compilers to keep supporting the old standard as well as the new one, but it's not like compilers need a lot of maintenance

I primarily work in Ruby and Python for work, and dabble in C# for games. This C++ code I have almost no familiarity with is perfectly readable.

>>105835532
Because big industry businesses don't want that. They want their legacy codebases to continue to compile. And they're the ones funding C++. They're sponsoring ISO C++. They're paying for Clang and GCC and MSVC development. So if they want backwards compatibility, backwards compatibility stays.

People can bitch about C++ being the way it is but the truth is that the people using it to make money want it that way, the best you can hope for is gradual cleanup. But C++ tends to incorporate new concepts over time and do so more rapidly than it cleans up old ones.

>>105831758
bro just fucking write the program, you don't have to go out of your way to use everything

>>105835588
Are big industry businesses using latest C++? As far as I am unaware the only people who use the latest features of C and C++ are artists making open source passion projects and everyone else is still using decades old standards

>>105835598
this is true in other languages, not in C++ where there are 10 ways to do anything, 8 of them will be insane nonsense you should never use, and telling them apart from the other 2 is not always obvious without prior knowledge.

What is the difference between std::pair and std::tuple?
Can't I just use std::tuple for everything?

>>105835598
The problem isn't that I'm not doing things the most optimal way, the problem is that there are a dozen ways to do one thing and when I am working on someone else's code I will have to deal with whichever arcane bullshit that person decided to use, and vice versa.

>>105835603
My company does

>>105835628
tuple when more than 2 elements. pair also has .first and .second

>>105831578 (OP)
Instead of using pair make a class with non-public fields and show how to make structured binding work with that

>>105835632
>>105835614
but it's the same in any big language with tons of features. you just settle on some design patterns and coding style in any given project and try to stick to them. hopping between codebases is a pain in the ass in any language because language features are just the tip of the iceberg, there's tons of shit you have to learn and abide by

>>105835603
Really don't see why not especially if you have access to the new compilers. My company or at least my team is always using new features because we use the latest compilers.

>>105835603
C++ 17 and 20 are pretty common in projects in academia-adjacent fields like computer vision, robotics, ML etc

>>105835678
>but it's the same in any big language with tons of features.
NO IT FUCKING ISN'T. it is difficult to overstate how needlessly complicated and badly designed C++ is on every level. there are probably less than 10 people on earth who have a full and cohesive understanding of the language and all of them are either committee golems or compiler devs.
C++ devs just don't care because they collectively have stockholm syndrome
>you just settle on some design patterns and coding style in any given project and try to stick to them
which just leads to endless bikeshedding over what the "sane" subset of C++ is

>>105835614
>>105835632
An ISO-standard-defined, compile-time only profile (ie. no code generation or runtime components) that only allows "modern" C++ and is slightly opinionated, and allows for opting-out when for instance implementing abstractions, might help with this.
Could call it "modern-c++26", have the recommended way to use it to enable it as an argument to the compiler invocation (not use the specific version annotation anywhere in source code), and let the generic opt-out annotation inside code be non-version-specific. Once C++29 and later versions roll around, create new, slightly opinionated profiles for each new version. That way, old code is supported, but projects that are new or kept up to date can have a consistent "modern" C++, standards-based compiler-enforced subset of C++. It should also enable gradual upgrading and refactoring. It could also enable standard rewrite suggestions, like what Rust has with Clippy. Could also take inspiration from https://github.com/rust-lang/rust-clippy .

>>105835737
>which just leads to endless bikeshedding over what the "sane" subset of C++ is
but that's my point, it doesn't really matter what subset you use, so long as you do the same thing the same way in your project. new contributors coming in will have to learn the ropes anyway, they can learn new syntax but only if you're consistent and principled in how you use it.

the problem with C++ is that if you aren't consistent you can do the same thing in 5 redundant ways which leads to confusing spaghetti down the line

>>105831578 (OP)
Looks perfectly readable to me. Long live C++! Static reflection for LLVM in 10 years. We will get there, bros!

You forgot to pad your code with dynamic_cast<> and the 5 other 20-character boilerplate expressions necessary to do amything in C++

>>105831578 (OP)
why is the syntax is so verbose and ugly?

>>105831578 (OP)
Looks shit. I'll stick to C#
t. filtered by modern cpp

>>105831578 (OP)
>not always using auto
not modern enough

>>105832252
>C++ code bases that are C with extras
And what's the problem with that?

>>105832648
Looks a lot like C#
>let
why though?

>>105836883
>Looks a lot like C#
Unlike C#, Beef already has discriminated union ;)

I think the syntax is purposefully designed to resemble C#, making it easier for developers familiar with XNA or Unity to adapt. Memory management is handled manually but includes quality-of-life features like defer statements, scope allocation, sized arrays, checked arithmetic, first-class custom allocator support, and memory leak detection in debug builds. Additionally, it offers a comprehensive IDE with a built-in debugger that supports hot reloading.

>why though?
let is somewhat like `const auto`. I'm too lazy to specify the types and it's immutable by default this way.

>>105836772
but they're not needed there

in fact, unless you're a retard you hardly ever need explicit casts at all. you're probably some JSnigger or pythonista trying to force design patterns from different languages onto C++

I will be shocked if module support and use is widespread before 2030.

>>105831578 (OP)
rust looks way better though
use std::collections::HashMap;

fn get_two_return_values() -> (i32, f64) {
let value1 = 32;
let value2 = 3.14;
(value1, value2)
}

fn execute_this_f<F>(f: F)
where
F: Fn(i32) -> i32,
{
println!("{}", f(3));
}

fn parse_int(s: &str) -> Result<i32, String> {
s.parse::<i32>().map_err(|_| format!("Failed to parse int: {}", s))
}

fn main() {
let (a, b) = get_two_return_values();
println!("a = {}, b = {}", a, b);

execute_this_f(|x| x * 3);

let config: HashMap<&str, i32> = [("Alice", 90), ("Bob", 85)]
.iter()
.cloned()
.collect();

for (k, v) in &config {
println!("{} = {}", k, v);
}

let v = vec![1, 2, 3, 4, 5];
let results = v.iter().filter(|&&n| n % 2 == 0);
for n in results {
println!("{}", n);
}

let input = "42";
match parse_int(input) {
Ok(value) => println!("Parsed int: {}", value),
Err(e) => println!("Error: {}", e),
}
}

>>105837200
Why are these needed?
.iter()
.cloned()
.collect();

>>105837225
I don't know any rust but I assume the "iter()" is needed to get an iterator to the object so you can apply the "cloned()" method of the iterator interface, and the collect is a reduction operation

why it doesn't process the literal directly I don't know

>>105832861
no modern language does this
not even fucking haskell does it

>>105833395
>lambda
fucking kys lisptranny

>>105837225
NTA, they are not. You can just do HashMap::from([(k1, v1), (k2, v2), ...]).
Also instead of .iter().cloned() you can just do .into_iter() to consume the array instead of iterating over copies of it's values(it will still compile to the same thing though)

>>105833395
>#define
kys

>>105835389
>Modules work but getting build systems like CMake to compile them is a nightmare. For others like XMake it is straight forward, but XMake has its own share of problems. Other than that, modules work.
>Better than headers, certainly. But not a very high bar to cross, huh? They compile faster and named translation units are just much more elegant than file/path specified includes. Not to mention that there is no longer a reason to split your code between declarations and source.
>Modules were a last minute thing tacked on to the language that should have been in C++ from the start like every modern language had. Ideally modules would be like Java where each package is tied to its path and namespaces corresponded to modules exactly. Furthermore, the tooling is absolute dogshit. Language servers can parse includes, but to parse modules you have to recompile everything and allow the language servers to read the generated .pcm file metadata. No other language has this problem. Not even Rust, which also works similarly with modules. There is also the lack of any convention when it comes to naming modules. Retards name their modules shit like math and util, which clash with any other project that name a module the same thing. At least with Java you had to begin with the company domain in the package names.
>Committee for coming up with such an awful last-minute proposal, compilers for doing fuck all to support them and make working tooling (intellisense module support is nonexistent, and clangd modules are useable on a good day), C++ community for the absolute lack of convention when it comes to naming modules.

>>105831578 (OP)
At what point will people realise that throwing more abstractions at programming languages won't make them easier in any capacity?

>>105837200
Only complaint about Rust is how fucking ugly the lambda syntax is, say what you want about C++ but in all my life programming C++ has the most elegant lambda syntax I have ever encountered.

>>105836841
>please saaaar use auto so it looks like my shitjeet dynamic typing language like jeetscript where we declare everything with let and var because i have zero iq and dont understand types saaaaaaaaaaaaaaaaar

>>105831578 (OP)
C++ finally got print function in 2023 standard?

>>105835706
provide examples of C++20 projects.
i won't make it difficult and ask for C++23.

>>105837475
You're the one who don't understand types. Go learn an actual strongly typed language like Haskell and come back. Unless you're arguing for verbosity, in that case go back to Java, jeet.

>>105837452
[](){} isn't better.

>>105837299
good reply. but for clarity's sake, you should have explained that .iter() gives you references.

>>105837572
[]<>(){} actually

>>105837548
>You're the one who don't understand types.
good morning saaaaaaaaaar!!!
do not redeeeeeeeem
fuckin esl lmao

>>105837370
Literally everything wrong with C++ can be traced back to Bjarne being a nigger.

>>105837572
[captures](params) -> return-type { body }

What is so difficult?

>>105838121
nothing
just midwits seething at actually sane syntax
java has literally the exact same lambda syntax too
>but muh java is a pajeet language
anyone who calls java pajeet is a gojeet trying to project away from their kikejeet lang

>>105837200
> let config: HashMap<&str, i32> = [("Alice", 90), ("Bob", 85)]
.iter()
.cloned()
.collect();
wow
var t = {"Alice": 90, "Bob": 90}.toTable

>>105838121
>What is so difficult?
Who says about anything being difficult there? >>105837452 claimed that Rust lambda syntax is ugly and I simply pointed out that C++ syntax isn't very pretty either.

Also why even care about aesthetics of engineering tools? Semantics and practicality is all that matters.

>>105838160
See >>105837299

How do I learn C++? Are the Stroustrup books good?

>>105833873
>C++20
>it was expected for late 2025
I like C++ but that is just sad

>>105838360
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

>>105838261
Because the C++/Java syntax is the most readable one

>>105838834
Readability =/= difficulty

>>105832159
it looks the exact same, except no pattern matching or halfway decent sum-types.
>w-what about std::variant
not only is this NOT a sum type, but it's also a pain in the ass to use, and without pattern matching it will never be as good as it needs to be.

>>105838834
sml mogs

>learn c++
>create some single file project
>wow that was actually pretty easy

>want to make a real project with multiple files
>gotta make separate declarations inside header files (what other language makes me write shit twice???)
>barely any tutorials on how to create a proper (c)make that recursively finds all your files

I've never had a problem with the language itself. The real issue is managing projects and compiling. Why do I have to deal with 3 fucking files (cpp, h, and make) when every other language compiler just needs 1?

>>105832861
Camel case is a telltale sign of an idiot. Genuinely revolting.

>>105838563

>>105839183
>only knows snake_case and camelCase
jveet detected

>>105836868
because people think that your project is C++, it's not, you are just polluting C++ statistics.
>>105838360
it depends, what is your background? A Tour of C++ is the best if you are a programmer, I read this book a long time ago, it was updated for C++20 I think.

>>105837200
being honest, do you really think that this shit looks better?

s.parse::<i32>().map_err(|_| format!("Failed to parse int: {}", s))


how this (|_| <expression>) is not a crime? not even jeetscript would dare to do something like that.

>>105839959
>unironically uses try..catch and calls it "modern"
>unironically complains about map_err later
>thinks he is above webshits
lol

>>105839179
>>gotta make separate declarations inside header files
because (stupidly) the language doesn't support hoisting.
>cpp, h
the difference between these is convention. they're both source files.
>make
>>barely any tutorials on how to create a proper (c)make that recursively finds all your files
make is just a scripting language to abstract away incremental builds by handling timestamp comparison and syntax sugar over your shell, it has nothing to do with c/c++. it's language (and task) agnostic.
to compile your program, you invoke the compiler from your shell:
$ cc myfile.c -o mybinaryname


for linking multiple files
$ cc myfile1.c myfile2.c -o mybinaryname


thus, using the power of your shell
$ cc src/*.c -o mybinaryname


of course, this is the naive invocation. you should understand the different configuration options your compiler exposes via flags, like how to delay linking, how to statically link things, set various warnings and settings on/off, set optimization levels, etc.
it's ultimately up to you to structure your project in a non-retarded way so that building is simple, and avoid ridiculous shitware like cmake and autotools that layer needless complexity and obscurity on top of the build process.

if your shell isn't shit, you should be able to glob recursive wildcards via
$ cc src/**/*.c

after you've mastered building from the shell, only then should you learn to use make. and forget about the meta-build systems entirely. the value proposition of make over a basic bitch shell script only makes sense once your compile times are more than like 10 seconds for a full rebuild.

>why don't other languages do this
because they have stronger opinions on their build process, and there are trade-offs to doing it that way. i'd rather debug a shell build script than cargo, quite frankly.
your os provides the facilities and utilities for ever aspect of development, you don't really need more.

>>105838360
https://rust-for-c-programmers.com/

>>105840006
just respond what I asked you, do you think that shitty lambda monstrosity looks great?

>>105840027
>of course, this is the naive invocation.
this is not just naive, it's slow.
gcc and clang are not internally parallel.

>>105839959
>how this (|_| <expression>) is not a crime?
You are free to name the unused argument and/or add type.

>>105840062
i'm not the same anon.
i never talk about syntax. i leave that to the juniors and sophomores (majority of /g/).
i do however note now the irony of a pretend C++ tard arguing unironically about syntax. lol.

>>105840093
C++ syntax has its issues, but rust syntax is not better, that's it.

>>105839872
>it depends, what is your background?
I took some basic courses on Python and C but that was a while ago so might as well say I'm a complete beginner. I wouldn't really mind if the book or material were to be too dense as long as it's aimed at people learning the language rather than professionals who want a refresher.

>>105840206
then you will do better with Programming: Principles and Practice Using C++: https://www.amazon.com/dp/0138308683

>>105839822
Which convention, if not camelcase, was implied?

>>105840304
Will check it out. Cheers.

>>105831578 (OP)
>C++
>Rust
Dalit tier languages

>>105839062
>it's also a pain in the ass to use
How is it a pain to use? Not fighting your C/C++ & Rust wars. It's rather simple

>>105834115
C++ is an indefensible affront to all common decency, the true Cnile only programmes in pristine C99 or C11.

>>105831578 (OP)
std::pair<int, double> getTwoReturnValues() {
return {32, 3.14};
}

void executeThisF(auto&& f) {
std::print("{}\n", f(3));
}

std::expected<int, std::string> parseInt(std::string_view s) {
int val;
return std::from_chars(s.data(), s.data() + s.size(), val)
? val : std::unexpected(std::string("Failed to parse int: ") + s);
}

>>105831788
2 more weeks!

>>105839183
kys you fucking cnile
>saaar i love it when my structs have the same convention as my methods

always a joy to see codecels arguing on /g/

but i must confess, for me its python. if it had structs it would be perfect but god himself had to step in and nerf it lest it took over the world (it took over the world anyway but i digress.)

>>105839179
>what other language makes me write shit twice???
C

>>105839179
>make
you aren't supposed to write makefiles yourself. you're supposed to use CMake to automatically make makefiles, and then use some sort of CMake wrapper to automatically preprocess your CMakeLists.txt files

>>105838360
you start writing software in C++. eventually, 20 years down the line, you're slightly less clueless in C++ than when you were starting out

>>105831578 (OP)
This is literally just a worse-looking and worse-typing version of Rust.
Sepples users in shambles

>>105834210
>literal nocoder
How does Bjarne get away with it bros?

>>105842118
>CMake wrapper to automatically preprocess your CMakeLists.txt files
I kekd at this part.

looks better than rust imho

>>105842343
it's real, example:
https://colcon.readthedocs.io/en/released/

>>105842118
actually we use ninja now because it is faster

>>105831578 (OP)
>When full support for C++ modules lands on Clang and CMake
keep hoping retard
>it's going to be over for rustranny, if you fell for rustroon meme and went troon, there's still time to turn back.
lmao

>>105837370
Who were behind modules, and who pushed most strongly for them? Who was responsible for what?
As I gather, Bjarne Stroustrup, Gabriel Dos Reis, and others, were some of the main people involved.
Bjarne Stroustrup probably had a lot on his plate beyond modules.
I am not sure of Gabriel Dos Reis, he has claimed on various social media that there was implementation experience, and he has defended modules multiple times, but I have also heard that the implementation experience was basically for a different specification than the specification that got into the ISO standard.

Modules being orthogonal to namespaces, and modules suffering from naming conflicts, if I understand you correctly, seems like a failure of requirements handling. But, if namespaces and modules are orthogonal, why is it that std can be imported with

import std;


Just a module name that is chosen to be the same as the namespace? Is that a general approach, as in people just name their modules the same as their namespaces, or with dot after the namespace name as an informal hierarchical nomenclature?

I cannot help but wonder if modules were pushed through in the hope of having something instead of risking having nothing. A major and fundamental feature like modules might in any case have had a difficult design or evolutionary process or path, since replacing header files was probably always going to be really difficult. Though, given the consequences, having high requirements and expectations for modules also makes sense, and maybe repeated rejection would have been better than accepting them.
Would it have been better to not have any modules for neither C++20, C++23 and C++26? A lot of people dislike current modules, or dislike the current state of implementation and ecosystem support.
Module support is coming along. I wonder if people will like or dislike modules in 5 and 10 years.

https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/
https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF
https://bpb-us-e1.wpmucdn.com/sites.gatech.edu/dist/a/2878/files/2022/10/OSSI-Final-Report-3.pdf
https://archive.ph/uLiWX
https://archive.ph/rESxe
https://lkml.org/lkml/2025/2/6/1292

The committee needs to stop overloading more operator.

>>105842412
rent free

>>105831578 (OP)
>std::views::filter([](int n) { return n % 2 == 0; });
is it really that impossible for c++ to define a new lambda syntax that is more like other languages where you can just go something like std::views::filter( auto n => n%2==0 );

>>105845996
that particular example is impossible because you're asking for a generic type you can specialize at runtime, yes. retard.

>>105846008
all the information is there, available at compile time, retard.

>>105846012
no it isn't. std::views::filter returns an object and you've tried to instantiate a specific object with a function of unknown type signature. faggot.

>>105846028
all you have to do is look 1 line above. I'll give you a hint: it has something to do with v's specialization. I wont help you any further but i believe even a dimwit such as you can figure it out from there.

>>105846028
>>105846051
The actual answer is that in some contexts, the type could be omitted due to being possible to infer, in others it couldn't. If the programming language is flexible enough, the language could allow omitting the type whenever it can be inferred. There can, however, be trade-offs. For instance, the more advanced kinds of type inference in programming languages can in the worst case take exponential time.

Basically: Both of you are both right and wrong.

>>105844799
>I wonder if people will like or dislike modules in 5 and 10 years.
zero non-bureaucracy people will ever care. c++ is already dead as an evolving language. even the bureaucracy checks would have stopped by then.

>>105846732
I'm not sure, and I don't think it'd be a good thing. Rust has too severe fundamental flaws or trade-offs in some ways, and there are few other candidates yet. I originally years ago hoped and hopped on the hype of Rust being a C++ killer, but the marketing/cult of Rust promises way more than what it delivers, especially on some rather important and critical points. Nothing to do with politics, since one could just rescue the language from the community if that was the case, it is open-source after all.

>>105846970
>Rust has too severe fundamental flaws
What are the fundamental flaws if Rust?

>>105847001
>if
Spelling error detected, presumed Rust evangelist.

>>105835559
>This C++ code I have almost no familiarity with is perfectly readable.
true, but also unneccessarily ugly

>>105835559
>This C++ code I have almost no familiarity with is perfectly readable
What is going on in 356-363L?

>>105847031
>unable to answer
Like pottery

>>105847156
Clearly able to answer, but:
Learn to spell.

>>105847151
NTA, but smells like template metaprogramming.

>>105847173
>Clearly able to answer
>still no answer
Like pottery

>>105847183
Clearly able to answer, but:
Learn to spell.

>>105831578 (OP)
That looks like unreadable shit compared to modern languages though. I don't think rust will go anywhere if that's C++ best.

>>105847181
It is. It's also not some random esoteric code but part of C++ stdlib (GNU IIRC).

>>105847187
Lurk moar

>>105831578 (OP)
>modern
>no trailing return type function declarations
stupid faggot.

>>105831578 (OP)
I find it funny that OP is trying to convince C++23 but anyone programming is less archaic programming languages look at this shit snippet and things it's the usual C++ jungle. Yes I know what's it's doing and how to program in C++ but do I like it and does it do a good job? No. I just tolerate it if I need to.

>>105847191
Learn to spell.

>>105847244
Learn to program

>>105847247
Judging by your ability to spell, I am a better programmer than you.
Learn to spell and program.

>>105847294
Sure thing, kiddo

>>105847298
Learn to spell and program, cheap whore.

>>105832648
Beef looks interesting because I already know C#. Might do some gamedev with this.

>>105847181
it smells like a rotting corpse

>>105847501
Does it smell better or worse than procedural macros?

>>105847531
thats a good question.

i think i prefer the third way, which is to have an explicit python script (or whatever langauge you want) that autogenerates whatever bits of code you need as a separate build step.

kind of like what llvm does with tablegen.

>>105847582
>langauge
Learn to spell and program, cheap whore.

>>105845996
>use => for lambdas
back to jeetscript with you

I respect C++ and Rust

>>105837495
Yeah, it's based on fmt::print but it lacks some features and utilities so fmt is still better :P

>>105833873
clang compiles C and Objective C just fine. There's nothing wrong with it at all.
I was heavily into C++ in the late 90s and 2000s, but really it's an abortion of a language that's grown into a demonic and demented abomination that should be exterminated with extreme prejudice.
Just the other day I was reviewing some work by your typical contemporary C++ programmer.... the sort of people who are in love with how smart they think they are and try way too hard to be too clever than they need to be.

>>105847752
what do you code (if at all) in these days?

language discussions to seem to be getting awfully quaint these days, especially when you can get chatgpt to generate chunks on demand.

>>105847731
Imagine being so conceited to name your library something as innocuous and ubiquitous as {fmt}. Something that implies it is otherwise part of the standard library, like how Rust has std::fmt and other languages have an fmt namespace within their standard library.
Oh wait, the author is a Jew from Belarus who does nothing but seethe about muh Ruzzia and le Putler in his bluesky (troon using bluesky, who could have seen this coming?).

>>105847787
I like trans peeps :) You aren't very nice

>>105847752
I've cleaned up and fixed shitty Rust code, Rust doesn't make incompetent people competent, unlike what some believe.

>>105847774
Mostly C because I do embedded stuff, but I quite like Swift and in the last year I've finally taken the plunge into getting familiar with Python.
Python is more awful than JS (I thought we left behind whitespace as indentation with COBOL) but it has some really great and powerful libraries like numpy, pandas and matplotlib that are great for working with datasets so I can see why it's big in ML/AI as it makes it easy to slap things together quickly.

>>105846970
For the purpose of being a C++ killer, it (the following is not an exhaustive list):

1. Restricts the range of architectures and designs, that it supports well and easily, way too much in practice. If it does not cover the vast majority of cases that C++ covers, it cannot kill C++.

2. Difficulty of implementing compilers for it. Even gccrs, which is a great advancement for Rust, aims to reuse a lot of compiler code from rustc. A C++ killer should be easier to make a compiler for than C++. And, judging by the years of work on Polonius, that still is not ready for production, some aspects of Rust may be even harder to write a compiler for than C++. This is 100% relevant for a systems language.

There are a lot of other issues, but those tend to either be theoretically fixable, or not that significant for the purpose of being a C++ killer.

>>105847787
>>105847862
samefagging

>>105848275
>way too much in practice
absolute bullshit. didn't even bother reading the rest of your post.

literally every correct and functional C++ program effectively copies the same patterns you'll see in Rust anyway. I don't know what world you live in, but if they don't, your code is very likely broken and you just don't know yet.

I can upgrade the Rust compiler and my software continues working, I go from GCC4 to 9 to get new, very valid, warnings and segfaults everywhere.

fuck off.

Redpill me on Beef. That looks like white man's C# to me. And I'm planning on making a game anyway.

>>105848514
Nope

>>105840064
So what's the right way? Where am I supposed to magically learn these mystic arts?

>>105848751
using Rust instead.

>>105844799
I think Dos Reis was the primary force behind modules. Bjarne obviously was involved, because he was desperate to roll out any feature to save his dying language. (When I say dying, I mean losing traction. C++ will never really die the same way C has not died yet after 50 years.)
The implementation experience originally came from MSVC, which had its own implementation of modules differing from the current ISO standard. You have to note modules were the last feature MSVC has ever pioneered. Since this Microsoft has invested very little into C++ (MSVC and the MSVC standard library is maintained by only one man, Stephen Lavavej) and still hardly feature compliant with C++23. Modules and namespaces are indeed orthogonal and function separately, but there is no named requirement enforcing that modules and namespaces do not intersect in name, seeing as the compiler loads their namespaces separately. In fact, the only limitations on module names are uniqueness and no use of reserved words (also std.* is reserved but can apparently be overridden with a compiler flag according to Wikipedia). The committee obviously chose the name std for the standard library module that imports all headers because that would be the most logical name, and matches the namespace std.
I think the push to have modules completed and finalized so soon was mostly pressure from the community and maintaining dominance in software engineering industries. You can really tell by the amount of backwards compatibility they try to enforce with modules. They added header units (import headers rather than #include) for that same reason, and did not tie modules to namespaces and file system paths unlike every other language that processes translation units as modules. This was done to allow the least amount of refactoring as possible. Dots in module names were introduced for library authors to suggest hierarchies, but when you compare the modules std and std.compat there is no hierarchy.

>>105848521
>fuck off.
No, you're the liar and the one bullshitting, so you are the one that should fuck off.

>literally every correct and functional C++ program effectively copies the same patterns you'll see in Rust anyway. I don't know what world you live in, but if they don't, your code is very likely broken and you just don't know yet.
Please write cyclic data structures in Rust without unsafe, the borrow checker and smart pointers, and with zero overhead.

>I can upgrade the Rust compiler and my software continues working, I go from GCC4 to 9 to get new, very valid, warnings and segfaults everywhere.
Not even my argument, but even there, Rust does not have a great track record.
https://github.com/rust-lang/rust/issues/127343
https://github.com/NixOS/nixpkgs/pull/332153#issuecomment-2267375183
>We need to be very careful here, because Rust 1.80.0 contains a major unfixable compilation regression that affects all but recent versions of the widely-used "time" crate. (Trying to assess the damage here is what's delayed me opening my own PR.)
https://github.com/rust-lang/rust/issues/75992

>>105848941
>cyclic
what are weak references, same shit you'd do in C++, fucking retard. even javascript has strong/weak refs.

rest of your shit is retarded. upgrading the compiler and breaking type inference isn't world ending, unlike silently eliding "unnecessary" null checks because they're not legally allowed to be null.

>>105848941
>Please write cyclic data structures in Rust without unsafe, the borrow checker and smart pointers, and with zero overhead.
NTA, you can't write a cyclic data structure in C++ without using anything that would be considered unsafe and without overhead. Just because C++ lacks explicit syntax for marking functions that could cause UB, it doesn't mean C++ functions can't cause UB. There is a reason why both C++ and Rust have means of doing things that could cause UB.

Also I don't think you know what borrow checker is. It's not something you invoke.

>>105831763
Exceptions are fine but they really need to be part of the type signature for the function. Also as far as I know stdlib implementations of stack unwinders remain absolute garbage even to this, which is the primary source of code bloat. The actual code generated to try/catch/throw is quite efficient, it's just the library support that is trash.

>>105842242
He's a useful patsy for MSFT. Gaby and Herb are both MSFT shills and they whisper into his ear like serpents. MSFT's goal for C++ is to sell VS licenses. That's it. And they're already setting up to do the same thing with Rust.

>>105849018
Checked exceptions from Java were a great idea and I'm tired of pretending otherwise. C++ should never have removed throws clauses. They should have just improved them to actually work at compile time.

>>105849018
>Exceptions are fine
I really don't agree. They suck asshole because they're basically a giant hole in the typesystem. languages like Rust expect you to just not catch them for a reason.

>>105849018
That's literally a result type

>>105848941
>Please write cyclic data structures in Rust without unsafe, the borrow checker and smart pointers, and with zero overhead.
struct CyclicBuffer<T, const SIZE: usize> {
inner: [T; SIZE],
pos: usize,
}

impl<T: Default, const SIZE: usize> CyclicBuffer<T, SIZE> {
fn new() -> Self {
Self {
inner: std::array::from_fn(|_| Default::default()),
pos: 0,
}
}

fn push(&mut self, val: T) -> T {
let val = mem::replace(&mut self.inner[self.pos], val);
self.pos = if self.pos + 1 >= SIZE { 0 } else { self.pos + 1 };
val
}

fn iter(&self) -> impl Iterator<Item = &T> {
self.inner.iter().rev().cycle().skip(SIZE - 1 + self.pos).take(SIZE)
}
}

>>105849207
Wrong definition of cyclic, as you are well aware, try again.

>>105848976
The only fucking retard with retarded posts here is you and your cheap whore friend, retarded bitch.
And you still didn't refer to the original arguments I made, fucking whore retard.
Try again, and try to be worth something instead of less than nothing.

>>105849432
This is cyclic and you know it.

>>105849016
Except C++ is easier to reason about overall than unsafe in Rust. You should already be aware of that. Are you the same retard behind the other posts, just using polite language?

And regarding the borrow checker, I know that it is a part of the type checking in Rust, and that it is involved with checking lifetimes. What I meant was borrow checking escapes like indices and similar approaches, like seen in bumpalo, since they tend to have a variety of drawbacks and are typically not as direct >>105825822 .

>>105831763
>>105849018
What is funny is that Rust sort of has exceptions in the form of panics compiled with a certain setting and caught using catch_unwind. Often used on Rust backend webservers. On LLVM, Rust panics and C++ exceptions even use some of the same functionality.

>>105849077
Herb Sutter is no longer employed at Microsoft, right?
I also am not sure how much revenue Microsoft gets from VS licenses.

>>105849105
Except with catch_unwind in Rust.

>>105849526
Wrong definition of cyclic, as you are well aware, try again retard.

>>105849625
>Except with catch_unwind in Rust.
which you aren't supposed to do.

>>105831578 (OP)
>std::
literally unusable boilerplate slop

>>105849638
>which you aren't supposed to do.
It is not a deprecated feature in Rust AFAIK, it was intentionally included and is still supported. And there are use cases where they explicitly recommend it. Actix-web, might be a prominent user of internally. Only present in a few places in their codebase I think, might be using it to terminate the connection of a handler that panics, or something like that.
https://github.com/actix/actix-web/issues/1501

>>105849700
>user of it internally

>>105849700
>Actix-web, might be a prominent user of internally
and actix-web is shit. tokio stuff does something similar which is why I'm forced to do shit like panic = "abort"

>>105849718
https://docs.rs/tokio/latest/tokio/runtime/enum.UnhandledPanic.html
ya, still "unstable."
makes me seethe so much.

>>105849578
>Except C++ is easier to reason about overall than unsafe in Rust
Unsafe semantics make it easier to reason about the correctness of code in the same way types make it easier, or any static analysis in general. The more invariants you encode in your type system, the less things have to be argued about in a non-formalized way.

>>105849700
You are not supposed to use catch_unwind for error handling in Rust. It's there so you can attach some nice logging and error reporting if things go bad, but you are not supposed to just resume normal operation after a panic is thrown.

>>105849751
Yet now you're being a retarded liar, for unsafe Rust semantics are complex, and forces upon the programmer of upholding for instance no-aliasing, unlike C++, and unlike C unless one uses "restrict". Please do explain tree borrows, pinning, etc.

>>105849718
So two frameworks seem to disagree with you. So, at the very least, there is not consensus in the Rust community on catch_unwind.

>>105849794
ok, that's fine. I just know better from actually managing Java jeet shitware that would chug on in the face of a storm of exceptions from something being horribly wrong. Maybe this behavior works in a classical shitadmin world, but when we have mostly self-healing shit like kubernetes, catching fundamentally broken shit is a waste of time. normal rust code should only panic if the sky is falling.

>>105849786
>you're being a retarded liar
Point out my lies.

>unsafe Rust semantics are complex
In the same way generics are complex, and types are complex, and calling conventions are complex.
But if you remove all types, all calling conventions, all variables, and return to the most simple things, basic machine instructions and registers, then reasoning about any complex program becomes incredibly difficult.

>>105849794
RTFM
https://doc.rust-lang.org/std/panic/fn.catch_unwind.html
>It is not recommended to use this function for a general try/catch mechanism. The Result type is more appropriate to use for functions that can fail on a regular basis. Additionally, this function is not guaranteed to catch all panics, see the “Notes” section below.

>>105849764
There are a variety of ways to use catch_unwind, as mentioned by different posters, some frameworks use it and survive the panic after some cleanup (like terminating a connection). Presumably requires correct "unwind safety" in Rust, like how C++ has exception safety. I do like using values for errors instead of exceptions, but even in Rust, catch_unwind is used for some specific purposes.

>>105849810
You are attacking a strawman, I just mentioned what the Rust ecosystem is doing, not coming with recommendations myself.

>>105849832
You are asking me to point out lies and retarded content that you are aware of yourself when you wrote them, retarded, cheap whore of a liar. Fuck off, retard.

>for a general try/catch mechanism.
Some popular Rust frameworks are using it in a different way from that. So the manual reinforces what I am saying, retard.

>>105848751
i was specifically referring to the fact that every C (or C++) file should be compiled separately into an object file, then the object files can be linked together at the end.
this is how build systems or (properly written) Makefiles work to allow for process parallelization. there is a protocol that controls the parallelization called "jobserver" which GNU Make supports. Other systems (like cargo) also support it:
https://www.gnu.org/software/make/manual/html_node/Job-Slots.html
as for a general answer about how to do things, you basically need a pre-Make tool to:
1. check for compiler language support and compiler/linker flag support.
2. check for optional/platform-specific API support (from e.g. libc/posix/...).
3. check for dependencies (libraries) that you depend on and get info about them (e.g. using pkg-config).
4. Generate a Makefile, or use the tool itself to build your project.
1 and 2 work by compiling snippets of code and see if the compiler returns with success. some build systems allow you to do run tests too, but that's not a beginner topic (and may complicate/break cross compilation).
with 1, success appends the flag to CFLAGS or LDFLAGS or ...
with 2, success defines a variable (for the C or C++ preprocessor), an error would fail the build process, or just not set the define (if it's something optional).
as for what tool should be used, there is no good answer. i picked a python-based one (which i won't name) for my old C projects MANY years ago. but if i was looking for a build tool today, i would possibly pick something different. but thankfully, i moved to rust for all new projects, and that problem solved itself.
note that you can use a Makefile directly and skip all that for personal projects, where it would work in "normal" circumstances.
(i'm not a fan of C++, and wouldn't recommend anyone waste time learning it , unless it's required for work. i would recommend learning C then Rust. but i don't care to force that view on others.)

>>105849899
>You are asking me to point out lies and retarded content that you are aware of yourself when you wrote them, retarded, cheap whore of a liar. Fuck off, retard.
Not an argument.

>>105849654
Use using statements like literally every other language
That is like complaining about java.lang.* and System.* as boilerplate

>>105848941
>Please write cyclic data structures in Rust without unsafe, the borrow checker and smart pointers, and with zero overhead.
nta but i'll admit that this is impossible, seconding >>105849016
for the record, it's very difficult to write a self-referential data type that actually obeys the lifetime rules without subtly introducing bad behavior
for example, this was my first attempt
struct SelfReferringS {
self_ref: Option<NonNull<SelfReferringS>>,
data: usize,
}

struct SelfReferring {
self_ref: &'static mut SelfReferring,
data: usize,
}

impl SelfReferring {
pub fn new() -> Pin<Box<SelfReferring>> {
let mut s = Box::pin(SelfReferringS {
self_ref: None,
data: 0,
});
s.self_ref = Some((&*s).into());
unsafe { mem::transmute(s) }
}
}

the issue here being that you can trivially violate the borrow rules simply by taking an &mut reference of the struct (since the struct also contains an &mut reference to itself, that's two, which violates the rules)

>>105850109
You have naught but lies and retardedness, while I have arguments and rightly call you out. Fuck off, retarded, cheap whore.

>>105849016
>>105850220
Samefag.

I literally don't understand C++ move functions and I've been coding with shit for 10 years. Pointers are much more simpler.

>>105850412
C++'s move is hideous. It's one of the worst named functions ever.
For one, it doesn't even *move* anything. It merely gives you a T&& so that you can *choose* to modify the reference (though this is not necessary, and in fact most types don't touch it).
It doesn't prevent the old object from being destructed either.
At best, it provides a way to make sure that things like fds are only closed once. But it's really a terrible name.

>>105839179
>I've never had a problem with the language itself. The real issue is managing projects and compiling.
For real. Would love to love C(++), but the management side is such a clusterfuck. Unironically the most complicated part of the language(s).

>>105850454
move is used to call move constructor

>>105850454
What is curious is that C++ supports non-destructive moves, while destructive moves are the norm in Rust.
(The concepts may be more complicated than "destructive" and "non-destructive", and compilers may optimize related code in different ways).
C++ got support for a kind of destructive moves in C++26, even though there was some controversy about it, including that the wretch Arthur O'Dwyer (assuming the rumors are true, I have seen one news article. Though maybe that was a different Arthur O'Dwyer, even though that seems unlikely) whined about it.
Rust has something called interior mutability, and UnsafeCell, related to this topic.

>>105850495
Move constructor is an okay name. std::move is bad though.
>>105850638
Non-destructive "moves" are not moves. Only C++ could invent this kind of mental gymnastics and claim it to be true.

>>105850220
>very difficult to write a self-referential data type that actually obeys the lifetime rules without subtly introducing bad behavior
Just use MaybeUninit and Pinning. There is no need to worry about lifetime rules here since lifetimes only apply to references and you can't use references for this kind of structure, neither in Rust nor C++. You can't even reassign references in C++.
struct SelfRef {
self_ref: NonNull<SelfRef>,
data: usize,
}

impl SelfRef {
fn new() -> Pin<Box<SelfRef>> {
let mut boxed = Box::new(MaybeUninit::<SelfRef>::uninit());
// SAFETY: needs to fully initialize `boxed` and pin it to make sure self_ref is always valid
unsafe {
let self_ref = NonNull::new_unchecked(boxed.as_mut_ptr());
boxed.write(SelfRef { self_ref, data: 0 });
Box::into_pin(boxed.assume_init())
}
}
}

>>105851434
Yes, I know it's fairly easy if you don't use references anymore. See >>105850220 which is similar

>>105851495
Sure. However you should drop the mut since you should not be allowed to get mutable reference to something while also holding some other reference to it(even via self).

Also, we both should have added PhantomPinned, especially in your case or it is trivial to cause UB
let SelfReferring {
self_ref: SelfReferring {
data: data2,
..
},
data: data1,
} = &mut *self_ref;
// data1 and data2 are &mut to the same location

>>105837548
>haskell
doctor, my neovagina is having yellow discharge... no i studied haskell.. no i have no job offers... NO INSURANCE U HECKIN BIGOT????

>>105831578 (OP)
>C++23
who cares about what it looks like, compilers wont support any of its features until 2067 or even later

>>105848941
>>105849016
>>105850220
>>105851434
Oh, I just realized you don't even need unsafe lmao.
I present you: a cyclic data structure in Rust without unsafe, "the borrow checker" and smart pointers, and with zero overhead.

use std::ptr::NonNull;
use std::pin::Pin;
use std::mem::MaybeUninit;

pub struct SelfRef {
self_ref: NonNull<SelfRef>,
data: usize,
}

impl SelfRef {
pub fn new() -> Pin<Box<SelfRef>> {
let mut boxed = Box::new(MaybeUninit::<SelfRef>::uninit());
let self_ref = NonNull::new(boxed.as_mut_ptr()).unwrap();
let boxed = Box::write(boxed, SelfRef { self_ref, data: 0 });
Box::into_pin(boxed)
}
}

>>105852717
blame bjarne

this is what rust looks like
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=7cbb0d2869b93cd32df6f0522c3c8667

>>105852901
Oh Box::write is nice
Though this still requires unsafe if you want to use the self ref at all

>>105853095
>Though this still requires unsafe if you want to use the self ref at all
But you don't need, everything is already reachable through self!

Statics can be self referential too.
static Ouroboros: SelfRef = SelfRef { self_ref: &Ouroboros, data: 0 };


Also MaybeUninit is not needed as well.
impl SelfRef {
pub fn new() -> Pin<Box<SelfRef>> {
let mut boxed = Box::pin(SelfRef { self_ref: NonNull::dangling(), data: 0 });
boxed.self_ref = NonNull::from(&*boxed);
boxed
}
}

>>105831578 (OP)
>>105850475
I will permanently use c++ once I don't need:
>a frankenstein "tool chain"
>header files

Rust is too restrictive but C++ faggots need to stop pretending unneeded extra work (that isn't even related to the language itself) is somehow a virtue and that the added complexity insists you must have 180 IQ. Rust does this well, but then fucks it up by requiring extreme language verbosity for anything more than hello world.

I just want C++ with modern expectations (that isn't just a replacement language with zero support). I'm simply not interested if I have to fuck around with make files, forward declarations, etc.

>>105854154
>Rust does this well, but then fucks it up by requiring extreme language verbosity for anything more than hello world.
Examples? Rust is not more verbose than, say, Java, in my experience

>>105849091
>>105849018
Correct. Fucking annoying how every method is a mystery box of different types of exceptions nowadays.

c++ scares me I'll stick to php

>>105850454
you do not even need to use std::move if u dont like it. it does effectively the same as the example below. it just calls the move constructor or move assignment constructor.
#include <iostream>

class C {
private:
int* mem_;
std::string name_;
public:
C(std::string name)
: name_(name)
{
mem_ = new int[1000];
}
~C()
{
if (mem_) {
delete[] mem_;
}
}
C& operator=(C&& other)
{
if (this != &other) {
delete[] mem_;
mem_ = other.mem_;
other.mem_ = nullptr;
}
return *this;
}
void print_addr()
{
std::cout << name_ << ": " << mem_ << "\n";
}
};

int main()
{
C c1("obj 1");
C c2("obj 2");
c1.print_addr();
c2.print_addr();
/// c1 = std::move(c2);
c1 = static_cast<C&&>(c2);
std::cout << "moved\n";
c1.print_addr();
c2.print_addr();
}

>>105854465
>> move assignment constructor
i meant operator

>>105849578
cyclic data structures aren't ub in c++, why would you even bring that up?

>>105854154
Rust is quite elegant 80% of the time but I agree with generics and lifetimes it gets extremely verbose.

No sir, not leaving C++11

Can i use C++ without any of the sexually transmitted disease usage?

>>105854159
no formal education cope. They think some outsider shit language will magically fix everything without realizing how much work was done on Rust to give it the semantics it has. All the midwit languages like go and zig start looking more "verbose" as they add the needed complexity to their type systems anyway.

>>105831758
99% of the time I have to use c++ was to write some plugins or modify something that already within a set framework and convections
only gods or idiots were assigned or chose to design stuff from scratch with c++

>>105831688
>return {x,y}
constructs and returns std::pair
>auto [x,y]
declares a structured binding

std::pair is a class with full allocated objects and some wrapper methods, structured binding is like a struct of references, but the struct itself is an unnamed, unique type (like a lambda)

I'll stick to C with classes

>>105850790
What are the big advantages to destructive moves? Code organization, ergonomics, performance by not having to call destructors? Non-destructive moves do provide some benefits in terms of performance.

>>105857503
>What are the big advantages to destructive moves?
Zero cost
https://www.youtube.com/watch?v=rHIkrotSwcc&t=1057s

>>105851749
>Also, we both should have added PhantomPinned, especially in your case or it is trivial to cause UB
Is it necessary to understand pinning and related types to avoid UB when wrangling with unsafe in Rust?

>>105852901
>SelfRef
Something more complex than that? Like a doubly-linked list?

>>105837245

>why it doesn't process the literal directly I don't know
Because he used an array literal and wants a hash map.

>>105854782
And what about in Rust? As was the focus in that conversation.

>>105857516
It's only necessary to understand pinning if you are dealing with unsafe and either async, self referencial structures or other objects that cannot be moved like raw mutexes or something. It's not something you have to worry about 99% of time.

>>105856596
Graydon Hoare (not me) would have done a lot differently.
https://graydon2.dreamwidth.org/307291.html

>>105850790
it moves resources from one object to another. that's why it's called move.
there is no "movement" in rust, just struct copying.

>>105831758
>>105835752

>>105857526
pub struct List<T> {
next: Option<Box<List<T>>>,
prev: Option<NonNull<List<T>>>,
data: T,
}


impl<T> List<T> {
fn new(data: T) -> Self {
Self { next: None, prev: None, data }
}

fn push(&mut self, data: T) -> &mut Self {
let this = NonNull::from(&*self);
match &mut self.next {
Some(next) => next.push(data),
next => {
*next = Some(Box::new(List {
next: None,
prev: Some(this),
data,
}));
next.as_mut().unwrap()
}
}
}

fn iter(&self) -> impl Iterator<Item = &T> {
iter::successors(Some(self), |node| node.next.as_deref())
.map(|node| &node.data)
}
}

fn main() {
let mut list = List::new(0);
list.push(1)
.push(2)
.push(3)
.push(4)
.push(5);

println!("{:?}", list.iter().collect::<Vec<_>>()); // [0, 1, 2, 3, 4, 5]
}

>>105831788
C++, unlike Rust, is not going to push, pressure and harrass others to get its way.

https://archive.ph/uLiWX
https://archive.ph/rESxe
https://lkml.org/lkml/2025/2/6/1292

>>105837245
>>105857529
HashMap implements From<[(K, V); N]> so you don't even need to use iterators.

>>105857572
So, it is actually something to worry about when dealing with unsafe in Rust.

>>105857771
It literally does though. Why do you think modules are being forced in even though no compiler, not even MSVC, implements them well?
You retards have some really mentally warped delusions.

>>105857656
In Rust, moving variable moves it from one scope to another. After the move, the variable is no longer there. That's why it is called a move. It also always happen and cannot fail.
In C++, moving is just fancy assignment operator. It only copies some members and moves resources, but the original variable doesn't move anywhere, you only pass a reference to it and it stays in a valid state and still needs to have destructor called if the compiler cannot deduce whenever the function you called even moved out these resources or not.
That's why C++ move semantics is not zero cost.

>>105857771
>C++, unlike Rust, is not going to push, pressure and harrass others to get its way
C will though. Why do you think Hellwig(the guy Hector was complaining about) got scolded by Linus and then left Linux?
This whole drama was just a result of Linus failing to step in and stop pointless drama between two autists.

>>105857763
Please give an example of using 'prev' in that code snippet, just some different operations, without using unsafe.

>>105857932
>moving the goalpost again
Yawn, now it's your turn. I have already gave you like 3 snippets.

>>105857828
Retarded cheap whore, you pretend to not understand, but even a retarded whore as cheap as you can only be assumed to understand already what "others" refer to. Apart from that, as usual, your "argument" is too faulty and wront to even be considered an argument.
And the only retard in this conversation is you. As you already knew when you typed that post.

>>105857964
>sexually frustrated post full of ad hominem with no substance
What made cniles like that?

>>105857964
>words words words
Linus says rust good, C++ bad. The C++ committee is full of literal psychopath sex pests who sexually harass or rape women and then force their nocoder opinions into the standard that gcc and clang (sometimes ideas so bad even MSVC doesn't either) never implement. You will never be a mentally sane person. Rust won.

>>105857894
Wrong, a large proportion of the Rust community supported Hector Martin and his harassment campaign, even in public. Steve Klabnik, incompetent Ruby programmer that turned into a major Rust evangelist, was a major supporter in public as well.

Hellwig never called for any harassment campaigns to the best of my knowledge, only complained loudly and block some things.

That Rust evangelists rewrite the story of what happened and downplay their harassment, only counts even more against the Rust community. A few voices in the Rust community tried to discreetly discourage this harassment, but did so very quietly, possibly in fear of retribution from the Rust community at large.

>>105857957
I see, you're the incompetent, deceitful, retarded, cheap whore. Fuck off, cheap whore.

>>105857997
>>105858028
Samefag.
Last I checked, ISO prevented throwing out participants, and no one has stood forth and announced who is enabling the wretch Arthur O'dwyer to still be a participant. But the wretch Arthur O'dwyer at least had every single one of his papers rejected for C++26 AFAIK, and he whined about it and was salty.
Curiously, not even the Rust evangelists that lurks in the C++ committee and community will say who is enabling Arthur O'dwyer to still participate in ISO.

Do you happen to know who is enabling him to still participate in ISO?

>>105857997
And the only posts that have no truth or substance are yours, retarded, cheap whore.

Surprisingly, Ralf Jung has acted less competently and more dishonestly than I remember him being. Did he get tilted? Is he so invested into Rust and Miri, with years of work and effort, that he is willing to do whatever to ensure the success of Rust?

>>105858104
>Arthur O'dwyer
Arthur O'Dwyer.
Also search online for
>arthur o'dwyer rape
for possibly relevant news articles.

>>105858060
>block
blocked

>>105841910
Use Mojo then

>>105831578 (OP)
Man, that's a lot of std::

>>105858060
>Wrong
https://lwn.net/ml/all/CAHk-=wgLbz1Bm8QhmJ4dJGSmTuV5w_R0Gwvg5kHrYr4Ko9dUHQ@mail.gmail.com/
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f7d5db965f3e

>>105858070
>>105858118
>sexually frustrated post full of ad hominem with no substance
What made cniles like that?

>>105858104

>>105858255
Your sources confirm my posts, and disproves yours.
How utterly retarded are you, cheap whore?

>>105858273
Since it bears repeating, apparently: The only posts that have no truth or substance are yours, retarded, cheap whore.

>>105858314
>>105858327
>sexually frustrated post full of ad hominem with no substance
What made cniles like that?

>>105858314
disprove

>>105858335
You shouldn't spam, retarded, cheap, lying whore. Now fuck off.

Who hurt him?

>>105858375
>segmentation fault
https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/
Try again, retarded, cheap whore. And this time without lies and retardedness.

>still going

And funnily enough, no one will say who is enabling Arthur O'Dwyer to participate in ISO, not even the Rustaceans in the C++ community.

>>105858375
society failed him so now he goes full contrarian even when it's literally retarded.
that or he's a giga baby duck C++ boomer who can't learn anything new.

>>105858430
>crossbeam
not even going to read the rest, kek.

>>105831578 (OP)
> if (auto result = parse_int(input); result) {
what the fuck is this syntax even

Man, C++ is so insanely ugly and unreadable.

>>105832229
bump bump bump

>>105854154
doesn't rust just ship an absolutely gigantic binary with everything as a crutch? or did they fix that

>>105831763
based go enjoyer

>>105858448

>>105858375
>>105858461
Samefag. Fuck off with your demented delusions, retarded, cheap whore.

>he is still going

>>105858602
Rust has the same, though with a better abstraction, in the form of "if let" statements.

>>105858729
Keep crying, retarded, cheap whore. Being delusional will not make you any less of a retard or whore.

>>105858602
C++ since 17 lets you run initializers inside the if statement so you don't have to construct shit in an external scope before running a boolean check

>if ( initializer(); condition() ) { // stuff }

>>105858602
>>105858767
Btw Rust supports this too.
if {let foo = 5; foo > 3} {
println!("{foo}"); // Error
}

But the variables declared inside condition block do not extend to if body block.

>>105858797
That is just a regular block expression, that exploits that blocks are expressions in Rust.

This code uses "if let" and "if let chains".

fn main() {
let a = Some(3);

if let Some(b) = a && b > 2 {

println!("{}", b);
}
}

>>105858661
Depends on how you link it.
$ bat main.c
───────────────────────────────
File: main.c
───────────────────────────────
1 #include <stdio.h>
2
3 int main() {
4 printf("Hello World!\n");
5 }
───────────────────────────────
$ bat main.rs
───────────────────────────────
File: main.rs
───────────────────────────────
1
2 fn main() {
3 println!("Hello World!");
4 }
───────────────────────────────
$ gcc main.c -O3 -static -o static_c
$ gcc main.c -O3 -o dynamic_c
$ rustc main.rs -O -o static_rs
$ rustc main.rs -O -C prefer-dynamic -o dynamic_rs
$ ls -sh1
total 4.5M
16K dynamic_c
8.0K dynamic_rs
4.0K main.c
4.0K main.rs
764K static_c
3.7M static_rs

>>105831578 (OP)
>c++
really nigga?
im still waiting for ada v rust thread

>>105858709
>go
go back to india pajeet

>>105858895
don't forget to strip rust binaries when doing such comparisons.
and also, these sizes look block-aligned (4KiB-alighned). is your environment unusual in some way where , or did you copy this off someone, or rather something?

>>105859409
>don't forget to strip rust binaries when doing such comparisons.
-O should strip IIRC

>is your environment unusual in some way where
Just Arch with gcc (GCC) 15.1.1 20250425 and rustc 1.90.0-nightly

>>105859435
actually, you're passing -s which explains this (why?). and i saw 1 as l (my bad).

>>105859531
>you're passing -s which explains this (why?).
Idk, to print sizes?
$ wc -c *
15416 dynamic_c
6424 dynamic_rs
65 main.c
45 main.rs
778264 static_c
3852024 static_rs
4652238 total

>>105859584
-s, --size
print the allocated size of each file, in blocks

see the "in blocks" there? this is equivalent to using "du" without "--apparent-size". you would get 4KiB for both a 1byte file and a 4KiB file.
look for some OS/filesystems 101 resource if you're interested in learning more.

>>105859584
>>105860268
oh and those are non-stripped sizes.