Ошибки, баги, вопросы - страница 2709
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Почему в MQL нельзя вызывать защищенный конструктор из своего метода-фабрики?
Проблема в значении по умолчанию, если его убрать, то все работает как надо:
Почему в MQL нельзя вызывать защищенный конструктор из своего метода-фабрики?
Не догадался, где такое может быть полезно.
Не догадался, где такое может быть полезно.
Классическая реализация паттерна Singleton.
Классическая реализация паттерна Singleton.
Чтобы нельзя было создать больше определенного количества объектов данного класса?
Чтобы нельзя было создать больше определенного количества объектов данного класса?
Да, чтобы была единая точка доступа из всех частей программы к экземпляру класса с изменяемым состоянием.
Вот прикольный сайт сегодня нашел про паттерны в картинках и псевдокодах: https://refactoring.guru/ru/design-patterns/singleton
Да, чтобы была единая точка доступа из всех частей программы к экземпляру класса с изменяемым состоянием.
Вот прикольный сайт сегодня нашел про паттерны в картинках и псевдокодах: https://refactoring.guru/ru/design-patterns/singleton
Понял, спасибо. Такую конструкцию раньше использовал.
Проблема в значении по умолчанию, если его убрать, то все работает как надо:
Но ведь в C++ работает и со значением по умолчанию. И как оно влияет?
У кого-нибудь получилось подружить MQL-евский CryptEncode(CRYPT_ARCH_ZIP, data[], key[] = {1,0,0,0}, result[]) со сжатием deflate из вебсокетов? Публичный эхо-сервер (echo.websocket.org) вроде не поддерживает данное расширение, другого эхо-сервера я не нашел, а локальный node.js дает ошибку "zlib invalid distance too far back" при попытке расшифровать сжатые данные. В заголовке ставлю по максимуму server_max_window_bits=15; client_max_window_bits=15, но дело похоже не в этом, т.к. сервер эти настройки подтверждает. А со стороны MQL ничего кроме ключа {1,0,0,0} и настраивать-то нельзя ;-(.
У кого-нибудь получилось подружить MQL-евский CryptEncode(CRYPT_ARCH_ZIP, data[], key[] = {1,0,0,0}, result[]) со сжатием deflate из вебсокетов? Публичный эхо-сервер (echo.websocket.org) вроде не поддерживает данное расширение, другого эхо-сервера я не нашел, а локальный node.js дает ошибку "zlib invalid distance too far back" при попытке расшифровать сжатые данные. В заголовке ставлю по максимуму server_max_window_bits=15; client_max_window_bits=15, но дело похоже не в этом, т.к. сервер эти настройки подтверждает. А со стороны MQL ничего кроме ключа {1,0,0,0} и настраивать-то нельзя ;-(.
Если я правильно понял вопрос, то в вебсокетах для упаковки данных, в основном используют GZIP сжатие.
Константа CRYPT_ARCH_ZIP скорее всего пакует в обычный ZIP.
Если знаете как запаковать/распаковать GZIP, средствами mql5, то тоже интересуюсь.
Если я правильно понял вопрос, то в вебсокетах для упаковки данных, в основном используют GZIP сжатие.
Константа CRYPT_ARCH_ZIP скорее всего пакует в обычный ZIP.
Если знаете как запаковать/распаковать GZIP, средствами mql5, то тоже интересуюсь.
Насколько я знаю, ключ {1,0,0,0} убирает все обрамление и оставляет только сжатый пакет. По крайней мере слово "Hello" представляется в сжатом виде одинаково на выходе CryptEncode и каким его делает deflate. Соответственно и в обратную сторону должно работать. Но MQL не дает более никаких настроек и не раскрывает используемые им "дифолтные" настройки deflate-а. Очевидно, что они отличаются, но в вебсокетах можно управлять только max_window_bits и no_context_takeover - во-первых их явно меньше, чем в алгоритме deflate (который настраивается на сервере), во-вторых, даже их нельзя настраивать в CryptEncode/Decode.