Errors, bugs, questions - page 1055

[borislg]

zfs:
Find servicedesk in your profile.

Thank you!

[Koldun Zloy]

A100:
There is no contradiction here, otherwise B would have access to C.t as shown below, while B is not derived from C

In your example B should have access to C.t and I see no reason to forbid it.

[Vladimir Gomonov]

Zloy_Koldun:
In your example, B should have access to C.t and I see no reason to forbid it.

You're both weird. You confuse classes and instances. I don't think another instance of the same class B should have access to t either.

Protected fields should be accessible only by own (of the same B instance, i.e. this), and other instance (even of the same B class) should be closed... Here let me rename it for clarity:

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

I.e. to me - both functions should not compile, not just the first one. If in C++ the second one compiles and works - that's a C++ puncture, not a virtue.

In short:

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

[Koldun Zloy]

Your comparison to the wallet is incorrect.

I can give you an example where you need access to procted members, but it's not about my or your preferences.

If the programmer wants to forbid something, he can do it himself and the compiler must forbid it,

if it is likely to interfere with the program.

In the above example, class B knows about class A, so it won't mess anything up there.

And if you want to disallow it, put it in the Private section, or don't inherit from one class, or think of a thousand other ways.

[A100]

MetaDriver:

I.e. to me - both functions should not compile, not just the first. If in C++ the second one compiles and works - that's a flaw in C++, not a virtue.

Then your wallet wouldn't be accessible either

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

[Vladimir Gomonov]

A100:
Then its wallet would not be accessed either

Once again: carefully distinguish between classes (types) and instances (variables). Own (this) proctored fields are freely accessible, also by inheritance (unlike private), others (other variables of the same class) must not be accessible. (should be inaccessible)

Zloy_Koldun:
.....

In the above example, class B knows about class A, so it won't mess anything up there.

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

Just because I know you have a wallet is not a reason to access it. To yours, please, only through get() and set() - if you allow it (public: int get(); int set();).

[A100]

MetaDriver:

protected does not restrict access at the object level, but at the class level, because it does not have object information at the time of compilation. I gave an example of a contradiction

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

object is the same

[Koldun Zloy]

MetaDriver:

Just because I know that you have a wallet, is no reason to access it. To yours - please. To yours - only through get() and set() - if you allow (public: int get(); int set();).

The wallet is just a special case. And no one is stopping it from being placed in the private part.

In another case, you may need to access the parent class variable of someone else's object.

And this is up to the programmer to decide whether to allow it or not. And the compiler must ensure that the program works correctly.

[Vladimir Gomonov]

A100:
I gave an example of a contradiction ... the object is the same

There is no contradiction. If you refer to yourself through an "external interface", be prepared to get hit in the face by yourself ;)

..........., because at the time of compilation it has no information about the objects.

[Vladimir Gomonov]

Zloy_Koldun:

1. The wallet is just a special case. And no one is stopping it from being placed in the private part.

2. In another case, you may need to access the parent class variable of someone else's object.

3 And this is up to the programmer to decide whether to allow it or not.

4. And it is up to the compiler to ensure that the program works correctly.

1. Putting it into the private part will not change anything in case of

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

It will inherit, that's evident.

2. There's very few things that will need to be done. grounds only in the case of access to a private copy.

3. so let him decide. correct. ;)

4. This is the whole question: what exactly counts as "correct work".