Есть ли возможность делать функции с переменным количеством параметров разного типа как Printf(argument, ...)?

 
В C/С++ такая возможность есть. В MQL5 внутри по всей видимости, такая возможность тоже есть. Но есть ли такая возможность для пользователя?
 
Вадим Калашнков:
В C/С++ такая возможность есть. В MQL5 внутри по всей видимости, такая возможность тоже есть. Но есть ли такая возможность для пользователя?

Объявляешь функцию, в которой максимальное количество параметров, и все они по умолчанию принимают невалидные значения. 

При вызове - передаешь только необходимые значения. 

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

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

 
Georgiy Merts #:

Объявляешь функцию, в которой максимальное количество параметров, и все они по умолчанию принимают невалидные значения. 

При вызове - передаешь только необходимые значения. 

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

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

Данные функции применяются в функциях форматированого вывода и прочего. На C++ для этого есть специальный удобный функционал для этого:

template <class... T>
  void some_function(const std::string& first_parameter, const T&... arguments)

 То, что вы предлагаете через аргументы по умолчанию - это дич. Во первых указывать 64 параметра по умолчанию (по аналогии с Print), во вторых - потом их перебирать, при этом, даже не в цикле. Видимо, нормальными способами организовать нельзя... Придется делать через перегрузку <<.

 
Вадим Калашнков:
В C/С++ такая возможность есть. В MQL5 внутри по всей видимости, такая возможность тоже есть. Но есть ли такая возможность для пользователя?

Костыли только. Даже делал на 64 параметра. Но писать еще больше пришлось в коде. Отказался.

 
Valeriy Yastremskiy #:

Костыли только. Даже делал на 64 параметра. Но писать еще больше пришлось в коде. Отказался.

Все таки пришел к аналогу std::cout. Просто делается перегруз << поз нужные типы, так же легко можно аналог форматирования как в cout сделать и endl.

 
Вадим Калашнков #:

Все таки пришел к аналогу std::cout. Просто делается перегруз << поз нужные типы, так же легко можно аналог форматирования как в cout сделать и endl.

Без ООП не обойтись))) Почему то принт, коммент с переменным количеством аргументов, а вот пользовательские функции нет. Видимо не захотели усложняться.

 
Valeriy Yastremskiy #:

Без ООП не обойтись))) Почему то принт, коммент с переменным количеством аргументов, а вот пользовательские функции нет. Видимо не захотели усложняться.

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

 
Вадим Калашнков #:

 То, что вы предлагаете через аргументы по умолчанию - это дич. Во первых указывать 64 параметра по умолчанию (по аналогии с Print), во вторых - потом их перебирать, при этом, даже не в цикле. Видимо, нормальными способами организовать нельзя... Придется делать через перегрузку <<.

Можно на "ты". 

Лично на мой взгляд, "дичь" - это 64 параметра. Лично мне не нравится, когда в функцию передается больше пяти параметров. 

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

 
Georgiy Merts #:

Можно на "ты". 

Лично на мой взгляд, "дичь" - это 64 параметра. Лично мне не нравится, когда в функцию передается больше пяти параметров. 

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

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

 
шаблоны проектирования
Вадим Калашнков #:

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

шаблоны проектирования ни разу не предназначены для того что отмечено

 
Maxim Kuznetsov #:
шаблоны проектирования

шаблоны проектирования ни разу не предназначены для того что отмечено

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

Из википедии:

В сравнении с полностью самостоятельным проектированием, шаблоны обладают рядом преимуществ. Основная польза от использования шаблонов состоит в снижении сложности разработки за счёт готовых абстракций для решения целого класса проблем. Шаблон даёт решению своё имя, что облегчает коммуникацию между разработчиками, позволяя ссылаться на известные шаблоны. Таким образом, за счёт шаблонов производится унификация деталей решений: модулей, элементов проекта, — снижается количество ошибок. Применение шаблонов концептуально сродни использованию готовых библиотек кода. Правильно сформулированный шаблон проектирования позволяет, отыскав удачное решение, пользоваться им снова и снова. Набор шаблонов помогает разработчику выбрать возможный, наиболее подходящий вариант проектирования.

Что из выше выделеного не следует из вышеописаного? )

Причина обращения: