IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++ Discussion :

spécialisation algorithme STL


Sujet :

C++

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre éclairé
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    301
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 301
    Par défaut spécialisation algorithme STL
    Bonsoir à tous,

    Je me demandais si les algorithmes de la STL sont spécialisés en fonction des types d'itérateurs qui leurs sont fournis. Par exemple dans le cas de std::find si je lui passe un itérateur sur le début et sur la fin d'un set est-ce que la recherche se fera en temps logarithmique? Si ce n'est pas le cas pourquoi ce n'est pas possible? (j'imagine que si ça l'était ce serait déjà implémenté).

    Merci

  2. #2
    Membre éprouvé
    Profil pro
    Inscrit en
    Décembre 2004
    Messages
    1 299
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2004
    Messages : 1 299
    Par défaut
    Je pense effectivement que le temps de recherche dépendent de ton conteneur. Dans un set, les données sont stockées par ordre croissant (ou décroissant). Dans une list, elles sont stockées les unes après les autres. Il y a aussi les map, les vector, les multimap, les multiset et les deque.

  3. #3
    Membre éclairé
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    301
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 301
    Par défaut
    en fait ma question porte plus sur les algorithmes externes aux classes conteneurs (algorithme find de <algorithm>). En effet, la méthode find de la classe set m'assure une recherche en temps logarithmique mais qu'en est-il pour std::find:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
     
    #include <set>
    #include <vector>
    #include <algorithm>
     
    int main()
    {
        std::vector<int> vect;
        std::find(vect.begin(), vect.end(), 2);  //recherche forcément en O(n)
     
        std::set<int> tree;
        tree.find(2);  //recherche en O(log(n))
        std::find(tree.begin(), tree.end(), 2);  //recherche en O(n) ou O(log(n)) ??
     
        return 0;
    }

  4. #4
    Membre expérimenté
    Homme Profil pro
    Consultant BigData
    Inscrit en
    Juillet 2009
    Messages
    129
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Consultant BigData

    Informations forums :
    Inscription : Juillet 2009
    Messages : 129
    Par défaut
    Je ne pense pas que find passe en temps logarithmique du fait qu'il prend en paramètres des itérateurs et non un set directement.

    CPP Reference confirme d'ailleurs ce que je pense
    Complexity

    linear in the distance between first and last

  5. #5
    Membre Expert
    Avatar de poukill
    Profil pro
    Inscrit en
    Février 2006
    Messages
    2 155
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 2 155
    Par défaut
    Par contre, set propose une implémentation de find que pour lui :
    std::set::find !!!

  6. #6
    Membre éclairé
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    301
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 301
    Par défaut
    ok pour std::set::find mais je me demandais dans le cas d'un algorithme générique si on ne perdait pas en performance par exemple:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
     
    template<typename Collection, typename Elt>
    void un_algorithme_generique(Collection const& src, Elt const& e)
    {
        //... des instructions
        //recherche d'un element
        std::find(src.begin(), src.end(), e);
        //... des instructions
    }
    Si je veux des performances optimales, il faudrait donc que je spécialise ma méthode un_algorithme_generique pour les set, les map, et leurs version unordered et que je remplace la ligne std::find(src.begin(), src.end(), e); par src.find(e); ce qui "casse" le côté générique de un_algorithme_generique. Je pensais que les itérateurs sur conteneur ordonné spécifiaient des tags qui étaient utilisés par std::find. Bref à priori ce n'est pas le cas et c'est un peu dommage.
    En tout cas merci pour vos réponses!

Discussions similaires

  1. [À télécharger] [Algorithmes type STL] copy_if
    Par 3DArchi dans le forum Téléchargez
    Réponses: 0
    Dernier message: 06/11/2010, 19h58
  2. algorithmes de la STL différences entre copy et insert?
    Par Benoit_T dans le forum SL & STL
    Réponses: 3
    Dernier message: 26/03/2009, 10h31
  3. [STL][algorithm]for_each vs transform
    Par r0d dans le forum SL & STL
    Réponses: 6
    Dernier message: 25/07/2007, 11h52
  4. Réponses: 5
    Dernier message: 04/04/2007, 09h34
  5. Foncteurs pour algorithmes de stl
    Par Feriaman dans le forum SL & STL
    Réponses: 9
    Dernier message: 14/12/2006, 18h08

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo