Errori, bug, domande - pagina 1055

[borislg]

zfs:
Trova servicedesk nel tuo profilo.

Grazie!

[[Eliminato]]

A100:
Non c'è contraddizione qui, altrimenti B avrebbe accesso a C.t come mostrato qui sotto, mentre B non è derivato da C

Nel tuo esempio B dovrebbe avere accesso a C.t e non vedo ragioni per proibirlo.

[Vladimir Gomonov]

Zloy_Koldun:
Nel tuo esempio, B dovrebbe avere accesso a C.t e non vedo ragioni per proibirlo.

Siete entrambi strani, confondete le classi e le istanze. Non credo che un'altra istanza della stessa classe B dovrebbe avere accesso a t.

I campi protetti dovrebbero essere accessibili solo dal proprio (della stessa istanza B, cioè questo), e le altre istanze (anche della stessa classe B) dovrebbero essere chiuse... Qui fammi rinominare per chiarezza:

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

Cioè per me - entrambe le funzioni non dovrebbero compilare, non solo la prima. Se in C++ la seconda si compila e funziona - allora è una foratura del C++, non una virtù.

In breve:

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

[[Eliminato]]

Il tuo paragone con il portafoglio non è corretto.

Posso farti un esempio in cui hai bisogno di accedere ai membri protetti, ma non si tratta delle mie o delle tue preferenze.

Se il programmatore vuole proibire qualcosa, può farlo lui stesso e il compilatore deve proibirlo,

se può interferire con il programma.

Nell'esempio di cui sopra, la classe B sa della classe A, quindi non incasinerà nulla lì.

E se volete impedirlo, mettetelo nella sezione privata, o non ereditate da una classe, o pensate a mille altri modi.

[A100]

MetaDriver:

Cioè per me - entrambe le funzioni non dovrebbero compilare, non solo la prima. Se in C++ la seconda si compila e funziona - questo è un difetto del C++, non una virtù.

Allora anche il tuo portafoglio non sarebbe accessibile

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

[Vladimir Gomonov]

A100:
Allora neanche il suo portafoglio sarebbe accessibile

Ancora una volta: distinguere attentamente tra classi (tipi) e istanze (variabili). I campi propri (questo) sono liberamente accessibili, anche per ereditarietà (a differenza dei privati), altri (altre variabili della stessa classe) non devono essere accessibili. (dovrebbe essere inaccessibile)

Zloy_Koldun:
.....

Nell'esempio precedente, la classe B sa della classe A, quindi non incasinerà nulla lì.

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

Solo perché so che hai un portafoglio non è una ragione per accedervi. Al tuo, per favore, solo attraverso get() e set() - se lo permetti (pubblico: int get(); int set();).

[A100]

MetaDriver:

protected non limita l'accesso a livello di oggetto, ma a livello di classe, perché non ha informazioni sull'oggetto al momento della compilazione. Ho dato un esempio di contraddizione

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

oggetto è lo stesso

[[Eliminato]]

MetaDriver:

Solo perché so che hai un portafoglio, non è una ragione per accedervi. Al tuo - per favore. Al tuo - solo attraverso get() e set() - se permetti (public: int get(); int set();).

Il portafoglio è solo un caso speciale. E nessuno impedisce di metterlo nella parte privata.

In un altro caso, potreste aver bisogno di accedere alla variabile della classe madre di un altro oggetto.

E questo sta al programmatore decidere se permetterlo o meno. E il compilatore deve assicurare che il programma funzioni correttamente.

[Vladimir Gomonov]

A100:
Ho dato un esempio di contraddizione ... l'oggetto è lo stesso

Non c'è contraddizione. Se ti riferisci a te stesso attraverso una "interfaccia esterna", preparati a essere colpito in faccia da te stesso ;)

..........., perché al momento della compilazione non ha informazioni sugli oggetti.

[Vladimir Gomonov]

Zloy_Koldun:

1. Il portafoglio è solo un caso speciale. E nessuno impedisce di metterlo nella parte privata.

2. In un altro caso, potreste aver bisogno di accedere alla variabile della classe madre di un altro oggetto.

3 E questo sta al programmatore decidere se permetterlo o meno.

4. Ed è compito del compilatore assicurarsi che il programma funzioni correttamente.

1. Metterlo nella parte privata non cambierà nulla in caso di

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

Erediterà, questo è evidente.

2. Ci sono poche cose che dovranno essere fatte. I motivi sono disponibili solo quando si accede alla propria copia.

3. quindi lasciatelo decidere. corretto. ;)

4. Questa è l'intera questione: cosa conta esattamente come "lavoro corretto".