Прощаи робот-да здравствует маразм - страница 6

Новый комментарий
 
pansa:

Привет,Винин!

Вы проверили индикатор  : AltrTrend_Signal_v2_2.mq4

и нашли логическую ошибку

в формуле :  SSP=MathCeil(Kperiod/iADX(NULL,0,PerADX,PRICE_CLOSE,MODE_MAIN,1));

вы подчеркнули 1 на конце

что же по Вашему мнению должно тут стоять?

панса



Наверно, 0! Попробуйте! А если в цикле, попробуйте и i или что там считается!
 
pansa:

Привет,Винин!

Вы проверили индикатор  : AltrTrend_Signal_v2_2.mq4

и нашли логическую ошибку

в формуле :  SSP=MathCeil(Kperiod/iADX(NULL,0,PerADX,PRICE_CLOSE,MODE_MAIN,1));

вы подчеркнули 1 на конце

что же по Вашему мнению должно тут стоять?

панса



Должно стоять shift 
 
Andrei01:

На эту стандартную, законную и распространенную конструкцию по стандартам языка Си редактор выдает предупреждение: "declaration of 'a' hides global declaration at line 4" и "declaration of 'b' hides global declaration at line 4", которое еще при этом неправильно и неграмотно по своей сути, так как тут нет ни декларации новой переменной внутри функции, ни намека на хоть какое-то возможное перекрытие переменных.

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

Сообщения абсолютно верные на 100%.

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

Даже сейчас в 2014 году C/C++ компиляторы (те что остались на Windows после их полного уничтожения Майкрософтом) не занимаются защитой программистов самих от себя. Да, есть слабенький(практически бесполезный), за отдельные деньги и отдельно запускаемый Code Analysis в Visial Studio, но все равно приходится пользоваться отдельно PVS Studio (хвала Богу за этих ребят), CPP Check и Lint для глубокого поиска ошибок.

Тестирование этого примера:

  • MQL4/MQL5 - дает предупреждения о потенциальной ошибке
    declaration of 'a' hides global declaration at line 6   Test.mq4        13      14
declaration of 'b' hides global declaration at line 6   Test.mq4        13      22

  • Visual Studio 2012, включая Code Analysis - ничего, качество анализа на потенциальные ошибки вообще на нуле. Они не парятся, так как конкурентов давно уже нет.

  • PVS Studio - сообщает верно
    V669 The 'a', 'b' arguments are non-constant references. The analyzer is unable to determine the position at which this argument is being modified.
     It is possible that the function contains an error. test.cpp 17

  • Lint - выдает аналогично, declaration 'x' hide...


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

 
Renat:

Я тоже думаю, что сообщения совершенно бесполезные. Я не проф программист, но меня такая ерунда в мкл напрягает. Интересно, если ссылки на a и b будут константными, PVS Studio выдаст предупреждение (нет возможности проверить самому)?

int a=1,b=2;
//--------------------------------------------------------------------
void start(){        
        int k=sum(a,b);
        Alert(k);
}
//--------------------------------------------------------------------
int sum(const int& a, const int& b){        
        return(a+b);
}
 
Renat:

Тестирование этого примера:

  • MQL4/MQL5 - дает предупреждения о потенциальной ошибке

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

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

2. Думаю, что качество написанного кода никак не связано с качеством компилятора и его способности анализа синтаксиса кода, а проявляется лишь в процессе качественно написанной тестовой среды, которая и позволяет сделать глубокий функциональный анализ написанного кода. Верование же в спасительный синтаксический анализ кода в отрыве от тестовой оболочки это утопия и пустая трата сил.

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

 
Renat:

Сообщения абсолютно верные на 100%.

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

Renat:

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

Интересно, почему же тогда именно эти языки и были взяты за основу для MQL4/MQL4++/MQL5?

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

Renat:

Даже сейчас в 2014 году C/C++ компиляторы (те что остались на Windows после их полного уничтожения Майкрософтом) не занимаются защитой программистов самих от себя. Да, есть слабенький(практически бесполезный), за отдельные деньги и отдельно запускаемый Code Analysis в Visial Studio, но все равно приходится пользоваться отдельно PVS Studio (хвала Богу за этих ребят), CPP Check и Lint для глубокого поиска ошибок.

Тестирование этого примера:

  • MQL4/MQL5 - дает предупреждения о потенциальной ошибке

  • Visual Studio 2012, включая Code Analysis - ничего, качество анализа на потенциальные ошибки вообще на нуле. Они не парятся, так как конкурентов давно уже нет.

  • PVS Studio - сообщает верно

  • Lint - выдает аналогично, declaration 'x' hide...

Во-первых, Microsoft не всесилен и не вездесущ. А, во-вторых, в 2014 году есть и другие компиляторы, что остались на Windows. Я приведу пример, правда, компилируя его из-под Linux, но в части "глубокого поиска ошибок" версии данного компилятора под Windows и под Linux не отличаются. Исходный код слегка изменён:

int a=1,b=2;
//--------------------------------------------------------------------
int sum(int& a, int& b){        
        return(a+b);
}
//--------------------------------------------------------------------
int main(){        
        return sum(a,b);
}

Компиляция и сообщения компилятора:

