Why are there so few experts in the MQL5 database? - page 9
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
'MyStruct' - forward declaration is not supported
There you go. How do you get rid of cyclic dependencies in architecture?
Don't tell me that they can't exist in a normal architecture. The only (crutch) way is to redesign the architecture by adding a bunch of unnecessary base classes, which turns into a real pain in the ass because of the lack of multiple inheritance, which you rejected, as I understand, not to bother implementing lozenge-like dependencies.
But you could have just implemented the declaration...
Well, let's see whether "unbiased novice users" are able to write "something really fundamental" in MQL5, as opposed to "professional system programmers".
Where did I write that they can't, my dear? Yes, they can, but it will be something crude and heavy.
There you go. How do you get rid of cyclical dependencies in architecture?
We don't allow forward descriptions yet because of the security system in complex use cases.
We have a language with very tight controls at both build and runtime. We can't afford to get potentially leaky code because of relaxed controls. The point is that these descriptions could be in completely different libraries and there is no strict way to control usage in such cases yet. Roughly speaking, it would be possible (it can't be done now) to conduct an attack by tucking in a left-handed class with other methods.
There is already a solution to the problem of forward declarations of external and cyclic dependencies, but we will implement it after launching the 64-bit terminal (compiler, terminal, editor and tester). We've already prepared a public 32/64 bit build today - we'll release it this week.
Until you start to write a managed code compiler yourself, with direct emphasis on security for the terminal/execution environment (C#/Java has nothing to do with it, because they are not secure for the environment), it is difficult to understand the reasons of developers' actions.
Well, let's see if "unbiased novice users" can write "something really fundamental" in MQL5 in spite of "professional system programmers".
TheXpert:
Where did I write that they can't, my dear? Yes, they can, but it will be something crude and hard.
There you go. How do you get rid of cyclic dependencies in architecture?
Don't tell me that they can't exist in a normal architecture. The only (crutch) way is to redesign the architecture by adding a bunch of unnecessary base classes, which turns into a real pain in the ass because of the lack of multiple inheritance, which you rejected, as I understand, not to bother implementing lozenge-like dependencies.
But you could have just implemented the declaration...
Where did I write that they cannot, dear? Yes, they can, but it's going to be a messy, heavy thing.
With all due respect, let me say that, judging from forum 5, it is the experts who grumble and grumble the most. While ordinary amateurs howl and create... You're an expert, so live up to your level. Sorry, if anything.
That's because everything is relative,
Those who have never been behind the wheel of a right-hand drive Japanese can't understand how it is possible to shift the gearbox with the left hand.
And a beginner doesn't care, he doesn't know how to shift it, right or left.
That's because everything is relative,
Those who have never been behind the wheel of a right-hand drive Japanese can't understand how it's possible to shift the gearbox with the left hand.
and a beginner doesn't care, he can't shift it with his right hand or his left.
There you go, you've made a mess of everything. :)
Someone who's used to driving a foreign car with an automatic can't move in a shakha with a fucked-up gearbox. But the one who rode in "classic" will give head start to any pro in "Japanese", if he will drive in "Japanese". I'm just being philosophical, I'm in a good mood... Notice I didn't say "beginners", I said "amateurs".
There you go, you've ruined everything. :)
Anyone who's used to driving a foreign car with an automatic can't move in a shakha with a fucked-up gearbox. But he, who rides a "classical" car, will give a head start to any pro in a "Japanese" car, if he rides a "Japanese" car. I'm just being philosophical, I'm in a good mood... Notice I didn't say "beginners", I said "amateurs".
There is already a solution to the problem of forward declarations of external and cyclic dependencies, but we will implement it after the launch of the 64 bit terminal (compiler, terminal, editor and tester). We've already prepared a public 32/64 bit build today - we'll release it this week.
Until you start writing a managed code compiler yourself, with a direct emphasis on security for the terminal/execution environment (C#/Java has nothing to do with it, because it is not safe for the environment), it is difficult to understand the reasons for certain actions of developers.
Here's the solution to the object constructors - too. The reasons for making them useless are unclear.
They don't take parameters. Should we emulate parameters now, using global variables to do so?
There is no mechanism to report that an object was not created because an unrecoverable error occurred while creating (initializing) one of the subobjects. One can add an initializing function to all classes used in subobjects, and call initializing functions of subobjects from corresponding class function of object itself, which will provide possibility to return error code. But, firstly, one should call such function explicitly right after object's creation and after its "under" constructor is executed (as well as deinitialization function before destroying object by destructor), and, secondly, when modifying main class, for example, when adding some subobject, one could easily forget to include, and also in proper place, to provide proper sequence, call of initialization function of added subobject from main class initialization function (the same applies to deinitialization function). After all, practically no one writes a whole thing at once from scratch. As a result you get semi-handwritten and unsafe code.
And the release declared as such more than a month ago did not include such an important solution...
You're stirring up a lot of creepiness by mixing it up and making up problems that aren't even for you. If you are so scared of writing, then give it up.
You know what hinders a bad dancer.
With all due respect to you, let me note: it is the experts who grumble and grumble the most, judging by the 5th forum.
So, there's a lot to grumble about. Quite soon after the release of the first public beta I started to write a trading system. Almost immediately I missed normal constructors, and then I gave up at all, because it was impossible to get a pointer without explicitly creating it with the new operator. Even then I suggested the possibility of importing classes, as a logical addition in light of the increasing complexity of programs and their structure (header and library or object files -- in some only the required declarations, in others the implementation).
Import classes and forward declarations completely solve the code placement problem.
A copy constructor simplifies the problem of constructors.
The problem that caused me to stop is solved. There is now a GetPointer(this) construct. Everything else is (so far) solvable within the language, but it's ruining my life.
You're the expert, be appropriate to your level, bcos the knowledgeable look for opportunities and the ignorant look for reasons... Sorry, if anything.
So I go on writing. Talking here doesn't interfere with writing code. No need to apologize for that - I went too far.