Renat Fatkhullin: Покажите полный код для воспроизведения и укажите, что именно вам в нем не нравится, пожалуйста.
Взял ваш код из #473 и переделал в MQL5:
class A
{
public:
int Test(int a) { return0; }
};
class B : public A
{
public:
int Test(int a, int b) { return0; }
};
voidOnStart()
{
B b;
b.Test(1);
}
Вывод: скомпилировался с хорошей подсказкой, которая отлично помогает в сложной иерархии классов, где запросто путаются на скрыто перекрытых методах
deprecated behavior, hidden method calling will be disabled in a future MQL compiler version0 error(s), 1 warning(s), 114 msec elapsed
Чтобы понимать важность таких предупреждений, надо много лет заниматься большими сложными проектами. По факту такое [пере]крытие методов заведомо является ошибкой проектирования и грязной работой.
Причем мы пока разрешаем такое перекрытие, только предупреждая. А вот MSVC 2017 вообще запрещает такое использование:
class A
{
public:
int Test(int a) { return0; }
};
class B : public A
{
public:
int Test(int a, int b) { return0; }
};
int main()
{
B b;
b.Test(1);
}
error C2660: 'B::Test': function does not take 1 arguments
note: see declaration of 'B::Test'
Clang/LLVM 8 тоже запрещает, подсказывая вариант доступа через A::Test
error : too few arguments to function call, expected 2, have 1; did you mean 'A::Test'?
note: 'A::Test' declared here
Я хочу верить, что это ошибка.
Раньше всегда хорошо работал. У меня проблема с метаредактором 2138
Если вы
хотите, чтобы базовый класс не создавался (работает только как статическая функциональность
провайдера) или просто работает как интерфейс, вы делаете защищенным / закрытым его конструктор.
Теперь это выдает ошибку ...
Вывод: скомпилировался с хорошей подсказкой, которая отлично помогает в сложной иерархии классов, где запросто путаются на скрыто
перекрытых методах
Чтобы понимать важность таких предупреждений, надо много лет заниматься большими сложными проектами. По факту такое [пере]крытие
методов заведомо является ошибкой проектирования и грязной работой.
Повторю вопрос: поясните, пожалуйста, в чём именно тут ошибка? В чём "грязная работа"? И почему в C#, который является чистым ООП языком (а
тут речь именно про ООП), это НЕ является "грязной работой"?
Что касается С++, то я же вот тут специально
показал разницу между тем, как это сделано в С++, и как нам предложено это решать в MQL.
Кстати, "перекрытие" метода, насколько я понимаю, это когда один метод закрывается (загораживается) другим методом с РАВНЫМ ЧИСЛОМ
аргументов. Поэтому данную ситуацию нельзя назвать перекрытием.
Наверное, лучше до конца следовать плюсовому стилю, а не делать смесь всего на свете?
Вот именно, что если следовать, то до конца. А значит надо сначала ввести using, прежде чем вводить
ограничения. Я хронологию развития C++ не изучал, но уверен, что там было сделано именно так.
А здесь предложено громоздить дополнительные обёртки для методов, увеличивая вероятность возможных ошибок. Ведь в процессе
запросто можно перепутать местами аргументы. А если потребуется что-то поменять в сигнатуре метода, то придётся редактировать её
сразу в нескольких местах одновременно.
И кстати, в приведённой вами выдержке из Страуструпа описана другая ситуация, а не та, которую мы обсуждаем.
Renat Fatkhullin: Уберем их полностью в следующем билде, идея неудачной оказалась.
МТ5 билд 2138 Виндовс 10 - 64
сделайте в тестере чекбокс "выбрать все" во вкладке параметры, чтобы галки на input-ы одним махом все поставить - иногда удобнее снимать галки чем ставить с нуля (когда много параметров)
ну и не понятна логика зачем мне тестер во вкладке оптимизация всегда добавляет колонки с моими input-ами, тоже нужна возможность убрать все сразу (или не добавлять без спроса!) , а не через контекстное меню оптимизируемые параметры и по одной снимать галки, все бы ничего, но если штук 40 input-ов, до довольно трудно сдержаться и не произносить молитву для Создателя этой "нужной фичи"
Вот именно, что если следовать, то до конца. А значит надо сначала ввести using, прежде чем вводить
ограничения. Я хронологию развития C++ не изучал, но уверен, что там было сделано именно так.
А здесь предложено громоздить дополнительные обёртки для методов, увеличивая вероятность возможных ошибок. Ведь в
процессе запросто можно перепутать местами аргументы. А если потребуется что-то поменять в сигнатуре метода, то придётся
редактировать её сразу в нескольких местах одновременно.
И кстати, в приведённой вами выдержке из Страуструпа описана другая ситуация, а не та, которую мы обсуждаем.
Ну почему же, описан частный случай касающийся скрытия.
Вообще как бы согласен, что вопрос спорный (да и Страуструп это признаёт). Применимо лишь с паблик наследованием (иначе не надо), но с паблик
можно легко сделать каст к базовому и наступить на грабли сделав ошибочный вызов.
В общем хз, как говорится - в любой непонятной ситуации делай как в крестах )), это и наличие using касается.
Вообще как бы согласен, что вопрос спорный (да и Страуструп это признаёт). Применимо лишь с паблик наследованием (иначе не надо), но с паблик
можно легко сделать каст к базовому и наступить на грабли сделав ошибочный вызов.
С другой стороны - плюсовое поведение открывает некторые возможности - делаем нужный каст и прогоняем указатель через обобщённый алгоритм,
т.е. будет задействован нужный набор функций (можно и иначе сделать, но как одна из возможных реализаций).
сделайте в тестере чекбокс "выбрать все" во вкладке параметры, чтобы галки на input-ы одним махом все поставить - иногда удобнее
снимать галки чем ставить с нуля (когда много параметров)
ну и не понятна логика зачем мне тестер во вкладке оптимизация всегда добавляет колонки с моими input-ами, тоже нужна возможность
убрать все сразу (или не добавлять без спроса!) , а не через контекстное меню оптимизируемые параметры и по одной снимать галки, все бы
ничего, но если штук 40 input-ов, до довольно трудно сдержаться и не произносить молитву для Создателя этой "нужной фичи"
заранее благодарен!
и еще раз - большая просьба сделать что-нибудь с ползунком скорости визуального
тестирования, писал и в прошлом месяце и обсуждение подтягивалось - вообще не возможно, что то сделать если жесткий диск ПК не
блещет скоростью и ползунок скорости был сдвинут на макс.
как минимум сделайте откат ползунка на 5 положений после теста от максимального ( после тестирования ),
чтобы при нажатии визуального тестирования не попадать в очередной раз на одну и ту же неприятную ситуацию - тест идет, а все кнопки
управления визуализацией висят (не активны)
Повторю вопрос: поясните, пожалуйста, в чём именно тут ошибка? В чём "грязная работа"? И почему в C#, который является чистым ООП языком (а
тут речь именно про ООП), это НЕ является "грязной работой"?
Что касается С++, то я же вот тут специально
показал разницу между тем, как это сделано в С++, и как нам предложено это решать в MQL.
Кстати, "перекрытие" метода, насколько я понимаю, это когда один метод закрывается (загораживается) другим методом с РАВНЫМ ЧИСЛОМ
аргументов. Поэтому данную ситуацию нельзя назвать перекрытием.
Еще раз:
1) у вас нет опыта в больших проектах, где за такое бьют по рукам
2) называть методы одинаково вне рамок виртуальных методов - это грязнейшая работа
3) мы все-таки позволяем правильно разрулить перекрытые методы, лишь предупреждая о конфликте
Продолжайте играть в самострел самостоятельно, пожалуйста.
Мы знаем свою дорогу по внедрению бОльшего контроля и эвристик. У нас нет задачи потакать плохим практикам.
Извините, не подскажете как удалить в Тестере историю его работы с ликвидацией вот этих элементов? Очистка/удаление папок Тестера не помогает.
Покажите полный код для воспроизведения и укажите, что именно вам в нем не нравится, пожалуйста.
Взял ваш код из #473 и переделал в MQL5:
Вывод: скомпилировался с хорошей подсказкой, которая отлично помогает в сложной иерархии классов, где запросто путаются на скрыто перекрытых методах
Чтобы понимать важность таких предупреждений, надо много лет заниматься большими сложными проектами. По факту такое [пере]крытие методов заведомо является ошибкой проектирования и грязной работой.
Причем мы пока разрешаем такое перекрытие, только предупреждая. А вот MSVC 2017 вообще запрещает такое использование:
Clang/LLVM 8 тоже запрещает, подсказывая вариант доступа через A::Test
Так что претензии к нам необоснованы.
Я хочу верить, что это ошибка. Раньше всегда хорошо работал. У меня проблема с метаредактором 2138
Если вы хотите, чтобы базовый класс не создавался (работает только как статическая функциональность провайдера) или просто работает как интерфейс, вы делаете защищенным / закрытым его конструктор. Теперь это выдает ошибку ...
Взял ваш код из #473 и переделал в MQL5:
Вывод: скомпилировался с хорошей подсказкой, которая отлично помогает в сложной иерархии классов, где запросто путаются на скрыто перекрытых методах
Чтобы понимать важность таких предупреждений, надо много лет заниматься большими сложными проектами. По факту такое [пере]крытие методов заведомо является ошибкой проектирования и грязной работой.
Повторю вопрос: поясните, пожалуйста, в чём именно тут ошибка? В чём "грязная работа"? И почему в C#, который является чистым ООП языком (а тут речь именно про ООП), это НЕ является "грязной работой"?
Что касается С++, то я же вот тут специально показал разницу между тем, как это сделано в С++, и как нам предложено это решать в MQL.
Кстати, "перекрытие" метода, насколько я понимаю, это когда один метод закрывается (загораживается) другим методом с РАВНЫМ ЧИСЛОМ аргументов. Поэтому данную ситуацию нельзя назвать перекрытием.
Наверное, лучше до конца следовать плюсовому стилю, а не делать смесь всего на свете?
Вот именно, что если следовать, то до конца. А значит надо сначала ввести using, прежде чем вводить ограничения. Я хронологию развития C++ не изучал, но уверен, что там было сделано именно так.
А здесь предложено громоздить дополнительные обёртки для методов, увеличивая вероятность возможных ошибок. Ведь в процессе запросто можно перепутать местами аргументы. А если потребуется что-то поменять в сигнатуре метода, то придётся редактировать её сразу в нескольких местах одновременно.
И кстати, в приведённой вами выдержке из Страуструпа описана другая ситуация, а не та, которую мы обсуждаем.
Уберем их полностью в следующем билде, идея неудачной оказалась.
МТ5 билд 2138 Виндовс 10 - 64
сделайте в тестере чекбокс "выбрать все" во вкладке параметры, чтобы галки на input-ы одним махом все поставить - иногда удобнее снимать галки чем ставить с нуля (когда много параметров)
ну и не понятна логика зачем мне тестер во вкладке оптимизация всегда добавляет колонки с моими input-ами, тоже нужна возможность убрать все сразу (или не добавлять без спроса!) , а не через контекстное меню оптимизируемые параметры и по одной снимать галки, все бы ничего, но если штук 40 input-ов, до довольно трудно сдержаться и не произносить молитву для Создателя этой "нужной фичи"
заранее благодарен!
Вот именно, что если следовать, то до конца. А значит надо сначала ввести using, прежде чем вводить ограничения. Я хронологию развития C++ не изучал, но уверен, что там было сделано именно так.
А здесь предложено громоздить дополнительные обёртки для методов, увеличивая вероятность возможных ошибок. Ведь в процессе запросто можно перепутать местами аргументы. А если потребуется что-то поменять в сигнатуре метода, то придётся редактировать её сразу в нескольких местах одновременно.
И кстати, в приведённой вами выдержке из Страуструпа описана другая ситуация, а не та, которую мы обсуждаем.
Ну почему же, описан частный случай касающийся скрытия.
Вообще как бы согласен, что вопрос спорный (да и Страуструп это признаёт). Применимо лишь с паблик наследованием (иначе не надо), но с паблик можно легко сделать каст к базовому и наступить на грабли сделав ошибочный вызов.
В общем хз, как говорится - в любой непонятной ситуации делай как в крестах )), это и наличие using касается.
МТ5 билд 2138 Виндовс 10 - 64
сделайте в тестере чекбокс "выбрать все" во вкладке параметры, чтобы галки на input-ы одним махом все поставить - иногда удобнее снимать галки чем ставить с нуля (когда много параметров)
ну и не понятна логика зачем мне тестер во вкладке оптимизация всегда добавляет колонки с моими input-ами, тоже нужна возможность убрать все сразу (или не добавлять без спроса!) , а не через контекстное меню оптимизируемые параметры и по одной снимать галки, все бы ничего, но если штук 40 input-ов, до довольно трудно сдержаться и не произносить молитву для Создателя этой "нужной фичи"
заранее благодарен!
и еще раз - большая просьба сделать что-нибудь с ползунком скорости визуального тестирования, писал и в прошлом месяце и обсуждение подтягивалось - вообще не возможно, что то сделать если жесткий диск ПК не блещет скоростью и ползунок скорости был сдвинут на макс.
как минимум сделайте откат ползунка на 5 положений после теста от максимального ( после тестирования ), чтобы при нажатии визуального тестирования не попадать в очередной раз на одну и ту же неприятную ситуацию - тест идет, а все кнопки управления визуализацией висят (не активны)
Повторю вопрос: поясните, пожалуйста, в чём именно тут ошибка? В чём "грязная работа"? И почему в C#, который является чистым ООП языком (а тут речь именно про ООП), это НЕ является "грязной работой"?
Что касается С++, то я же вот тут специально показал разницу между тем, как это сделано в С++, и как нам предложено это решать в MQL.
Кстати, "перекрытие" метода, насколько я понимаю, это когда один метод закрывается (загораживается) другим методом с РАВНЫМ ЧИСЛОМ аргументов. Поэтому данную ситуацию нельзя назвать перекрытием.