I've been spreading this info all over the forum and to people I speak to in chats and in real life, and I finally got around to putting together a decent article that explains exactly why I hold this stance:
Nobody has countered my claims on these forums, so I assume many of you agree, but just in case you disagree I'm posting this topic for you to respond to. Maybe people wanted to say something but didn't want to derail the topic.
You should add something about the C-style of using function pointers, and about how passing along variables to callback functions are replaced in C++.
I suppose a reminder that most container implementations use internal pointers should be made. Life would be very difficult without pointers in the lower-level uses of C++.
Nobody has countered my claims on these forums, so I assume many of you agree, but just in case you disagree I'm posting this topic for you to respond to. Maybe people wanted to say something but didn't want to derail the topic.
The absence of disagreement doesn't mean agreement. Makes me think of a comment I got PM'ed on a separate forum I used to be part of.
I disagree with 90% of what is said here, but I feel it is below me to correct such idiocy.
Everything in C++ has its use no matter how remote the use is, but just because you don't like it doesn't mean it has no use. For example, the debate that used to spring up regularly about 1D vs 2D+ vectors/arrays..the difference is minute making the argument pointless, but a lot still want to argue that using 1D to simulate 2D+ is better.
The absence of disagreement doesn't mean agreement.
An assumption is not an assertion. I was confident in my assumption though because of how much I've spoken with people on this and read similar or identical information from others.
BHX Specter wrote:
Everything in C++ has its use no matter how remote the use is, but just because you don't like it doesn't mean it has no use.
I was careful when I titled the article. I also didn't say I disliked raw pointers.
I missed helios' second post.
helios wrote:
Your argument is that pointers have little use. How does "unwrapping the class" eliminate the very real presence of pointers from the code?
I was careful when I titled the article. Not only that, but your code isn't the code using the pointer.
helios wrote:
How is that response relevant to that point?
Well, I suppose std::optional isn't the only wrapper you'd ever use for data structures.
helios wrote:
A small object pool.
I meant, give me an example of an allocator where it is unavoidable to use a pointer.
There are at least 2 uses for raw pointers which I continue to use:
- An object keeping a pointer to its owner.
- When something is needed to refer to something else without necessarily having ownership of it. (weak_ptr works fine here but requires you have a shared_ptr ... it does not work if the object is stack allocated or in a unique_ptr)
@Disch: both of those uses are better served by references or std::reference_wrapper.
helios wrote:
You keep saying that, but I have no idea what it means.
I'm not saying there are no uses for raw pointers at all. I'm only considering common cases in my experience, not obscure cases like ABI/DLLs and C libraries/legacy code which can be wrapped.
helios wrote:
It may or may not be. In the case of byte-level manipulations, it very likely will be.
I still don't understand why these byte-level manipulations are not wrapped.
helios wrote:
I'm not sure what you think I meant by "data structures", but I was talking about sequences, trees, graphs, etc. Buffer-like structures in particular.
Sequences: Standard Library Containers
Trees: std::optional<std::unique_ptr<Node>>
Graphs: std::set<std::unique_ptr<Node>> and std::set<std::reference_wrapper<Node>>
Buffers: std::unique_ptr<T[]>
helios wrote:
Are we talking about avoiding using pointers, or about using the best possible thing for the problem at hand?
The latter results in the former.
@giblit: I have not used Qt, so I don't have an opinion on the matter. My opinion can, however, be managed by a std::optional ;)
I'm not saying there are no uses for raw pointers at all.
I'm not saying you are saying that.
I'm only considering common cases in my experience, not obscure cases like ABI/DLLs and C libraries/legacy code which can be wrapped.
So you get away with saying that there's little use for them by ignoring the cases where they're most often used? Just because you don't interface with C very often doesn't mean it's not a common scenario.
I still don't understand why these byte-level manipulations are not wrapped.
To what advantage? Seems like abstraction for the sake of itself.
Sequences: Standard Library Containers
Trees: std::optional
Graphs: std::set<std::unique_ptr<Node>> and std::set<std::reference_wrapper<Node>>
Buffers: std::unique_ptr<T[]>
Disch, you're asking me what advantage references offer over pointers? Haven't you personally explained this to people on these forums many times?
helios wrote:
I'm not saying you are saying that.
Then what are you saying?
helios wrote:
So you get away with saying that there's little use for them by ignoring the cases where they're most often used? Just because you don't interface with C very often doesn't mean it's not a common scenario.
In C, compare the frequency of use cases for pointers that I ignore to the frequency of use cases for pointers that I don't ignore. (I'm also very biased against C)
helios wrote:
To what advantage? Seems like abstraction for the sake of itself.
OK, I'll let you explain your mysterious byte-level manipulations with comments instead.
helios wrote:
implementing
I meant that you use those classes in the process of implementing those data structures, not that those classes already implement those data structures.
