Ошибки, баги, вопросы - страница 1953

[fxsaber]

Alexey Navoykov:

В общем я вынужден с прискорбием признать, что компилятор MQL далеко не такой умный, как о нём думал )  Я бы даже сказал - совсем не умный )  Попробовал набросать простенькие примеры, и оказалось что даже если создаётся объект-пустышка, который  нигде не используется и ничего не делает, то компилятору на это пофиг. Оптимизации никакой.  Сужу чисто по скорости работы.  Причём в новых билдах почему-то работает медленнее, чем в старых.

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

ЗЫ Есть и такие неоднозначности компилятора.

[Alexey Navoykov]

fxsaber:

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

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

[Alexey Navoykov]

fxsaber:

Поэтому предлагаю в OnTesterInit добавить возможность изменения сформированной по-умолчанию таблицы проходов:

int PassesSet( const int Index, const MqlParam& Parameters[] );

Я полагаю, сами наборы параметров не хранятся в системе, а вычисляются по уникальному номеру комбинации (сейчас он совпадает с номером прохода).  Поэтому можно лишь поменять порядок следования комбинаций, но не их состав.  Т.е. в данном случае было бы что-то вроде SwapPasses(long index1, long index2).

Но могу и ошибаться.

[fxsaber]

Alexey Navoykov:

Я полагаю, сами наборы параметров не хранятся в системе, а вычисляются по уникальному номеру комбинации (сейчас он совпадает с номером прохода).  Поэтому можно лишь поменять порядок следования комбинаций, но не их состав.  Т.е. в данном случае было бы что-то вроде SwapPasses(long index1, long index2).

Возможно, и так. Сейчас на порядок можно еще как-то влиять через Swap input-строк в исходнике советника.

[Stanislav Korotky]

fxsaber:

Возможно, и так. Сейчас на порядок можно еще как-то влиять через Swap input-строк в исходнике советника.

Это же убивает алгоритм оптимизации - все равно что оптимизировать в случайном направлении.

[fxsaber]

Stanislav Korotky:

Это же убивает алгоритм оптимизации - все равно что оптимизировать в случайном направлении.

Речь про полный перебор в первую очередь.

[[Удален]]

Постепенно осваиваю ООП и встретился с одной неочевидной вещью.

Есть класс А, полями которого являются объекты другого класса В.

в классе А вызывается константный метод, возвращающий объект класса В.

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

Выглядит это так (пример упрощен, писался в браузере):

class B
{
private:
   int m_width;
   int m_length;
public:
   void Reset() { m_width = 0; m_length = 0; }
}
class A
{
private:
   B m_member;
public:
   B GetBMember() const { return( m_member ); }
}
//---
A obj;
obj.GetBMember().Reset();

В результате получается, что Reset() не срабатывает, т.е. поля m_member не очищаются.

Вопрос: не должен ли компилятор на этапе сборки сообщать (ошибку/предупреждение), что вызывается неконстантный метод для константного объекта (или что-то в этом духе)? 

[Sergey Dzyublik]

Alexey Kozitsyn:

Вопрос: не должен ли компилятор на этапе сборки сообщать (ошибку/предупреждение), что вызывается неконстантный метод для константного объекта (или что-то в этом духе)? 

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

[[Удален]]

Sergey Dzyublik:

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

Спасибо. Вероятно Вы правы, причем спецификатор const не влияет на результат (и с ним, и без него сброса не происходит).

[Andrey Barinov]

Alexey Kozitsyn:

Постепенно осваиваю ООП и встретился с одной неочевидной вещью.

Есть класс А, полями которого являются объекты другого класса В.

в классе А вызывается константный метод, возвращающий объект класса В.

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

Выглядит это так (пример упрощен, писался в браузере):

В результате получается, что Reset() не срабатывает, т.е. поля m_member не очищаются.

Вопрос: не должен ли компилятор на этапе сборки сообщать (ошибку/предупреждение), что вызывается неконстантный метод для константного объекта (или что-то в этом духе)? 

Возвращайте указатели.

class B
{
private:
   int m_width;
   int m_length;
public:
   void Reset() { m_width = 0; m_length = 0; }
}
class A
{
private:
   B m_member;
public:
   B *GetBMember() const { return( &m_member ); }
}
//---
A obj;
obj.GetBMember().Reset();