Erros, bugs, perguntas - página 1055

[borislg]

zfs:
Encontre servicedesk no seu perfil.

Obrigado!

[Koldun Zloy]

A100:
Não há aqui qualquer contradição, caso contrário B teria acesso a C.t como se mostra abaixo, enquanto B não é derivado de C

No seu exemplo B deve ter acesso ao C.t e não vejo qualquer razão para o proibir.

[Vladimir Gomonov]

Zloy_Koldun:
No seu exemplo, B deveria ter acesso ao C.t e não vejo qualquer razão para o proibir.

São ambos estranhos. Confundem classes e instâncias. Não creio que outra instância da mesma classe B deva ter acesso a nenhuma delas.

Os campos protegidos só devem ser acessíveis por si (da mesma instância B, ou seja, esta), e outras instâncias (mesmo da mesma classe B) devem ser fechadas... Aqui deixe-me dar-lhe um novo nome para maior clareza:

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;
}

Isto é, para mim - ambas as funções não devem compilar, não apenas a primeira. Se em C++ a segunda compila e funciona - então é uma punção em C++, não uma virtude.

Em resumo:

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

[Koldun Zloy]

A sua comparação com a carteira está incorrecta.

Posso dar-lhe um exemplo em que precisa de acesso aos membros processados, mas não se trata da minha ou das suas preferências.

Se o programador quiser proibir alguma coisa, pode fazê-lo ele próprio e o compilador deve proibi-la,

se for susceptível de interferir com o programa.

No exemplo acima, a classe B conhece a classe A, por isso não vai estragar nada lá em cima.

E se o quiser proibir, coloque-o na secção privada, ou não herde de uma classe, ou pense em mil outras formas.

[A100]

MetaDriver:

Isto é, para mim - ambas as funções não devem compilar, não apenas a primeira. Se em C++ a segunda compila e funciona - isso é uma falha em C++, não uma virtude.

Então a sua carteira também não estaria acessível

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

[Vladimir Gomonov]

A100:
Então a sua carteira também não seria acedida

Mais uma vez: distinguir cuidadosamente entre classes (tipos) e instâncias (variáveis). Os campos próprios (isto) são livremente acessíveis, também por herança (ao contrário do privado), outros (outras variáveis da mesma classe) não devem ser acessíveis. (deve ser inacessível)

Zloy_Koldun:
.....

No exemplo acima, a classe B conhece a classe A, por isso não vai estragar nada lá em cima.

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

Só porque sei que tem uma carteira não é motivo para aceder à sua. À sua, por favor, apenas através de get() e set() - se o permitir (público: int get(); int set();).

[A100]

MetaDriver:

protegido não restringe o acesso ao nível do objecto, mas ao nível da classe, porque não tem informação sobre objectos no momento da compilação. Dei um exemplo de uma contradição

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

o objecto é o mesmo

[Koldun Zloy]

MetaDriver:

Só porque sei que tem uma carteira, não é razão para aceder a ela. À sua - por favor. À sua - apenas através de get() e set() - se permitir (público: int get(); int set();).

A carteira é apenas um caso especial. E ninguém a impede de ser colocada na parte privada.

Num outro caso, poderá ser necessário aceder à variável de classe mãe do objecto de outra pessoa.

E isto cabe ao programador decidir se o permite ou não. E o compilador deve garantir que o programa funciona correctamente.

[Vladimir Gomonov]

A100:
Dei um exemplo de uma contradição ... o objecto é o mesmo

Não há contradição. Se se referir a si próprio através de uma "interface externa", esteja preparado para ser atingido na cara por si próprio ;)

..........., porque no momento da compilação não tem informações sobre os objectos.

[Vladimir Gomonov]

Zloy_Koldun:

1. A carteira é apenas um caso especial. E ninguém a impede de ser colocada na parte privada.

2. Num outro caso, poderá ser necessário aceder à variável de classe mãe do objecto de outra pessoa.

3 E cabe ao programador decidir se o permite ou não.

4. e cabe ao compilador assegurar que o programa funciona correctamente.

1. Colocá-lo na parte privada não mudará nada no caso de

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

Vai herdar, isso é evidente.

2. Há muito poucas coisas que precisarão de ser feitas. só estão disponíveis quando se acede à sua própria cópia.

3. portanto, deixe-o decidir. correcto. ;)

4. Esta é toda a questão: o que conta exactamente como "trabalho correcto".