Почему так мало экспертов в базе MQL5? - страница 9
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
'MyStruct' - forward declaration is not supported
Воот. Как избавляться от циклических зависимостей в архитектуре?
Только не говорите, что в нормальной архитектуре их быть не может. Единственный (костыльный) способ -- перепроектирование с добавлением кучи ненужных базовых классов, которое превращается в тот еще геморрой из-за отсутствия множественного наследования, от которого вы я так понимаю отказались, дабы не мучаться с реализацией ромбовидных зависимостей.
А ведь можно было просто реализовать объявление...
Ну что ж, посмотрим, смогут ли "непредвзятые начинающие пользователи" написать на MQL5 "что-нибудь действительно фундаментальное" в пику "профессиональным системным программистам".
А где я написал, что не смогут, уважаемый? Смогут, но это будет корявое тяжелое нечто.
Воот. Как избавляться от циклических зависимостей в архитектуре?
Форвардные описания нами пока не разрешены из-за системы безопасности в сложных случаях использования.
У нас язык с очень жестким контролем как на этапе сборки, так и исполнения. Мы не можем позволить себе получить потенциально дырявый код из-за ослабления контроля. Дело в том, что эти описания могут быть совершенно в других библиотеках и пока нет жесткого способа контроля использования в таких случаях. Грубо говоря, можно было бы (сейчас такое сделать нельзя) провести атаку с подсовыванием левого класса с другими методами.
Решение проблемы форвардных деклараций внешних и циклических зависимостей уже есть, но мы ее реализуем после запуска 64 битного терминала (компилятора, терминала, редактора и тестера). Сегодня уже приготовили публичный 32/64 битный билд - выпустим на этой неделе.
Пока сам не начнешь писать компилятор managed кода с прямым упором на безопасность для терминала/среды исполнения (C#/Java к этому никакого отношения не имеют, ибо не безопасны для среды), сложно понять причины тех или иных действий разработчиков.
Ну что ж, посмотрим, смогут ли "непредвзятые начинающие пользователи" написать на MQL5 "что-нибудь действительно фундаментальное" в пику "профессиональным системным программистам".
TheXpert:
А где я написал, что не смогут, уважаемый? Смогут, но это будет корявое тяжелое нечто.
Воот. Как избавляться от циклических зависимостей в архитектуре?
Только не говорите, что в нормальной архитектуре их быть не может. Единственный (костыльный) способ -- перепроектирование с добавлением кучи ненужных базовых классов, которое превращается в тот еще геморрой из-за отсутствия множественного наследования, от которого вы я так понимаю отказались, дабы не мучаться с реализацией ромбовидных зависимостей.
А ведь можно было просто реализовать объявление...
А где я написал, что не смогут, уважаемый? Смогут, но это будет корявое тяжелое нечто.
При всем моем уважении к Вам, позволю себе заметить: больше всего, судя по 5-му форуму ропщут и роптают именно эксперты. А простые любители вояют и творят... Вы же эксперт, соответствуйте своему уровню. Сори, если что.
А это потому что всё относительно,
те кто никогда не сидел за рулём японца с правым рулём не может понять как это можно коробку левой рукой переключать.
А новичку без разницы он всё равно не умеет её переключать ни правой ни левой.
А это потому что всё относительно,
те кто никогда не сидел за рулём японца с правым рулём не может понять как это можно коробку левой рукой переключать.
А новичку без разницы он всё равно не умеет её переключать ни правой ни левой.
Ну вот, взял, и всё опошлил. :)
Тот, кто привык ездить на иномарках с автоматом, хрен с места сдвинется на шахе с раздолбаной коробкой. Зато тот, кто ездил на "классике", даст фору любому профи на "японце", если сядет на "японца". Ну это я так, философствую чуток, настроение подходящее... Заметь, я сказал не "новички", а "любители".
Ну вот, взял, и всё опошлил. :)
Тот, кто привык ездить на иномарках с автоматом, хрен с места сдвинется на шахе с раздолбаной коробкой. Зато тот, кто ездил на "классике", даст фору любому профи на "японце", если сядет на "японца". Ну это я так, философствую чуток, настроение подходящее... Заметь, я сказал не "новички", а "любители".
Решение проблемы форвардных деклараций внешних и циклических зависимостей уже есть, но мы ее реализуем после запуска 64 битного терминала (компилятора, терминала, редактора и тестера). Сегодня уже приготовили публичный 32/64 битный билд - выпустим на этой неделе.
Пока сам не начнешь писать компилятор managed кода с прямым упором на безопасность для терминала/среды исполнения (C#/Java к этому никакого отношения не имеют, ибо не безопасны для среды), сложно понять причины тех или иных действий разработчиков.
Вот и с решением по поводу конструкторов объектов - тоже. Причины, по которым они сделаны бесполезными, непонятны.
Параметров не принимают. Эмулировать параметры теперь, что ли, используя для этого глoбальные пeременные?
Отсутствует механизм, позволяющий сообщить о том, что объект не создан из-за того, что при создании (инициализации) одного из подобъектов возникла неустранимая ошибка. Можно добавить инициализирующую функцию во все классы, используемые в подобъектах, а из соответствующей функции класса самого объекта вызывать инициализирующие функции подобъектов, что обеспечит возможность вернуть кoд oшибки. Но, во-первых, вызывать такую функцию надо явно сразу после сoздания oбъекта и отработки его "недо"конструктора (как и функцию деинициализации до уничтoжения oбъекта деструктором), а, во-вторых, при модификации основного класса, например, при добавлении какого-то подобъекта, легко забыть включить, да ещё и в правильном месте, чтобы обеспечить правильную последовательность, вызoв фyнкции инициализации добавляемого подобъекта из функции инициализации основного класса (то же относится и к функции деинициализации). Ведь практически никто не пишет сразу начистовую. В результате получается полуручной и небезопасный код.
И в релиз, продекларированный таковым более месяца назад, такое важное решение не попало...
Нагнетаете жути, намешивая и придумывая даже не для себя проблемы. Если Вам так страшно писать, то бросайте это дело.
Плохому танцору сами знаете что мешает.
При всем моем уважении к Вам, позволю себе заметить: больше всего, судя по 5-му форуму ропщут и роптают именно эксперты.
Так это, есть чего. Довольно быстро после выпуска первой публичной беты начал писать торговую систему. Почти сразу соскучился по нормальным конструкторам, а потом вообще забил, из-за того, что нельзя было получить указатель без явного создания его оператором new. Еще тогда предложил возможность импорта классов, как логичное дополнение в свете усложнения программ и их структуры (заголовочные и библиотечные или объектные файлы -- в одних только нужные объявления, в других реализация).
Импорт классов и форвардные объявления полностью решают проблему размещения кода.
Копирующий конструктор упрощает решение проблемы конструкторов.
Проблема, из-за которой я остановился, решена. Теперь есть конструкция GetPointer(this). Остальное все (пока) решаемо в рамках языка , но жизнь все-таки портит.
Вы же эксперт, соответствуйте своему уровню, бекоз знающие ищут возможности, а незнающие ищут причины... Сори, если что.
Дык продолжаю писать. Общение здесь написанию кода не мешает. Извиняться не за что -- я немного перегнул палку.