¿Algún problema con esta lengua de interfaz de acceso const referencia C++?

Question

Estaba convirtiendo una estructura en una clase para poder aplicar una interfaz setter para mis variables.
No quise cambiar todas las instancias donde se leyó la variable. Así que convierte esto:

struct foo_t { 
    int x; 
    float y; 
}; 

a esto:

class foo_t { 
    int _x; 
    float _y; 
public: 
    foot_t() : x(_x), y(_y) { set(0, 0.0); } 

    const int &x; 
    const float &y; 

    set(int x, float y) { _x = x; _y = y; } 
}; 

estoy interesado en esto porque parece modelar idea de C# 's de las propiedades públicas de sólo lectura.
Compila muy bien, y todavía no he visto ningún problema.

Además de la repetición de las referencias de const en el constructor, ¿cuáles son las desventajas de este método?
¿Algún problema de alias extraño?
¿Por qué no he visto este idioma antes?

Answer 1

Existe un problema de alias porque expone una referencia a los datos internos de foo_t, es posible que el código externo a un objeto foo_t retenga referencias en sus datos más allá de la duración del objeto. Considere:

foo_t* f = new foo_t(); 
const int& x2 = f->x; 
delete f; 
std::cout << x2; // Undefined behavior; x2 refers into a foo_t object that was deleted 

O, aún más simple:

const int& x2 = foo_t().x; 
std::cout << x2; // Undefined behvior; x2 refers into a foo_t object that no longer exists 

Estos no son ejemplos particularmente realistas, pero este es un problema potencial cuando un objeto expone o devuelve una referencia a sus datos (pública o privada) Por supuesto, es posible conservar una referencia al objeto foo_t más allá de su tiempo de vida, pero puede ser más difícil pasar por alto o hacerlo por accidente.

No es que este sea un argumento en contra de lo que estás haciendo. De hecho, he usado este patrón antes (por una razón diferente) y no creo que haya algo intrínsecamente incorrecto en él, aparte de la falta de encapsulación, que pareces reconocer. El problema anterior es algo de lo que hay que estar consciente.

Answer 2

Su enfoque no es flexible. Cuando tiene un getter/setter para cada variable, significa que no tiene que volver a escribir su método set si agrega algo a su clase.

No es bueno porque no se puede tener const y non-const captadores (que se utilizan raramente, pero a veces podría ser útil).

No puede copiar referencias, por lo tanto, su clase no se puede copiar.

Además, al haber inicializado referenciado en su clase de medios de memoria extra y si estamos hablando de, por ejemplo, la clase vértice (aunque creo que no debería ser una clase en realidad), esto podría convertirse en un desastre.

---

[Todo lo que sigue es completamente subjetivo]

Propósito de captadores y definidores, en mi opinión, no es la modificación sobre simple, sino más bien de la encapsulación de una secuencia de acciones que da lugar a la modificación de valor o devuelve el valor (que tratamos como resultado visible).

Personalmente, struct en el caso de su ejemplo sería más eficaz, ya que ajusta los datos POD y lógicamente "lo estructura".

Answer 3

Un problema es que su clase ya no se puede copiar ni asignar, por lo que no se puede almacenar en contenedores C++ como vectores. Otra es que los experimentados programadores de C++ que mantengan su código lo verán y exclamarán "WTF !!" muy fuerte, lo cual nunca es algo bueno.

Answer 4

También podría hacer algo como esto, que trabaja para construida en tipos: (Lo siento si este fragmento de código contiene errores, pero se entiende la idea)

template <typename T, typename F> 
class read_only{ 
    typedef read_only<T, F> my_type; 
    friend F; 

public: 
    operator T() const {return mVal;} 

private: 
    my_type operator=(const T& val) {mVal = val; return *this;} 
    T mVal; 
}; 


class MyClass { 
public: 
    read_only <int, MyClass> mInt; 
    void MyFunc() { 
     mInt = 7; //Works 
    } 
}; 

AnyFunction(){ 
    MyClass myClass; 
    int x = myClass.mVal; // Works (okay it hasnt been initalized yet so you might get a warning =) 
    myClass.mVal = 7; // Error 
}