Comme tu dis toi-même, dans ce cas, le fait que ça marche ou pas ne dépend pas de l’architecture de la machine mais des capacités de la machine.
Ce qui n’est pas en soit surprenant.
> Ca a tout son sens quand ton soft gere 32768
Tu mélanges deux situations différentes. Ton soft gère 32768 éléments ou MAX_INT éléments ? Ce n’est pas la même chose.
Cas où ton soft gère 32768 éléments : ben tu fais pas MAX_INT, mais #define MAXELEMS
Cas où ton soft gère MAX_INT : tu aimerais bien que ton algo scale avec les capacités de ta machine, donc il me semble normal que MAX_INT change selon l’architecture, et tant pis si ça plante pour une machine pas assez puissante.
> et on verra regulierement des tables de 2^32 elements
Ha, mais c’est exactement mon argument plus bas, hein !
1. Là où Java est portable dans le sens où il garantit que l’algo aura les mêmes limites partout, là où C est portable dans le sens où l’algo « scale » avec les capacités de la machine.
2. Justement, je suis impatient de voir comment fera Java quand on verra régulièrement des tables de 2^32 éléments, alors qu’il est écrit dans sa spec que l’index d’un tableau, c’est 32 bits.
> Quand t'as des types de taille statique, ce genre de merde n'arrive pas, si tu passes ton soft sur le nouvel OS, ton code il marche, point.
Mais il est incapable de profiter de la puissance de ce nouvel OS flambant neuf, et au final, si tu veux en profiter, tu es obligé de recoder ton programme en changeant des int par des long.
C’est pas « plus » ou « moins » portable, c’est différent. Pour une FFT fenêtrée de taille fixe sur un stream, l’approche Java est plus adaptée. Pour de la manipulation d’images, l’approche C est plus adaptée (tu aimerais que la limite en taille d’image puisse s’adapter avec l’évolution du matos : images 170 par 170 au max sur du 16 bits, 65000 par 65000).
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 3.
Ce qui n’est pas en soit surprenant.
> Ca a tout son sens quand ton soft gere 32768
Tu mélanges deux situations différentes. Ton soft gère 32768 éléments ou MAX_INT éléments ? Ce n’est pas la même chose.
Cas où ton soft gère 32768 éléments : ben tu fais pas MAX_INT, mais #define MAXELEMS
Cas où ton soft gère MAX_INT : tu aimerais bien que ton algo scale avec les capacités de ta machine, donc il me semble normal que MAX_INT change selon l’architecture, et tant pis si ça plante pour une machine pas assez puissante.
> et on verra regulierement des tables de 2^32 elements
Ha, mais c’est exactement mon argument plus bas, hein !
1. Là où Java est portable dans le sens où il garantit que l’algo aura les mêmes limites partout, là où C est portable dans le sens où l’algo « scale » avec les capacités de la machine.
2. Justement, je suis impatient de voir comment fera Java quand on verra régulièrement des tables de 2^32 éléments, alors qu’il est écrit dans sa spec que l’index d’un tableau, c’est 32 bits.
> Quand t'as des types de taille statique, ce genre de merde n'arrive pas, si tu passes ton soft sur le nouvel OS, ton code il marche, point.
Mais il est incapable de profiter de la puissance de ce nouvel OS flambant neuf, et au final, si tu veux en profiter, tu es obligé de recoder ton programme en changeant des int par des long.
C’est pas « plus » ou « moins » portable, c’est différent. Pour une FFT fenêtrée de taille fixe sur un stream, l’approche Java est plus adaptée. Pour de la manipulation d’images, l’approche C est plus adaptée (tu aimerais que la limite en taille d’image puisse s’adapter avec l’évolution du matos : images 170 par 170 au max sur du 16 bits, 65000 par 65000).