On voit souvent des "quel linux choisir ?", des "pourquoi linux ?" etc.
Mais finalement à devoir choisir entre la peste (du côté de chez MS) et
la grippe (notre bon vieux nunux), celà ne vous arrive pas le matin en
vous réveillant de vous dire que les programmes qui font fonctionner
votre machines ne sont que des bidouillages plus ou moins réussis ?
Regardez les codes sources d'un programme en C. Même le code d'un bon
programmeur n'est rempli que d'horreurs. Ce fameux "void" : c'est quoi
cette abomination de la programmation ? Il n'y a aucune sémantique
valable là derrière. D'ailleurs les types en C n'ont de type que le nom.
Comment se fait il qu'on puisse écrire dans la 11e case d'un tableau de
10 éléments. Ce langage surestime beaucoup les capacités des personnes
qui vont l'utiliser. Une telle chose ne doit pas être possible. Comment
imaginer que ce genre de choses peut être voulu par le programmeur ?
Je pense que vous avez déjà vu du JAVA. Mais c'est à gerber cet
emboîtement de new, cette masse colossale de classes à faire pour faire
trois fois rien ! J'ose même pas imaginer la quantité de calculs
inutiles faits par la machine pour gérer ces merdes. D'accord il y a de
l'optimisation, mais c'est loin d'être suffisant.
Dans le temps les programmes étaient bidouillés parce qu'il n'y avait
pas assez de mémoire : par exemple on utilisait une variable pour
stocker deux informations. Maintenant l'horreur est à l'autre extrême :
on a tellement de mémoire de disponible que l'on utilise trop. En C :
tant pis c'est perdu. Un trou de mémoire ? Tant que le pc doit pas
redémarrer toutes les heures à cause de ça on s'en fout. En JAVA : il y
a le ramasse miettes alors on peut bouffer de la mémoire : c'est pô grave.
Dès que les programmes ont commencé à ne plus rentrer sur une disquette
ils sont devenus beaucoup trop compliqués pour fonctionner correctement.
On en vient à une époque où on trouve acceptable un programme quand il a
moins de cent bugs alors que rien que le fait de consommer trop de
ressources fait que le programme n'est pas bon. Aujourd'hui on nous
parle de .NET et de merdouilles dans le genre. A quoi ça sert de se
lancer dans la création de langages qui se copient les uns les autres.
C, C++, JAVA, Pascal : c'est la même chose, la même façon de penser. Et
c'est une manière de penser qui pousse à faire des fautes.
Bref l'informatique ne va pas fort.
Si si ... j'ai dejà eu un stack overflow en calculant les termes d'une suite de fabionacci (donc pas grand chose) en OCaml. D'une manière recursive j'entends.
Ahem, tu es certain que c'est le compilateur qui hurlait ?
S'il avait un module ispell pourquoi pas.
-- Irvin
On 2005-03-08, Guillaume L. <vect+news@nerim.net> wrote:
Si si ... j'ai dejà eu un stack overflow en calculant les termes d'une
suite de fabionacci (donc pas grand chose) en OCaml. D'une manière
recursive j'entends.
Ahem, tu es certain que c'est le compilateur qui hurlait ?
Si si ... j'ai dejà eu un stack overflow en calculant les termes d'une suite de fabionacci (donc pas grand chose) en OCaml. D'une manière recursive j'entends.
Ahem, tu es certain que c'est le compilateur qui hurlait ?
S'il avait un module ispell pourquoi pas.
-- Irvin
batyann811
Ouais, en gros, "ceux qui ne sont pas d'accord avec moi sont forcement des cons" ?
Ben quoi c'est la définition même du con non ?
Un con c'est celui qui n'est pas d'accord avec toi et qui ne veut pas admettre que tu as raison alors que tu lui a donné tout un tas d'arguments qui prouvent qu'il a tort. Seulement comme le con est un con il ne comprend pas tes arguments. C'est même à ça que l'on reconnait qu'il est con. D'un autre côté il y a de bonne chance pour qu'il t'ai donné, lui aussi, tout un tas d'arguments qui prouvent qu'il a raison mais tu persistes à penser qu'il a tort alors il s'imagine que tu es un con. Ce qui prouve bien que c'est un con puisque si tu étais un con tu n'aurais pas été capable de lui présenter les arguments qui prouvent qu'il a tort.
Ouais, en gros, "ceux qui ne sont pas d'accord avec moi sont forcement
des cons" ?
Ben quoi c'est la définition même du con non ?
Un con c'est celui qui n'est pas d'accord avec toi et qui ne veut pas
admettre que tu as raison alors que tu lui a donné tout un tas
d'arguments qui prouvent qu'il a tort. Seulement comme le con est un con
il ne comprend pas tes arguments. C'est même à ça que l'on reconnait
qu'il est con. D'un autre côté il y a de bonne chance pour qu'il t'ai
donné, lui aussi, tout un tas d'arguments qui prouvent qu'il a raison
mais tu persistes à penser qu'il a tort alors il s'imagine que tu es un
con. Ce qui prouve bien que c'est un con puisque si tu étais un con tu
n'aurais pas été capable de lui présenter les arguments qui prouvent
qu'il a tort.
Ouais, en gros, "ceux qui ne sont pas d'accord avec moi sont forcement des cons" ?
Ben quoi c'est la définition même du con non ?
Un con c'est celui qui n'est pas d'accord avec toi et qui ne veut pas admettre que tu as raison alors que tu lui a donné tout un tas d'arguments qui prouvent qu'il a tort. Seulement comme le con est un con il ne comprend pas tes arguments. C'est même à ça que l'on reconnait qu'il est con. D'un autre côté il y a de bonne chance pour qu'il t'ai donné, lui aussi, tout un tas d'arguments qui prouvent qu'il a raison mais tu persistes à penser qu'il a tort alors il s'imagine que tu es un con. Ce qui prouve bien que c'est un con puisque si tu étais un con tu n'aurais pas été capable de lui présenter les arguments qui prouvent qu'il a tort.
Rakotomandimby (R12y) Mihamina
( Tue, 08 Mar 2005 22:46:14 +0000 ) Nicolas George :
récursive, mais pas récursive terminale
'tain ... y a ça aussi? pfff... y a trop de choses. -- L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance) Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
( Tue, 08 Mar 2005 22:46:14 +0000 ) Nicolas George :
récursive, mais pas récursive terminale
'tain ... y a ça aussi? pfff... y a trop de choses.
--
L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses
activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance)
Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
( Tue, 08 Mar 2005 22:46:14 +0000 ) Nicolas George :
récursive, mais pas récursive terminale
'tain ... y a ça aussi? pfff... y a trop de choses. -- L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance) Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
Rakotomandimby (R12y) Mihamina
( Tue, 08 Mar 2005 22:52:18 +0000 ) Guillaume L. :
tu es certain que c'est le compilateur qui hurlait ?
certain, non. j'ai fait mon script, j'ai demandé de l'éxécuter, et "stack overflow". qui a parlé? ... je sais pas exactement. -- L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance) Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
( Tue, 08 Mar 2005 22:52:18 +0000 ) Guillaume L. :
tu es certain que c'est le compilateur qui hurlait ?
certain, non. j'ai fait mon script, j'ai demandé de l'éxécuter, et
"stack overflow". qui a parlé? ... je sais pas exactement.
--
L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses
activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance)
Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
( Tue, 08 Mar 2005 22:52:18 +0000 ) Guillaume L. :
tu es certain que c'est le compilateur qui hurlait ?
certain, non. j'ai fait mon script, j'ai demandé de l'éxécuter, et "stack overflow". qui a parlé? ... je sais pas exactement. -- L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance) Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
Guillaume L.
( Tue, 08 Mar 2005 22:52:18 +0000 ) Guillaume L. :
tu es certain que c'est le compilateur qui hurlait ?
certain, non. j'ai fait mon script, j'ai demandé de l'éxécuter, et "stack overflow". qui a parlé? ... je sais pas exactement.
Le "stack overflow" c'est quand la pile déborde (surprenant non ?), la pile est remplie à l'exécution d'un programme, par des variables, des appels de fonctions imbriqués (tiens, on dirait de la récursivité), etc. Je te laisse terminer cette intense réflexion.
Guillaume Leconte.
-- You're not a beautiful and unique snowflake.
( Tue, 08 Mar 2005 22:52:18 +0000 ) Guillaume L. :
tu es certain que c'est le compilateur qui hurlait ?
certain, non. j'ai fait mon script, j'ai demandé de l'éxécuter, et
"stack overflow". qui a parlé? ... je sais pas exactement.
Le "stack overflow" c'est quand la pile déborde (surprenant non ?), la pile
est remplie à l'exécution d'un programme, par des variables, des appels
de fonctions imbriqués (tiens, on dirait de la récursivité), etc. Je te
laisse terminer cette intense réflexion.
( Tue, 08 Mar 2005 22:52:18 +0000 ) Guillaume L. :
tu es certain que c'est le compilateur qui hurlait ?
certain, non. j'ai fait mon script, j'ai demandé de l'éxécuter, et "stack overflow". qui a parlé? ... je sais pas exactement.
Le "stack overflow" c'est quand la pile déborde (surprenant non ?), la pile est remplie à l'exécution d'un programme, par des variables, des appels de fonctions imbriqués (tiens, on dirait de la récursivité), etc. Je te laisse terminer cette intense réflexion.
Guillaume Leconte.
-- You're not a beautiful and unique snowflake.
Raphaël 'SurcouF' Bordet
Bonjour,
On voit souvent des "quel linux choisir ?", des "pourquoi linux ?" etc. Mais finalement à devoir choisir entre la peste (du côté de chez MS) et la grippe (notre bon vieux nunux), celà ne vous arrive pas le matin en vous réveillant de vous dire que les programmes qui font fonctionner votre machines ne sont que des bidouillages plus ou moins réussis ?
Oui mais ces "bidouillages" sont gratuits et je les ai choisis, je ne vais donc pas trop me plaindre ;-)
Regardez les codes sources d'un programme en C. Même le code d'un bon programmeur n'est rempli que d'horreurs. Ce fameux "void" : c'est quoi cette abomination de la programmation ? Il n'y a aucune sémantique valable là derrière. D'ailleurs les types en C n'ont de type que le nom. Comment se fait il qu'on puisse écrire dans la 11e case d'un tableau de 10 éléments. Ce langage surestime beaucoup les capacités des personnes qui vont l'utiliser. Une telle chose ne doit pas être possible. Comment imaginer que ce genre de choses peut être voulu par le programmeur ? Je pense que vous avez déjà vu du JAVA. Mais c'est à gerber cet emboîtement de new, cette masse colossale de classes à faire pour faire trois fois rien ! J'ose même pas imaginer la quantité de calculs inutiles faits par la machine pour gérer ces merdes. D'accord il y a de l'optimisation, mais c'est loin d'être suffisant. Dans le temps les programmes étaient bidouillés parce qu'il n'y avait pas assez de mémoire : par exemple on utilisait une variable pour stocker deux informations. Maintenant l'horreur est à l'autre extrême : on a tellement de mémoire de disponible que l'on utilise trop. En C : tant pis c'est perdu. Un trou de mémoire ? Tant que le pc doit pas redémarrer toutes les heures à cause de ça on s'en fout. En JAVA : il y a le ramasse miettes alors on peut bouffer de la mémoire : c'est pô grave.
Je crois que tu viens de trouver sans t'en rendre compte l'élément essentiel pour lequel ton troll s'effrondre. Quelque soit le langage (même un programme Ada peut faire exploser une fusée Ariane), il existe deux types de développeurs: le bon développeur qui sait développer et le mauvais développeur. Le bon ressemble au mauvais sauf qu'il est bon ! Bref, tu devrais regarder entre la chaise et le clavier et tu auras 90% des causes de problèmes informatiques.
Dès que les programmes ont commencé à ne plus rentrer sur une disquette ils sont devenus beaucoup trop compliqués pour fonctionner correctement. On en vient à une époque où on trouve acceptable un programme quand il a moins de cent bugs alors que rien que le fait de consommer trop de ressources fait que le programme n'est pas bon. Aujourd'hui on nous parle de .NET et de merdouilles dans le genre. A quoi ça sert de se lancer dans la création de langages qui se copient les uns les autres. C, C++, JAVA, Pascal : c'est la même chose, la même façon de penser. Et c'est une manière de penser qui pousse à faire des fautes. Bref l'informatique ne va pas fort.
C'est vrai ça: pourquoi qu'on écrirait pas en français, d'abord ? ;-)
-- Raphaël 'SurcouF' Bordet http://debianfr.net/ | surcouf at debianfr dot net
Bonjour,
On voit souvent des "quel linux choisir ?", des "pourquoi linux ?" etc.
Mais finalement à devoir choisir entre la peste (du côté de chez MS) et
la grippe (notre bon vieux nunux), celà ne vous arrive pas le matin en
vous réveillant de vous dire que les programmes qui font fonctionner
votre machines ne sont que des bidouillages plus ou moins réussis ?
Oui mais ces "bidouillages" sont gratuits et je les ai choisis, je ne
vais donc pas trop me plaindre ;-)
Regardez les codes sources d'un programme en C. Même le code d'un bon
programmeur n'est rempli que d'horreurs. Ce fameux "void" : c'est quoi
cette abomination de la programmation ? Il n'y a aucune sémantique
valable là derrière. D'ailleurs les types en C n'ont de type que le nom.
Comment se fait il qu'on puisse écrire dans la 11e case d'un tableau de
10 éléments. Ce langage surestime beaucoup les capacités des personnes
qui vont l'utiliser. Une telle chose ne doit pas être possible. Comment
imaginer que ce genre de choses peut être voulu par le programmeur ?
Je pense que vous avez déjà vu du JAVA. Mais c'est à gerber cet
emboîtement de new, cette masse colossale de classes à faire pour faire
trois fois rien ! J'ose même pas imaginer la quantité de calculs
inutiles faits par la machine pour gérer ces merdes. D'accord il y a de
l'optimisation, mais c'est loin d'être suffisant.
Dans le temps les programmes étaient bidouillés parce qu'il n'y avait
pas assez de mémoire : par exemple on utilisait une variable pour
stocker deux informations. Maintenant l'horreur est à l'autre extrême :
on a tellement de mémoire de disponible que l'on utilise trop. En C :
tant pis c'est perdu. Un trou de mémoire ? Tant que le pc doit pas
redémarrer toutes les heures à cause de ça on s'en fout. En JAVA : il y
a le ramasse miettes alors on peut bouffer de la mémoire : c'est pô grave.
Je crois que tu viens de trouver sans t'en rendre compte l'élément
essentiel pour lequel ton troll s'effrondre. Quelque soit le langage
(même un programme Ada peut faire exploser une fusée Ariane), il existe
deux types de développeurs: le bon développeur qui sait développer et le
mauvais développeur. Le bon ressemble au mauvais sauf qu'il est bon !
Bref, tu devrais regarder entre la chaise et le clavier et tu auras 90%
des causes de problèmes informatiques.
Dès que les programmes ont commencé à ne plus rentrer sur une disquette
ils sont devenus beaucoup trop compliqués pour fonctionner correctement.
On en vient à une époque où on trouve acceptable un programme quand il a
moins de cent bugs alors que rien que le fait de consommer trop de
ressources fait que le programme n'est pas bon. Aujourd'hui on nous
parle de .NET et de merdouilles dans le genre. A quoi ça sert de se
lancer dans la création de langages qui se copient les uns les autres.
C, C++, JAVA, Pascal : c'est la même chose, la même façon de penser. Et
c'est une manière de penser qui pousse à faire des fautes.
Bref l'informatique ne va pas fort.
C'est vrai ça: pourquoi qu'on écrirait pas en français, d'abord ? ;-)
--
Raphaël 'SurcouF' Bordet
http://debianfr.net/ | surcouf at debianfr dot net
On voit souvent des "quel linux choisir ?", des "pourquoi linux ?" etc. Mais finalement à devoir choisir entre la peste (du côté de chez MS) et la grippe (notre bon vieux nunux), celà ne vous arrive pas le matin en vous réveillant de vous dire que les programmes qui font fonctionner votre machines ne sont que des bidouillages plus ou moins réussis ?
Oui mais ces "bidouillages" sont gratuits et je les ai choisis, je ne vais donc pas trop me plaindre ;-)
Regardez les codes sources d'un programme en C. Même le code d'un bon programmeur n'est rempli que d'horreurs. Ce fameux "void" : c'est quoi cette abomination de la programmation ? Il n'y a aucune sémantique valable là derrière. D'ailleurs les types en C n'ont de type que le nom. Comment se fait il qu'on puisse écrire dans la 11e case d'un tableau de 10 éléments. Ce langage surestime beaucoup les capacités des personnes qui vont l'utiliser. Une telle chose ne doit pas être possible. Comment imaginer que ce genre de choses peut être voulu par le programmeur ? Je pense que vous avez déjà vu du JAVA. Mais c'est à gerber cet emboîtement de new, cette masse colossale de classes à faire pour faire trois fois rien ! J'ose même pas imaginer la quantité de calculs inutiles faits par la machine pour gérer ces merdes. D'accord il y a de l'optimisation, mais c'est loin d'être suffisant. Dans le temps les programmes étaient bidouillés parce qu'il n'y avait pas assez de mémoire : par exemple on utilisait une variable pour stocker deux informations. Maintenant l'horreur est à l'autre extrême : on a tellement de mémoire de disponible que l'on utilise trop. En C : tant pis c'est perdu. Un trou de mémoire ? Tant que le pc doit pas redémarrer toutes les heures à cause de ça on s'en fout. En JAVA : il y a le ramasse miettes alors on peut bouffer de la mémoire : c'est pô grave.
Je crois que tu viens de trouver sans t'en rendre compte l'élément essentiel pour lequel ton troll s'effrondre. Quelque soit le langage (même un programme Ada peut faire exploser une fusée Ariane), il existe deux types de développeurs: le bon développeur qui sait développer et le mauvais développeur. Le bon ressemble au mauvais sauf qu'il est bon ! Bref, tu devrais regarder entre la chaise et le clavier et tu auras 90% des causes de problèmes informatiques.
Dès que les programmes ont commencé à ne plus rentrer sur une disquette ils sont devenus beaucoup trop compliqués pour fonctionner correctement. On en vient à une époque où on trouve acceptable un programme quand il a moins de cent bugs alors que rien que le fait de consommer trop de ressources fait que le programme n'est pas bon. Aujourd'hui on nous parle de .NET et de merdouilles dans le genre. A quoi ça sert de se lancer dans la création de langages qui se copient les uns les autres. C, C++, JAVA, Pascal : c'est la même chose, la même façon de penser. Et c'est une manière de penser qui pousse à faire des fautes. Bref l'informatique ne va pas fort.
C'est vrai ça: pourquoi qu'on écrirait pas en français, d'abord ? ;-)
-- Raphaël 'SurcouF' Bordet http://debianfr.net/ | surcouf at debianfr dot net
Raphaël 'SurcouF' Bordet
Bref l'informatique ne va pas fort.
Mais si, mais si.
Mais non, l'informatique est aux mains de marchands de soupe.
S'il n'y avait que l'informatique...
-- Raphaël 'SurcouF' Bordet http://debianfr.net/ | surcouf at debianfr dot net
Bref l'informatique ne va pas fort.
Mais si, mais si.
Mais non, l'informatique est aux mains de marchands de soupe.
S'il n'y avait que l'informatique...
--
Raphaël 'SurcouF' Bordet
http://debianfr.net/ | surcouf at debianfr dot net
Mais non, l'informatique est aux mains de marchands de soupe.
S'il n'y avait que l'informatique...
-- Raphaël 'SurcouF' Bordet http://debianfr.net/ | surcouf at debianfr dot net
Jérémy JUST
On Wed, 09 Mar 2005 00:36:52 +0100 Raphaël 'SurcouF' Bordet wrote:
Mais non, l'informatique est aux mains de marchands de soupe. S'il n'y avait que l'informatique...
Pour ce qui est des soupes, lesdits marchants se débrouillent plutôt bien. En peu de temps (peut-être deux ans), le nombre de variétés s'est accru considérablement. Récemment, j'ai vu des soupes apparaître au rayon frais, ce qui est le signe d'un produit en bonne santé (quand le consommateur est prêt à payer le prix d'un produit frais et à se plier aux contraintes de ce type de produits, c'est qu'il est accro).
L'avenir est dans la soupe!
-- Jérémy JUST
On Wed, 09 Mar 2005 00:36:52 +0100
Raphaël 'SurcouF' Bordet <surcouf@debianfr.net> wrote:
Mais non, l'informatique est aux mains de marchands de soupe.
S'il n'y avait que l'informatique...
Pour ce qui est des soupes, lesdits marchants se débrouillent plutôt
bien.
En peu de temps (peut-être deux ans), le nombre de variétés s'est
accru considérablement. Récemment, j'ai vu des soupes apparaître au
rayon frais, ce qui est le signe d'un produit en bonne santé (quand le
consommateur est prêt à payer le prix d'un produit frais et à se plier
aux contraintes de ce type de produits, c'est qu'il est accro).
On Wed, 09 Mar 2005 00:36:52 +0100 Raphaël 'SurcouF' Bordet wrote:
Mais non, l'informatique est aux mains de marchands de soupe. S'il n'y avait que l'informatique...
Pour ce qui est des soupes, lesdits marchants se débrouillent plutôt bien. En peu de temps (peut-être deux ans), le nombre de variétés s'est accru considérablement. Récemment, j'ai vu des soupes apparaître au rayon frais, ce qui est le signe d'un produit en bonne santé (quand le consommateur est prêt à payer le prix d'un produit frais et à se plier aux contraintes de ce type de produits, c'est qu'il est accro).
L'avenir est dans la soupe!
-- Jérémy JUST
Richard Delorme
Sous DOS (Borland C) : short = 16 bits int = 16 bits long = 32 bits
Sous Linux i386 (gcc) : short = 16 bits int = 32 bits long = 32 bits
Sous Linux alpha (gcc) : short = 16 bits int = 32 bits long = 64 bits
Sous sparc64, idem.
Maintenant, portez moi un code utilisant int et long de DOS à sparc64 pour rigoler ! Là, on commence à apprécier sérieusement les integer*8 (un peu hors norme) du Fortran ! Ça fait vingt ans que je code en C, et pour l'instant, je n'ai pas trouvé mieux et plus portable que des grands coups de typedef conditionnés par un script configure.
Ben, il faut arrêter les trucs d'il y a vingt ans.
#include <stdint.h> ou sur les systèmes Unix un peu vieillot #include <inttypes.h>
Dedans on trouve des types à taille garantie : int8_t int16_t int32_t int64_t etc.
-- Richard
Sous DOS (Borland C) :
short = 16 bits
int = 16 bits
long = 32 bits
Sous Linux i386 (gcc) :
short = 16 bits
int = 32 bits
long = 32 bits
Sous Linux alpha (gcc) :
short = 16 bits
int = 32 bits
long = 64 bits
Sous sparc64, idem.
Maintenant, portez moi un code utilisant int et long de DOS à
sparc64 pour rigoler ! Là, on commence à apprécier sérieusement les
integer*8 (un peu hors norme) du Fortran ! Ça fait vingt ans que je
code en C, et pour l'instant, je n'ai pas trouvé mieux et plus
portable que des grands coups de typedef conditionnés par un script
configure.
Ben, il faut arrêter les trucs d'il y a vingt ans.
#include <stdint.h>
ou sur les systèmes Unix un peu vieillot
#include <inttypes.h>
Dedans on trouve des types à taille garantie :
int8_t
int16_t
int32_t
int64_t
etc.
Sous DOS (Borland C) : short = 16 bits int = 16 bits long = 32 bits
Sous Linux i386 (gcc) : short = 16 bits int = 32 bits long = 32 bits
Sous Linux alpha (gcc) : short = 16 bits int = 32 bits long = 64 bits
Sous sparc64, idem.
Maintenant, portez moi un code utilisant int et long de DOS à sparc64 pour rigoler ! Là, on commence à apprécier sérieusement les integer*8 (un peu hors norme) du Fortran ! Ça fait vingt ans que je code en C, et pour l'instant, je n'ai pas trouvé mieux et plus portable que des grands coups de typedef conditionnés par un script configure.
Ben, il faut arrêter les trucs d'il y a vingt ans.
#include <stdint.h> ou sur les systèmes Unix un peu vieillot #include <inttypes.h>
Dedans on trouve des types à taille garantie : int8_t int16_t int32_t int64_t etc.
-- Richard
Richard Delorme
Contrairement à ce que l'on croit, la portabilité d'un langage est uniquement déterminée par la qualité de sa spécification. Un langage d'assemblage est portable car sa sémantique est univoque, alors que la liste des « undefined behaviors » du C fait 20 pages.
Permettez-moi donc de traiter de con tout ceux qui affirment péremptoirement que le C est portable.
Justement, les comportements indéfinis sont là pour faciliter la portabilité du langage sur des architectures très différentes. Le résultat est que qu'il existe des compilateurs C pour presque tout ce qui a un processeur, ce qui est loin d'être le cas pour les autres langages.
-- Richard
Contrairement à ce que l'on croit, la portabilité d'un langage est
uniquement déterminée par la qualité de sa spécification. Un langage
d'assemblage est portable car sa sémantique est univoque, alors que la
liste des « undefined behaviors » du C fait 20 pages.
Permettez-moi donc de traiter de con tout ceux qui affirment
péremptoirement que le C est portable.
Justement, les comportements indéfinis sont là pour faciliter la
portabilité du langage sur des architectures très différentes. Le
résultat est que qu'il existe des compilateurs C pour presque tout ce
qui a un processeur, ce qui est loin d'être le cas pour les autres langages.
Contrairement à ce que l'on croit, la portabilité d'un langage est uniquement déterminée par la qualité de sa spécification. Un langage d'assemblage est portable car sa sémantique est univoque, alors que la liste des « undefined behaviors » du C fait 20 pages.
Permettez-moi donc de traiter de con tout ceux qui affirment péremptoirement que le C est portable.
Justement, les comportements indéfinis sont là pour faciliter la portabilité du langage sur des architectures très différentes. Le résultat est que qu'il existe des compilateurs C pour presque tout ce qui a un processeur, ce qui est loin d'être le cas pour les autres langages.
