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

Langage C++ Discussion :

Les User Defined Literals


Sujet :

Langage C++

  1. #1
    Membre émérite Avatar de ctxnop
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juillet 2007
    Messages
    858
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Morbihan (Bretagne)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2007
    Messages : 858
    Par défaut Les User Defined Literals
    Bonjour,
    Suite à la présentation de Loïc Joly aux Tech Days 2015, j'ai une interrogation sur les User Defined Literals.

    Bien que je trouve la fonctionnalité très utile, je me demande s'il n'y a pas un risque de collision/ambiguïté. Que se passe-t-il si deux bibliothèques tierces définissent le même literal ?
    S'il y a bien un risque, alors il devrait exister des règles de bonnes pratique ? Par exemple de ne pas exposer ce genre de literals dans une bibliothèque, ou utiliser un prefix/suffix (ce qui donnerait des literals très long perdant ainsi leurs intérêts).

    En fait la fonctionnalité et ses défaut me font penser aux méthodes d'extensions de C#.
    Pour ceux qui ne savent pas ce que c'est, voici un exemple :
    Code c# : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
     
    public static class MyExtentions
    {
        public static int Count(this IEnumerable<string> lst)
        {
            int i = 0;
            foreach(string s in lst) ++i;
            return i;
        }
    }
     
    // Du coup je peux écrire ça, alors que "Count" n'est pas un membre de IEnumerable<string>.
    IEnumerable<string> myList = ...;
    int c = myList.Count();

    Cette fonctionnalité pose deux problème :
    - Que se passe-t-il si une évolution du framework (ou de la bibliothèque fournissant le type) ajoute une méthode "Count" sur le type ?
    - Que se passe-t-il si une bibliothèque fournit des méthodes d'extensions identiques ? (Ce qui est d'ailleurs le cas dans l'exemple donné, puisque c'est que fait LinQ)

    Pour répondre à ces problèmes on recommande de ne pas utiliser les méthodes d'extensions, ou, si on ne veut pas s'en passer, de leurs donner un nom évitant toute collision, avec des préfix/suffixes par exemple.

    Du coup, est-ce que les user defined literals ont le même genre de problèmes ? Et auquel cas, est-ce qu'il y a des règles/recommandations pour éviter ces problèmes ?

  2. #2
    Rédacteur/Modérateur
    Avatar de JolyLoic
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2004
    Messages
    5 463
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 5 463
    Par défaut
    Pour mitiger les problèmes de collision, les user defined literals peuvent être placés dans des namespaces (il faut alors faire des using pour y accéder). À partir de là, et pour peu que personne ne fournisse de bibliothèques sans cette protection, il me semble qu'on a ce qu'il faut pour que ça puisse fonctionner. Mais je ne sais pas encore si ça restera agréable.

    Je ne sais plus comment se comportent les méthodes d'extension avec les namespaces.
    Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
    Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
    Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
    Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.

  3. #3
    Membre émérite Avatar de ctxnop
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juillet 2007
    Messages
    858
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Morbihan (Bretagne)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2007
    Messages : 858
    Par défaut
    D'accord, donc c'est bien les mêmes problèmes qu'avec les méthodes d'extensions.
    Effectivement le risque est réduit en les mettant dans un namespace séparés.
    Du coup, dans l'absolu, les développeurs de libs devraient éviter la fonctionnalité ou prendre grande attention a son isolation.

  4. #4
    Expert éminent

    Femme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2007
    Messages
    5 202
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Juin 2007
    Messages : 5 202
    Par défaut
    En effet. À ce sujet, tu peux regarder ce qui est fait dans la STL.

    Certains littéraux sont définis dans des sous-espaces de std, et importés dans std

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [2008R2] Récupérer les colonnes d'un User-Defined Table Type
    Par Kropernic dans le forum Développement
    Réponses: 2
    Dernier message: 15/04/2014, 12h08
  2. soucis sur les USER DEFINED DATA TYPE
    Par f_bobo dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 17/05/2006, 15h53

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