C++ вернуть итератор.

разрешаю...

И правда нужно только аргументы шаблона вродеб

Верни свой итерабельный интерфейс. Возвращать итераторы STL - дурная практика.

http://cplusplus.com/reference/std/iterator/

Итератор и так скрывает подробности реализации.

std::map::iterator != std::vector::iterator, хотя интерфейсы у них одинаковы.

virtual std::iterator<std::wstring, DocumentInfo> getDocInfo() = 0; virtual std::iterator<std::wstring> getFiles() = 0; Требует второй аргумент во втором случае. Как все таки это сделать то?

Еще я свой итерабельный интерфейс возвращать буду. В Яве же можно просто вернуть итератор и все тут. А в С++ походу нельзя.

можно, но нужно будет задать свой итератор, а не брать готовый от map или vector

Охохо, еще и свой итератор. В Яве все просто а тут.

да тут не так, так что решать тебе что использовать ....

Т.е. чтобы клиент не знал std::map там или std::vector?

1. Пусть клиент знает что ты возвращаешь какой-нибудь FooIterator, а в классе сделаешь typedef с итератора реализации на FooIterator.

2. Пусть клиент auto использует :-)

Говнокоду привет! Читать про граничные интерфейсы.

А в С++ походу нельзя.

В С++ можно всё, дело лишь в библиотеке, stl не излучших, увы.

Пусть клиент auto использует :-)

не подходит для компиляторов не поддерживающие С++11 (

но можно прикрутить мув из буста

мув из буста

Ты хохел сказать BOOST_AUTO?

да, я чо-то сижу сплю целый день

хотя тащить его наверное нет смысла даже при помощи bcp

Если только его тащить - то нет смысла, проще typedef'ом абстрагироваться от типа итератора реализации.

В ASL есть adobe::any_iterator: http://stlab.adobe.com/classadobe_1_1any__iterator.html

Можно взять его или написать такой же.

Вот еще: http://www.rsdn.ru/forum/cpp.applied/2188115.all.aspx

Неужели ещё остались компиляторы, не поддерживающие auto/decltype? Откопали обратно уже чтоли?

ТСу: способа аж целых 3.

• auto
• typedef итератора внутренней коллекции - по результату полностью идентично яве
• унаследовать класс от итератора внутренней коллекции и возвращать только его, это даже лучше чем typedef более строгой проверкой типов, но придётся описать конструкторы

В Яве все просто а тут.

здесь тебе не «яхве», а то что ты пытаешься сделать пахнет как косяк какой-то архитектурный

с криокамеры что-ли?

4.2

Последняя версия компилятора gcc без C++0x. Вижуал студио в 2010 тоже имеет auto. Наркоманы, использующие до сих пор 2003-ю студию (а такие есть) пусть оперируют указателями, ни к чему им итераторы.

Неужели ещё остались компиляторы, не поддерживающие auto/decltype?

nvcc, хвостом его по голове.

Вижуал студио в 2010 тоже имеет auto

2008?

Нет.

I know)

плюс возьму тот же NDK от гугла или ББ

так что не гони)

Можно из функции - члена класса в С++ вернуть итератор так чтобы сокрыть подробности внутренней реализации коллекции. Т.е. чтобы клиент не знал std::map там или std::vector?

скажи, ты и правда не понимаешь что ты здесь написал дичь?

В книге head first это описано как паттерн а не как косяк. Хотя там ява.

сейчас меня закидают ссаными тряпками

void *

Толсто!

В книге head first это описано как паттерн а не как косяк. Хотя там ява.

да, но тогда это косяк уже самой книги :)

а если серьёзно что за задача то?

В книге head first это описано как паттерн а не как косяк. Хотя там ява.

Ты же понимаешь, что ява и плюсы - очень разные языки. Что русскому хорошо, то немцу - смерть.

Есть класс который собирает сообщение для передачи по сети: некоторые файлы шифрует, некоторые еще подписывает и все в итоге зипует. И есть классы котрые хранят список файлов и инфу о данных файлах. Инфа нужна для описания сообщения и для того чтобы знать какой файл шифровать и т.д. Вдобавок эти классы генерируют дополнительно служебные файлы которые тоже посылаются вместе с сообщением. Логика там разная. поэтому несколько классов, которые собственно и возвращают итератор файлов и итератор информации о данных файлах для класса-упаковщика. Сделал в итоге итератор свой - обертку над stl-овским который просто имеет методы next, hasNext (как в ява). Правда совсем абстрагироваться от реализации не получилось: клиент знает что там за коллекция. Пока ладно, в принципе std::map подходит для всех классов-генераторов. Прочитал заодно слайды Александреску iterator must go. Там как раз это описано все.

Есть всеж таки и минусы у stl. Тот же Александреску например так считает.

visitor спасёт отца русской демократии

Александреску, например, толстый неосилятор :) и не потому что стлкака, а потому что дникомуненужен

У нас в компании используются велосипедные ява-стайл итераторы, лучшего решения пока не вижу. Возвращать raw STL container/iterator во внешний мир - это плохо для кармы, б-женька накажет.

Да, александресковские Ranges - это именно то, что нужно. Мне только название не нравится: никакие это не Ranges, а именно что Iterator, в GoF'овском смысле этого термина.