P>std::list<int> A;
P>...
P>int a = A[i];
P>...
P>std::list<int>::const_iterator i = A ????
P>
P>С уважением, Павел.
ну либо сам делай инкремент нужное число раз, либо используй std::advance. вообще список — контейнер не подходящий для такого доступа.
и список не имеет оператора [].
Of course, the code must be complete enough to compile and link.
P>>std::list<int> A;
P>>...
P>>int a = A[i];
P>>...
P>>std::list<int>::const_iterator i = A ????
P>>
P>>С уважением, Павел.
L_L>ну либо сам делай инкремент нужное число раз, либо используй std::advance. вообще список — контейнер не подходящий для такого доступа. L_L>и список не имеет оператора [].
Да, понял, я поспешил!
а для deque такое возможно?
Если хочешь выиграть в лотерею, то купи, хотя-бы лотерейный билет. (В.Мэгре)
Здравствуйте, Pavel515, Вы писали:
P>Здравствуйте, Lorenzo_LAMAS, Вы писали:
P>>>Да, понял, я поспешил!
P>>>а для deque такое возможно?
L_L>>возможно и для дек. но опять же, вряд ли разумно использовать advance. для дек есть оператор [].
P>оператор [] возвращает const_reference, а нужен именно const_iterator и advance в общем-то выход, если не создавать новый класс или шаблон
вообще я погорячился — для дек итератора адванс — самое оно, так как там не будет кучи инкрементов а будет + (+=).
можешь вместо адванса сам использовать оператор +=
Of course, the code must be complete enough to compile and link.
Здравствуйте, Lorenzo_LAMAS, Вы писали:
L_L>Здравствуйте, Pavel515, Вы писали:
P>>Здравствуйте, Lorenzo_LAMAS, Вы писали:
P>>>>Да, понял, я поспешил!
P>>>>а для deque такое возможно?
L_L>>>возможно и для дек. но опять же, вряд ли разумно использовать advance. для дек есть оператор [].
P>>оператор [] возвращает const_reference, а нужен именно const_iterator и advance в общем-то выход, если не создавать новый класс или шаблон
L_L>вообще я погорячился — для дек итератора адванс — самое оно, так как там не будет кучи инкрементов а будет + (+=). L_L>можешь вместо адванса сам использовать оператор +=
Спасибо!
Если хочешь выиграть в лотерею, то купи, хотя-бы лотерейный билет. (В.Мэгре)
Здравствуйте, Pavel515, Вы писали:
P>Доброго времени суток!
P>Есть ли возможность в stl::list доступиться к i-тому итератору
P>
P>std::list<int> A;
P>...
P>int a = A[i];
P>...
P>std::list<int>::const_iterator i = A ????
P>
P>С уважением, Павел.
Я для подобных целей использую класс-обертку, содержащий составной контейнер из связки vector+list или map+list
Доступ к элементам листа осуществляется по индексу или ключу, содержащимися в vector'e или map'e
Здравствуйте, Molchalnik, Вы писали:
M>Не нравится, что есть — наследуйся и задавай operator[] как тебе нравится
От него контейнеров нельзя наследоваться.
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, Molchalnik, Вы писали:
M>>Не нравится, что есть — наследуйся и задавай operator[] как тебе нравится K>От него контейнеров нельзя наследоваться.
можно вполне, если знаешь/понимаешь, что делаешь
Of course, the code must be complete enough to compile and link.
Здравствуйте, Kernan, Вы писали:
M>>Не нравится, что есть — наследуйся и задавай operator[] как тебе нравится K>От него контейнеров нельзя наследоваться.
Можно. И такие примеры даже Страуструп в своих книжках показывал.
Другое дело что в этом конкретном случае наследование скорей всего не нужно, как и std::list.
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, Molchalnik, Вы писали:
M>>Не нравится, что есть — наследуйся и задавай operator[] как тебе нравится K>От него контейнеров нельзя наследоваться.
Имхо, нельзя использовать материал без анализа. Кто-то когда-то написал, что нельзя наследовать контейнеры stl, и толпы леммингов от программирования побежали жечь на костре всех, кто делает иначе.
Я не согласен с фразой "От контейнеров stl нельзя наследовать класс". Если бы даже я ляпнул что-то такое, то я бы сформулировал это иначе: "В общем случае наследование от невиртуальной имплементации (например, контейнера stl) дурная практика". При этом вроде бы как мы говорим одно и тоже, но я прав, а ты — нет.
Почему? Потому что конечная цель кодера (а не быдлолемминга) — быстрый конечный результат без проблем в будущем. Один перегруженный оператор — это оно. Это быстрый конечный результат без проблем в будущем. В голове должна быть чёткая целевая функция.
Если тебе нужно перегрузить квадратные скобки у list, и ты не планируешь развивать свой класс дальше, то — вперёд. Но если вдруг входе развития ты добавишь к этому классу ещё пару перегруженных функций, то вместо добавления третьей-четвёртой перегруженной функции лучше отрефакторить твоё чудо в сторону обёртки над list.
И нужно чётко понимать, что наследник stl нельзя удалять через указатель на базовый класс.
Иногда до смешного грустно наблюдать, как разумные идеи в руках некоторых коллег превращаются в религиозные догмы, применяемые без рассуждения и с последующими сожжениями еретиков.
