Слудующая проблема
Изначально создаю обобщающий итератор, который определяет методы:\

Также создаю специализированный итератор

при компиляции выходит сообщение

Как можно это заставить работать?

По-моему, это плохая идея. Уж если хочется java like iterator, то и делай до конца, как в жабе: вместо перегрузки оператора сделай метод next.

Никак. Абстрактные классы нельзя инстанциировать :) Возвращай указатель/ссылку.

Вообще то итераторы предполагают использование template( хотя бы по Вашему типу Еntry), a шаблоны с virtual не дружат. Если хотите - делайте специализацию шаблонов, virtual тут не при чем.
А если хотите дальше заниматься глупостью, ибо иначе написанное выше назвать трудно, operator++(int) должен возвращать ссылку на объект, так что добавьте &, и будет Вам щастье:):)

Так дела в том что я инстанциирую не абстрактый класс. Смотри ниже

Это как раз и ведёт к выше упомянутой выдаче на экран.

Я тут с Вами не очень согласен. У постфикс-оператора это просто не возможно. Он возвращает копию объекта. Смотрите ниже пример из инета.

Дело в том что идея состоит в том траверзировать контейнер с помощью разных итераторов в основу обобщающего итератора (абстрактного).
Т. е. все классы итераторы (специализированные или нет) это внутренние классы контейнера.
Самая главная проблема наверное и состоит в использовании template и virtual. Если использовать похожиую конструкцию без template, то всё вполне вероятно зароботает.
Но меня интересует именно тот факт - возможно это или нет.

Ага, только вот вернуть ты хочешь копию абстрактного класса :) А для того, чтобы вернуть копию абстрактного класса его (абстрактный класс) надо создать :) А этого делать нельзя :D

Вы правы. Если использовать только префикс-часть, то компайлер не выдаёт ошибок.
Получается что для постфикс инкремент в СИ++ этот вариант невозможен.

Это что за бред вообще? Курить стандарт С++ до полного прояснения. Чем не устроили обычные итераторы С++?

Не надо next. Он объединяет функции инкрементирования и возврата элемента, что делает многие алгоритмы более сложными.

Тут не о бреде речь. Хочу немного ознaкомиться с програмированием на СТЛ.
Некоторые вещи меня просто интересуют, т. к. у меня ещё не хватает навыков.

stl весъ на шаблонах :)

зато он решает проблему автора :)

С какой стати постфикс-оператор невозможен???
Самое главное - итераторы реализуются шаблонами, иногда их специализируют, но не виртуальными классами. Это же на java, где кишки тянутся через весь язык до класса Object, зато нет шаблонов.

Спасибо. Меня как раз возможность реализации и интересовала. Будем считать что вопрос исчерпан.

Не вполне. Курить здесь - http://www.boost.org/doc/libs/1_50_0/libs/iterator/doc/index.html
А вообще главное умение для программиста - умение гуглить. Например так: https://www.google.com/search?hl=en&q=c%2B%2B+iterator+site%3Astackoverflow.com

Что-то говорит мне, что итераторы с шаблонами никак не связаны :) Просто потому что шаблон нужен для более высокого уровня абстракции, а итератор для перебора элементов.
Так например FindFirstFile и FindNextFile - вполне себе итератор, но шаблонами там и не пахнет :)
Очевидно, что реалицовывать итератор можно и без шаблонов. Например:

как видишь, итератор есть, а шаблонов нет :)

итератор есть
-----
Где? Я не вижу ни одной возможности получить этот итератор...

+100:)
Как у Ходжи Насреддина: даже если 100 раз сказать халва, во рту слаще не станет...

кстати, итератор, возвращающий void*, сам по себе весьма занятная конструкция

По поводу FindxxxFile рассмешил. Специализированная операция прохода по списку и итератор. Ню ню. А как без шаблонов реализовать универсальный итератор на c++, чтоб им можно было дереференсировать любые объекты, поделись пожалуйста опытом. reinterpret_cast<MySuperPuperClass>( void* ) рулит?

