Ошибки, баги, вопросы - страница 1653
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Например, когда SellLimit_Price == BuyTP_Price, SellLimit_Lots = Buy_Lots, в тестере возникает неоднозначность:
Если график инструмента открыт, то его (символ) скрыть невозможно...
Закройте график и тогда будет счастье...
Интересует вариант без "если" (см.текст полностью, а не только картинку)
Вариант без "если" - закрой график символа который хочешь скрыть и будет тебе счастье...
Выбирай на вкус...
Если график инструмента открыт, то его (символ) скрыть невозможно...
Закройте график и тогда будет счастье...
А то не знаем...
Хочешь сказать при закрытых графиках не скрывается символ?
Хочешь сказать при закрытых графиках не скрывается символ?
Да. Несколько раз уже сталкивался с такой бякой.
Все равно сообщение об ошибке правильное.
Первоначально не придал этому значения, но столкнувшись с этим повторно - появились аргументы, что оно не правильное. И вот почему: далее условный код
Рассуждения что ставить после while(true) {} сводятся к следующему: "Мы же там все-равно никогда не будем... return нужен только формально - чтобы компилятор сказал OK... значит - поставим там случайное значение - return Random();"
Спустя время вносим в код изменения и появляется необходимость поставить break внутри while
В этом случае компилятор скажет: "OK: Да все нормально. Там же после while(true) {} есть код - значит случай break был предусмотрен ранее и наверняка среди этого множества строк уже есть такой же break. Все значения возврата уже были продуманы еще тогда - не парься!"
И в итоге получим случайное значение.
А если бы первоначально не было строки (*), то компилятор скажет: "Error: Нее... так не пойдет... раньше break не было и нужно вернуть что-то осознанное"
Получается, что строка (*) не просто избыточна, а еще и увеличивает вероятность появления трудноуловимых ошибок
Первоначально не придал этому значения, но столкнувшись с этим повторно - появились аргументы, что оно не правильное...