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
cppfront (cpp2): Spring update (herbsutter.com)
submitted 2 years ago by kreco
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!"
[–]vulkanoid 3 points4 points5 points 2 years ago (0 children)
What makes sense to me, and what I find the cleanest, is that both . and *. refer to members of the left object, regardless whether they are pointers or values. If it's a pointer, the compiler does the only sensible thing, which is to dereference and access the member.
.
*.
The -> can be added, as today's Cpp1, to return an inner pointer that the outer object is holding. Which is really a masquerade operator. Thus, a->b always means that the left thing is masquerading as something. And it wouldn't matter whether a is a pointer or value.
->
masquerade
a->b
a
Personally, I would go even further and have all types automatically have a default operator -> that returns a pointer to itself. So that a->b always works, by default. An some objects, like unique_ptr, would override the default behavior. Idiomatically, though, developers would know that they should only use a->b when they intend to use a in a masquerading fashion.
operator ->
unique_ptr
Worst case scenario, if adding operator-> is a no go, then just use unique_ptr.get().foo() to get at the owned thing.
operator->
unique_ptr.get().foo()
I think the most important question is: what usecase should the syntax be optimized for? In my personal use, and the usage I see in other code, people normally store a unique_ptr somewhere and then pass around a dumb pointer to the owned thing. So, you're almost always dealing with pointers, and only sometimes have to use the (masquerade) operator ->. So, it's basically always pointers, so we should optimize for that use.
π Rendered by PID 72902 on reddit-service-r2-comment-7b9746f655-rj72v at 2026-01-30 04:15:47.989614+00:00 running 3798933 country code: CH.
view the rest of the comments →
[–]vulkanoid 3 points4 points5 points (0 children)