$ icpc -c -Wremarks 1.cpp
1.cpp(3): remark #1418: external function definition with no prior declaration
  int sum(int& a, int& b){        
      ^

1.cpp(3): remark #3280: declaration hides variable "a" (declared at line 1)
  int sum(int& a, int& b){        
               ^

1.cpp(3): remark #3280: declaration hides variable "b" (declared at line 1)
  int sum(int& a, int& b){        
                       ^

Видите, в 2014-м году компиляторы под Windows, имеющие сервис того самого "глубокого поиска ошибок", - есть.

Заметьте, право решать, использовать или нет "глубокий поиск", отдано программисту: тот же код при более практичной компиляции без опции "-Wremarks", но со всеми предупреждениями, включёнными при помощи опции "-Wall", компилируется уже без всяких замечаний:

$ icpc -c -Wall 1.cpp
$

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

Использована следующая версия компилятора:

$ icpc --version
icpc (ICC) 15.0.0 20140723
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.

Кстати, данный компилятор интегрируется в Visual Studio, по крайней мере, более ранние его версии раньше интегрировались в более ранние версии Visual Studio.

Renat:

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

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

#property strict

/******************************************************************************/
class A {
private:
  /******************************************************************************/
  A() { }

  /******************************************************************************/
  void f() { }

public:
  /******************************************************************************/
  static void sf1(A &a) {
    a.f(); // Нет ошибки
  }

  /******************************************************************************/
  static void sf2() {
    A a; // Место "ошибки"

    a.f(); // Нет ошибки
  }
};

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

Почему метод f(), объявленный в секции private, прекрасно вызывается из статического метода, как он и должен, а конструктор класса, также объявленный в секции private, из такого же самого статического метода уже "не вызывается" при определении переменной?

Сообщения об ошибках:

'A::A' - cannot call private member function

Данный bug компилятора не позволяет, например, реализовать по-человечески singleton Майерса (данный пример НЕ является реализацией упомянутого singleton'а). И это не последний bug в части доступа к сущностям, объявленным в секции private.

Это именно bug, а не какая-нибудь особенность, направленная, например, против самоубийственных/безрассудных методик, поскольку, стоит заменить определение автоматической переменной на динамическое создание объекта, как конструктор самым замечательным образом вдруг начинает вызываться:

  /******************************************************************************/
  static void sf2() {
    A *a = new A;

    a.f();
    delete a;
  }

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

Пока остаются такие bug'и, странно говорить о качественном компиляторе. По части ошибок в самой реализации языка, компиляторы C/C++, как коммерческие, так и некоммерческие, существенно превосходят компилятор MQL4++, потому что такого безобразия в них нет. Настолько превосходят, что, я бы сказал, по сравнению с ними, компилятор MQL4++ вообще "не работает".

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

 
Pavlick:

Я тоже думаю, что сообщения совершенно бесполезные. Я не проф программист, но меня такая ерунда в мкл напрягает. Интересно, если ссылки на a и b будут константными, PVS Studio выдаст предупреждение (нет возможности проверить самому)?

int a=1,b=2;
//--------------------------------------------------------------------
void start(){        
        int k=sum(a,b);
        Alert(k);
}
//--------------------------------------------------------------------
int sum(const int& a, const int& b){        
        return(a+b);
}
Компилятор Intel C++ версии 15.0.0 при компиляции с опцией -Wremarks выдаёт одинаковые ремарки для обоих случаев.
 
simpleton:

Верные-то они - верные, но - не практичные.

Ну раз указания на потенциальные ошибки верные, значит надо эти ошибки исправлять.
 
Renat:
Ну раз указания на потенциальные ошибки верные, значит надо эти ошибки исправлять.

Потенциальная ошибка на то и потенциальная, что это - совсем не обязательно ошибка. Поэтому утверждение о том, что "значит, надо эти ошибки исправлять", неверно, потому что это могут быть совсем НЕ ошибки.

Есть случаи, когда ошибка имеется почти наверняка, например, случай отсутствия проверки результата вызова функции, которая может завершиться неуспешно. Предупреждение о таком случае и уместно, и весьма полезно. А предупреждение о случае, когда нельзя утверждать, имеется ошибка или нет, обычно и неуместно, и не полезно. В случае сокрытия имён нельзя утверждать, что ошибка почти наверняка имеет место.

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

Очевидно, что в компиляторе Intel факты сокрытия во вложенной области видимости имени, прежде объявленного во внешней области видимости, детектируются лишь как ремарки, а не как предупреждения - по той же самой причине: это могут быть совсем НЕ ошибки. И в других компиляторах, включая некоммерческие, такие факты сокрытия НЕ соответствуют никакому предупреждению. Потому что весь собирательный опыт пользователей компиляторов, то есть, программистов, говорит о том, что это не должно быть предупреждением. И, естественно, пользователь должен иметь возможность настроить, какие предупреждения/ремарки будут выдаваться, а какие - нет.

Кстати, раз MQL - отдельный язык, который не обязан следовать стандартам C/C++, - не проще ли тогда вообще запретить в нём сокрытие имён во вложенных областях видимости?

  
1.cpp(3): remark #3280: declaration hides variable "a" (declared at line 1)
  int sum(int& a, int& b){       

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

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

12345678910111213...16
Новый комментарий
Причина обращения: