Écoute, si c’est pour ne pas me lire et répondre en automatique à partir de quelques mots clefs, c’est pas la peine de me répondre. Tu n’y es pas légalement obligé.
> Eh tu vas rire, mais en Java, y'a un type "long" et un type "double".
Aucun, mais alors vraiment aucun rapport avec ce que j’ai écrit.
Ou alors on peut utiliser les double pour indexer des tableaux en Java. Dans ce cas, c’est une killer feature que vous devriez mettre en avant.
> Et là tu vas te bidonner : même que Java, si le besoin s'en fait ressentir, peut évoluer,
Ben nan, et c’est très précisément ce que je voulais dire.
En C, on a pas défini en dur « taille d’un pointeur », de même qu’on a pas défini en dur « type de l’indice d’un tableau » dans la spec. Alors ça pose quelques soucis de portabilité à certains gruiks qui voyant que sur leur machine sizeof(int) = sizeof(void*) pensent qu’ils peuvent caster des int en void* et vice-versa, certes, mais ça laisse le champ libre à l’évolution du C.
Donc quand on est passé de 16 bits à 32 bits puis 32 bits à 64 bits, pas de souci pour passer de tableaux contenant des dizaines de milliers d’éléments à des millions, et on aura ensuite aucun souci pour passer de tableaux contenant des centaines de millions d’éléments à des tableaux de plusieurs milliards d’éléments.
Au contraire, Java a dit :
- int = 32 bits
- indice des tableaux = int. long doit balancer une exception [http://java.sun.com/docs/books/jls/second_edition/html/array(...)] Ergo, avec Java, tu ne pourras tout simplement pas faire de tableaux de quelques milliards d’éléments même quand ce sera monnaie « courante » chez d’autres langages.
Le but est juste de montrer les inconvénients de définir une taille d’entiers fixes, pourquoi le C a choisi de ne pas le faire, et pourquoi ce choix a été un facteur de réussite sur le long terme.
Tu veux un autre exemple ? Prenons le cas où j’ai codé un algorithme sur ma machine 32 bits, que je veux utiliser sur un processeur 16 bits sans addl (je pense qu’on peut plus en trouver aujourd’hui, mais ça a existé).
En Java :
- soit la JVM n’existe pas pour cette machine : on a rien pour faire de l’int
- soit la JVM force artificiellement le 32 bits à l’aide d’une fonction addl, et bonjour les performances où toute opération sur un int c’est un appel de fonction
- donc, en pratique, je fais un sed s/int/short/g MonAlgo.java > MonAlgo-16.java
En C:
- je recompile et ça juste marche (tm). Sauf si bien sûr j’ai codé comme un porc.
- différence entre les plateformes : les limites de mon algorithme sont plus basses sur la machine 16 bits. Rien qui ne me choque là-dedans.
Pour moi, sur cet exemple, le C est plus portable.
Encore une fois, ce que je dis, c’est ça :
- le fait de ne pas fixer les tailles en C a été un choix
- ce choix, en pratique, revient à privilégier une forme de portabilité (algorithme qui s’adapte « automagiquement » aux capacités de la machine) sur une autre (certaines opérations peuvent « tomber en marche » sur une machine et planter 2 ans plus tard quand tu changes de machine)
- ce choix a été un des facteurs de succès du C sur le long terme
> Non clairement en C il faut utiliser ces types à taille fixe si on veut du code portable
Que dalle. Il faut utiliser des entiers de taille et d’endianness fixe pour la communication avec l’extérieur et vérifier les tailles lors de la sérialisation/déserialisation, c’est tout.
Si je veux un "entier sur 32 bits", parce que ça a un sens sémantiquement dans le contexte (pour coder une couleur RGBA par exemple), oui, je prend un entier de taille fixe.
Si je veux juste "un nombre sur lequel ma machine peut faire des opérations arithmétiques" (l’immense majorité des algos), je prend un int.
Bon sang, c’est juste une règle de bonne conduite dans tout projet et dans tout langage : un choix d’ordre sémantique doit être explicité ! int et int32_t, ce n’est pas _du tout_ la même chose sémantiquement, et si tu les mélanges au petit bonheur la chance, c’est pas la faute du langage, c’est parce que tu ne sais pas ce que tu fais, et dans ce cas, comme le disait mon prof d’ingénierie logicielle : tu enlèves les mains de ton clavier et tu réfléchis. unsigned int rgbaColor = 0xdeadbeef, c’est une hérésie, que ce soit en C ou en Java, parce que pour du RGBA-32, la taille a un sens important. Même si ça marche et c’est portable en Java, c’est du même ordre que mon exemple new int[(int)PI] : c’est pas parce que _par hasard_ la constante ((int)PI ou sizeof(int)) marche pour mon problème qu’il est correct de l’utiliser !
> C'est quoi cet argument ridicule ?
Relis mon exemple. Tu ne l’as pas compris.
tl;dr : sur la question de la taille des entiers, il n’y a pas un langage plus ou mois portable qu’un autre entre Java et C : il y a portabilité formelle (si ma fonction multiplyByTwo fonctionne sur une architecture avec 2**30 en entrée, alors elle doit fonctionner partout avec cette entrée, même si ça signifie que toute opération sur un int doit être ralentie (à la louche) d’un facteur 10 ou plus si la machine ne sait pas faire nativement) pour Java contre portabilité sémantique (la sémantique générale de l’algorithme multiplyByTwo est préservée, mais ses limites dépendent de la machine) pour le C
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
> Eh tu vas rire, mais en Java, y'a un type "long" et un type "double".
Aucun, mais alors vraiment aucun rapport avec ce que j’ai écrit.
Ou alors on peut utiliser les double pour indexer des tableaux en Java. Dans ce cas, c’est une killer feature que vous devriez mettre en avant.
> Et là tu vas te bidonner : même que Java, si le besoin s'en fait ressentir, peut évoluer,
Ben nan, et c’est très précisément ce que je voulais dire.
En C, on a pas défini en dur « taille d’un pointeur », de même qu’on a pas défini en dur « type de l’indice d’un tableau » dans la spec. Alors ça pose quelques soucis de portabilité à certains gruiks qui voyant que sur leur machine sizeof(int) = sizeof(void*) pensent qu’ils peuvent caster des int en void* et vice-versa, certes, mais ça laisse le champ libre à l’évolution du C.
Donc quand on est passé de 16 bits à 32 bits puis 32 bits à 64 bits, pas de souci pour passer de tableaux contenant des dizaines de milliers d’éléments à des millions, et on aura ensuite aucun souci pour passer de tableaux contenant des centaines de millions d’éléments à des tableaux de plusieurs milliards d’éléments.
Au contraire, Java a dit :
- int = 32 bits
- indice des tableaux = int. long doit balancer une exception [http://java.sun.com/docs/books/jls/second_edition/html/array(...)]
Ergo, avec Java, tu ne pourras tout simplement pas faire de tableaux de quelques milliards d’éléments même quand ce sera monnaie « courante » chez d’autres langages.
Le but est juste de montrer les inconvénients de définir une taille d’entiers fixes, pourquoi le C a choisi de ne pas le faire, et pourquoi ce choix a été un facteur de réussite sur le long terme.
Tu veux un autre exemple ? Prenons le cas où j’ai codé un algorithme sur ma machine 32 bits, que je veux utiliser sur un processeur 16 bits sans addl (je pense qu’on peut plus en trouver aujourd’hui, mais ça a existé).
En Java :
- soit la JVM n’existe pas pour cette machine : on a rien pour faire de l’int
- soit la JVM force artificiellement le 32 bits à l’aide d’une fonction addl, et bonjour les performances où toute opération sur un int c’est un appel de fonction
- donc, en pratique, je fais un sed s/int/short/g MonAlgo.java > MonAlgo-16.java
En C:
- je recompile et ça juste marche (tm). Sauf si bien sûr j’ai codé comme un porc.
- différence entre les plateformes : les limites de mon algorithme sont plus basses sur la machine 16 bits. Rien qui ne me choque là-dedans.
Pour moi, sur cet exemple, le C est plus portable.
Encore une fois, ce que je dis, c’est ça :
- le fait de ne pas fixer les tailles en C a été un choix
- ce choix, en pratique, revient à privilégier une forme de portabilité (algorithme qui s’adapte « automagiquement » aux capacités de la machine) sur une autre (certaines opérations peuvent « tomber en marche » sur une machine et planter 2 ans plus tard quand tu changes de machine)
- ce choix a été un des facteurs de succès du C sur le long terme
> Non clairement en C il faut utiliser ces types à taille fixe si on veut du code portable
Que dalle. Il faut utiliser des entiers de taille et d’endianness fixe pour la communication avec l’extérieur et vérifier les tailles lors de la sérialisation/déserialisation, c’est tout.
Si je veux un "entier sur 32 bits", parce que ça a un sens sémantiquement dans le contexte (pour coder une couleur RGBA par exemple), oui, je prend un entier de taille fixe.
Si je veux juste "un nombre sur lequel ma machine peut faire des opérations arithmétiques" (l’immense majorité des algos), je prend un int.
Bon sang, c’est juste une règle de bonne conduite dans tout projet et dans tout langage : un choix d’ordre sémantique doit être explicité ! int et int32_t, ce n’est pas _du tout_ la même chose sémantiquement, et si tu les mélanges au petit bonheur la chance, c’est pas la faute du langage, c’est parce que tu ne sais pas ce que tu fais, et dans ce cas, comme le disait mon prof d’ingénierie logicielle : tu enlèves les mains de ton clavier et tu réfléchis. unsigned int rgbaColor = 0xdeadbeef, c’est une hérésie, que ce soit en C ou en Java, parce que pour du RGBA-32, la taille a un sens important. Même si ça marche et c’est portable en Java, c’est du même ordre que mon exemple new int[(int)PI] : c’est pas parce que _par hasard_ la constante ((int)PI ou sizeof(int)) marche pour mon problème qu’il est correct de l’utiliser !
> C'est quoi cet argument ridicule ?
Relis mon exemple. Tu ne l’as pas compris.
tl;dr : sur la question de la taille des entiers, il n’y a pas un langage plus ou mois portable qu’un autre entre Java et C : il y a portabilité formelle (si ma fonction multiplyByTwo fonctionne sur une architecture avec 2**30 en entrée, alors elle doit fonctionner partout avec cette entrée, même si ça signifie que toute opération sur un int doit être ralentie (à la louche) d’un facteur 10 ou plus si la machine ne sait pas faire nativement) pour Java contre portabilité sémantique (la sémantique générale de l’algorithme multiplyByTwo est préservée, mais ses limites dépendent de la machine) pour le C