Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Мдяя... Как с const у людей все запущено-то(((
Для понимания методов со спецификатором const
А теперь сделайте
//int Get() const {return i;}
, а потом наоборот:
// int Get() {return 2*i;}
)))
Тоже вариантик все тот же код
Он же с констами
А ты уверен, что на вход
всегда подашь
, что бы без проверки писать
?
вариант без конста т.к. у базового класса нету ссылки на входные параметры то тоже будет работать корректно, хотя не очень грамотный такой стиль
Так не годится. В Compare сигнатуру менять нельзя. Она в основном для того и нужна, чтобы работала штатная входящая в СБ сортировка методом QuickSort.
Поменяете сигнатуру, будет не переопределение вирт. функции, а перегрузка, и будет вызываться метод базового класса CObject, где return 0;
Ну конечно решается обертками (декорированием) к контейнерам, но зачем эти лишние движения, или тогда уж не применять СБ а всё с нуля писать.
Вроде как один в один с твоим, только букв поменьше. Так-то дело вкуса, кому как больше нравится, но лишнюю переменную я убрал (скорее всего ее и компилятор бы убрал в рамках оптимизации).
По поводу моей проверки !node. По хорошему ее надо заменить на CheckPointer(node)==POINTER_INVALID, но это оверхед, вызов функции. Даже если заинлайнить, это все равно, как минимум, разыменование и проверка флага состояния. Если Compare методы только библиотека или конкретная, тобой написанная прога использовать будут, то лучше !node и по коду следить, что бы невалидный указатель не подать. Если лень за указателями следить или это библиотека для недоджунов, то тогда только CheckPointer(node)==POINTER_INVALID.
Если ты уберешь, выделенный тобой, спецификатор const, то ты не сможешь вызвать эти методы из константного объекта.
UPD: выделенную проверку можно убрать, так как она есть в вызываемых методах.
Владимир, вот как раз в данном случае CheckPointer излишний же. dynamic_cast вернёт NULL при любом неудачном касте, в т.ч. если указатель битый. Если не прав, поправьте. Тестил давно, тест 5 секунд)
Механизм CheckPointer работы какой ( выражаюсь простыми словами, в низкоуровневых терминах не силён) - он смотрит по указателю что за объект, динамический или статический, если получить информацию не удаётся, значит POINTER_INVALID. Это может быть в каком случае, если динамический объект удален, других ситуаций не знаю, ну или закастили мусор к указателю, но это компилятор должен проверять вроде,если лазейки не найти.
а dynamic_cast делает тоже самое, ещё и проверяя, можно ли привести этот указатель к требуемому типу, т.е. является ли он указателем этого типа, или дочернего класса.
Если указатель битый, то dynamic_cast не удастся определить ничего, и он возвращает NULL.
Именно поэтому я и не использовал CheckPointer. Хотя обычно везде эту проверку применяю от греха. Всё таки найти ошибку в ПО, которое не упало, чуть легче вроде бы)
А насчёт не-const - теоретически можно иметь метод типа GetRatingByAnyFormula() { m_rating01=Formula01(); return m_rating01;}
неудобно если его так сразу не использовать в сортировке, т.е. в любом случае сначала рейтинг считать, а потом сортировку по нему вызывать. Ну или как уже сказано писать свою СБ с нуля)
Так не годится. В Compare сигнатуру менять нельзя. Она в основном для того и нужна, чтобы работала штатная входящая в СБ сортировка методом QuickSort.
Поменяете сигнатуру, будет не переопределение вирт. функции, а перегрузка, и будет вызываться метод базового класса CObject, где return 0;
Ну конечно решается обертками (декорированием) к контейнерам, но зачем эти лишние движения, или тогда уж не применять СБ а всё с нуля писать.
Самый правильный способ все-ж на мкл не написать
Владимир, вот как раз в данном случае CheckPointer излишний же. dynamic_cast вернёт NULL при любом неудачном касте, в т.ч. если указатель битый. Если не прав, поправьте. Тестил давно, тест 5 секунд)
Механизм CheckPointer работы какой ( выражаюсь простыми словами, в низкоуровневых терминах не силён) - он смотрит по указателю что за объект, динамический или статический, если получить информацию не удаётся, значит POINTER_INVALID. Это может быть в каком случае, если динамический объект удален, других ситуаций не знаю, ну или закастили мусор к указателю, но это компилятор должен проверять вроде,если лазейки не найти.
а dynamic_cast делает тоже самое, ещё и проверяя, можно ли привести этот указатель к требуемому типу, т.е. является ли он указателем этого типа, или дочернего класса.
Если указатель битый, то dynamic_cast не удастся определить ничего, и он возвращает NULL.
Именно поэтому я и не использовал CheckPointer. Хотя обычно везде эту проверку применяю от греха. Всё таки найти ошибку в ПО, которое не упало, чуть легче вроде бы)
А насчёт не-const - теоретически можно иметь метод типа GetRatingByAnyFormula() { m_rating01=Formula01(); return m_rating01;}
неудобно если его так сразу не использовать в сортировке, т.е. в любом случае сначала рейтинг считать, а потом сортировку по нему вызывать. Ну или как уже сказано писать свою СБ с нуля)
По поводу моей проверки !node. По хорошему ее надо заменить на CheckPointer(node)==POINTER_INVALID, но это оверхед, вызов функции.
Проблема будет не в оверхеде, в том, что битый указатель изменит логику программу. Т.е. вместо того, чтобы выявить проблему, ты закопаешь её ещё глубже.
CheckPointer следует применять лишь для отладочных целей, ну либо в качестве реализации слабого указателя.
1. Не спорю, но я то говорил о том что НЕ ТРЕБУЕТСЯ CheckPointer (даже для недоджунов) , т.к. dynamic_cast НЕ может вернуть какой-то НЕвалидный указатель, только NULL.
2. Даже интересно, но не могу сходу придумать пример, как можно получить невалидный указатель, кроме того как убить динамический объект, ну или в процессе работы напрямую память "запачкать".
Полагаю такие способы ещё есть, но все они скорее всего лежат в плоскости обхода проверок компилятора.
3,4 Согласен
P.S.
Видимо я заблуждался насчёт 1-го. Тест говорит об обратном. Значит показалось)
можно ли статический массив объявить в секции класса public, а инициализировать в конструкторе? (как указано ниже) (или только поэлементно?)
Можно инициализировать локальный массив и выполнить ArrayCopy в соответствующее массив-поле: