Залил в модуль icpp валидацию итераторов. В 2.5  пока не стану заливать (до релиза как минимум), а то может ещё боком выйти. Сделано тупенько, через поле Version в индексе.  Всё в общем-то нормально, тесты проходят. Кроме одного: тестСохранениеИтератора - после восстановления итератора у них получается конфликт версий, потому что фильтр менялся.  И что-то я не знаю, чего тут делать. Может, ну их нафик вообще, эти методы? В свете  CVTExtProvider::FindRow(CVTExtIterator* pIterator, int nRowIndex)?

Про  CVTExtProvider::FindRow(CVTExtIterator* pIterator, int nRowIndex).  Думаю, самым правильным будет добавить такой метод в сам итератор, а не исполнять акробатических трюков без страховки под куполом цирка.

CVTExtProvider::FindRow(CVTExtIterator* pIterator, int nRowIndex)  мальца поправил, тест прилагается.

Цитата:
Да, я имел в виду именно текущую реализацию. Для отдельно живущих итераторов это ни к чему.

Цитата:
Если итераторы будут существовать как отдельные объекты, то такая операция и не потребуется.  Но! А как насчёт  CVTExtProvider::FindRow()?    Оно же как так и работает сейчас. Кстати, может всё-таки не по номеру строки позиционироваться, а по уникальному ключу, как провайдере для ODBC?

ADirks писал(а) 04. Мая 2008 :: 10:48:

Леш, а давай все-таки вытащим итераторы (и, видимо, фильтры) в виде пользовательских объектов.
Это тема благодарная, точно говорю.

Цитата:

Ну, поскольку сейчас ты сделал проверку валидности итератора, я могу хранить итератор в строках ТП, отказавшись для большинства случаев от позиционирования по номеру строки.
Но в случае инвалидации итератора, все равно нужен FindRow();

Позиционирование по номеру строки сделано по соображениям компромисса между эффективностью и гибкостью.
Я решил разрешить использование неуникальных индексов - и предоставить разработчику возможность самому управлять сложностью алгоритма позиционирования.
Для уникальных индексов сложность O(n), для простого неиндексировнного индекса сложность const, для неуникальных индексов - от O(n) до N.

Была еще идея вместо номеров строк использовать значения уже строго уникального опорного индекса - пока обдумываю, надо ли.
Там сложность позиционирования выше, чем при позиционирование на номер строки, но по другому будет работать восстановление итератора после удаления строк.
Но все равно все сводится к определению номеру строки по опорному индексу и FindRow() на эту строку.

Т.е. FindRow() это такая довольно универсальная и полезная штука.

Цитата:

Уф. Все, теперь я спокоен. В двух словах ты описал суть процесса разработки.  

PVR писал(а) 04. Мая 2008 :: 20:22:

Не, к одному индексу в одной ИТ можно будет прицепить несколько независимых итераторов.

Это просто необходимо в некоторых рекурсивных алгоритмах.
Например, есть индекс "контрагент,номенклатура, день" и показатель "количество".
Если мы сами подсчитать итоги, мы должны

0. Построить индекс "Контрагент,Номенклатура"
1. Выбрать уникальных контрагентов
2. Для каждого контрагента из п.1 зафиксировать подмножество ("Контрагент")
3. Для каждого подмножества из п.2 выбрать уникальную номенклатуру
  4. Для каждой номенклатуры из п.3 зафиксировать подмножество ("Контрагент, Номенклатура")
  5. Для каждого подмножества из п.4 подсчитать Итог("Количество")
6. Для каждого подмножества из п.2 подсчитать Итог("Количество") (здесь можно считать только групповые итоги из п.5)
 

Здесь нужно 2 итератора с разными фильтрами по одному индексу.
Конечно, в таких случаях можно строить несколько индексов, но это лишние затраты, без которых можно обойтись.

Ну и в самом языке удобнее (и быстрее) было бы использование итераторов.

_ит =_т.СоздатьИтератор("Контрагенты"); // итератор по индексу
_ит.ВНачало();
Пока _ит.СледующаяСтрока() // нет необходимости повторно ресолвить индекс по имени + меньше возможностей для ошибки
    Сообщить(_ит.Контрагент); // нет понятия "текущая строка" для всей таблицы, есть понятие "независимая текущая позиция" для итератора
КонецЦикла;
 

И т.д.

kms
Спасибо, за объяснения , хотим-хотим-хотим 

kms писал(а) 04. Мая 2008 :: 17:29:

Дык! Вытащим конечно! Я сам был бы сильно благодарен этой теме 

lustin

remove() - невозможно (в твоей интерпретации), не нужно (в смысле удаления строки из ИТ)
hasNext() - не нужно; если потребуется, реализуется через Next() /Previous() без проблем

Вообще, итератор - это по сути просто указатель на строку ИТ, со своей логикой обхода ИТ по соответствующему индексу.

Итератор ИТ - двунаправленный, который также с малыми затратами может быть спозиционирован на первую и на последнюю строку выборки.
Скорее всего, будет добавлена возможность позиционирования на произвольный номер строки, но это не превращает итератор в итератор с произвольным доступом, ибо как я уже выше отметил, обеспечить const время доступа к произвольной строке он не может.

ADirks писал(а) 05. Мая 2008 :: 09:42:

Исправил, но как же тяжко такие проблемы диагностировать!
Намного тяжелее, кстати, чем простое повторное освобождение памяти, например.