MetaTrader 4 Build 574 with Updated MQL4 Language and Market of Applications Released - page 23

[gchrmt4]

ubzen:

I wonder if anyone who visits know how C++ handles it........

See above for C and C++.

What's even odder is this:

   uint ExampleTickCount = 0xE63E21EB;
   int test_int = ExampleTickCount;
   test_int++; // Affects the subsequent cast
   long test_long = (long)test_int;
   MessageBox("int: " + test_int + "\r\nlong: " + test_long);

If you do any manipulation of the int, such as test_int++, then it ceases to have the "memory" of the uint.

I think it's almost certain that the difference is an unintentional artifact of the compiler's optimization. If you do a cast, and then another cast of the unmodified value, then the compiler in effect optimizes to doing a cast from the original value. IMHO that's a very, very obscure and very, very unimportant bug.

[Ian Venner]

ubzen:
Yes.

ok good, all I wanted to do is get the last digit of GetTickCount() lol ... you'll see why when I submit my entry for your competition ubzen ;) I wrote it for 509 but I was testing it on 577 to see if it worked but that value kept comming out negative on 577 and messing up my calculations.

[Ubzen]

gchrmt4:

See above for C and C++.

What's even odder is this:

If you do any manipulation of the int, such as test_int++, then it ceases to have the "memory" of the uint.

I think it's almost certain that the difference is an unintentional artifact of the compiler's optimization. If you do a cast, and then another cast of the unmodified value, then the compiler in effect optimizes to doing a cast from the original value. IMHO that's a very, very obscure and very, very unimportant bug.

Thats nice to know ... Thank you.

[Ubzen]

SDC: ok good, all I wanted to do is get the last digit of GetTickCount() lol ... you'll see why when I submit my entry for your competition ubzen ;) I wrote it for 509 but I was testing it on 577 to see if it worked.

Cool .

[Sunaley]

gchrmt4:

https://www.mql5.com/en/forum/148851/page15#898140 may mean that this will be changed back before launch so that old EAs use the old RateInfo structure.

If not, or if you want to recompile your EAs with the new version of MT4, then you need to change your DLL (or add a second version of each function0.

Thanks a lot.

I used to link DLLs with VC++ 2008.

Notice that the length of long type in VC++ is 4 byte but in Mql+ is 8 byte.

So I modify the declaration of struct RateInfo in CPP like below:

struct RateInfo
{
    long long   ctm;  
    double      open; 
    double      high; 
    double      low;  
    double      close;
    long long   tick_vol;
    int         spread;  
    long long   real_vol;
};

Now the DLLs receive the correct OHLC so that old EAs can work well.

[Ex Ovo Omnia]

Ovo:

If any one is still interested with weird behaviour... this time it is about indicators.

• I am still having issues with the 509 ex4 indicators in compatibility mode. They start correctly when attached, but end up with expert stopped error after changing timeframe or input parameters. Then they cannot recover until detached. Edit: according to trace information in logs it looks like it crashes on a first ex4-library call.

Seems fixed in 578.

[[Deleted]]

Did anyone else notice the excessive memory usage of the "new" MT4? I am running the exact same optimization as with build 509 and the memory build 509 takes is maxing out at 329mb per instance. With build 577 it´s going up all the time, now at 1300mb for the same type of opti and raising further. Seems like a heavy leak of memory somewhere with it :( Whenever I run the "cleanmem" program (google for it), it pushes the new MT4 instances down again to 400mb, which shows that the overhead of memory it creates is not really needed but must be a leak somewhere. After cleanmem finished it starts to go up to 1300mb+ again within a few minutes.... only solution to not totally overload the memory is to run cleanmem all few minutes :(

[gchrmt4]

gchrmt4
Ticket #937128. I also very strongly suggest that #933683 and #927090 are fixed. It is now a long time since I have had any response from the Service Desk to any of my open tickets.

alexvd:

All tickets in work.

#937128 seems to be fixed in build 578.

#933683 and #927090 are not fixed.

[onewithzachy]

gchrmt4:

#937128 seems to be fixed in build 578.

#933683 and #927090 are not fixed.

And we are here also have no idea what are those either.

Mind sharing what are those ?

[gchrmt4]

onewithzachy:

And we are here also have no idea what are those either.

See above. They were discussed on page 15 onwards.

#933683 is a recommendation that old EAs continue to use experts\files in FileOpen(), instead of MQL4\Files. #927090 is a recommendation that old EAs continue to use the old RateInfo structure when passing price data to DLLs.

Both will cause major transition problems for thousands of users with old EAs if not implemented. Both are no different in principle to old EAs continuing to use Ansi strings in DLL calls. If preserving backward compatibility by keeping Ansi strings, why not keep other aspects of backward compatibility by continuing to use the same file locations and data structures?