ADirks писал(а) 04. Мая 2008 :: 08:48:Залил в модуль icpp валидацию итераторов. В 2.5 пока не стану заливать (до релиза как минимум), а то может ещё боком выйти. Сделано тупенько, через поле Version в индексе. Всё в общем-то нормально, тесты проходят. Кроме одного: тестСохранениеИтератора - после восстановления итератора у них получается конфликт версий, потому что фильтр менялся. И что-то я не знаю, чего тут делать. Может, ну их нафик вообще, эти методы? В свете CVTExtProvider::FindRow(CVTExtIterator* pIterator, int nRowIndex)?
Леша, а надо ли при установке фильтра вырубать существующие итераторы?
Я понимаю, сейчас, в текущей организации ИТ, это имеет смысл.
Но если мыслить в терминах независимых итераторов /фильтров - то не нужно этого делать.
Завтра я захочу иметь несколько итераторов с разными фильтрами - у меня должна быть возможность их использования.
Цитата:Про CVTExtProvider::FindRow(CVTExtIterator* pIterator, int nRowIndex). Думаю, самым правильным будет добавить такой метод в сам итератор, а не исполнять акробатических трюков без страховки под куполом цирка.
Да, полностью согласен, это плохие методы.
Но FindRow - это не замена.
Этот метод имеет сложность от log(N) до N, а нужна возможность использования нескольких независимых итераторов, причем с затратами 0 (ноль).
Цитата:CVTExtProvider::FindRow(CVTExtIterator* pIterator, int nRowIndex) мальца поправил, тест прилагается.
А где поправил, не нашел пока...
Или ты хотел сказать метод Last()?
nCurrentRow = pCurrentNode->ID;
if( pCurrentNode->ArrayEqualIDs )
IndexInNode = pCurrentNode->ArrayEqualIDs->size();
else
IndexInNode = 0;
Леш, вот здесь, ты уверен, что nCurrentRow не должен сдвигаться на последнюю строку равных значений?
Т.е. точно должно отличаться от GoToNode_Backward()?
Прости мою дотошность, но нельзя ли небольшой ликбез?