iteratore "generico" in C++

Question

ho:

void add_all_msgs(std::deque<Message>::iterator &iter); 

Come posso fare che la funzione "generico", in modo che possa prendere qualsiasi tipo di inputiterators? Non mi interessa davvero se stia iterando un deque, un vettore o qualcos'altro, fintanto che l'iteratore sta iterando Message's. - Questo è possibile in C++?

Answer 1

template<class InputIterator> 
void add_all_msgs(InputIterator iter); 

Usage:

std::deque<Message> deq; 
add_all_msgs(deq.begin()); 

Answer 2

#include <deque> 
#include <vector> 
#include <list> 
#include <string> 
using namespace std; 

template<typename T> 
void add_all_msgs(T &iter) 
{ 

} 

int _tmain(int argc, _TCHAR* argv[]) 
{ 
    std::deque<string>::iterator it1; 
    std::vector<string>::iterator it2; 
    std::list<string>::iterator it3; 

    add_all_msgs(it1); 
    add_all_msgs(it2); 
    add_all_msgs(it3); 


    return 0; 
} 

Answer 3

template <typename Iterator> 
void add_all_messages(Iterator first, Iterator last) 

utilizzo:

vector<message> v; 
add_all_messages(v.begin(), v.end()); 

È necessario specificare alla fine, altrimenti non si sa quando smettere! Ti dà anche la flessibilità di aggiungere solo un subrange di un contenitore.

Answer 4

Se si desidera che il compilatore verifichi che l'iteratore si riferisca effettivamente agli oggetti Message, è possibile utilizzare una tecnica simile alla seguente.

template <typename InputIterator, typename ValueType> 
struct AddAllMessages { }; 

template <typename InputIterator> 
struct AddAllMessages<InputIterator, Message> { 
    static void execute(const InputIterator &it) { 
    // ... 
    } 
}; 

template <typename InputIterator> 
void add_all_msgs(const InputIterator &it) { 
    AddAllMessages<InputIterator, 
       typename std::iterator_traits<InputIterator>::value_type>::execute(it); 
} 

Answer 5

leggermente più semplice che quanto sopra (in quanto sfrutta le librerie esistenti):

#include <boost/static_assert.hpp> // or use C++0x static_assert 
#include <boost/type_traits/is_same.hpp> 

template <typename InputIterator> 
void add_all_msgs(InputIterator it) { 
    BOOST_STATIC_ASSERT((boost::is_same< 
     typename std::iterator_traits<InputIterator>::value_type, 
     Message>::value)); 
    // ... 

Answer 6

Se non si desidera templatize la funzione add_all_msgs, è possibile utilizzare adobe::any_iterator:

typedef adobe::any_iterator<Message, std::input_iterator_tag> any_message_iterator; 
void add_all_msgs(any_message_iterator begin, any_message_iterator end); 

Answer 7

È difficile avere un polimorfismo dinamico con gli iteratori in stile C++. operator++(int) restituisce per valore, che afaik è intrattabile: non è possibile avere una funzione membro virtuale che restituisce *this in base al valore senza essere affettato.

Se possibile, è consigliabile utilizzare i modelli come tutti gli altri dicono.

Tuttavia, se avete bisogno di polimorfismo dinamico, ad esempio perché non si può esporre l'attuazione di add_all_msgs come modello avrebbe fatto, allora io credo che si possa fingere di essere Java, in questo modo:

struct MessageIterator { 
    virtual Message &get() = 0; 
    virtual void next() = 0; 
    // add more functions if you need more than a Forward Iterator. 
    virtual ~MessageIterator() { }; // Not currently needed, but best be safe 
}; 

// implementation elsewhere. Uses get() and next() instead of * and ++ 
void add_all_msgs(MessageIterator &it); 

template <typename T> 
struct Adaptor : public MessageIterator { 
    typename T::iterator wrapped; 
    Adaptor(typename T::iterator w) : wrapped(w) { } 
    virtual Message &get() { 
     return *wrapped; 
    } 
    virtual void next() { 
     ++wrapped; 
    } 
}; 

int main() { 
    std::deque<Message> v; 
    Adaptor<std::deque<Message> > a(v.begin()); 
    add_all_msgs(a); 
} 

Ho controllato che questo compili, ma non l'ho ancora testato e non ho mai usato questo design prima. Inoltre non mi sono preoccupato della costanza: in pratica probabilmente vorrai un const Message &get() const. E al momento l'adattatore non ha modo di sapere quando fermarsi, ma poi nemmeno il codice con cui hai iniziato, quindi ho ignorato anche questo. Fondamentalmente avresti bisogno di una funzione hasNext che confronta wrapped con un iteratore finale fornito al costruttore.

Potrebbe essere possibile eseguire un'operazione con una funzione di modello e riferimenti const, in modo che il client non debba conoscere o dichiarare quel tipo di adattatore sgradevole.

[Modifica: a pensarci bene, probabilmente è meglio disporre di un modello di funzione stub add_all_msgs, che avvolge i suoi parametri in un adapter e quindi chiama real_add_all_msgs. Questo nasconde completamente l'adattatore dal client.]