Jak zapobiec modyfikacji danych tablicowych?

Powiedzmy, że mam klasę, która wygląda tak (to tylko przykład):

class A {
    double *ptr;
public:
    A() : ptr( new double[100] ) {}
    A( const A &other ) {
        other.ptr[7] = 15;
    }
    void doNotChangeMyData() const {
        ptr[43] = 14;
    }
    void changeMyData() {
        ptr[43] = 14;
    }
    ~A() { delete[] ptr; }
};

Zarówno constw konstruktorze kopiowania, jak i doNotChangeMyDatafunkcji sprawiają, że ptrnie można go zmienić; jednak nadal pozwala mi to modyfikować zawartość tablicy, na którą wskazuje ptr.

Czy istnieje sposób, aby zapobiec ptrzmianie zawartości tablicy consttylko w instancjach, poza „ostrożnością” (lub odejściem od surowego wskaźnika)?

Wiem, że mógłbym zrobić coś takiego

void doNotChangeMyData() const {
    const double *const ptr = this->ptr;
    ptr[43] = 14; // then this would fail to compile
}

Ale wolałbym nie musieć ...

Wskaźniki nie rozprzestrzeniają się const. Dodanie constdo typu double*daje wynik double* const, który powoduje brak wartości constpo dereferencji.

Zamiast tego możesz użyć std::vector:

class A {
    std::vector<double> data(100);
public:
    // no explicit copy ctor or dtor
};

a std::array:

class A {
    std::array<double, 100> data{};
public:
    // no explicit copy ctor or dtor
};

lub wbudowana tablica (niezalecane):

class A {
    double data[100] {};
public:
    // no explicit copy ctor or dtor
};

Wszystkie trzy opcje są propagowane const.

Jeśli naprawdę chcesz używać wskaźników (zdecydowanie nie zalecane), przynajmniej użyj, std::unique_ptraby uniknąć ręcznego zarządzania pamięcią. Możesz użyć std::experimental::propagate_constopakowania z podstaw biblioteki 2 TS:

class A {
    std::experimental::propagate_const<std::unique_ptr<double[]>> ptr;
public:
    A()
        : ptr{new double[100] {}}
    {
    }
    // manual copy ctor
    A(const A& other)
        : ptr{new double[100]}
    {
        std::copy_n(other.ptr.get(), 100, ptr.get());
    }
    // defaulted move ctor & dtor
    // assignment operator, etc.
    // ...
};

Nie ma go jeszcze w standardzie, ale obsługuje go wiele kompilatorów. Oczywiście takie podejście jest gorsze od odpowiednich pojemników.