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.
« évidemment possible », c'est à dire possible d'une manière assez simple pour que le compilateur la voie.
donc peu utile.
JKB
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Tom écrivait dans fr.comp.os.linux.debats :
C'est comme l'ISO 9001 qui permet de faire de la m*rde lorsqu'on l'a spécifié ;-)
JKB
Le C c'est la liberté... de faire des non programmes, des trucs qui n'ont aucune signification. Mais c'est dans les normes du C alors c'est bon ça compile. On serre les fesses à l'exécution et si c'est bien rustiné (un néologisme ? très utile en tout cas) ça passe plus ou moins bien.
Ce n'est pas tout à fait mon propos. Le C est un langage batard, mais à partir du moment où on arrive à contourner tous les "implementation defined" et "undefined result", on arrive à faire des trucs intéressants. Le problèmes, c'est que pour faire la même chose, avec la même fiabilité qu'un bout de code ADA ou Fortran, il faut trois fois plus de lignes (et je suis gentil). Même le mécanisme de gestion des erreurs et des exceptions est une rustine (tm) ! Renvoyer une valeur pour savoir si la fonction s'est bien passée (et se contre foutre de la non lecture de cette valeur...), c'est vraiment le mécanisme le plus foireux existant... Et je ne parle pas des errno...
JKB
Le 09-03-2005, à propos de
Re: a-t-on le choix ?,
Tom écrivait dans fr.comp.os.linux.debats :
C'est comme l'ISO 9001 qui permet de faire de la m*rde lorsqu'on l'a
spécifié ;-)
JKB
Le C c'est la liberté... de faire des non programmes, des trucs qui
n'ont aucune signification. Mais c'est dans les normes du C alors c'est
bon ça compile. On serre les fesses à l'exécution et si c'est bien
rustiné (un néologisme ? très utile en tout cas) ça passe plus ou moins
bien.
Ce n'est pas tout à fait mon propos. Le C est un langage batard,
mais à partir du moment où on arrive à contourner tous les
"implementation defined" et "undefined result", on arrive à faire
des trucs intéressants. Le problèmes, c'est que pour faire la même
chose, avec la même fiabilité qu'un bout de code ADA ou Fortran, il
faut trois fois plus de lignes (et je suis gentil). Même le
mécanisme de gestion des erreurs et des exceptions est une rustine
(tm) ! Renvoyer une valeur pour savoir si la fonction s'est bien
passée (et se contre foutre de la non lecture de cette valeur...),
c'est vraiment le mécanisme le plus foireux existant... Et je ne
parle pas des errno...
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Tom écrivait dans fr.comp.os.linux.debats :
C'est comme l'ISO 9001 qui permet de faire de la m*rde lorsqu'on l'a spécifié ;-)
JKB
Le C c'est la liberté... de faire des non programmes, des trucs qui n'ont aucune signification. Mais c'est dans les normes du C alors c'est bon ça compile. On serre les fesses à l'exécution et si c'est bien rustiné (un néologisme ? très utile en tout cas) ça passe plus ou moins bien.
Ce n'est pas tout à fait mon propos. Le C est un langage batard, mais à partir du moment où on arrive à contourner tous les "implementation defined" et "undefined result", on arrive à faire des trucs intéressants. Le problèmes, c'est que pour faire la même chose, avec la même fiabilité qu'un bout de code ADA ou Fortran, il faut trois fois plus de lignes (et je suis gentil). Même le mécanisme de gestion des erreurs et des exceptions est une rustine (tm) ! Renvoyer une valeur pour savoir si la fonction s'est bien passée (et se contre foutre de la non lecture de cette valeur...), c'est vraiment le mécanisme le plus foireux existant... Et je ne parle pas des errno...
JKB
Blaise Potard
Joe Cool wrote:
La machine vérifie le type et le devine en observant la manière dont le programme utilise ses données. On évite les erreurs de typage dues au programmeur et on certifie que le programme ne peut en aucun cas générer d'erreur d'exécution : un programme typé statiquement ne peut pas planter.
On ne certifie certainement pas cela. Une récursion mal écrite et ton programme plante. Et ne me dit pas que c'est du à la limitation des ressources de la machine, de toute façon un tel programme va être faux, donc qu'il plante ce n'est pas plus mal. D'autre part, là tu parles des avantage de l'inférence de type et du typage fort, pas du typage statique. Un bon programme en C est typé statiquement (avec un typage faible, certes). Tu vois, je suis tout à fait d'accord que pour beaucoup de choses le langage caml est très largement supérieur au C, mais pas à cause du fait que le typage soit statique. Le typage statique des objets est un avantage par rapport à d'autres langages OO par contre ; mais c'est un autre débat (d'ailleurs, maintenant que j'y pense, ce débat n'a pas grand chose à voir avec linux, mais bon).
Preuve de quoi ? De la cohérence des types ? De la correction du programme (ce qui est en générale ce qu'on appelle preuve, et qui est très difficile à faire automatiquement puisque la machine est incapable de deviner ce qu'on veut faire, et à même beaucoup de mal à comprendre quand on lui explique), certainement pas. En même temps, ça m'arrangerait, comme tout mes programmes C sont correctement typés, ça prouverait qu'ils sont corrects.
Non car le système de type du C est incohérent. Le système de typage de caml génère pour chaque programme la preuve qu'il utilise ses données de manière cohérente : il génère la preuve que le programme ne peut pas planter. Du moins si il plante, ce n'est pas de sa faute mais celle du système d'exploitation ou du matériel.
Ou surtout du programmeur qui programme comme un manche... Le système de type du C n'est pas incohérent. Le typage est faible, il y a des conversions implicites qui sont parfois gênantes, mais c'est tout. Évidemment, la permissivité du C permet de faire un peu n'importe quoi sans nécessairement le signaler, et du coup on ne peut effectivement pas garantir la cohérence du typage des données (mais ça, dès que l'on utilise des pointeurs, ce n'est de toute façon pas possible).
Honnêtement, pour quelqu'un qui programme depuis longtemps, les erreurs de typage sont assez rares. Par contre, les dépassements de mémoire ça arrive bien souvent, mais ça, aucun compilateur n'est encore capable de le détecter, et ça n'a strictement rien à voir avec le typage. La plupart des erreurs, c'est encore au niveau des calculs que l'on effectue qu'elles se situent (oubli d'appeler une sous-fonction, erreur d'indice,...). Évidemment, si tu n'as qu'une confiance relative dans les capacités de ton programmeur, ne le laisse surtout pas programmer en C, c'est la meilleur chance d'avoir un truc illisible et non portable, en plus de buggué.
Joe Cool wrote:
La machine vérifie le type et le devine en observant la manière dont le
programme utilise ses données. On évite les erreurs de typage dues au
programmeur et on certifie que le programme ne peut en aucun cas générer
d'erreur d'exécution : un programme typé statiquement ne peut pas planter.
On ne certifie certainement pas cela. Une récursion mal écrite et ton
programme plante. Et ne me dit pas que c'est du à la limitation des
ressources de la machine, de toute façon un tel programme va être faux,
donc qu'il plante ce n'est pas plus mal. D'autre part, là tu parles des
avantage de l'inférence de type et du typage fort, pas du typage
statique. Un bon programme en C est typé statiquement (avec un typage
faible, certes). Tu vois, je suis tout à fait d'accord que pour beaucoup
de choses le langage caml est très largement supérieur au C, mais pas à
cause du fait que le typage soit statique. Le typage statique des objets
est un avantage par rapport à d'autres langages OO par contre ; mais
c'est un autre débat (d'ailleurs, maintenant que j'y pense, ce débat n'a
pas grand chose à voir avec linux, mais bon).
Preuve de quoi ? De la cohérence des types ? De la correction du
programme (ce qui est en générale ce qu'on appelle preuve, et qui est
très difficile à faire automatiquement puisque la machine est
incapable de deviner ce qu'on veut faire, et à même beaucoup de mal à
comprendre quand on lui explique), certainement pas. En même temps, ça
m'arrangerait, comme tout mes programmes C sont correctement typés, ça
prouverait qu'ils sont corrects.
Non car le système de type du C est incohérent. Le système de typage de
caml génère pour chaque programme la preuve qu'il utilise ses données de
manière cohérente : il génère la preuve que le programme ne peut pas
planter. Du moins si il plante, ce n'est pas de sa faute mais celle du
système d'exploitation ou du matériel.
Ou surtout du programmeur qui programme comme un manche...
Le système de type du C n'est pas incohérent. Le typage est faible, il y
a des conversions implicites qui sont parfois gênantes, mais c'est tout.
Évidemment, la permissivité du C permet de faire un peu n'importe quoi
sans nécessairement le signaler, et du coup on ne peut effectivement pas
garantir la cohérence du typage des données (mais ça, dès que l'on
utilise des pointeurs, ce n'est de toute façon pas possible).
Honnêtement, pour quelqu'un qui programme depuis longtemps, les erreurs
de typage sont assez rares. Par contre, les dépassements
de mémoire ça arrive bien souvent, mais ça, aucun compilateur n'est
encore capable de le détecter, et ça n'a strictement rien à voir avec le
typage. La plupart des erreurs, c'est encore au niveau des calculs que
l'on effectue qu'elles se situent (oubli d'appeler une sous-fonction,
erreur d'indice,...). Évidemment, si tu n'as qu'une confiance relative
dans les capacités de ton programmeur, ne le laisse surtout pas
programmer en C, c'est la meilleur chance d'avoir un truc illisible et
non portable, en plus de buggué.
La machine vérifie le type et le devine en observant la manière dont le programme utilise ses données. On évite les erreurs de typage dues au programmeur et on certifie que le programme ne peut en aucun cas générer d'erreur d'exécution : un programme typé statiquement ne peut pas planter.
On ne certifie certainement pas cela. Une récursion mal écrite et ton programme plante. Et ne me dit pas que c'est du à la limitation des ressources de la machine, de toute façon un tel programme va être faux, donc qu'il plante ce n'est pas plus mal. D'autre part, là tu parles des avantage de l'inférence de type et du typage fort, pas du typage statique. Un bon programme en C est typé statiquement (avec un typage faible, certes). Tu vois, je suis tout à fait d'accord que pour beaucoup de choses le langage caml est très largement supérieur au C, mais pas à cause du fait que le typage soit statique. Le typage statique des objets est un avantage par rapport à d'autres langages OO par contre ; mais c'est un autre débat (d'ailleurs, maintenant que j'y pense, ce débat n'a pas grand chose à voir avec linux, mais bon).
Preuve de quoi ? De la cohérence des types ? De la correction du programme (ce qui est en générale ce qu'on appelle preuve, et qui est très difficile à faire automatiquement puisque la machine est incapable de deviner ce qu'on veut faire, et à même beaucoup de mal à comprendre quand on lui explique), certainement pas. En même temps, ça m'arrangerait, comme tout mes programmes C sont correctement typés, ça prouverait qu'ils sont corrects.
Non car le système de type du C est incohérent. Le système de typage de caml génère pour chaque programme la preuve qu'il utilise ses données de manière cohérente : il génère la preuve que le programme ne peut pas planter. Du moins si il plante, ce n'est pas de sa faute mais celle du système d'exploitation ou du matériel.
Ou surtout du programmeur qui programme comme un manche... Le système de type du C n'est pas incohérent. Le typage est faible, il y a des conversions implicites qui sont parfois gênantes, mais c'est tout. Évidemment, la permissivité du C permet de faire un peu n'importe quoi sans nécessairement le signaler, et du coup on ne peut effectivement pas garantir la cohérence du typage des données (mais ça, dès que l'on utilise des pointeurs, ce n'est de toute façon pas possible).
Honnêtement, pour quelqu'un qui programme depuis longtemps, les erreurs de typage sont assez rares. Par contre, les dépassements de mémoire ça arrive bien souvent, mais ça, aucun compilateur n'est encore capable de le détecter, et ça n'a strictement rien à voir avec le typage. La plupart des erreurs, c'est encore au niveau des calculs que l'on effectue qu'elles se situent (oubli d'appeler une sous-fonction, erreur d'indice,...). Évidemment, si tu n'as qu'une confiance relative dans les capacités de ton programmeur, ne le laisse surtout pas programmer en C, c'est la meilleur chance d'avoir un truc illisible et non portable, en plus de buggué.
Nicolas George
Tom , dans le message <422f23d0$0$31661$, a écrit :
Par contre on ne pourra pas contredire le fait qu'on puisse écrire dedans
On ne peut pas écrire dedans, puisqu'elle n'existe pas. Tu es du genre à regarder les cavaliers sans têtes dans les yeux qu'ils n'ont pas, toi ?
Tom , dans le message <422f23d0$0$31661$636a15ce@news.free.fr>, a
écrit :
Par contre on ne
pourra pas contredire le fait qu'on puisse écrire dedans
On ne peut pas écrire dedans, puisqu'elle n'existe pas. Tu es du genre à
regarder les cavaliers sans têtes dans les yeux qu'ils n'ont pas, toi ?
Tom , dans le message <422f23d0$0$31661$, a écrit :
Par contre on ne pourra pas contredire le fait qu'on puisse écrire dedans
On ne peut pas écrire dedans, puisqu'elle n'existe pas. Tu es du genre à regarder les cavaliers sans têtes dans les yeux qu'ils n'ont pas, toi ?
JKB
Le 09-03-2005, à propos de Re: a-t-on le choix ?, JustMe écrivait dans fr.comp.os.linux.debats :
Il se trouve que Tom a formulé :
Ah ? Un programme qui plante c'est la faute du systeme maintenant :-D
Le programme ne gère pas la mémoire.
Tom
Le programme demande de la mémoire au systeme qui lui repond "oui" ou "non"
Ou peut-être.
Apres, le traitement du "non" est parfois baclé par des programmeurs merdiques...
s/bâclé/négligé/
Et personne n'assure que si malloc() renvoie un pointeur non NULL, la mémoire est utilisable. Tout ce que l'on sait, c'est que si le pointeur retourné est NULL, il y aura un problème...
JKB
Le 09-03-2005, à propos de
Re: a-t-on le choix ?,
JustMe écrivait dans fr.comp.os.linux.debats :
Il se trouve que Tom a formulé :
Ah ? Un programme qui plante c'est la faute du systeme maintenant :-D
Le programme ne gère pas la mémoire.
Tom
Le programme demande de la mémoire au systeme qui lui repond "oui" ou
"non"
Ou peut-être.
Apres, le traitement du "non" est parfois baclé par des programmeurs
merdiques...
s/bâclé/négligé/
Et personne n'assure que si malloc() renvoie un pointeur non NULL,
la mémoire est utilisable. Tout ce que l'on sait, c'est que si le
pointeur retourné est NULL, il y aura un problème...
Le 09-03-2005, à propos de Re: a-t-on le choix ?, JustMe écrivait dans fr.comp.os.linux.debats :
Il se trouve que Tom a formulé :
Ah ? Un programme qui plante c'est la faute du systeme maintenant :-D
Le programme ne gère pas la mémoire.
Tom
Le programme demande de la mémoire au systeme qui lui repond "oui" ou "non"
Ou peut-être.
Apres, le traitement du "non" est parfois baclé par des programmeurs merdiques...
s/bâclé/négligé/
Et personne n'assure que si malloc() renvoie un pointeur non NULL, la mémoire est utilisable. Tout ce que l'on sait, c'est que si le pointeur retourné est NULL, il y aura un problème...
JKB
Richard Delorme
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Richard Delorme écrivait dans fr.comp.os.linux.debats :
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.
D'accord. Pas portable pour un sou. J'ai essayé. Au passage, ce truc ne vous garantit jamais la structure même de l'entier.
C'est portable entre les compilateurs qui supportent la norme C99.
-- Richard
Le 09-03-2005, à propos de
Re: a-t-on le choix ?,
Richard Delorme écrivait dans fr.comp.os.linux.debats :
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.
D'accord. Pas portable pour un sou. J'ai essayé. Au passage, ce truc
ne vous garantit jamais la structure même de l'entier.
C'est portable entre les compilateurs qui supportent la norme C99.
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Richard Delorme écrivait dans fr.comp.os.linux.debats :
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.
D'accord. Pas portable pour un sou. J'ai essayé. Au passage, ce truc ne vous garantit jamais la structure même de l'entier.
C'est portable entre les compilateurs qui supportent la norme C99.
-- Richard
Tom
Apres, le traitement du "non" est parfois baclé par des programmeurs merdiques... On revient au problème entre la chaise et le clavier. Problème qui est
traité trop à la légère dans le C.
Tom
Apres, le traitement du "non" est parfois baclé par des programmeurs
merdiques...
On revient au problème entre la chaise et le clavier. Problème qui est
Apres, le traitement du "non" est parfois baclé par des programmeurs merdiques... On revient au problème entre la chaise et le clavier. Problème qui est
traité trop à la légère dans le C.
Tom
JustMe
JKB avait énoncé :
Le 09-03-2005, à propos de Re: a-t-on le choix ?, JustMe écrivait dans fr.comp.os.linux.debats :
Il se trouve que Tom a formulé :
Ah ? Un programme qui plante c'est la faute du systeme maintenant :-D
Le programme ne gère pas la mémoire.
Tom
Le programme demande de la mémoire au systeme qui lui repond "oui" ou "non"
Ou peut-être.
"peut etre" ? Un systeme qui fait de la logique floue ? Ah ?
C'est windows ? ;-)
Apres, le traitement du "non" est parfois baclé par des programmeurs merdiques...
s/bâclé/négligé/
non, baclé. Reserver de la mémoire sans se soucier de l'echer ou de la reussite de la reservation c'est du travail baclé
Et personne n'assure que si malloc() renvoie un pointeur non NULL, la mémoire est utilisable.
Ah ? Source ?
Tout ce que l'on sait, c'est que si le pointeur retourné est NULL, il y aura un problème...
JKB avait énoncé :
Le 09-03-2005, à propos de
Re: a-t-on le choix ?,
JustMe écrivait dans fr.comp.os.linux.debats :
Il se trouve que Tom a formulé :
Ah ? Un programme qui plante c'est la faute du systeme maintenant :-D
Le programme ne gère pas la mémoire.
Tom
Le programme demande de la mémoire au systeme qui lui repond "oui" ou
"non"
Ou peut-être.
"peut etre" ? Un systeme qui fait de la logique floue ? Ah ?
C'est windows ? ;-)
Apres, le traitement du "non" est parfois baclé par des programmeurs
merdiques...
s/bâclé/négligé/
non, baclé. Reserver de la mémoire sans se soucier de l'echer ou de la
reussite de la reservation c'est du travail baclé
Et personne n'assure que si malloc() renvoie un pointeur non NULL,
la mémoire est utilisable.
Ah ? Source ?
Tout ce que l'on sait, c'est que si le
pointeur retourné est NULL, il y aura un problème...
Le 09-03-2005, à propos de Re: a-t-on le choix ?, JustMe écrivait dans fr.comp.os.linux.debats :
Il se trouve que Tom a formulé :
Ah ? Un programme qui plante c'est la faute du systeme maintenant :-D
Le programme ne gère pas la mémoire.
Tom
Le programme demande de la mémoire au systeme qui lui repond "oui" ou "non"
Ou peut-être.
"peut etre" ? Un systeme qui fait de la logique floue ? Ah ?
C'est windows ? ;-)
Apres, le traitement du "non" est parfois baclé par des programmeurs merdiques...
s/bâclé/négligé/
non, baclé. Reserver de la mémoire sans se soucier de l'echer ou de la reussite de la reservation c'est du travail baclé
Et personne n'assure que si malloc() renvoie un pointeur non NULL, la mémoire est utilisable.
Ah ? Source ?
Tout ce que l'on sait, c'est que si le pointeur retourné est NULL, il y aura un problème...
JustMe
Apres, le traitement du "non" est parfois baclé par des programmeurs merdiques... On revient au problème entre la chaise et le clavier. Problème qui est traité
trop à la légère dans le C.
Tom
Et pas mieux en caml d'apres l'exemple :-D
Apres, le traitement du "non" est parfois baclé par des programmeurs
merdiques...
On revient au problème entre la chaise et le clavier. Problème qui est traité
Apres, le traitement du "non" est parfois baclé par des programmeurs merdiques... On revient au problème entre la chaise et le clavier. Problème qui est traité
