Errors, bugs, questions - page 1056

New comment
 

I can find a justification for the current situation myself: strict separation of "ownership" between instances of the same class could lead to cluttered syntax when describing all sorts of binary operations (even at the same hierarchy level). However, with inheritance, "direct access" should certainly be trimmed.

Because there's no point in doing so... ;)

 
MetaDriver:

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

In the case of inheritance it will, that's clear.

2. Few things will be needed... Grounds are only available in the case of access to one's own copy.

3. so let it decide. correct. ;)

4. That's the whole question: what exactly counts as "correct operation".

1. If you really want to hide your wallet, why do you do gch() ?

2. And when copying instances, are there any?

 
Zloy_Koldun:

1. If you really want to hide your wallet, why do you do the gh() function ?

2. And when copying instances are available?

Read my previous post. All the answers are there.

Once upon a time, it was a "political decision" to consider other objects (instances) of your own class as friends by "default" - purely to save bukaf. And now you take this exception as a norm of life and want to climb into private pockets of all distant relatives unhindered.

Huh...

 
MetaDriver:

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

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

In the case of inheritance it will, that's clear.

2. Few things will be needed... grounds only in the case of access to one's own copy.

3. so let it be decided. correct. ;)

4. That's the whole question: what exactly is to be considered "correct work".

Yes it works, but it shouldn't. By the way, when autocomplete in ME (when writing a ch) you are not given the "wallet" variable because it is in private, so this feature probably went unnoticed for so long.
  
class Человек
{
private:
   int кошелёк; 
public:
   void Человек() {  кошелёк=3; }
   void gч( Человек& ч )  
   { 
    ч.кошелёк--;   // Работает и должно работать!
   }
   void gcч( const Человек& ч )  
   { 
    ч.кошелёк--;   // Не работает, как и должно.
   }
};
 
Zloy_Koldun:

Ok. So tell me. How to define such a field in a class, that it can be modified only and exclusively by methods of "master" instance and no one else.

If it's impossible, then the subject of encapsulation tits isn't covered in the language, is it?

 
MetaDriver:

Ok. So tell me. How to define such a field in a class, that it can be modified only and exclusively by methods of "master" instance and no one else.

If it's impossible, then the subject of encapsulation tits probably hasn't been covered in the language, no?

It is impossible. And it doesn't need to be. If you disagree, give a sensible example.
 
What does this error mean, the pending order has not been triggered: " HistoryBase: 114 errors in 'GBPUSD60'
 
MetaDriver:
class Человек
{
private:
   int кошелёк; 
public:
   void Человек() {  кошелёк=3; }
   void gч( Человек& ч )  
   { 
    ч.кошелёк--;   // сейчас работает.  а не должно ;)
   }
};
This feature was unpleasantly surprising. It's definitely bullshit if the compiler allows to change the private field of someone else's instance. It should be posted to servicedesk.
 
C-4:
This feature is unpleasantly surprising. It's obviously bullshit if your compiler allows you to change the private field of somebody else's instance. We should post it to servicedesk.

I don't understand: why do you want to limit yourself so much?

Do you think it will automatically make your programme safer?

It won't! On the contrary.

It is unnecessary restrictions that will make you write it that way someday:

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