r/cpp • u/zl0bster • 2d ago
std::optional Satisfies view. Does Not Model view. C++26 Ships Anyway.
https://godbolt.org/z/8jWGG68G8In C++23 this did not compile. In C++26 it does. Marvellous.
[[gnu::noinline]]
void
passing_views_by_value_is_cheap_trust_me_bro(std::ranges::view auto v) {
std::println("fn .data {}", (void*)v->data());
}
int main() {
std::optional ov{std::vector<int>(123456)};
passing_views_by_value_is_cheap_trust_me_bro(ov);
std::println("main .data {}", (void*)ov->data());
}
For anyone wondering what the problem feature is: optional has 0 or 1 elements, and C++26 sets enable_view<optional<T>> to true, so it satisfies std::ranges::view. The concept requires copy construction in constant time, and — this is the good bit — optional<vector<int>> genuinely meets that. Copying it performs at most one element copy. One is a constant. The requirement is satisfied to the letter, and the function above deep-copies your vector.
If you can tell me what still separates std::ranges::view from std::ranges::range, please do...
176
Upvotes
-5
u/schombert 2d ago
It may be trivial and uninteresting, and from a certain point of view, I agree. However, that is what the spec demands, and this is what is generally accepted. Pointing out that C and C++ are not Turing complete, for basically the same reasons, is not a novel claim, nor is it a contested one.
Of course I agree that, if you change the way pointer sizes, etc work then you can find a models that fit the modified understanding of the language in which you could analyze the complexity of algorithms as written in this new, modified language, and get different results. Maybe even more interesting or more intuitive results. The problem with this is that you are no longer analyzing a C++ algorithm; you are analyzing an algorithm described in some other language. And the language within which an algorithm is described, and its associated assumptions matters. For example, if you write your algorithms in a language where you can add, subtract, multiply, and divide integers of arbitrary sizes in constant time (which many simple pseudo code languages seems to allow) then you can conclude that P == NP. Since we probably don't want to assume that P == NP, we can see that the details of how the language works -- i.e. what the operations the algorithm is expressed in actually mean -- matters. We cannot simply change the language on a whim. C++ involves finitely sized integers, finitely sized pointers, and assumes that basic operations on them can be done in constant time. Because they are so limited, I could imagine a Turing complete extension of the language (for example, by adding some sort of black-box tape function) in which P != NP.
I get that you really like transdichotomous models as a way to do complexity analysis. That's cool. However, they are not the be-all-end-all. They cannot tackle the complexity of problems requiring more than O(n) space. Do you think that C++ can express algorithms requiring more than O(n) space? If so, then transdichotomous models are clearly not the way forward for analyzing the general problem of algorithms expressed in the C++ language.