Чтобы нельзя было создать больше определенного количества объектов данного класса?
Да, чтобы была единая точка доступа из всех частей программы к экземпляру класса с изменяемым состоянием. Вот прикольный сайт сегодня нашел про паттерны в картинках и псевдокодах: https://refactoring.guru/ru/design-patterns/singleton
Одиночка — это порождающий паттерн проектирования, который гарантирует, что у класса есть только один экземпляр, и предоставляет к нему глобальную точку доступа. Проблема Одиночка решает сразу две проблемы, нарушая принцип единственной ответственности класса. Гарантирует наличие единственного экземпляра класса. Чаще всего это полезно для...
Да, чтобы была единая точка доступа из всех частей программы к экземпляру класса с изменяемым состоянием. Вот прикольный сайт сегодня нашел про паттерны в картинках и псевдокодах: https://refactoring.guru/ru/design-patterns/singleton
Понял, спасибо. Такую конструкцию раньше использовал.
template <typename T>
struct PTR
{
T* Ptr;
PTR( void ) : Ptr(NULL)
{
}
PTR( T* ptr ) : Ptr(ptr)
{
}
~PTR( void )
{
if (this.Ptr)
deletethis.Ptr;
}
bool Set( T* ptr )
{
this.Ptr = ptr;
return(true);
}
voidoperator =( bool )
{
}
};
class CLASS
{
private:
#define THIS CLASS::sPtr.Ptr
static PTR<CLASS> sPtr;
CLASS( constbool x /* = false */ )
{
}
staticbool Set()
{
return(THIS ? false : CLASS::sPtr.Set(new CLASS(true)));
}
#undef THIS
};
// Создается скрытый объект CLASS со скрытым конструктором.// Ни создать CLASS-объект, ни обратиться к существующему нельзяstatic PTR<CLASS> CLASS::sPtr = CLASS::Set();
У кого-нибудь получилось подружить 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.
Насколько я знаю, ключ {1,0,0,0} убирает все обрамление и оставляет только сжатый пакет. По крайней мере слово "Hello" представляется в сжатом виде одинаково на выходе CryptEncode и каким его делает deflate. Соответственно и в обратную сторону должно работать. Но MQL не дает более никаких настроек и не раскрывает используемые им "дифолтные" настройки deflate-а. Очевидно, что они отличаются, но в вебсокетах можно управлять только max_window_bits и no_context_takeover - во-первых их явно меньше, чем в алгоритме deflate (который настраивается на сервере), во-вторых, даже их нельзя настраивать в CryptEncode/Decode.
Ааа, вон он что, я так глубоко не копал, и думал что параметр ключ только для алгоритмов шифрования. Но чтоб ключ применялся к методу упаковки как то и не думал, это наверно уже низкоуровневые фишки, требующие сакральных знаний. Логично, что напрашивается добавление разработчиками стандартной константы для работы с gzip.
Остаётся как есть - этот код может получиться в результате специализации шаблона (в части, которая работать не будет, но на компиляцию повлияет).
Runtime Error: Incorrect casting of pointers. Expected result: Compilation ErrorRuntime Error: Incorrect casting of pointers. Expected result: Compilation Error
Из ваших объяснений мало что понятно. Не могли бы пояснить поподробней? Человек указывал на проблему: неявный динамик-каст указателя от базового класса к производному. Такое поведение противоречит как C++, так и другим известным языкам со статической типизацией, будь то C# или Java. Данный кастинг должен проводиться только явно, т.к. он опасен. А при чём здесь шаблоны - не очень ясно.
Чтобы нельзя было создать больше определенного количества объектов данного класса?
Да, чтобы была единая точка доступа из всех частей программы к экземпляру класса с изменяемым состоянием.
Вот прикольный сайт сегодня нашел про паттерны в картинках и псевдокодах: 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.
Насколько я знаю, ключ {1,0,0,0} убирает все обрамление и оставляет только сжатый пакет. По крайней мере слово "Hello" представляется в сжатом виде одинаково на выходе CryptEncode и каким его делает deflate. Соответственно и в обратную сторону должно работать. Но MQL не дает более никаких настроек и не раскрывает используемые им "дифолтные" настройки deflate-а. Очевидно, что они отличаются, но в вебсокетах можно управлять только max_window_bits и no_context_takeover - во-первых их явно меньше, чем в алгоритме deflate (который настраивается на сервере), во-вторых, даже их нельзя настраивать в CryptEncode/Decode.
Ааа, вон он что, я так глубоко не копал, и думал что параметр ключ только для алгоритмов шифрования.
Но чтоб ключ применялся к методу упаковки как то и не думал, это наверно уже низкоуровневые фишки, требующие сакральных знаний.
Логично, что напрашивается добавление разработчиками стандартной константы для работы с gzip.
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Ошибки, баги, вопросы
Ilyas, 2020.04.16 11:31
...
Остаётся как есть - этот код может получиться в результате специализации шаблона (в части, которая работать не будет, но на компиляцию повлияет).
Из ваших объяснений мало что понятно. Не могли бы пояснить поподробней? Человек указывал на проблему: неявный динамик-каст указателя от базового класса к производному. Такое поведение противоречит как C++, так и другим известным языкам со статической типизацией, будь то C# или Java. Данный кастинг должен проводиться только явно, т.к. он опасен. А при чём здесь шаблоны - не очень ясно.
Почему сайт "криво" отображается в Опере?