Errors, bugs, questions - page 2271

New comment
 
A100:
A compilation error:

What is the fundamental difference between (1)(2) and (3)(4)?

If you declare classes (3)(4) outside of functions - no error occurs. If you declare inside a function, errors occur.

 
Vladimir Pastushak:

What can the following behavior be related to

compile indicator works correctly, compile again indicator does not work correctly. Does it work correctly in the tester?

Which indicator?

 
fxsaber:

What does C++ produce here?

To make it work in MQL5, you need to have two different strings in the output, not the same one. But then the mechanism of signature forming should be absolutely different. If C++ gives the same result in print, the __FUNCSIG__ cost will drop dramatically.

Result: C++

void f<g1::A>( g1::A& )
void f<g2::A>( g2::A& )

As you can see the strings are different... the function signature is used

 
A100:

Result: C++

void f<g1::A>( g1::A& )
void f<g2::A>( g2::A& )

As you can see the strings are different... the function signature is used

MQL5 gives out.

void f<A>(A&)

I.e. there is no class signature inside the function. It will be supported someday.


And if the class is global, which line will C++ generate?

void f<::A>( ::A& )

void f<A>( A& )

 
fxsaber:

MQL5 gives out

I.e. there is no class signature inside the function. It will be supported someday.

If obsolete C++ compilers do not support it, they already give an error on the first line (1) in the source code. That's why the question was posed in this way in the first place: why is there an error in one case and a normal error in the other?

We expected the same behavior in both cases: either an error or no error. And the error is not in the lack of support per se, but in the unequal behaviour under otherwise equal conditions (as in this example)

 
fxsaber:
And if the class is global, which line does C++ produce?

void f<::A>( ::A& )

void f<A>( A& )

The second variant

 
A100:

If obsolete C++ compilers do not support this, they already give an error on the first line (1) in the source code. That's why the question was posed in this way in the first place: why is there an error in one case and a normal error in another?

We expected the same behavior in both cases: either an error or no error. And the error is not in the lack of support per se, but in unequal behavior, all else being equal (as in this example)

Well, it's easy to explain. The compiler goes from top to bottom through the code forming corresponding signatures as it goes along. The first signature is created without any problems. It comes to the second one and there is already such a signature. Here we have an error on the second line.

 
Georgiy Merts:

If you declare classes (3)(4) outside functions, no errors occur. If you declare inside a function - errors occur.

If in the initial example
        class  A2 { int i; }; //(3)

replace by

        interface  A2 {};      //(5)

If you declare inside a function, no errors occur either... what is the fundamental difference?

 
fxsaber:

So it's understandable. The compiler goes from top to bottom of the code, forming appropriate signatures as it goes along. It creates the first signature without any problems. It gets to the second one and it already has one. Thus, there is an error on the second line.

So why does it compile in MQL without errors?

template<typename T>
void f() { Print(__FUNCSIG__); }
void g1() { class A { int    x; } a; f<A>(); }
void g2() { class A { double x; } a; f<A>(); }
void OnStart()
{
        g1();
        g2();
}

Result: MQL C++

void f<A>() void f<g1::A>()
void f<A>() void f<g2::A>()

Why are the signatures created here without any interference?

 
A100:

So why does it compile in MQL without errors?

Result: MQL C++

void f<A>() void f<g1::A>()
void f<A>() void f<g2::A>()

Why are the signatures created here without any interference?

One is only created. Moreover, in f you cannot use T. Anyway, the situation is obvious to me.

1...226422652266226722682269227022712272227322742275227622772278...3191
New comment