Errores, fallos, preguntas - página 1055

[borislg]

zfs:
Encuentra a servicedesk en su perfil.

Gracias.

[Koldun Zloy]

A100:
No hay contradicción aquí, de lo contrario B tendría acceso a C.t como se muestra a continuación, mientras que B no se deriva de C

En tu ejemplo B debería tener acceso a C.t y no veo ninguna razón para prohibirlo.

[Vladimir Gomonov]

Zloy_Koldun:
En tu ejemplo, B debería tener acceso a C.t y no veo ninguna razón para prohibirlo.

Los dos sois raros, confundís clases e instancias. Tampoco creo que otra instancia de la misma clase B deba tener acceso a t.

Los campos protegidos deben ser accesibles sólo por los propios (de la misma instancia B, es decir, esto), y otras instancias (incluso de la misma clase B) deben estar cerradas... Aquí permítanme cambiar el nombre para mayor claridad:

class Человек
{
protected:
   int кошелёк;
};
class Мужчина : public Человек
{
   int fч( Человек& ч );
   int fм( Мужчина& м );
};
int Мужчина::fч( Человек& ч )  // 1
{
   кошелёк = 100;       // Всё в порядке.  моё.
   int s =  ч.кошелёк;   // protected member access error  вполне справедливо
   return s;
}
int Мужчина::fм( Мужчина& м )  // 2
{
   кошелёк = 100;       // Всё в порядке, кошелёк мой собственный
   int s = м.кошелёк;   // это компилируется.  и это НЕПРАВИЛЬНО! кошелёк ЧУЖОЙ !!
// С фига ли я должен иметь доступ к твоему кошельку, только на основании того что мы с тобой оба "Мужчины" ?? 
   return s;
}

Es decir, para mí - ambas funciones no deberían compilar, no sólo la primera. Si en C++ la segunda compila y funciona - eso es un pinchazo de C++, no una virtud.

En resumen:

class Человек
{
protected:
   int кошелёк;
public:
   void Человек() {  a=3; }
   void gч( Человек& ч )
   {
    ч.кошелёк--;  // Даже это не должно компилироваться.  не следует лазить в чужой кошелёк!
    кошелёк++;    // в свой можно
   }   
};

[Koldun Zloy]

Su comparación con la cartera es incorrecta.

Puedo poner un ejemplo en el que se necesita acceso a los miembros proctos, pero no se trata de mis preferencias ni de las tuyas.

Si el programador quiere prohibir algo, puede hacerlo él mismo y el compilador debe prohibirlo,

si es probable que interfiera con el programa.

En el ejemplo anterior, la clase B conoce la clase A, por lo que no va a estropear nada allí.

Y si quieres desautorizarlo, ponlo en la sección Private, o no heredes de una clase, o piensa en mil formas más.

[A100]

MetaDriver:

Es decir, para mí - ambas funciones no deberían compilar, no sólo la primera. Si en C++ la segunda compila y funciona - eso es un defecto de C++, no una virtud.

Entonces tu cartera tampoco sería accesible

Человек ч;
ч.gч( ч );

[Vladimir Gomonov]

A100:
Entonces tampoco se podría acceder a su cartera

Una vez más: distinga con cuidado entre clases (tipos) e instancias (variables). Los campos propios (este) proctorados son de libre acceso, también por herencia (a diferencia de los privados), los otros (otras variables de la misma clase) no deben ser accesibles. (debería ser inaccesible)

Zloy_Koldun:
.....

En el ejemplo anterior, la clase B conoce la clase A, por lo que no va a estropear nada allí.

...............

El hecho de saber que tienes una cartera, no es razón para acceder a ella. A la tuya, por favor, sólo a través de get() y set() - si lo permites (public: int get(); int set();).

[A100]

MetaDriver:

protected no restringe el acceso a nivel de objeto, sino a nivel de clase, porque no tiene información del objeto en el momento de la compilación. He dado un ejemplo de contradicción

Человек ч;
ч.gч( ч );

objeto es el mismo

[Koldun Zloy]

MetaDriver:

Que yo sepa que tienes una cartera, no es razón para acceder a ella. A la tuya - por favor. A la tuya - sólo a través de get() y set() - si lo permites (public: int get(); int set();).

La cartera es sólo un caso especial. Y nadie impide que se coloque en la parte privada.

En otro caso, puede que necesites acceder a la variable de la clase padre del objeto de otra persona.

Y esto lo decide el programador si lo permite o no. Y el compilador debe garantizar que el programa funcione correctamente.

[Vladimir Gomonov]

A100:
He dado un ejemplo de contradicción ... el objeto es el mismo

No hay ninguna contradicción. Si te refieres a ti mismo a través de una "interfaz externa", prepárate para recibir un golpe en la cara por ti mismo ;)

..........., porque en el momento de la compilación no tiene información sobre los objetos.

[Vladimir Gomonov]

Zloy_Koldun:

1. La cartera es sólo un caso especial. Y nadie impide que se coloque en la parte privada.

2. En otro caso, puede que necesites acceder a la variable de la clase padre del objeto de otra persona.

3 Y esto lo decide el programador si lo permite o no.

4. Y es el compilador el que se encarga de que el programa funcione correctamente.

1. Ponerlo en la parte privada no cambiará nada en caso de

class Человек
{
private:
   int кошелёк; 
public:
   void Человек() {  кошелёк=3; }
   void gч( Человек& ч )  
   { 
    ч.кошелёк--;   // сейчас работает.  а не должно ;)
   }
};

Heredará, eso es evidente.

2. Hay muy pocas cosas que haya que hacer. sólo están disponibles cuando se accede a su propia copia.

3. que decida él. correcto. ;)

4. Esta es toda la cuestión: qué cuenta exactamente como "trabajo correcto".