Errors, bugs, questions - page 2358

 
Ilya Malev:

Although even if the object had no virtual methods, you should still check the validity of the pointer when accessing it.

Actually this is an ambiguous question. For example, this check is always present in C# and only if needed in C++, which gives an advantage in speed.

After all, if you call a method that doesn't access an object's fields, there's really no point in checking the pointer. In essence, such a method is equivalent to a static one.

 
Alexey Navoykov:

In general, this is an ambiguous issue. For example, C# always has such a check, while C++ only has it when needed, which gives a speed advantage.

Because if you're calling a method with no reference to the object's fields, there's really no point in checking the pointer. In fact, such a method is equivalent to a static one.

An object may have no data at all, but it can implement absolutely different and critically important behavior, e.g. refer to some external data in a special type-dependent way, or perform a special action at all. I'm not sure how to justify such approach as "method equivalence to static (i.e. 100% not virtual) method in absence of data".

That is, at least a pointer object always has one field - it's its type. By which you can determine the addresses of methods being called. Otherwise why do you need OOP at all?

P.S. Although for automatic objects I personally have nothing against any logic of behavior (as I almost don't use them), but then don't let them be assigned to pointers
 

Unfortunately, I have misled everyone, for constructions

B *b=a;
B b=a;

the copy operator is called instead of the copy constructor.
In the second case, after the B() constructor is called

In any case, we'll analyze first, then correct.

 

Oh, it turns out µl has an autogenerated copy constructor (I thought it didn't exist at all, since you can't class obj(other_obj), only with =). But why isn't it generated if:

class Q
{
public:
   Q(Q&)=default;  // нельзя
   Q(int) {}       // из-за него копирующий конструктор исчез
};
 
pavlick_:

Oh, it turns out µl has an autogenerated copy constructor (I thought it didn't exist at all, since you can't class obj(other_obj), only with =). But why isn't it generated if:

default and delete are not supported.

The default copy constructor, it turns out, has been done so far.

Only copy operator, i.e. for constructs:

CFoo foo=another_foo;

Default CFoo constructor is called first, and then the copy operator

 
Ilyas:

the copy operator is called, not the copy constructor.

But this is still a mistake, because the implicit copy operator should only be created for class B, not for all parent classes. i.e. the object should not be allowed to partially replace its internals.
 
Ilyas:

default and delete are not supported

That's right, but you only need to override the copy constructor generation when there's a custom copy constructor, don't you? Not any custom one.

 
Alexey Navoykov:
I.e. the object should not be allowed to partially replace its insides.

This is some kind of artificial self-limitation... I would even say narrow-mindedness.

class A {};
class B : public A {
public:
        void operator =( const A& ) {}
};

What is the problem?

I've found such a design in myself... and it works... fine. So I suggest the Developers leave it as it is... at least if the corresponding operators/constructors are explicitly defined

 
A100:

This is some kind of artificial self-limitation... I would even say narrow-mindedness.

What's the problem?

Found such a construct in my place... and everything works... fine. So I suggest the Developers leave it as it is... at least if the relevant operators are explicitly defined

Check for starters how things work in C++. Apparently its rules were invented by "narrow-minded" people.

And to turn into a plug each time in order to protect oneself from wrong architecture of the language... No, you have to do it right from the beginning. I mean, the language

 
Alexey Navoykov:

Check first how things work in C++. Apparently its rules were invented by "narrow-minded" people.

But to make plugs in every time to protect yourself from a wrong language architecture... No, you have to do it right from the start. I mean the language.

Re-checked it especially for you taking into account https://www.mql5.com/ru/forum/1111/page2358#comment_10003995

#ifdef __cplusplus
#include "https://www.mql5.com/ru/forum/1111/page2358#comment_10003995"
void OnStart()
{
        A a;
        B b;
        b = a;
}
#endif

It's OK DJ

Ошибки, баги, вопросы
Ошибки, баги, вопросы
  • 2018.12.24
  • www.mql5.com
Общее обсуждение: Ошибки, баги, вопросы
Reason: