Если у вас есть большая база индюков, сов и т. д - MQL4 и MetaTrader 4

[Удален] 2014.09.22 12:22 #101

По поводу скрытия имени переменной:

simpleton уже писал про intel компилятор, аналогичная ситуация у gcc и clang. При компиляции в весьма строгом режиме (в плане наличия сообщений):

gcc(clang) -Wall -Wextra

компилятор по данному вопросу не жалуется. Жалобы на скрытие активируются отдельной опцией -Wshadow. Т.е. сама проверка на c++ компиляторах (кроме MSVC) не является затруднительной. Но я не видел ни одной ide (на основе gcc,. Например, qt creator, code blocks ...), где -Wshadow была бы активирована по умолчанию.

Почему? Наверное потому, что для большинства полезность данного сообщения сомнительна.

Обновление платформы MetaTrader 4 Любые вопросы новичков по У меня глюк, или

Renat Fatkhullin 2014.09.22 12:29 #102

Pavlick:

По поводу скрытия имени переменной:

simpleton уже писал про intel компилятор, аналогичная ситуация у gcc и clang. При компиляции в весьма строгом режиме (в плане наличия сообщений):

По всей видимости, вы путаете вводящий в заблуждение "строгий режим компилятора" и реальную работу статических анализаторов, так как никогда ими не пользовались.

Компилер завершает компиляцию на 1-2 минуты, а анализаторы на том же коде будут работать и несколько часов (PVS Studio) и десятки часов (CPP Check). Отсюда столь разное качество и глубина результатов.

Новая версия платформы MetaTrader Можно ли доверять чужому Скорость оптимизации

Дмитрий 2014.09.22 15:45 #103

Приветствую всех.

Вот уже почти год проходит, как "чехорда" и маразм с нововведениями в MQL4 не прекращается. "А воз и ныне там!" (с).

Раньше ругали "Метаквотов" за слабый язык, сейчас за лишнюю "воду". Проблем меньше не стало.

От себя могу добавить следующее.

Трейдерам, не программистам и начинающим программистам простой алгоритм и код реализовать можно.

Если у Вас имеется большая база индюков, сов и т.д, которые не компилятся в новых билдах, значит имеет смысл присмотреться и "перетряхнуть свой сундук". Оставить полезное, и не пожалеть времени переписать и отладить под новые билды.

Настоящие матёрые программисты или те кто хочет ими стать, всегда следуют за нововведениями, баги и глюки их хлеб. Именно написание кода без ошибок считается хорошим программированием. Если нет сил, времени, возможности или желания вникать во все нововведения "Метаквотов", пользуйтесь тем языком, коим владеете в совершенстве. DLL не отменили, подключайте свои отлаженные алгоритмы.

Муки выбора Итак, наконец. Мы не Покупателям и заказчикам Советников

[Удален] 2014.09.22 19:38 #104

Andrei01:

Тестовые среды широко используются в программных продуктах для функциональной верификации програмных дезайнов чипов, где требования к качеству кода очень высокие. Более того, функциональная оболочка это неотъемлемая часть разработки любого кода для проектирования чипов. При написании же обычных софтверных проектов многие программисты даже не имеют представления о подобных функциональных тестах, это связано с тем что написание подобных тестов с нуля может занять больше времени чем написание непосредственно когда проекта и оправдано лишь когда есть требование написания высококачественного кода либо планируется много версий одного и того же проекта. С другой стороны грамотно написанная тестовая среда значительно экономит время отладки и проверки кода.

Статический анализ тоже используется, но лишь как очень поверхностая и первичная проверка синтаксиса.

Тестовые среды - это тестовые среды. Тестовая среда "заточена" под продукт, который она тестирует.

Я же имел ввиду инструменты общего плана, - те, что "не имеют представления" об анализируемом продукте и поэтому могут анализировать и находить проблемы в любом продукте.

Безиндикаторная торговля. От теории к практике Регрессионная модель Султонова (РМС)

[Удален] 2014.09.22 20:30 #105

Renat:

Simpleton, какой бред.

"Какой бред" - это, видимо, означает полное несовпадение позиций.

Renat:

Когда подниметесь на уровень тотального контроля качества, только тогда это поймете. А пока остаетесь на уровне восприятия отдельного самолюбивого программиста, будете и дальше придумывать "разумно меня не контролировать, пусть контроль будет отдельными никогда не запускаемыми утилитами".

Почему же "тотальный контроль качества" допускает такой невысокий его уровень?

Например:

#property strict

/******************************************************************************/
class A {
private:
  A() { Print("A::A()"); }

public:
  static void method1() {
    //A a; // 'A::A' - cannot call private member function      3.mq4   10      7
  }

  static void method2() {
    A *a = new A; // А здесь private member function великолепно вызывается
    delete a;
  }
};

/******************************************************************************/
void OnStart() {
  A::method1();
  A::method2();
}

Конструктор вызывается при создании объекта в method2:

00:50:23 Script 3 EURUSDm,M5: loaded successfully
00:50:23 3 EURUSDm,M5: initialized
00:50:23 3 EURUSDm,M5: A::A()
00:50:23 3 EURUSDm,M5: uninit reason 0
00:50:23 Script 3 EURUSDm,M5: removed

Почему при динамическом создании объекта всё нормально, то есть, private-конструктор доступен из метода объекта, а при автоматическом - private-конструктор вдруг недоступен?

Я лично отказался от того, чтобы что-то чуть более сложное, чем простое, делать на MQL, потому что мне это очень сложно: вечно натыкаюсь на что-то неработающее.

А вот с компиляторами C/C++ у меня таких проблем нет.

Проблема же "разумно меня не контролировать, пусть контроль будет отдельными никогда не запускаемыми утилитами" напрямую связана с психологией. Здесь психологию требуется корректировать, чтобы программист мог себя заставить, а не технологию пытаться подстроить под психологию, чтобы эту психологию обойти.

Я не придумываю, отдельные утилиты на моих глазах успешно используются на регулярной основе, а результат их работы также с успехом используется затем для устранения ошибок.

Renat:

С глюками боремся, но параллельно мы многое добавляем и улучшаем.

Возможно, приоритеты смещены в сторону добавления и улучшения за счёт качества. Но тогда это уже не тотальный его контроль.

Renat:

В пятницу как раз будет релиз MT4 с явными улучшениями в скорости исполнения и тестирования.

А улучшения по части работоспособности языка, - в данном случае я имею ввиду доступность private-конструктора из методов объекта не только для случая создания динамического создания объекта, - в нём уже будут?

Renat:

В отличие от С++, MQL абсолютно не опасен (если нет выхода в dll) за счет отказа от сырых ссылок, да и вообще - это managed язык.

Хорошо, пусть "C++ - опасен и самоубийственен", а "MQL абсолютно не опасен".

Зачем было брать за основу для MQL язык, настолько далёкий по критерию безопасности от того, что хотелось бы получить, то есть, создавать "абсолютно не опасный" язык на основе именно "опасного и самоубийственного"?

Ошибки, баги, вопросы Создание собственного расширения MetaTrader Тестируем CGraphic - вопросы

pansa 2014.09.23 05:06 #106

Pavlick:

ok?

Привет,павлик!

ето снова я панса!

я тестовал Ваш код по вызову скрипта на разных МТ4

и обнаружились странные вещи!

Ваш код пркрасно работает на МТ4 буилд 670 от Пепперстоне

(Австралия) ,но не хочет работать на МТ4 буилд 670 Алпари!

на Алпари вызов user32.dll идет странно!

сперва вызываются 2 ДЛЛ(хотя в коде не предусмотено!)

затем вызывается user32.dll но его кидают в библиотеку!

а ведь из библиотеки тоже нужно вызывать!

такое впечатление что Алпари борется с вызовом

тоесть идет явное вмешательство в работу кода!

2 картинки прилагаю для сравнения.

желаю успеха!

панса

oo-bild zu gross!

MT4-Pepperstone-user32.dll

MT4-Alpari-KERNEL32.dll,GDI.dll,E:\metaQuotes\Terminal\F................OBO\MQL4\Libraries\user32.dll

Советник с DLL на Сложный технический вопрос по Странная проблема Access violation

Renat Fatkhullin 2014.09.23 07:09 #107

simpleton:

"Какой бред" - это, видимо, означает полное несовпадение позиций.

Это означает, что у кого-то заведомо больше опыта руководства выпуском множества софтверных продуктов на конкурирующий рынок.

Почему же "тотальный контроль качества" допускает такой невысокий его уровень?

Не надо переводить тему с обсуждения общих принципов контроля качества на конкретные недочеты конкретного решения. Такой метод недопустим, так как заведомо всегда можно найти любой огрех в любом продукте.

Например:

Конструктор вызывается при создании объекта в method2:

Почему при динамическом создании объекта всё нормально, то есть, private-конструктор доступен из метода объекта, а при автоматическом - private-конструктор вдруг недоступен?

Это посто последствия чрезмерной защиты "статический метод класса не имеет права лазать в содержимое класса". Хотя в данном случае нужно контроль доступа ослабить.

Я лично отказался от того, чтобы что-то чуть более сложное, чем простое, делать на MQL, потому что мне это очень сложно: вечно натыкаюсь на что-то неработающее.

Приведите рабочий пример, а не случай вида "я так специально все закрутил, позакрывал доступы, а потом стал аппелировать к пограничному поведению".

А вот с компиляторами C/C++ у меня таких проблем нет.

Там проблемы другого вида. Причем их заведомо больше на порядки, если принять во внимание то, что вы не пользуетесь статическими анализаторами.

Проблема же "разумно меня не контролировать, пусть контроль будет отдельными никогда не запускаемыми утилитами" напрямую связана с психологией. Здесь психологию требуется корректировать, чтобы программист мог себя заставить, а не технологию пытаться подстроить под психологию, чтобы эту психологию обойти.

Я не придумываю, отдельные утилиты на моих глазах успешно используются на регулярной основе, а результат их работы также с успехом используется затем для устранения ошибок.

Возможно, приоритеты смещены в сторону добавления и улучшения за счёт качества. Но тогда это уже не тотальный его контроль.

Это уже просто словесная игра. Ваша позиция уже была ранее четко очерчена "меня нельзя контролировать", так что да "на глазах кто-то, где-то использует, но надо мной никто с палкой не стоит и я не использую".

А улучшения по части работоспособности языка, - в данном случае я имею ввиду доступность private-конструктора из методов объекта не только для случая создания динамического создания объекта, - в нём уже будут?

А вам нравится в своих "простых" программах ставить заведомые подножки "спрячу конструктор в приват, создам статик метод, а потом буду из него долбиться в скрытый конструктор"?

Хорошо, пусть "C++ - опасен и самоубийственен", а "MQL абсолютно не опасен".

Зачем было брать за основу для MQL язык, настолько далёкий по критерию безопасности от того, что хотелось бы получить, то есть, создавать "абсолютно не опасный" язык на основе именно "опасного и самоубийственного"?

Вы в состоянии придумать "другую основу" для языков общего плана?

Так, чтобы иметь возможность каждому второму программисту дать язык и он через пару часов начнет на нем с удовольствием писать, а не вышвырнет с отвращением и руганью? Вот трейдеры посмотрели на Easy Language и выкинули, а MQL4/MQL5 с радостью используют и развивают.

Большинство широко распространенных языков базируются на базовых принципах построения конструкций как в C/C++. Так что мы взяли известную всем основу, убрали самые опасные вещи со ссылками, добавили DRM и получили защищенный и безопасный язык.

В результате мы на коне, а конкуренты ходят в неправильных, но более дешевых, как им кажется, направлениях.

Сервисдеск. Жалобы, предложения. Вопрос знатокам ООП. простая DLL все что

[Удален] 2014.09.23 20:04 #108

Renat:
Это означает, что у кого-то заведомо больше опыта руководства выпуском множества софтверных продуктов на конкурирующий рынок.

Кстати, по поводу опыта руководства. 5 лет назад мы спорили на форуме mql5 по поводу перспектив MT5, я тогда сказал, что время покажет. Прошло 5 лет, и мы видим, что сообщество отвергло MT5. Опыт руководства не гарантирует от ошибок. Даже если у человека есть опыт в какой-то области, он все равно может ошибаться. По поводу конкурирующего рынка, а, точнее, конкурентов, - в самом конце.

Однако, в данном случае речь идёт не об опыте выпуска множества программных продуктов, а о качестве продукта и, в частности, компилятора и инструментах и способах достижения высокого качества.

Renat:
Не надо переводить тему с обсуждения общих принципов контроля качества на конкретные недочеты конкретного решения. Такой метод недопустим, так как заведомо всегда можно найти любой огрех в любом продукте.

Это посто последствия чрезмерной защиты "статический метод класса не имеет права лазать в содержимое класса". Хотя в данном случае нужно контроль доступа ослабить.

