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

Collection et Stream Java Discussion :

Instanciation d'un tableau d'éléments de type générique


Sujet :

Collection et Stream Java

  1. #1
    Membre à l'essai
    Homme Profil pro
    Inscrit en
    Novembre 2011
    Messages
    22
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Novembre 2011
    Messages : 22
    Points : 15
    Points
    15
    Par défaut Instanciation d'un tableau d'éléments de type générique
    Bonjour,

    J'essaye d'instancier un tableau d'éléments de type générique T dans une constructeur d'une classe générique :

    Code java : 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
    17
    18
    19
    20
    21
    22
     
     
        class Plan<T> {
                public Plan(T[][] plan) {
                        this.plan = plan;
                }
     
                public Plan(int yTaille, int xTaille, int valeurParDefaut) {
                        plan = new T[yTaille][xTaille];
     
                }
     
                public T recevoirElement(int y, int x) {
                        return plan[y][x];
                }
     
                public int recevoirLargeur() {return xTaille;}
                public int recevoirHauteur() {return yTaille;}
     
                private T[][] plan;
                private int yTaille, xTaille;
        }

    L'erreur est ligne 9. Je sais pourquoi cela est interdit (limitation de la programmation générique en Java ; T est en fait remplacé par Object), mais j'aimerais bien contourner cette limitation. Je peux procéder ainsi :

    Code "java : Sélectionner tout - Visualiser dans une fenêtre à part
    plan = (T[][]) new Object[yTaille][xTaille];

    Mais ce n'est pas très propre et il reste un panneau attention à la compilation.

    Merci d'avance !

  2. #2
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2007
    Messages
    25 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2007
    Messages : 25 481
    Points : 48 806
    Points
    48 806
    Par défaut
    Et surtout ça ne marchera pas quand tu remontera un cran plus haut et que tu castera ton T[][] en, par exemple, Integer[][] car la jvm te lancera un ClassCastException (un Integer[][] n'est pas la même chose qu'un Object[][]).


    Le problème ici est le même que l'impossibilité de faire un new T(). La seule solution de contournement, c'est qu'on te passer une instance de T[][] et que, éventuellement, tu l'agrandisse. C'est ce que fait la classe ArrayList, dont je te suggère d'aller voir la méthode "T[] toArray(T[])" qui en dit long sur ce problème de generic et de tableau

  3. #3
    Membre à l'essai
    Homme Profil pro
    Inscrit en
    Novembre 2011
    Messages
    22
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Novembre 2011
    Messages : 22
    Points : 15
    Points
    15
    Par défaut
    Ah, mince, je souhaitais que ma classe se charge elle-même de tout construire... Mais n'a-t-on pas le même problème pour agrandir ?
    De ce que j'ai trouvé, la méthode n'en dit pas si long : http://docs.oracle.com/javase/7/docs...#toArray%28%29
    Et que la classe Integer aurait-elle de particulier pour ne pas pouvoir émaner d'un Object ?
    Dommage que la compatibilité ait voulue être conservée à tout prix avec des versions antérieures de Java lors de l'ajout de la programmation générique, ça bricke toutes les possibilités...

    (Merci pour ta réponse )

  4. #4
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2007
    Messages
    25 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2007
    Messages : 25 481
    Points : 48 806
    Points
    48 806
    Par défaut
    De la même manière que tu ne peux pas faire en java

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    Object o = new Object();
    Integer i = (Integer) o;

    Tu ne peux pas faire
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    Object[] o = new Object[1];
    Integer[] i  = (Integer[]) o;
    (Integer n'est qu'un exemple).

    Je parlais d'aller voir les sources, pas la javadoc

  5. #5
    Modérateur

    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    12 547
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 12 547
    Points : 21 602
    Points
    21 602
    Par défaut
    Oui enfin, ArrayList n'est pas magique. Elle fait bel et bien :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    T[] array = (T[])new Object[size];
    Le truc étant que le T[] array en question est private, n'est jamais exposé à l'extérieur, et n'est donc jamais casté après sa création. Ce qui évite le problème.

    Rien n'empêche de faire la même chose.
    Et pour le warning, ben il est normal : le compilateur signale qu'il n'est pas capable de vérifier la cohérence des types, et c'est la vérité. C'est le programmeur qui doit s'assurer qu'il ne fait pas de connerie, et notamment qu'il n'expose pas le tableau ainsi créé.
    Si on est sûr de soi, pour enlever le warning, il y a l'annotation "je sais ce que je fais, je comprends l'erreur et les risques qu'elle implique, mais la conception de cette classe garantit que ces risques ne s'appliquent pas" @SuppressWarnings("unchecked"). Une description de la preuve qu'il n'y a aucune risque, sera bienvenue dans les commentaires du code.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  6. #6
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    Avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : Avril 2002
    Messages : 13 938
    Points : 23 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut
    Salut,

    Citation Envoyé par collect Voir le message
    Je sais pourquoi cela est interdit (limitation de la programmation générique en Java ; T est en fait remplacé par Object),
    Non au contraire c'est surtout une limitation des tableaux, qui ne garantissent pas un code typesafe (au contraire même).

    Avec des tableaux tu peux très bien écrire un code comme celui-ci sans avoir aucun problème à la compilation :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    	T[] typedArray = ...
    	Object[] objectArray = typedArray; // OK
    	objectArray[0] = "Hello"; // ClassCastException
    Mais tu risques d'obtenir une exception à l'exécution selon le type réel de T...

    Tout cela à cause de l'héritage un peu trompeur des tableau (String[] hérite de Object[], etc.)
    D'ailleurs ceci est également vrai avant Java 5 et les Generics...



    Or l'objectif premier des Generics est d'empêcher les exceptions à l’exécution.
    Mais c'est impossible de faire cela avec des tableaux, donc la création de tableau Generics est bloqué pour éviter la confusion (croire que c'est typesage alors que cela ne l'est pas)






    Avec les Generics, tu n'a pas ce genre de problème, puis qu'il n'y a pas d'héritage des paramétrages.
    Tu auras forcément une erreur à la compilation :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    	List<T> typedList = ...
    	List<Object> objectList = typedList; // COMPILE ERROR
    Au lieu de cela on peut utiliser la covariance/contravariance, mais ici aussi cela bloque les utilisations incorrects :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    	List<T> typedList = Arrays.asList(a);
    	List<?> objectList = typedList; // OK
    	objectList.add("Hello"); // COMPILE ERROR

    Bref :
    • tableau Java code non-typesafe
    • collections Generics code typesafe





    Citation Envoyé par collect Voir le message
    Mais ce n'est pas très propre et il reste un panneau attention à la compilation.
    Si tu veux vraiment utiliser un tableau tu devras faire avec ce warning, quitte à utiliser une annotation @SuppressWarning pour dire au compilateur que tu prends en charge la responsabilité du typeage de ce code.

    Par contre je te conseillerais plutôt de déclarer le tableau en Object, et d'utiliser deux méthodes get/set pour accéder à ses éléments, par exemple :
    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
    class Plan<T> {
        public Plan(int yTaille, int xTaille) {
            plan = new Object[yTaille][xTaille];
        }
     
        @SuppressWarnings("unchecked")
    	public T get(int y, int x) {
                return (T)plan[y][x];
        }
     
        public void set(int y, int x, T value) {
        	plan[y][x] = value;
        }
     
        private Object[][] plan;
    }

    a++

  7. #7
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2007
    Messages
    25 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2007
    Messages : 25 481
    Points : 48 806
    Points
    48 806
    Par défaut
    Citation Envoyé par thelvin Voir le message
    Le truc étant que le T[] array en question est private, n'est jamais exposé à l'extérieur, et n'est donc jamais casté après sa création. Ce qui évite le problème.
    C'est pour ça que je parlais de la méthode toArray qui retourn un T[], où là t'es bien obligé que le type sois correct, pas comme la variable privée qui elle absue du language dans tous les sens


    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
         @SuppressWarnings("unchecked")
         public <T> T[] More ...toArray(T[] a) {
             if (a.length < size)
                 // Make a new array of a's runtime type, but my contents:
                 return (T[]) Arrays.copyOf(elementData, size, a.getClass());
             System.arraycopy(elementData, 0, a, 0, size);
             if (a.length > size)
                 a[size] = null;
             return a;
         }
    Tu notera que le seule moyen d'instancier un T[] correct, c'est d'avoir déjà un tableau, de faire un getClass() dessus et de passer par Arrays.copyOf dont l'implétentation utilise joyeusement le reflection

  8. #8
    Membre à l'essai
    Homme Profil pro
    Inscrit en
    Novembre 2011
    Messages
    22
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Novembre 2011
    Messages : 22
    Points : 15
    Points
    15
    Par défaut
    Merci à tous pour votre aide.

    J'ai résolu une des erreurs d'exécution car j'utilisais le toArray de Vector, et je passe maintenant en paramètre un tableau de la bonne taille et du bon type.

    Et la méthode d'adiGuba fonctionne très bien.

    Juste le petit regret que les développeurs du Java ne lui donnent pas de la vraie programmation générique...

  9. #9
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    Avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : Avril 2002
    Messages : 13 938
    Points : 23 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par collect Voir le message
    Juste le petit regret que les développeurs du Java ne lui donnent pas de la vraie programmation générique...
    Comme je l'ai dit le problème ne vient pas des Generics mais des tableaux Java.

    Le "problème" existe aussi avec du code qui n'utilise pas les Generics :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    String[] stringArray = new String[10];
    Object[] objectArray = stringArray;
    objectArray[0] = new Date(); // ClassCastException

    S'il faudrait revoir quelque chose, ce serait plutôt la gestion des tableaux Java :
    • Leur "héritage" particulier qui empêche d'avoir du code typesafe.
    • L'impossibilité d'avoir des tableaux immutables.
    • L'impossibilité de les redimensionner (sans avoir à recréer un nouveau tableau)



    Les "limitations" des Generics sont bien moins problématique en pratique...


    a++

  10. #10
    Membre à l'essai
    Homme Profil pro
    Inscrit en
    Novembre 2011
    Messages
    22
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Novembre 2011
    Messages : 22
    Points : 15
    Points
    15
    Par défaut
    Oui, c'est vrai qu'ici, le problème vient surtout des tableaux, mais le mauvais générique pose aussi parfois problème (CF http://sucre.syntaxique.fr/doku.php?id=java).

    Citation Envoyé par adiGuba Voir le message
    • L'impossibilité d'avoir des tableaux immutables.
    "final" ?

    Citation Envoyé par adiGuba Voir le message
    • L'impossibilité de les redimensionner (sans avoir à recréer un nouveau tableau)
    Personnellement, cela me semble logique que l'on doive passer par une classe spécialisée pour cela, telle Vector, puisque cela peut se gérer de différentes manières selon les besoins...

  11. #11
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    Avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : Avril 2002
    Messages : 13 938
    Points : 23 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par collect Voir le message
    Oui, c'est vrai qu'ici, le problème vient surtout des tableaux, mais le mauvais générique pose aussi parfois problème (CF http://sucre.syntaxique.fr/doku.php?id=java).
    Il n'est pas question de Generics dans le lien que tu cites.
    Au contraire la section "typage faible" fait référence à des méthodes qui utilise des Objects (pour des raisons historique), et non pas des types paramétrés Generics...


    Citation Envoyé par collect Voir le message
    "final" ?
    Non justement !
    Le mot-clef final empêche juste d'affecter un nouveau tableau, mais cela n'empêche pas de modifier les différentes valeurs...


    Citation Envoyé par collect Voir le message
    Personnellement, cela me semble logique que l'on doive passer par une classe spécialisée pour cela, telle Vector, puisque cela peut se gérer de différentes manières selon les besoins...
    Hum. ArrayList plutôt parce que Vector est une antiquité.

    Dès lors que tu utilises une ArrayList et via les Generics tous les problèmes des tableaux sont oubliés.
    • Il n'y a pas d'héritage farfelu (une List<String> n'étend pas de List<Object>) mais on peut utiliser la variance pour écrire du code plus générique.
    • On peut très bien créer une instance immuable via Collections.unmodifiableList()
    • Et bien sûr on peut redimensionner plus facilement (même si en interne cela utilisera toujours un tableau).



    a++

  12. #12
    Membre à l'essai
    Homme Profil pro
    Inscrit en
    Novembre 2011
    Messages
    22
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Novembre 2011
    Messages : 22
    Points : 15
    Points
    15
    Par défaut
    Il me semble que la partie historique ne bricke pas seulement les classes préétablies, mais bloque également toute nouvelle possibilité. Lors de l'introduction de la généricité, les développeurs ont voulu laisser le langage compatible avec les anciennes versions, d'où le fait que le code générique n'est rien d'autre que remplacer "T" par "Object" (si on oublie les avertissements à la compilation).

    Mais Java est capable de bien pire que ça :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    ArrayList<Short> foo = new ArrayList<Short>();
    foo.add(12); // ok...
    foo.contains(12); // renvoie false !
    Cette partie ne me paraît pas intéressante, il est évident que deux objets de références différentes, même s'ils contiennent la même chose, sont différents ? Sauf erreur de ma part.

    Citation Envoyé par adiGuba Voir le message
    Non justement !
    Le mot-clef final empêche juste d'affecter un nouveau tableau, mais cela n'empêche pas de modifier les différentes valeurs...
    En effet. Ils auraient pu choisir de procéder ainsi :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    final int[] t; // tableau à termes finaux
    int final[] t; // tableau à référence finale
    final int final[] t; // tableau à référence et termes finaux


    Enfin bon, ne nous appesantissons pas là-dessus.

  13. #13
    Modérateur

    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    12 547
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 12 547
    Points : 21 602
    Points
    21 602
    Par défaut
    Citation Envoyé par collect Voir le message
    Il me semble que la partie historique ne bricke pas seulement les classes préétablies, mais bloque également toute nouvelle possibilité. Lors de l'introduction de la généricité, les développeurs ont voulu laisser le langage compatible avec les anciennes versions, d'où le fait que le code générique n'est rien d'autre que remplacer "T" par "Object" (si on oublie les avertissements à la compilation).
    C'est pas clair ton histoire, tu mélanges plusieurs choses.
    - Pour garder la compatibilité avec le code existant, les classes génériques n'obligent pas d'utiliser leur généricité. Ce qui fait des warning et a pour effet de remplacer le type générique par Object (ou du moins le type le plus ascendant autorisé.)

    - Pour garder la compatibilité avec les fonctionnalités existantes, l'égalité entre objets définie avec equals() autorise que des objets de classes arbitrairement éparses puissent être considérées égales. Cette propriété étant utilisée pour la recherche dans des collections, elle a dû être gardée et tout ce qui est recherche d'objet présent se fait avec paramètre Object.
    Pour éviter ça, il aurait fallu créer de nouvelles relations d'égalité imposant que la classe comparant soit ascendante de l'autre, et de nouvelles collections qui s'en servent. Pas impossible mais lourd pour peu de gains.

    Citation Envoyé par collect Voir le message
    Cette partie ne me paraît pas intéressante, il est évident que deux objets de références différentes, même s'ils contiennent la même chose, sont différents ? Sauf erreur de ma part.
    Plus exactement cet exemple est faux. Java n'est pas capable de faire ça. Ce bout de code ne compile pas.

    Par contre ce bout de code-ci compile :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    ArrayList<Short> foo = new ArrayList<Short>();
    Short s = 12;
    foo.add(s); // ok...
    foo.contains(12); // renvoie false !
    et c'est presque la même chose.

    Tu te dis que c'est normal, mais non. Que se passe-t-il si on utilise une ArrayList<Integer> au lieu de <Short> ?
    Le problème illustré dans cet exemple, c'est qu'une Collection<T> utilise le paramètre T à l'ajout (pour assurer que les objets contenus dans la Collection sont bien du type paramétré,) mais Object au test d'appartenance (pour respecter le mécanisme historique de relation d'égalité.)

    Ce qui signifie que si le paramètre <T> est fixé à Short, le add() prendra comme paramètre add(Short e), qu'on peut lui fournir avec Short s = 12;. Alors que le contains() aura comme paramètre contains(Object o), et qu'on peut appeler dessus contains(12), ce qui créera une instance d'Integer, et non pas de Short, qui vaut 12.
    Short et Integer ne sont jamais equals() et c'est la raison pour laquelle add() et contains() ne s'y retrouvent pas en leur passant chacun un nombre qui vaut 12.
    Si le type paramétré était Integer, les deux instances créées seraient Integer, elles seraient equals() et par définition, contains() renverrait true.

    C'est effectivement un problème de typage assez faible, où s'emmêlent le contains() qui n'utilise pas les génériques, et l'auto-inbox qui convertit implicitement les types de base en leur équivalent objet.

    Ça peut être déroutant, mais rarement en pratique. Par exemple l'intérêt d'une liste de Short ne va pas loin, sauf si l'idée est de contraindre la plage de valeurs possibles des nombres, et non pas d'occuper moins de mémoire.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  14. #14
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    Avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : Avril 2002
    Messages : 13 938
    Points : 23 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par collect Voir le message
    Il me semble que la partie historique ne bricke pas seulement les classes préétablies, mais bloque également toute nouvelle possibilité. Lors de l'introduction de la généricité, les développeurs ont voulu laisser le langage compatible avec les anciennes versions, d'où le fait que le code générique n'est rien d'autre que remplacer "T" par "Object" (si on oublie les avertissements à la compilation).
    Comme l'indique thelvin, cela ne concerne pas les Generics puisque la méthode contains(Object) utilise un type Object et non pas un type T !

    Certaines méthodes des Collections, basé sur l’égalité (comme contains()), n'utilisent pas les Generics car il n'y a pas forcément besoin d'avoir un typage fort pour cela.


    Citation Envoyé par collect Voir le message
    En effet. Ils auraient pu choisir de procéder ainsi :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    final int[] t; // tableau à termes finaux
    int final[] t; // tableau à référence finale
    final int final[] t; // tableau à référence et termes finaux
    En fait il serait plus simple de "supprimer" les tableaux Java du langage, purement et simplement.
    Le tout en les remplaçant par une classe Array<T> qui proposerait les mêmes fonctionnalité via un vrai objet, bien plus flexible via les Generics et la covariance/contravariance en remplacement de l'héritage "particulier" des tableaux...





    Plus globalement il est de "bon ton" de critiquer les Generics de Java à cause du type-erasure, même si les problèmes que cela pose sont minime et facilement contournable.
    Mais en pratique le truc est quand même vachement bien foutu et bien pensé !



    a++

  15. #15
    Membre à l'essai
    Homme Profil pro
    Inscrit en
    Novembre 2011
    Messages
    22
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Novembre 2011
    Messages : 22
    Points : 15
    Points
    15
    Par défaut
    Oui, c'est vrai, mais c'est toujours un inconvénient, de devoir s'adapter aux particularités de chaque langage, et d'avoir parfois des résultats non escomptés, qui seraient logiquement absurdes. Cela peut compliquer le debug.

    Merci pour votre aide en tout cas !

  16. #16
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    Avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : Avril 2002
    Messages : 13 938
    Points : 23 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par collect Voir le message
    Oui, c'est vrai, mais c'est toujours un inconvénient, de devoir s'adapter aux particularités de chaque langage, et d'avoir parfois des résultats non escomptés, qui seraient logiquement absurdes. Cela peut compliquer le debug.
    Qu'est-ce qui est "logiquement absurdes" ?

    a++

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

Discussions similaires

  1. tableau de structure(variable Type) traiter les éléments
    Par Patnel dans le forum Macros et VBA Excel
    Réponses: 1
    Dernier message: 18/04/2014, 09h48
  2. Réponses: 5
    Dernier message: 23/04/2013, 20h29
  3. Réponses: 37
    Dernier message: 19/05/2008, 00h20
  4. Tableau d'objets de type différents
    Par Hell dans le forum C++
    Réponses: 9
    Dernier message: 11/01/2005, 23h57
  5. Tableau d'éléments de type variable
    Par Drooxy dans le forum Langage
    Réponses: 4
    Dernier message: 16/03/2003, 16h20

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