Iterator for a list implemented using unique_ptr - c++

Question

I am creating a datastructure that uses unique_ptr. I now want to define different iterators over this datastructure, however the nodes of my data structure are part of the data itself. Because of this I want the iterators to return the actual nodes and not only the values contained within.
Here is what I got so far (much simplified example):
#include <algorithm>
#include <iostream>
#include <memory>
using namespace std;
template <typename T> struct node {
node(T val) : val(val), next(nullptr) {}
node(T val, unique_ptr<node<T>> &n) : val(val), next(move(n)) {}
T val;
unique_ptr<node<T>> next;
template <bool Const = true> struct iter {
using reference =
typename std::conditional<Const, const node<T> *, node<T> *>::type;
iter() : nptr(nullptr) {}
iter(node<T> *n) : nptr(n) {}
reference operator*() { return nptr; }
iter &operator++() {
nptr = nptr->next.get();
return *this;
}
friend bool operator==(const iter &lhs, const iter &rhs) {
return lhs.nptr == rhs.nptr;
}
friend bool operator!=(const iter &lhs, const iter &rhs) {
return lhs.nptr != rhs.nptr;
}
node<T> *nptr;
};
iter<> begin() const { return iter<>(this); }
iter<> end() const { return iter<>(); }
iter<false> begin() { return iter<false>(this); }
iter<false> end() { return iter<false>(); }
};
template <typename T> void pretty_print(const unique_ptr<node<T>> &l) {
auto it = l->begin();
while (it != l->end()) {
auto elem = *it;
cout << elem->val << endl;
++it;
}
}
int main() {
auto a = make_unique<node<int>>(4);
auto b = make_unique<node<int>>(3, a);
auto c = make_unique<node<int>>(2, b);
auto d = make_unique<node<int>>(1, c);
for (auto *elem : *d) {
elem->val = elem->val - 1;
}
pretty_print(d);
return 0;
}
Is it considered bad practice to expose the raw pointers to the elements of the datastructure in this way? Will this work in a more complex example, especially in regard to const-correctness?

Answer 1

This is largely opinion, but I'd say it's a bad idea. unique_ptrs should be unique; the rare exceptions should be if you need to pass a raw pointer to some other function that isn't properly templated (and you know for a fact it doesn't hold on to the pointer).
Otherwise, you're in a situation where reasonable uses, e.g. initializing to a std::vector<node<int>*> using your iterator, violate the assumptions baked into unique_ptr. In general, you want your APIs to behave predictably with limited developer headaches, and your proposal adds the headache of "You can iterate it as long as you don't store anything to anything with a lifetime beyond my custom structure's lifetime".
Better options are:
Returning references to your actual unique_ptrs (so people are able to work with them without violating the uniqueness contract; make them const if they shouldn't be mutated); they'd have to take ownership or explicitly use "borrowed" unmanaged pointers at their own risk to store the results, but iteration would work fine and they can't accidentally violate uniqueness guarantees
Store shared_ptrs internally, and hand out new shared_ptrs during iteration, so ownership is automatically shared and lifetime extends as long as a single shared pointer remains
Importantly, neither of these two options allows someone to accidentally "do the wrong thing". The caller can do bad things, but they have to personally, explicitly bypass the smart pointer protection mechanisms to do so, and that's on their head.
Of course, the third option is:
Return a reference to the value pointed to, not the pointer; if the value is stored it should be copy-constructed
It's possible for users to get this last one wrong (by storing the reference long term, taking the address of it to get a new pointer violating uniqueness guarantees, etc.), but it follows existing C++ conventions (as Ryan points out in the comments) for containers like std::vector, so it's not a new concern; C++ developers generally know not to do terrible things with references acquired from iteration. It's arguably the best option, since it maps well to the standard patterns, making it easier for developers by fitting into existing mental models.

Answer 2

I would use reference instead of pointer in your iterator
using reference =
typename std::conditional<Const, const node<T>&, node<T>&>::type;
So your iterator has only to be dereferencing once.
(I would keep pointer for the member though).
Pointer in (public) interface introduce a doubt about ownership.
The usage syntax would be:
for (auto& elem : *d) {
elem.val = elem.val - 1;
}
or
while (it != l->end()) {
const auto& elem = *it;
std::cout << elem.val << std::endl;
++it;
}
Your iterator indeed is invalidated when its corresponding node is released which is the common case.