Я не перевожу, общие принципы, теория, - не для самой теории, а для применения на практике. Вы не найдёте таких серьёзных "огрехов" в тех же компиляторах C/C++.

Если вы говорите, что в данном случае "статический метод класса не имеет права лазать в содержимое класса", то почему при динамическом создании объекта он это право уже имеет?

А как быть с тем, что точно так же себя ведёт и нестатический?

#property strict

/******************************************************************************/
class A {
private:
  A() { Print("A::A()"); }
  ~A() { Print("A::~A()"); }

public:
  void method() { // Метод - обычный, никакой не статический
    A a;
  }

};

/******************************************************************************/
void OnStart() {
}

Те же самые ошибки:

'3.mq4' 3.mq4   1       1
'A::~A' - cannot call private member function   3.mq4   11      7
'A::A' - cannot call private member function    3.mq4   11      7
2 error(s), 0 warning(s)                3       1

Хорошо, рассмотрим запрет на "лазать в содержимое класса":

#property strict

/******************************************************************************/
class A {
private:
  A() { Print("A::A()"); }
  ~A() { Print("A::~A()"); }
  A(const A &a) { Print("A::A(const A &)"); }
  void operator =(const A &a) { Print("A::operator =()"); }
  void f() { Print("A::f()"); }

public:
  static void assign(A &l, const A &r) {
    l = r;
  }

  static void method() {
    A *p = new A, b(p);

    b = p;
    b.f();
    delete p;
  }

};

Объект b создаётся путём обращения к конструктору копии, затем выполняется присваивание путём обращения к "operator =", вызывается метод f(), и все эти конструкторы, операторы и методы - private, то есть, статический метод method() изволит "лазать в содержимое класса":

00:59:18 Script 3 EURUSDm,M5: loaded successfully
00:59:18 3 EURUSDm,M5: initialized
00:59:18 3 EURUSDm,M5: A::A()
00:59:18 3 EURUSDm,M5: A::A(const A &)
00:59:18 3 EURUSDm,M5: A::operator =()
00:59:18 3 EURUSDm,M5: A::f()
00:59:18 3 EURUSDm,M5: A::~A()
00:59:18 3 EURUSDm,M5: A::~A()
00:59:18 3 EURUSDm,M5: uninit reason 0
00:59:18 Script 3 EURUSDm,M5: removed

Рассмотрим ещё один пример, очень близкий к первому:

#property strict

/******************************************************************************/
class A {
private:
  A(int i = 0) { Print("A::A(int i = ", i, ")"); }
  ~A() { Print("A::~A()"); }
public:

  static void method() {
    A a;
  }
};

/******************************************************************************/
void OnStart() {
  A::method();
}

Ошибка компиляции, - и конструктор, и деструктор недоступны:

'3.mq4' 3.mq4   1       1
'A::~A' - cannot call private member function   3.mq4   11      7
'A::A' - cannot call private member function    3.mq4   11      7
2 error(s), 0 warning(s)                3       1

Теперь, вообще ничего не меняя, инициализируем переменную a значением, отличным от значения по умолчанию в конструкторе:

#property strict

/******************************************************************************/
class A {
private:
  A(int i = 0) { Print("A::A(int i = ", i, ")"); }
  ~A() { Print("A::~A()"); }
public:

  static void method() {
    A a(1);
  }
};

/******************************************************************************/
void OnStart() {
  A::method();
}

Теперь пример компилируется и исполняется:

00:20:35 Script 3 EURUSDm,M5: loaded successfully
00:20:35 3 EURUSDm,M5: initialized
00:20:35 3 EURUSDm,M5: A::A(int i = 1)
00:20:35 3 EURUSDm,M5: A::~A()
00:20:35 3 EURUSDm,M5: uninit reason 0
00:20:35 Script 3 EURUSDm,M5: removed

Каким образом вдруг статическому методу стало позволено "лазать в содержимое класса"?

Совершенно очевидно, что в данном случае никакая это не "чрезмерная защита", а банальный bug. Слова о тотальном контроле качества, конечно, громкие, но факты - вещь упрямая.

Renat:
Приведите рабочий пример, а не случай вида "я так специально все закрутил, позакрывал доступы, а потом стал аппелировать к пограничному поведению".

Пожалуйста, классический синглтон, а именно - синглтон Майерса, который описан по ссылке в секции примера на C++:

