View programming pattern in C++ without raw pointers

Lesser item first:

class View {
 public:
   View() = delete;
   View(const View&) = delete;
   View(View&&) = delete;
   View operator=(const View&) = delete;
   View operator=(View&&) = delete;
   ...
 private:
   ...
   Data& data_;
   View(const Data& data) : data_(data) {}
 };

You have provided a non-default constructor. This means the default constructor is not implicitly declared. You also have a data member that is of a reference type. Even if you hadn't provided a non-default constructor, the default constructor would have implicitly defined as deleted. Bottom line: You don't need to say View() = delete.

There's also no need for defining all four of the copy and move constructors and assignment operators as deleted. The very nice capability of defining a special member function as deleted did not exist in older versions of C++. One insteadhad to use the ugly trick of declaring that special member special member function as private but never providing an implementation.

You are obviously using C++11 (or perhaps even C++14), so you have this nice capability available (and you are using it). You should also understand the rules by which the compiler implicitly declares and defines special member functions that you have not explicitly declared.

• The move constructor and move assignment operator are not implicitly declared if the code explicitly declares any one of a copy constructor, a copy assignment operator, or the destructor. Declaring any one of those C++03 special member functions for a class essentially turns off move semantics for that class. This is essential in making C++11 backward compatible with C++03 code.

• The move constructor is not implicitly declared if the code explicitly declares a move assignment operator. The same applies to the move assignment operator if a move constructor is explicitly declared.

• The copy constructor and assignment operator are implicitly declared and defined as deleted if the code explicitly declares a move constructor or a move assignment operator.

What this means is that defining the move constructor (or the move assignment operator) as deleted implicitly knocks out the other three.

All you need is

 class View {
 public:
   View(View&&) = delete;
   ...
 private:
   ...
   Data& data_;
   View(const Data& data) : data_(data) {}
 };

Since the non-default constructor is private, specifying View() = delete is okay for readability reasons. On the other hand, when I see a slew of XXX = delete definitions where only one is needed is a sign to me that the author of the code doesn't know the language and that I should poke deeply into that code during review.

Regarding how you are using views

There are multiple schools of thought on what "views" are and how they should be implemented. One is that the thing being viewed should know all about the view. Another is that the thing being viewed should know nothing at about the view. Both can be correct. I'll give two concrete examples to illustrate.

One example is JSON. There are seven types of JSON values: An object, an array, a string, a number, and the three special values true, false, and null. The two boolean values can obviously be collapsed to one type, and a numerical value can be expanded to two types (floating point or integral). It helps very much to have different views on a value that implement the details. Most reasonable C++ implementations of JSON do exactly that. Since a specific JSON value can be of one and only one of those types, most implementations contains an enum value that indicates the type and a union of views, only one of which is active, the view corresponding to the enum value).

The other example is very large multidimensional arrays of numerical data. There are a number of different packages that address this problem, and in a variety of ways. Very few use standard library containers. A std::vector<std::vector<std::vector< ... std::vector<double>...>>> is a phenomenally bad idea. Sometimes these arrays are so very large they will not fit into the memory of the largest of computers. Suppose you have found such an array of interest, representing years or even decades of data collected around the globe, but you are only interested in a couple of days worth of data over a tiny portion of the Earth. What you want is a view on that huge array that easily lets you slice and dice that huge array down to a very small size. In this case, the underlying huge array does not need to know that the view even exists. On the other hand, the view needs to know all about that huge array.

You have obviously taken the first approach. Whether that is the correct approach depends very much on what you are trying to view and why you are trying to view things that way.