void* pUniversal;
слово даю на отсечение: итерирует всё!

Но через жопу.

через ж-пу разименование. а итерирование ничем не хуже.

А при итерации по массиву через что -жопу или тухес?
{}

а хочь чез что. разници то нет

Не понял, в чем проблема?

И что? Оно работает? Или все же абстрактный класс не инстанцируется?

Задача итетатора - пройти по элементам списка.

Ну тогда уж dinamic_cast, чтобы проверить на NULL :D
В любом случае, если не хочешь иметь дело с void *, то используй структуру классов. В чем проблема?
Кроме того, шаблонами хорошо описывать алгоритмы без привязки к типам данных, однако при использовании шаблонов ты все равно должен задать тип данных. Стл-список на void * накойже валинный как и на любом другом типе данных. А если у тебя есть структура классов, то ты легко можешь реализовать итератор на этих классах БЕЗ использования шаблонов.
Я не говорю о том насколько это хорошо или плохо (зачем изобретать велосипед, когда есть стл? :D), но все таки итераторы (по своему смыслу) вполне себе могут существовать и без шаблонов.

Работает конечно :) Тут же возвращается указатель на абстрактный класс, а не сам абстрактный класс ;)

Тут же возвращается указатель на
-----
Это Я, разумеется, вижу...
Чего Я не вижу - где инстанцируется то, что должно быть возвращено...
Ну и, должно быть очевидно, что писать руками имплементацию итератора каждый раз нет никакого желания...

return this; там стоит. Это конечно дебилизм - приравнивать контейнер к итератору, но инстанция там есть.

Это было очевидно Абрахамсу уже 10 лет назад, почему он и написал итератор адаптор. На который я выше давал ссылку.

return this; там стоит.
------
Это Я вижу.
Я не вижу имплементации абстрактных методов. Писать их нет желания, а без них этот this бессмысленнен.
я выше давал ссылку
-----
Это не совсем ко мне - это к изобретателям сложных имплементаций давно наработанных решений.

>>Задача итетатора - пройти по элементам списка.
Задача итератора - пройтись по ЛЮБОМУ контейнеру, включая вектор и массив
>>Ну тогда уж dinamic_cast, чтобы проверить на NULL :D
А если у класса нет виртуальных функций, то компилятор шлет такому dynamic_cast большой пианэрский привет
>>В любом случае, если не хочешь иметь дело с void *, то используй структуру классов. В чем проблема?
Извини конечно, но какого ...уя использовать малопривлекательное решение от Явы? Как быть со встроенными типами? Писать оболочки вокруг int/char/float?

мне лично совершенно не понятно ЗАЧЕМ нужна такая вот универсальность?
Универсальность чаще всего идет в конфликте с производительностью или требуемым рессурсам.
Наоборот: каждому контейнеру свой итератор - специализированыый и быстрый и наиболее лучше подходящий.
Ну разве то ради забавы да спортивного интереса...

Интерфейс итераторов STL и с++-98 абсолютно универсален и на производительность влияет только реализация. Не нужна универсальность - на кой тогда нужны итераторы вообще? Пиши от руки списки, деревья и прочая, и будет тебе щастье.

а чем итерировать без них то?
как раз там несколько специализированных итераторов для разных контейнеров.
к примеру vector::iterator имеет operator+=(int N), и реализация его считай мгновенная
а list::iterator такового не имеет, в виду того что реализовать его мгновенно (т.е. без перебора N раз) невозможно.

Ну да, лучше как в жабе, где список возвращает итератор случайного доступа...

Вы наверное имели ввиду operator++.
'Мгновенная' реализация, т.е. О(1), заслуга вовсе не итератора, а структуры данных, выбранной для реализации вектора.
Советую немного почитать про STL.

Ты уж прости меня, но писать всю эту требуху я не буду :) Ибо не смысла :D

кэп! :)