class OnlyOne
{
public:
        static const OnlyOne& Instance()
        {
                static OnlyOne theSingleInstance;
                return theSingleInstance;
        }
private:        
        OnlyOne(){};
        OnlyOne(const OnlyOne& root);
        OnlyOne& operator=(const OnlyOne&);
};

С вновь открывшейся feature'ой даже перекладывается на MQL4++:

#property strict

/******************************************************************************/
class OnlyOne
{
public:
        static OnlyOne *Instance()
        {
                static OnlyOne theSingleInstance(1);
                return GetPointer(theSingleInstance);
        }
private:        
        OnlyOne(int i = 0) { Print("Создан"); };
        ~OnlyOne() { Print("Уничтожен"); };
        OnlyOne(const OnlyOne &);
        void operator=(const OnlyOne &);
};

/******************************************************************************/
void OnStart() {
  OnlyOne *p = OnlyOne::Instance();
}

Компилируется и исполняется:

01:31:49 Script 3 EURUSDm,M5: loaded successfully
01:31:49 3 EURUSDm,M5: Создан
01:31:49 3 EURUSDm,M5: initialized
01:31:49 3 EURUSDm,M5: uninit reason 0
01:31:49 3 EURUSDm,M5: Уничтожен
01:31:49 Script 3 EURUSDm,M5: removed

Попытки создать объект каким-либо способом, отличным от вызова OnlyOne::Instance(), приведут к ошибке компиляции.

А по поводу "я так специально все закрутил, позакрывал доступы, а потом стал аппелировать к пограничному поведению" - разве что-то было использовано неправмерно?

В языке есть механизмы, - имею право использовать, как захочется в пределах допустимого языком. Во всяком случае, с компиляторами C++ именно так дело обстоит.

Если же в реализации языка ошибки, - ну, да, ошибки. Вы говорите о тотальном контроле качества, - так избавьтесь на практике от ошибок реализации компилятора MQL4++, чтобы ошибки найти было почти так же сложно, как в компиляторах C++, раз у вас есть такой контроль. Я по-прежнему считаю, что синтаксический анализатор не поможет избавиться от ошибок типа тех, которые я продемонстрировал.

Renat:
А вам нравится в своих "простых" программах ставить заведомые подножки "спрячу конструктор в приват, создам статик метод, а потом буду из него долбиться в скрытый конструктор"?

Дело не в нравится или не нравится. Есть инструмент. Почему я должен отказываться пользоваться всеми его возможностями?

В данном случае дело даже не в "мне нравится". Это, если уж на то пошло, Майерсу так нравится. И почему-то никто не пытается его обвинить в том, что он пытается "ставить заведомые подножки" компиляторам C++.

Renat:
Вы в состоянии придумать "другую основу" для языков общего плана?

Так, чтобы иметь возможность каждому второму программисту дать язык и он через пару часов начнет на нем с удовольствием писать, а не вышвырнет с отвращением и руганью? Вот трейдеры посмотрели на Easy Language и выкинули, а MQL4/MQL5 с радостью используют и развивают.

Большинство широко распространенных языков базируются на базовых принципах построения конструкций как в C/C++. Так что мы взяли известную всем основу, убрали самые опасные вещи со ссылками, добавили DRM и получили защищенный и безопасный язык.

В результате мы на коне, а конкуренты ходят в неправильных, но более дешевых, как им кажется, направлениях.

Это непростая задача, навскидку не решается. Тут усилия приложить надо и немалые. Пользователи MQL в подавляющем большинстве не являются программистами. И при проектировании языка это в существенной степени должно учитываться. Но задача, уверен, решаемая.

Если уж на то пошло, достаточно было добавить в старый MQL4 структуры, подчистить кое что, вроде приоритета операций, как это было сделано для MQL4++, - это был бы разумный компромисс. Успех MT4 в достаточной степени был обусловлен в том числе и отсутствием "навороченности" языка. Теперь это не так. И ошибок в реализации компилятора стало значительно больше, потому что MQL4++ намного сложнее старого MQL4, а команда разработчиков вряд ли сильно изменилась.

Renat:
В результате мы на коне, а конкуренты ходят в неправильных, но более дешевых, как им кажется, направлениях.

Вот здесь с вами согласен, но считаю, что это, в основном, из-за того, что конкуренты занимаются непонятно чем.

Советники: Pending Trailing 2 Обсуждение статьи "Графические интерфейсы Как запустить 50 терминалов

pansa 2014.09.24 05:20 #109