Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
там не суть чем инициализировать, хоть int - любое число, чтобы вызвать именно этот конструктор
а 0.0 выбрал, чтобы не было опечаток - любая цифра, т.е. 0.0. написать и опечататься сложнее чем 123
(double)0
а не так то тоже верно))) только сейчас код посмотрел по нормальному, еще есть способ ненормально смотреть))(double)0
нет
пишу только 0.0 - других цифр не предполагается - там же даже переменной нет в конструкторе
в общем как модно - авторский стиль, возможно не самый лучший
суть не в х) а то что там может быть и float на приеме по мимо дабла, указывать просто 0.0 Тоже не надежно
0.0 - это для компилятора однозначный double, float будет 0.f
зачёт)
Пока рубрика "вопросы за 50" открыта, позвольте влезу со своим в тему кастов.
- Какие есть способы улучшить код в плане отказоустойчивости или неизбыточности?
- Нужна ли проверка CheckPointer()!=POINTER_INVALID ? Или точно не нужна? объясните почему.
- Приведение к не-const, чтобы была возможность вызова не-const методов. А можно ли сразу в методе Compare вызывать не-const ? т.е. избавиться от выделенных желтым const ?
Пока рубрика "вопросы за 50" открыта, позвольте влезу со своим в тему кастов.
- Какие есть способы улучшить код в плане отказоустойчивости или неизбыточности?
- Нужна ли проверка CheckPointer()!=POINTER_INVALID ? Или точно не нужна? объясните почему.
- Приведение к не-const, чтобы была возможность вызова не-const методов. А можно ли сразу в методе Compare вызывать не-const ? т.е. избавиться от выделенных желтым const ?
Вроде как один в один с твоим, только букв поменьше. Так-то дело вкуса, кому как больше нравится, но лишнюю переменную я убрал (скорее всего ее и компилятор бы убрал в рамках оптимизации).
По поводу моей проверки !node. По хорошему ее надо заменить на CheckPointer(node)==POINTER_INVALID, но это оверхед, вызов функции. Даже если заинлайнить, это все равно, как минимум, разыменование и проверка флага состояния. Если Compare методы только библиотека или конкретная, тобой написанная прога использовать будут, то лучше !node и по коду следить, что бы невалидный указатель не подать. Если лень за указателями следить или это библиотека для недоджунов, то тогда только CheckPointer(node)==POINTER_INVALID.
Если ты уберешь, выделенный тобой, спецификатор const, то ты не сможешь вызвать эти методы из константного объекта.
UPD: выделенную проверку можно убрать, так как она есть в вызываемых методах.
Пока рубрика "вопросы за 50" открыта, позвольте влезу со своим в тему кастов.
- Какие есть способы улучшить код в плане отказоустойчивости или неизбыточности?
- Нужна ли проверка CheckPointer()!=POINTER_INVALID ? Или точно не нужна? объясните почему.
- Приведение к не-const, чтобы была возможность вызова не-const методов. А можно ли сразу в методе Compare вызывать не-const ? т.е. избавиться от выделенных желтым const ?
По идее писать два метода одной функции с телом конст и без него - мягко говоря - не стоит)))
Но и вероятность того что встретишь два метода близка к нулю.... в этом коде const можно упустить. т.к. вероятность существования CChartObjectRectangle::Price - без конст в теле - думаю мало вероятна.
На вызов этой функции из вне ну никак не влияет. Т,е. конст работает только с внутренними функциями и следит за тем чтобы никто ничего не записывал в память объекта (не менял значения переменной). Т.е. при конст нельзя вызвать Set(a)... Часто, в какой-нить путанице, чтобы быть уверенным что эта функция ничего не переписывает, можно быстро эти консты расставить (хотя наверное это моя делетанщина).
Считается что конст надо пихать просто везде куда не попадая))) чтобы потом можно было проще чего-то проверить.
Нужна ли проверка CheckPointer()!=POINTER_INVALID ?
А почему нет.... сделать один bool Check(<шаблон> &T) { retun CheckPointer(T)!=POINTER_INVALID } по идее компилятор должен все это максимально опитмизировать до наиболее простого вида. что то типо (nc!=NULL) и получиться в конце концов. Да и смотреться симпатичнее будет.
Это из оперы что быстрее
Ну я почти ничего не менял
Это полностью Ваш код
Вроде как один в один с твоим, только букв поменьше. Так-то дело вкуса, кому как больше нравится, но лишнюю переменную я убрал (скорее всего ее и компилятор бы убрал в рамках оптимизации).
По поводу моей проверки !node. По хорошему ее надо заменить на CheckPointer(node)==POINTER_INVALID, но это оверхед, вызов функции. Даже если заинлайнить, это все равно, как минимум, разыменование и проверка флага состояния. Если Compare методы только библиотека или конкретная, тобой написанная прога использовать будут, то лучше !node и по коду следить, что бы невалидный указатель не подать. Если лень за указателями следить или это библиотека для недоджунов, то тогда только CheckPointer(node)==POINTER_INVALID.
Если ты уберешь, выделенный тобой, спецификатор const, то ты не сможешь вызвать эти методы из константного объекта.
долго-ж вкладка открыта у меня была
мде походу 4 года учебы в строительном техникуме мне не прибавили знания (грамотность объяснения отстает в хлам)
вариант без конста т.к. у базового класса нету ссылки на входные параметры то тоже будет работать корректно, хотя не очень грамотный такой стиль
Тоже вариантик все тот же код
Он же с констами