Erros, bugs, perguntas - página 1056

 

Eu próprio posso encontrar uma justificação para a situação actual: uma separação estrita de "propriedade" entre instâncias da mesma classe poderia levar a uma sintaxe desordenada ao descrever todo o tipo de operações binárias (mesmo ao mesmo nível hierárquico). No entanto, com a herança, o "acesso directo" deve certamente ser aparado.

Porque não vale a pena fazer isso... ;)

[Excluído]  
MetaDriver:

1. A colocação de uma parte privada não mudará nada no caso de

Em caso de herança, isso é evidente.

2. Poucas coisas serão necessárias... Os fundamentos só estão disponíveis em caso de acesso a uma cópia própria.

3. portanto, que decida. correcto. ;)

4. É essa a questão: o que conta exactamente como "funcionamento correcto".

1. Se quer realmente esconder a sua carteira, porque é que faz gch() ?

2. e quando se copiam instâncias, há alguma?

 
Zloy_Koldun:

1. Se quer realmente esconder a sua carteira, porque é que faz a função gh() ?

2. e quando estão disponíveis instâncias de cópia?

Leia o meu post anterior. Todas as respostas estão lá.

Era uma vez uma "decisão política" considerar outros objectos (instâncias) da sua própria classe como amigos por "defeito" - puramente para salvar o bukaf. E agora toma esta excepção como uma norma de vida e quer subir sem obstáculos aos bolsos privados de todos os parentes distantes.

Huh....

 
MetaDriver:

1. A colocação de uma parte privada não mudará nada no caso de

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

Em caso de herança, isso é evidente.

2. Poucas coisas serão necessárias... apenas no caso de acesso à sua própria cópia.

3. portanto, que seja decidido. correcto. ;)

4. É essa a questão: o que deve ser considerado exactamente "trabalho correcto".

Sim, funciona, mas não deve funcionar. A propósito, quando se autocompleta em ME (ao escrever uma ch) não lhe é dada a variável "carteira" porque está em privado, pelo que esta característica provavelmente passou despercebida durante tanto tempo.
[Excluído]  
class Человек
{
private:
   int кошелёк; 
public:
   void Человек() {  кошелёк=3; }
   void gч( Человек& ч )  
   { 
    ч.кошелёк--;   // Работает и должно работать!
   }
   void gcч( const Человек& ч )  
   { 
    ч.кошелёк--;   // Не работает, как и должно.
   }
};
 
Zloy_Koldun:

Ok. Então diz-me. Como definir tal campo numa classe, que só e exclusivamente pode ser modificado por métodos de instância "mestre" e por ninguém mais.

Se é impossível, então o assunto das mamas de encapsulamento não está coberto na língua, pois não?

[Excluído]  
MetaDriver:

Ok. Então diz-me. Como definir tal campo numa classe, que só e exclusivamente pode ser modificado por métodos de instância "mestre" e por ninguém mais.

Se é impossível, então o assunto das mamas de encapsulamento provavelmente não foi coberto na língua, não?

É impossível. E não precisa de ser. Se não estiver de acordo, dê um exemplo sensato.
 
O que significa este erro, a ordem pendente não foi accionada: " HistoryBase: 114 erros em 'GBPUSD60'
 
MetaDriver:
class Человек
{
private:
   int кошелёк; 
public:
   void Человек() {  кошелёк=3; }
   void gч( Человек& ч )  
   { 
    ч.кошелёк--;   // сейчас работает.  а не должно ;)
   }
};
Esta característica foi desagradavelmente surpreendente. É definitivamente uma treta se o compilador permitir mudar o campo privado da instância de outra pessoa. Deve ser afixado no Servicedesk.
[Excluído]  
C-4:
Esta característica é desagradavelmente surpreendente. É obviamente uma treta se o seu compilador lhe permitir mudar o campo privado da instância de outra pessoa. Deveríamos afixá-lo ao servicedesk.

Não compreendo: porque é que se quer limitar tanto?

Acha que tornará automaticamente o seu programa mais seguro?

Não o fará! Pelo contrário.

São restrições desnecessárias que um dia o farão escrever dessa forma:

static int Мой_Кошелёк; // Бери, все, кто хочет.