Ошибки, баги, вопросы - страница 1732
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
(1)const <type> (2)const * (3)const &
Во-первых по самой сути ссылки ее нет смысла делать константной.
Во-вторых если бы смысл был,
const A * const & const [] -- вот такую запись считаю правильной.
Во-первых по самой сути ссылки ее нет смысла делать константной.
Во-вторых если бы смысл был,
const A * const & const [] -- вот такую запись считаю правильной.
Смысл есть делать ссылку константной. А вот запись вижу нелогичной.
Лелеял красивое стройное дерево понимания языка, а тут эдакий вандализм ))
Смысл есть делать ссылку константной.
Пример?
Пример?
Когда хочется гарантировать, что элементы и размер массива не будут изменены.
Ссылка для массивов это костыль в языке MQL, а не ссылка.
А если [] это модификатор типа такой же как *, у него должен быть свой const! а не у ссылки.
- CHART_WINDOWS_TOTAL - определяются как [UNKNOWN ENUM]::101
- CHART_WINDOW_IS_VISIBLE - определяется как [UNKNOWN ENUM]::102
И конечно функция ChartSetInteger выдает ошибку 4109 - Ошибочный идентификатор свойства графика.
Ссылка для массивов это костыль в языке MQL, а не ссылка.
А если [] это модификатор типа такой же как *, у него должен быть свой const! а не у ссылки.
Ошибка обоснована - эти идентификаторы в справке указаны как ReadOnly (не сочетаются с ChartSetInteger) https://www.mql5.com/ru/docs/constants/chartconstants/enum_chart_property
может это поможет ?
Очень внимательно прочел. С++ много тяжелее воспринимается, чем MQL. Мало, что понял из статьи. И не понял совсем, как она касается обсуждаемого здесь.
Однако, понравилась такая возможность,
Совершенная передача(perfectforwarding)
Прежде чем описать что же это, такое вернемся к предыдущему стандарту и опишем существующую проблему. Предположим, у нас есть шаблонная функция foo принимающая один параметр, и передающая его функции bar(T& something):
void foo(T& Object)
{
bar(Object);
}
Итак, все хорошо. Но, что если мы захотим передать, скажем, число 100 в качестве аргумента функции?
Не беда, напишем так:
void foo(const T& Object)
{
bar(Object);//Ooops
}
Но в этом случае будет ошибка компиляции, т.к. bar принимает не константную ссылку. Значит надо предоставить 2 функции bar - константную и нет. А теперь представим, что у функции не один параметр а 2,3, или 5? Получается, что подобная задача очень трудна в реализации, т.к мы имеем (2^n - 1) перегруженных функций, где n - количество аргументов функции. Если вы думаете, что такое количество параметров является плохим стилем и вообще так никто не пишет, тогда обратите свой взор на std::bind, std::make_shared и т.д.
Теперь посмотрим, какое же решение нам предоставляет новый стандарт:
void foo(T&& Object)
{
bar(std::forward<T>(Object));
}
Используя вышеприведённый код проблема с передачей параметров полностью решается, это и называется совершенной передачей, т.к. тип аргумента сохраняется между вызовами внешней функции fooи внутренней функции bar. Больше нет нужды в перегрузке кучи функций - разработчики обобщенного кода могут быть довольны.
Это решение возможно благодаря тому, что если параметром шаблона является T&&, то переданный тип сохранит себя, а std::forward нужен затем, что любой именованный тип внутри функции foo превращается в lvalue, а нам нужен исходный тип - для этого и применяется std::forward он сохраняет исходный тип аргумента и лишает его имени(получается T&&), что позволяет в дальнейшем передать его в точности в функцию bar.