In MQL5 there is always room for an exploit ! ;) - page 8

[Alexander Gandzyuk]

you're muddling water in a pail.
Pointers to variables, to functions, taking address by reference are all MQL restrictions.
It's not even something that is not provided for by the syntax, it's a ban on memory handling.
Even the void* pointer is not a pointer in the usual C-like sense.
It's an object to work with class objects to prevent them from being copied.
The same reference & is not an address taking, but a specifier for the compiler to pass an object without copying it into the stack.
You want to write in Syakh, write in Syakh and import dll, that's fine.

If you are really itching to get the hang of it and you can't foregn dll, then importing from native dll is not a big sin, and your MQL product will not lose value from this.

Not to make a fuss, for example, you can use just a 4-byte pointer and import memcpy to work with memory inside a terminal process.

#import "msvcrt.dll"

int memcpy(short&,short&,int);

int memcpy(int&,int&,int);

int memcpy(double&,double&,int);

int memcpy(string& s,string& int);

#import

some kind of wrapper class:

struct TPtr

{

int addr;

TPtr():addr(0){}

TPtr(const TPtr& r):addr(r.addr){}

template<typename _T> TPtr operator =(_T& r) {

addr = memcpy(r,r,0);

return this;

}

};

and an example of usage:

string sval = "123";

short bval = 123;

int ival = 123;

double dval = 123;

TPtr p = sval;

int ptrs = p.addr;

p = bval;

int ptrb = p.addr;

p = ival;

int ptri = p.addr;

p = dval;

int ptrd = p.addr;

This way you can manipulate memory as you like... Not the usual C-pointers, but still

How may it be useful?
Well, for example, you can use GlobalAlloc import feature, so that you don't need to use global variables to transfer data between modules.
GlobalAlloc allocates memory to the process, which is not associated with a heap or internal static virtual for the work of an owl or an induced.
You can place arrays of any size in it and use memcpy for indexing.

Import example:

#define HANDLE int
#define LPVOID int

#import "kernel32.dll"

HANDLE GlobalAlloc(uint flags, uint cnt);

LPVOID GlobalLock(HANDLE hmem);

int GlobalUnlock(HANDLE hmem);

HANDLE GlobalFree(HANDLE hmem);

#import "ntdll.dll".

// GetLastError already exists in MT, so use from WinAPI:

int RtlGetLastWin32Error();

#import

An example of usage:

// owl N1, prepare your array of rates

MqlRates rates[123];
// here we fill
HANDLE memid = GlobalAlloc(GMEM_MOVEABLE, 123*sizeof(MqlRates));
LPVOID ptr=GlobalLock(memid);
memcpy(ptr,rates[0].time, 123*sizeof(MqlRates)); // here, in order to compile, one should prototype int memcpy(int&,const datetime&,int)
GlobalUnlock(memid);
// send a memory descriptor
EventChartCustom(CID, MY_SEND_DATA, memid, 0, "");

// owl N2
void OnChartEvent(const int id, const long &lparam, const double &dparam, const string &sparam)
{
if( id == CHARTEVENT_CUSTOM+MY_SEND_DATA )
{
LPVOID ptr = GlobalLock((HANDLE)lparam);
MqlRates rates[123];
// got rates
memcpy(rates[0].time,ptr,123*sizeof(MqlRates)); // here is the prototype int memcpy(datetime&,const int&,int)
GlobalUnlock(memid);
GlobalFree(memid);
}
}

That's all... no pipes, external files, import of leftover dlls.
I just rushed a small sample with big possibilities, but my mind knows no bounds.
Yes, regarding GlobalAlloc I still suggest to use GMEM_MOVEABLE, with lock and anloak of memory to get pointer for specific operation, give it back.
If you use fixed global memory, at N number of open descriptors fragmentation may occur...
it's whatever the OS kernel wants depending on the load.
Good luck, hackers )))

[---]

alexsis78:

Not to be vague, for example, you can use just a 4-byte pointer and import memcpy to work with memory inside the terminal process

you've got the wrong branch a bit.

[Alexey Volchanskiy]

There is an old book by Henry Warren, "Algorithmic tricks for programmers", which is full of such tricks. However, most examples won't work in MQL because of lack of C++ pointers.

I'll try to find something fun.

[Alexander Gandzyuk]

You won't find the similarity of my example in C ))) First it's MQL, second it's a workaround for C pointer syntax.

A little more clarification for those who know plus.

In C:
int var = 0; // declare variable var
int* ptr = &var; // get pointer to variable var
int var2 = *ptr; // copy value by pointer to var into var2

In MQL:
#import "msvcrt.dll"
uint memcpy(int& destination, const int& source, int cnt); // prototype of memcpy to get the address of variable destination
uint memcpy(int& destination, uint ptr, int cnt); // the memcpy prototype to copy from the address ptr
// the compiler will substitute one of the two prototypes by type difference of the second argument
// let's take a pointer type, for example uint
#import

int var = 0;
uint ptr = memcpy(var,var,0); // get a pointer ptr to the variable var (here memcpy does not copy anything but returns the address var)
int var2
memcpy(var2, ptr, 4); // copy 4 bytes or sizeof(int) from pointer ptr to variable var2 (the second prototype of memcpy works)

I hope you will find the method useful )))

[---]

alexsis78:
You won't find the similarity of my example in C))) Firstly, it is MQL, secondly, bypassing of C pointers syntax.
I hope you will find it useful ))))

people, don't write for the sake of writing something.

All these variants with memcpy are chewed up several years ago and are not suitable for this topic.

[Alexey Volchanskiy]

o_O:

People, don't write for the sake of writing something.

All of these memcpy options were chewed up years ago and are not suitable for this topic.

I agree, moreover the variant without pointer arithmetic was described, i.e. defective. They are not really needed in C#, there are no pointers. There is unsafe but it is only for personal use and there will be a lot of restrictions like prohibition to install through network and so on.

[Vadim Konyaev]

I wanted to put it in the code base, but then I changed my mind:

Using MQL5 on Kaggle, Digit Recognizer Task

[Georgiy Merts]

o_O:

People, don't just write for the sake of writing something.

All these memcpy options have been chewed over for years and are not suitable for this topic.

Why is it "inappropriate"?

I've forgotten where it was and couldn't find it...

By the way, I would consider saving a pointer to an array without calling external DLLs a feat. I don't want to have to confirm every time I start indicators that I agree to import functions from the DLL.

[Alexey Volchanskiy]

George Merts:

Why is it "not suitable"?

I've already forgotten where it was and couldn't find it...

By the way, I would consider it a feat to save a pointer to an array without involving external DLLs. I don't want to have to confirm every time I start indicators that I agree to import functions from a DLL

Wrap the array in a class, you can make MQL pseudo-pointers to it with new

[Georgiy Merts]

Alexey Volchanskiy:
Wrap the array in a class and you can make MQL pseudo-pointers to it with new

Alexey, you should also tell me how to wrap arrays, issued by OnCalculate() function, into a class - in this case you can't do without copying pointers.

At the moment, I'm just copying data into my class-array, and then I'm pulling a pointer to this object. But that would get some extra copying, which, as I see, adds quite a noticeable "heaviness" with frequent ticks and large number of charts. I want to get rid of this copying. But, except for a crutch via DLL (standard or self-written), there is nothing I can suggest.

In Service Desk, they keep pushing me back saying "the object may be deleted". But these are their own arrays! When I say that I may create an object and then remove it and the pointer will become invalid - they reply that "it is I who will be responsible for this". This is a "double morality" at work here.

I don't care about the DLL - but such indicators require constant confirmation when running - what a bother...