Задача (прикладная) пройтись по элементам конкретного контейнера, о котором известно ВСЕ уже на стадии написания кода.
А "пройтись по ЛЮБОМУ" контейнеру - это АБСТРАКЦИЯ, и разрешается, например, шаблонами. А можно эту абвстракцию разрешить и другим способом - например унаследовав все типы данных от CObject. Итератор будет, а шаблонов нет.

Ну так можно ж сделать виртуальную функцию... в чем проблема?

Ты что пытаешься мне доказать? Что стл рулит? :) Я это и так знаю и использую стл когда мне это нужно :) И своих итераторов не пишу :)
Но ведь это не означает, что нельзя написать итератор БЕЗ шаблона? Или как?

А как поступим с примитивными типами данных?

Конечно можно. Но только в качестве примера, типа так делать ни в коем случае нинада :-)

Уверен, что для примитивов тожно можено накалякать итератор :)

Ну вот и славненько :)
Следовательно высказывание

опровергнуто.
ЧТД.

Это уже другая тема :D

нет, я имел ввиду +=
речь шла об универсальном итераторе для всех конрейнеров с любой структурой данных.
советую почитать тему.

насчет оператора я погорячился :-)

>>Задача (прикладная) пройтись по элементам конкретного контейнера, о котором известно ВСЕ уже на стадии написания кода.
Да ну? А как же быть с std::copy и практически всем <algorithm>?
>>Ну так можно ж сделать виртуальную функцию... в чем проблема?
Ни в чем, но зачем ? Ради dynamic_cast'а? Кстати, если ты уж озабочен производительностью, то dynamic_cast вещь довольно тяжеловесная, я уж не говорю, что :(
>>А можно эту абвстракцию разрешить и другим способом - например унаследовав все типы данных от CObject.
Привет из жабы... Осталось только как в жабе написать классы-оболочки вокруг встроенных типов( по другому и не получится )...
Самое главное, то что вы вдвоем впариваете, в лучшем случае может ( через анус и тухес ) работать со списками и деревьями, но пока что я не услышал ответа на вопрос: как итератор, не заточенный под конкретный тип дереференцируемого объекта, можно без шаблонов реализовать для векторов и массивов?
Короче, резюме:
Ты мне хочешь доказать, что умеешь ковырять в носу пяткой? Можно и так, согласен, но не надо пропагандировать это как здоровый образ жизни.

Это где вы такое определение видели? Вики говорит: "an iterator is an object that enables a programmer to traverse a container. "

Хотите задачу "из жизни". Есть контейнер, реализованный то ли как вектор, то ли лист. Он содержит пойнтеры на абстрактный CChannel, из который наследуется DVB-S Channel, DVB-T Channel, DVB-C Channel, etc (спутник, наземный сигнал, кабель, и т.д.)
По этому листу надо пройтись огромной кучей способов: последовательно от одного к другому, последовательно но пропустить не совпадающие каналы (для DVB-S должны совпадать bandwidth и поляризация - не суть важно), перепрыгнуть на величину графической страницы, перепрыгнуть но только на совпадающий канал, и т.д.
В этой задаче то, что предложил ТС и то что поддерживает "Программист" это то, что и нужно и ты не обойдешся здесь решениями из STL, и ни кто здесь не говорит об универсальном итераторе для встроенных типов, то есть "каждому овощу - свою корзину!"

Первое впечатление: кривость дизайна. Если у CChannel есть интерфейс (а он должен быть), значит, информация о конкретных типах неважна. Следовательно, вполне достаточно стандартных итераторов.

А никто и не говорит об конкретных типах: CChannel имеет какои нибудь bool IsCompatibly( CChannel& ) =0. Только второй итератор должен пропускать, те элементы которые ответят false, а первый итератор об этом и не спрашивает. А четверый ещё и должен подсчитывать, а сколько элементов он не пропустил.

Это все можно сделать алгоритмами.
Впрочем, почему бы и нет?