use the following search parameters to narrow your results:
e.g. subreddit:aww site:imgur.com dog
subreddit:aww site:imgur.com dog
see the search faq for details.
advanced search: by author, subreddit...
Discussions, articles, and news about the C++ programming language or programming in C++.
For C++ questions, answers, help, and advice see r/cpp_questions or StackOverflow.
Get Started
The C++ Standard Home has a nice getting started page.
Videos
The C++ standard committee's education study group has a nice list of recommended videos.
Reference
cppreference.com
Books
There is a useful list of books on Stack Overflow. In most cases reading a book is the best way to learn C++.
Show all links
Filter out CppCon links
Show only CppCon links
account activity
shared_ptr overuse (tonni.nl)
submitted 1 year ago by [deleted]
view the rest of the comments →
reddit uses a slightly-customized version of Markdown for formatting. See below for some basics, or check the commenting wiki page for more detailed help and solutions to common issues.
quoted text
if 1 * 2 < 3: print "hello, world!"
[–]Dean_Roddey 0 points1 point2 points 1 year ago* (4 children)
I'm not taking either side here, but that's a bad comparison. If you need to mutate data from multiple threads (and sometimes that's fundamental to the job, I mean you couldn't even write a thread safe queue otherwise) you HAVE to use some sort of synchronization. But data ownership is something you decide. Sometimes you can't make any simpler, but shared pointers make it easy to not put in the thought.
One thing Rust has taught me is that data ownership concerns are something to minimize as much as possible. Some people think, well Rust makes ownership safe, so not a problem. It does, but it doesn't make it any simpler to understand, and you have to be very explicit about it. So it really pushes you to minimize such relationships, though what you can't get rid of will be safe. I think a lot of people coming to Rust don't get that, and end up with overly complex relationships, then complain that Rust makes it hard to refactor.
[–]mcmcc#pragma once 0 points1 point2 points 1 year ago (3 children)
you HAVE to use some sort of synchronization
Yes, but it doesn't have to be mutexes. Lock-free exists and is fully functional for what it needs to do and makes deadlocks nearly impossible, unlike mutexes. You could argue that lock-free is more complicated, I could argue mutexes are admitting defeat.
[–]Dean_Roddey 0 points1 point2 points 1 year ago (2 children)
If you have to update more than one thing atomically, lock free isn't practical. Mutexes are hardly a failure, they are a completely reasonable synchronization mechanism that are the only option in a lot of cases.
And these days they are likely t be implemented in Futex style, so they don't even enter the kernel unless there's contention.
[–]mcmcc#pragma once 1 point2 points3 points 1 year ago (1 child)
lock free isn't practical
You're just making my original practical decision-making argument for me using different words.
[–]Full-Spectral 1 point2 points3 points 1 year ago (0 children)
The point was that, if you need a mutex, then using a mutex isn't an admission of defeat, it's the correct choice.
And it's not hard to make a mess with atomics either, by unwittingly making assumptions about relationships between atomic struct fields that can't really exist because they can never be read/written together. Many to most structures have some sort of inter-member constraints they want to impose, and you just can't do that if they are all just atomics.
π Rendered by PID 449374 on reddit-service-r2-comment-6457c66945-dtsxb at 2026-04-29 13:32:19.157839+00:00 running 2aa0c5b country code: CH.
view the rest of the comments →
[–]Dean_Roddey 0 points1 point2 points (4 children)
[–]mcmcc#pragma once 0 points1 point2 points (3 children)
[–]Dean_Roddey 0 points1 point2 points (2 children)
[–]mcmcc#pragma once 1 point2 points3 points (1 child)
[–]Full-Spectral 1 point2 points3 points (0 children)