Erros, bugs, perguntas - página 1055
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Encontre servicedesk no seu perfil.
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 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:
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:
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.
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 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)
.....
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();).
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.
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.
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
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".