Ben nan, et c’est très précisément ce que je voulais dire.
C'est totalement idiot comme affirmation. Le passé l'a montré : Java a déjà évolué de nombreuses fois, et si le besoin se fait sentir demain d'indexer un tableau avec un long, aucun doute qu'il évoluera dans ce sens, et ca va pas casser grand chose.
Si je veux juste "un nombre sur lequel ma machine peut faire des opérations arithmétiques" (l’immense majorité des algos),
L'immense majorité des algos ont besoins d'être bornés, tu connais beaucoup d'algo générique qui marche quelque soit la taille d'un int ?
int et int32_t, ce n’est pas _du tout_ la même chose sémantiquement,
On est d'accord, mais le int existe, est dans la norme, et est beaucoup trop dépendant de la machine pour qu'il soit considéré comme non portable pour la majorité des codes qui l'utilise.
unsigned int rgbaColor = 0xdeadbeef, c’est une hérésie, que ce soit en C ou en Java
C'est absolument pas une hérésie en Java, la taille des int est garantie, et tu peux compter dessus.
Relis mon exemple. Tu ne l’as pas compris.
Tu essaies de nous démontrer que ca a un intérêt pour un algo de voir ses possibilités décuplés parceque demain la taille de ses pointeurs ou de ses int va augmenter. C'est totalement ridicule.
Le seul intérêt qu'il y a à manipuler des int, c'est pour une question d'optimisation puisque celà correspond à la taille des données manipulées nativement par l'UC. Ce qui montre bien que celà n'a strictement rien de portable.
Le C, c'est un compromis entre portabilité et performance.
il n’y a pas un langage plus ou mois portable qu’un autre entre Java et C
Bah si : en Java, quelque soit l'architecture sur laquelle tu tournes, ton algorithme aura toujours les mêmes bornes, toujours le même comportement et toujours le même résultat.
la sémantique générale de l’algorithme multiplyByTwo est préservée
Si tu définies la sémantique comme étant celle exprimée par la construction syntaxique en C, effectivement elle sera préservée. Le risque, c'est que la sémantique qu'a voulu donner le programmeur avant de le traduire en C, elle peut en prendre un gros coup dans l'aile.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
C'est totalement idiot comme affirmation. Le passé l'a montré : Java a déjà évolué de nombreuses fois, et si le besoin se fait sentir demain d'indexer un tableau avec un long, aucun doute qu'il évoluera dans ce sens, et ca va pas casser grand chose.
Si je veux juste "un nombre sur lequel ma machine peut faire des opérations arithmétiques" (l’immense majorité des algos),
L'immense majorité des algos ont besoins d'être bornés, tu connais beaucoup d'algo générique qui marche quelque soit la taille d'un int ?
int et int32_t, ce n’est pas _du tout_ la même chose sémantiquement,
On est d'accord, mais le int existe, est dans la norme, et est beaucoup trop dépendant de la machine pour qu'il soit considéré comme non portable pour la majorité des codes qui l'utilise.
unsigned int rgbaColor = 0xdeadbeef, c’est une hérésie, que ce soit en C ou en Java
C'est absolument pas une hérésie en Java, la taille des int est garantie, et tu peux compter dessus.
Relis mon exemple. Tu ne l’as pas compris.
Tu essaies de nous démontrer que ca a un intérêt pour un algo de voir ses possibilités décuplés parceque demain la taille de ses pointeurs ou de ses int va augmenter. C'est totalement ridicule.
Le seul intérêt qu'il y a à manipuler des int, c'est pour une question d'optimisation puisque celà correspond à la taille des données manipulées nativement par l'UC. Ce qui montre bien que celà n'a strictement rien de portable.
Le C, c'est un compromis entre portabilité et performance.
il n’y a pas un langage plus ou mois portable qu’un autre entre Java et C
Bah si : en Java, quelque soit l'architecture sur laquelle tu tournes, ton algorithme aura toujours les mêmes bornes, toujours le même comportement et toujours le même résultat.
la sémantique générale de l’algorithme multiplyByTwo est préservée
Si tu définies la sémantique comme étant celle exprimée par la construction syntaxique en C, effectivement elle sera préservée. Le risque, c'est que la sémantique qu'a voulu donner le programmeur avant de le traduire en C, elle peut en prendre un gros coup dans l'aile.