Le 28-11-2009, ? propos de Re: go, batyann811 ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Mouais... Affaire de goût. Le seul avantage de ce type, c'est d'avoir rué contre le goto.
Je trouve qu'il a quand même pondu des langages pas mal : Pascal,
Il faudra un jour qu'on m'explique la différence _fondamentale_ entre C et Pascal. J'ai beau chercher, je ne vois pas bien. On peut écrire un compilo Pascal à l'aide d'un préprocesseur et de gcc (c'est même comme ça qu'on compile généralement du Pascal sous Unix).
On ne peut pas faire le contraire.
-- Richard
Le 28/11/2009 15:18, JKB a écrit :
Le 28-11-2009, ? propos de
Re: go,
batyann811 ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Mouais... Affaire de goût. Le seul avantage de ce type, c'est
d'avoir rué contre le goto.
Je trouve qu'il a quand même pondu des langages pas mal : Pascal,
Il faudra un jour qu'on m'explique la différence _fondamentale_
entre C et Pascal. J'ai beau chercher, je ne vois pas bien.
On peut écrire un compilo Pascal à l'aide d'un préprocesseur et de
gcc (c'est même comme ça qu'on compile généralement du Pascal sous Unix).
Le 28-11-2009, ? propos de Re: go, batyann811 ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Mouais... Affaire de goût. Le seul avantage de ce type, c'est d'avoir rué contre le goto.
Je trouve qu'il a quand même pondu des langages pas mal : Pascal,
Il faudra un jour qu'on m'explique la différence _fondamentale_ entre C et Pascal. J'ai beau chercher, je ne vois pas bien. On peut écrire un compilo Pascal à l'aide d'un préprocesseur et de gcc (c'est même comme ça qu'on compile généralement du Pascal sous Unix).
On ne peut pas faire le contraire.
-- Richard
batyann811
Francky a écrit :
Pascal est antérieur à C donc je ne vois pas comment Niklaus Wirth aurait pu vouloir sécuriser quelque chose qui n'existait pas lorsqu'il a conçu le Pascal.
Ha ! Oui c'est vrai en plus. Le C est donc bien une régression. Merci de ton soutien.
Il n'y a pas d'obligation de récupération des exception en Java. Java met en oeuvre deux types d'exception. Les "checked exception" et les "unchecked exception".
Les "checked exception" doivent être traitées *ou* être spécifiées dans une clause throws.
Oui mais justement ça c'est un peu lourd. Encore que maintenant au moins avec Netbeans les clauses throws sont générées automatiquement.
Francky a écrit :
Pascal est antérieur à C donc je ne vois pas comment Niklaus Wirth aurait
pu vouloir sécuriser quelque chose qui n'existait pas lorsqu'il a conçu
le Pascal.
Ha ! Oui c'est vrai en plus. Le C est donc bien une régression. Merci de
ton soutien.
Il n'y a pas d'obligation de récupération des exception en Java. Java
met en oeuvre deux types d'exception. Les "checked exception" et les
"unchecked exception".
Les "checked exception" doivent être traitées *ou* être spécifiées dans
une clause throws.
Oui mais justement ça c'est un peu lourd. Encore que maintenant au moins
avec Netbeans les clauses throws sont générées automatiquement.
Pascal est antérieur à C donc je ne vois pas comment Niklaus Wirth aurait pu vouloir sécuriser quelque chose qui n'existait pas lorsqu'il a conçu le Pascal.
Ha ! Oui c'est vrai en plus. Le C est donc bien une régression. Merci de ton soutien.
Il n'y a pas d'obligation de récupération des exception en Java. Java met en oeuvre deux types d'exception. Les "checked exception" et les "unchecked exception".
Les "checked exception" doivent être traitées *ou* être spécifiées dans une clause throws.
Oui mais justement ça c'est un peu lourd. Encore que maintenant au moins avec Netbeans les clauses throws sont générées automatiquement.
JKB
Le 28-11-2009, ? propos de Re: go, batyann811 ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Je parle de différences _fondamentales_ et non de garde-fous. Rien n'empêche d'écrire un compilo C qui regarde les bornes des tableaux (par exemple). Il n'y a aucune différence entre le C et le Pascal for ces garde-fous (le 'var' n'est par exemple qu'une façon de masquer un pointeur dans un passage d'argument).
Je trouve que tous ces garde-fous font une grande différence à l'usage. Tous les compilos pascal, ADA ou Modula ont ces garde-fous à ma connaissance. Pour le C je n'en connais pas (de toute façon je connais que gcc et turbo c en son temps). J'ai bien essayé des trucs genre lint ou splint mais bof...
Il n'y a pas que le préprocesseur du C. On peut faire des tas de trucs avec un vrai préprocesseur comme m4.
Tu as un lien vers un préprocesseur qui traduit du pascal en C ?
Il y en a un dans toute bonne distributino Linux.
Le compilo ne peut pas imaginer tous les usages de la syntaxe. Après, c'est une histoire de compromis. En cela, Pascal est une bouse parce qu'il part de l'unique principe qu'il 'sécurise' le C.
Moi je vois plutôt ça comme un pas dans la bonne direction. Et le C comme un régression.
Je n'ai pas dit que c'était une régression. Simplement que la syntaxe trop stricte est une connerie.
C'est au programmeur de savoir ce qu'il fait. Maintenant, un enum peut parfaitement rentrer dans un switch, et le switch prend un argument entier.
Là je ne vois pas trop ou tu veux en venir. En pascal ou en ADA tu peux utiliser n'importe quel type scalaire dans l'équivalent du swicth. Avec en plus pour l'ADA l'obligation de traiter tous les cas possible comme ça pas de risque d'en oublier.
Le problème n'est pas de risquer d'en oublier. Le problème est que le switch est ce qu'il est convenu d'appeler en Fortran un 'goto calculé'. Ça prend naturellement un entier en entrée.
Non. Java t'impose la récupération des erreurs alors que dans certains cas, tu sais par avance qu'il n'y a pas d'erreur. C'est tout aussi con comme technique. Je te répète que c'est au programmeur de savoir ce qu'il fait. On peut écrire du code crade dans tous les langages. Le simple fait de rajouter des contraintes se justifie aux marges, mais pas dans une utilisation standard.
Pour la récupération obligatoire des exceptions de Java c'est vrai que c'est un peu lourd. Mais je l'avais glissé pour te faire râler. Fais gaffe t'es à la limite du réflexe pavlovien. ;-)
Après pour ton "c'est au programmeur de savoir ce qu'il fait" je ne vois pas en quoi le fait d'avoir ce que tu as nommé plus haut des garde-fous l'empêche de savoir ce qu'il fait d'autant qu'au besoin on peut contourner ces protections. Pour ma part je préfère laisser le compilateur détecter le plus possible de mes erreurs.
Le C n'a pas de garde-fous parce qu'il est conçu pour faire de la programmation système dans laquelle on fait souvent des trucs pas vraiment nets, mais nécessaire. Il suffit de regarder un noyau Unix pour s'en convaincre. Je n'aurais pas voulu l'écrire en Pascal.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 28-11-2009, ? propos de
Re: go,
batyann811 ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Je parle de différences _fondamentales_ et non de garde-fous. Rien
n'empêche d'écrire un compilo C qui regarde les bornes des tableaux
(par exemple). Il n'y a aucune différence entre le C et le Pascal
for ces garde-fous (le 'var' n'est par exemple qu'une façon de
masquer un pointeur dans un passage d'argument).
Je trouve que tous ces garde-fous font une grande différence à l'usage.
Tous les compilos pascal, ADA ou Modula ont ces garde-fous à ma
connaissance. Pour le C je n'en connais pas (de toute façon je connais
que gcc et turbo c en son temps). J'ai bien essayé des trucs genre lint
ou splint mais bof...
Il n'y a pas que le préprocesseur du C. On peut faire des tas de
trucs avec un vrai préprocesseur comme m4.
Tu as un lien vers un préprocesseur qui traduit du pascal en C ?
Il y en a un dans toute bonne distributino Linux.
Le compilo ne peut pas imaginer tous les usages de la syntaxe.
Après, c'est une histoire de compromis. En cela, Pascal est une
bouse parce qu'il part de l'unique principe qu'il 'sécurise' le C.
Moi je vois plutôt ça comme un pas dans la bonne direction. Et le C
comme un régression.
Je n'ai pas dit que c'était une régression. Simplement que la
syntaxe trop stricte est une connerie.
C'est au programmeur de savoir ce qu'il fait. Maintenant, un enum
peut parfaitement rentrer dans un switch, et le switch prend un
argument entier.
Là je ne vois pas trop ou tu veux en venir. En pascal ou en ADA tu peux
utiliser n'importe quel type scalaire dans l'équivalent du swicth. Avec
en plus pour l'ADA l'obligation de traiter tous les cas possible comme
ça pas de risque d'en oublier.
Le problème n'est pas de risquer d'en oublier. Le problème est que
le switch est ce qu'il est convenu d'appeler en Fortran un 'goto
calculé'. Ça prend naturellement un entier en entrée.
Non. Java t'impose la récupération des erreurs alors que dans
certains cas, tu sais par avance qu'il n'y a pas d'erreur. C'est
tout aussi con comme technique. Je te répète que c'est au
programmeur de savoir ce qu'il fait. On peut écrire du code crade
dans tous les langages. Le simple fait de rajouter des contraintes
se justifie aux marges, mais pas dans une utilisation standard.
Pour la récupération obligatoire des exceptions de Java c'est vrai que
c'est un peu lourd. Mais je l'avais glissé pour te faire râler. Fais
gaffe t'es à la limite du réflexe pavlovien. ;-)
Après pour ton "c'est au programmeur de savoir ce qu'il fait" je ne vois
pas en quoi le fait d'avoir ce que tu as nommé plus haut des garde-fous
l'empêche de savoir ce qu'il fait d'autant qu'au besoin on peut
contourner ces protections. Pour ma part je préfère laisser le
compilateur détecter le plus possible de mes erreurs.
Le C n'a pas de garde-fous parce qu'il est conçu pour faire de la
programmation système dans laquelle on fait souvent des trucs pas
vraiment nets, mais nécessaire. Il suffit de regarder un noyau Unix
pour s'en convaincre. Je n'aurais pas voulu l'écrire en Pascal.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 28-11-2009, ? propos de Re: go, batyann811 ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Je parle de différences _fondamentales_ et non de garde-fous. Rien n'empêche d'écrire un compilo C qui regarde les bornes des tableaux (par exemple). Il n'y a aucune différence entre le C et le Pascal for ces garde-fous (le 'var' n'est par exemple qu'une façon de masquer un pointeur dans un passage d'argument).
Je trouve que tous ces garde-fous font une grande différence à l'usage. Tous les compilos pascal, ADA ou Modula ont ces garde-fous à ma connaissance. Pour le C je n'en connais pas (de toute façon je connais que gcc et turbo c en son temps). J'ai bien essayé des trucs genre lint ou splint mais bof...
Il n'y a pas que le préprocesseur du C. On peut faire des tas de trucs avec un vrai préprocesseur comme m4.
Tu as un lien vers un préprocesseur qui traduit du pascal en C ?
Il y en a un dans toute bonne distributino Linux.
Le compilo ne peut pas imaginer tous les usages de la syntaxe. Après, c'est une histoire de compromis. En cela, Pascal est une bouse parce qu'il part de l'unique principe qu'il 'sécurise' le C.
Moi je vois plutôt ça comme un pas dans la bonne direction. Et le C comme un régression.
Je n'ai pas dit que c'était une régression. Simplement que la syntaxe trop stricte est une connerie.
C'est au programmeur de savoir ce qu'il fait. Maintenant, un enum peut parfaitement rentrer dans un switch, et le switch prend un argument entier.
Là je ne vois pas trop ou tu veux en venir. En pascal ou en ADA tu peux utiliser n'importe quel type scalaire dans l'équivalent du swicth. Avec en plus pour l'ADA l'obligation de traiter tous les cas possible comme ça pas de risque d'en oublier.
Le problème n'est pas de risquer d'en oublier. Le problème est que le switch est ce qu'il est convenu d'appeler en Fortran un 'goto calculé'. Ça prend naturellement un entier en entrée.
Non. Java t'impose la récupération des erreurs alors que dans certains cas, tu sais par avance qu'il n'y a pas d'erreur. C'est tout aussi con comme technique. Je te répète que c'est au programmeur de savoir ce qu'il fait. On peut écrire du code crade dans tous les langages. Le simple fait de rajouter des contraintes se justifie aux marges, mais pas dans une utilisation standard.
Pour la récupération obligatoire des exceptions de Java c'est vrai que c'est un peu lourd. Mais je l'avais glissé pour te faire râler. Fais gaffe t'es à la limite du réflexe pavlovien. ;-)
Après pour ton "c'est au programmeur de savoir ce qu'il fait" je ne vois pas en quoi le fait d'avoir ce que tu as nommé plus haut des garde-fous l'empêche de savoir ce qu'il fait d'autant qu'au besoin on peut contourner ces protections. Pour ma part je préfère laisser le compilateur détecter le plus possible de mes erreurs.
Le C n'a pas de garde-fous parce qu'il est conçu pour faire de la programmation système dans laquelle on fait souvent des trucs pas vraiment nets, mais nécessaire. Il suffit de regarder un noyau Unix pour s'en convaincre. Je n'aurais pas voulu l'écrire en Pascal.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
JKB
Le 28-11-2009, ? propos de Re: go, Francky ?crivait dans fr.comp.os.linux.debats :
batyann811 a écrit:
Le compilo ne peut pas imaginer tous les usages de la syntaxe. Après, c'est une histoire de compromis. En cela, Pascal est une bouse parce qu'il part de l'unique principe qu'il 'sécurise' le C.
Moi je vois plutôt ça comme un pas dans la bonne direction. Et le C comme un régression.
Pascal est antérieur à C donc je ne vois pas comment Niklaus Wirth aurait pu vouloir sécuriser quelque chose qui n'existait pas lorsqu'il a conçu le Pascal.
Euh... La première version de Pascal date de 69. La première version de C de 72. Sauf que pour avoir eu dans les pattes un compilo Pascal originel (celui qui ne connaît même pas les chaînes de caractères), je peux t'assurer que la grande évolution du Pascal a été faite en même temps que celle du C, à savoir à partir du milieu des années 70.
Pour la récupération obligatoire des exceptions de Java c'est vrai que c'est un peu lourd.
Il n'y a pas d'obligation de récupération des exception en Java. Java met en oeuvre deux types d'exception. Les "checked exception" et les "unchecked exception".
Les "checked exception" doivent être traitées *ou* être spécifiées dans une clause throws.
Les "unchecked exception" peuvent être traitées et il n'est pas nécéssaire de les spécifier dans une clause throws. Cela concerne les RuntimeException, Error et les dérivées de ces classes.
Lorsqu'un "unchecked exception" n'est pas traitée, c'est au thread courant de la traiter au travers de son UncaughtExceptionHandler s'il en a un ou à celui du ThreadGroup auquel il appartient.
Ce qui revient à dire qu'elle est toujours traitée.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 28-11-2009, ? propos de
Re: go,
Francky ?crivait dans fr.comp.os.linux.debats :
batyann811 a écrit:
Le compilo ne peut pas imaginer tous les usages de la syntaxe.
Après, c'est une histoire de compromis. En cela, Pascal est une
bouse parce qu'il part de l'unique principe qu'il 'sécurise' le C.
Moi je vois plutôt ça comme un pas dans la bonne direction. Et le C
comme un régression.
Pascal est antérieur à C donc je ne vois pas comment Niklaus Wirth aurait
pu vouloir sécuriser quelque chose qui n'existait pas lorsqu'il a conçu
le Pascal.
Euh... La première version de Pascal date de 69. La première version
de C de 72. Sauf que pour avoir eu dans les pattes un compilo Pascal
originel (celui qui ne connaît même pas les chaînes de caractères),
je peux t'assurer que la grande évolution du Pascal a été faite en
même temps que celle du C, à savoir à partir du milieu des années 70.
Pour la récupération obligatoire des exceptions de Java c'est vrai que
c'est un peu lourd.
Il n'y a pas d'obligation de récupération des exception en Java. Java
met en oeuvre deux types d'exception. Les "checked exception" et les
"unchecked exception".
Les "checked exception" doivent être traitées *ou* être spécifiées dans
une clause throws.
Les "unchecked exception" peuvent être traitées et il n'est pas nécéssaire
de les spécifier dans une clause throws. Cela concerne les
RuntimeException,
Error et les dérivées de ces classes.
Lorsqu'un "unchecked exception" n'est pas traitée, c'est au thread courant
de la traiter au travers de son UncaughtExceptionHandler s'il en a un ou
à celui du ThreadGroup auquel il appartient.
Ce qui revient à dire qu'elle est toujours traitée.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 28-11-2009, ? propos de Re: go, Francky ?crivait dans fr.comp.os.linux.debats :
batyann811 a écrit:
Le compilo ne peut pas imaginer tous les usages de la syntaxe. Après, c'est une histoire de compromis. En cela, Pascal est une bouse parce qu'il part de l'unique principe qu'il 'sécurise' le C.
Moi je vois plutôt ça comme un pas dans la bonne direction. Et le C comme un régression.
Pascal est antérieur à C donc je ne vois pas comment Niklaus Wirth aurait pu vouloir sécuriser quelque chose qui n'existait pas lorsqu'il a conçu le Pascal.
Euh... La première version de Pascal date de 69. La première version de C de 72. Sauf que pour avoir eu dans les pattes un compilo Pascal originel (celui qui ne connaît même pas les chaînes de caractères), je peux t'assurer que la grande évolution du Pascal a été faite en même temps que celle du C, à savoir à partir du milieu des années 70.
Pour la récupération obligatoire des exceptions de Java c'est vrai que c'est un peu lourd.
Il n'y a pas d'obligation de récupération des exception en Java. Java met en oeuvre deux types d'exception. Les "checked exception" et les "unchecked exception".
Les "checked exception" doivent être traitées *ou* être spécifiées dans une clause throws.
Les "unchecked exception" peuvent être traitées et il n'est pas nécéssaire de les spécifier dans une clause throws. Cela concerne les RuntimeException, Error et les dérivées de ces classes.
Lorsqu'un "unchecked exception" n'est pas traitée, c'est au thread courant de la traiter au travers de son UncaughtExceptionHandler s'il en a un ou à celui du ThreadGroup auquel il appartient.
Ce qui revient à dire qu'elle est toujours traitée.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
batyann811
JKB a écrit :
Il y en a un dans toute bonne distributino Linux.
Chic une liste !
J'espère que tu ne considère pas que p2c est un préprocesseur ?
Je n'ai pas dit que c'était une régression. Simplement que la syntaxe trop stricte est une connerie.
C'est une affaire de goût on va dire. Je pense plutôt que c'est un ensemble de sécurités pour limiter les bugs.
Le problème n'est pas de risquer d'en oublier. Le problème est que le switch est ce qu'il est convenu d'appeler en Fortran un 'goto calculé'. Ça prend naturellement un entier en entrée.
Outre que le risque d'oubli ne me semble pas anodin je ne vois pas pourquoi l'entrée d'un switch doit être un entier. Un entier ou un enum on s'en fout c'est le compilo qui fait le traduction. Bien sûr il en fait un entier à la fin mais pour le programeur entier, enum ou caractère il s'en cogne.
Le C n'a pas de garde-fous parce qu'il est conçu pour faire de la programmation système dans laquelle on fait souvent des trucs pas vraiment nets, mais nécessaire. Il suffit de regarder un noyau Unix pour s'en convaincre. Je n'aurais pas voulu l'écrire en Pascal.
Ce sur quoi j'ai déjà dit être tout à fait d'accord.
JKB a écrit :
Il y en a un dans toute bonne distributino Linux.
Chic une liste !
J'espère que tu ne considère pas que p2c est un préprocesseur ?
Je n'ai pas dit que c'était une régression. Simplement que la
syntaxe trop stricte est une connerie.
C'est une affaire de goût on va dire. Je pense plutôt que c'est un
ensemble de sécurités pour limiter les bugs.
Le problème n'est pas de risquer d'en oublier. Le problème est que
le switch est ce qu'il est convenu d'appeler en Fortran un 'goto
calculé'. Ça prend naturellement un entier en entrée.
Outre que le risque d'oubli ne me semble pas anodin je ne vois pas
pourquoi l'entrée d'un switch doit être un entier. Un entier ou un enum
on s'en fout c'est le compilo qui fait le traduction. Bien sûr il en
fait un entier à la fin mais pour le programeur entier, enum ou
caractère il s'en cogne.
Le C n'a pas de garde-fous parce qu'il est conçu pour faire de la
programmation système dans laquelle on fait souvent des trucs pas
vraiment nets, mais nécessaire. Il suffit de regarder un noyau Unix
pour s'en convaincre. Je n'aurais pas voulu l'écrire en Pascal.
Ce sur quoi j'ai déjà dit être tout à fait d'accord.
J'espère que tu ne considère pas que p2c est un préprocesseur ?
Je n'ai pas dit que c'était une régression. Simplement que la syntaxe trop stricte est une connerie.
C'est une affaire de goût on va dire. Je pense plutôt que c'est un ensemble de sécurités pour limiter les bugs.
Le problème n'est pas de risquer d'en oublier. Le problème est que le switch est ce qu'il est convenu d'appeler en Fortran un 'goto calculé'. Ça prend naturellement un entier en entrée.
Outre que le risque d'oubli ne me semble pas anodin je ne vois pas pourquoi l'entrée d'un switch doit être un entier. Un entier ou un enum on s'en fout c'est le compilo qui fait le traduction. Bien sûr il en fait un entier à la fin mais pour le programeur entier, enum ou caractère il s'en cogne.
Le C n'a pas de garde-fous parce qu'il est conçu pour faire de la programmation système dans laquelle on fait souvent des trucs pas vraiment nets, mais nécessaire. Il suffit de regarder un noyau Unix pour s'en convaincre. Je n'aurais pas voulu l'écrire en Pascal.
Ce sur quoi j'ai déjà dit être tout à fait d'accord.
Patrick Lamaizière
batyann811 :
Ahahahahaha....
Toujours les même vieilles conneries depuis 30 ans (même si tout n'est pas faux). Tu sais que le pascal à largement évolué depuis ?
Oui, on peut même dire qu'il est mort.
batyann811 :
Ahahahahaha....
Toujours les même vieilles conneries depuis 30 ans (même si tout n'est
pas faux). Tu sais que le pascal à largement évolué depuis ?
Toujours les même vieilles conneries depuis 30 ans (même si tout n'est pas faux). Tu sais que le pascal à largement évolué depuis ?
Oui, on peut même dire qu'il est mort.
batyann811
Patrick Lamaizière a écrit :
Oui, on peut même dire qu'il est mort.
Pas tout à fait mort mais dans un coma végétatif irréversible. Ce qui n'empêche pas que la plupart des critiques de ce vieux document ne sont plus d'actualité depuis au moins 25 ans...
Patrick Lamaizière a écrit :
Oui, on peut même dire qu'il est mort.
Pas tout à fait mort mais dans un coma végétatif irréversible. Ce qui
n'empêche pas que la plupart des critiques de ce vieux document ne sont
plus d'actualité depuis au moins 25 ans...
Pas tout à fait mort mais dans un coma végétatif irréversible. Ce qui n'empêche pas que la plupart des critiques de ce vieux document ne sont plus d'actualité depuis au moins 25 ans...
Stephane TOUGARD
JKB wrote:
... Si pour éviter des constructions de structures conditionnelles tu es contraint à l'utilisation du goto, c'est que ton code a un sérieux problème de conception.
Ah, ca y est, le grand maitre du code et de la raison universelle a parle.
Puisque tu es un grand defenseur des grandes choses et un grand attaquants des mauvaises. J'ai voulu voir si les grandes choses en faisaient des mauvaises :
En tous cas, il semble que qmail ai environ 15 fois moins de "problemes de conception" que sendmail ... environ. Tout ca pour arriver a un objectif similaire (etre un MX).
J'attends aussi l'argument du "le goto, ça évite au programme de gérer la pile en passant d'un point à un autre d'une routine", parce
Bof, pour moi le goto ca sert simplement a ce que j'ai deja dit : eviter des if imbriques les uns dans les autres a en rendre le programme illisible.
Il me semble d'ailleurs que malgre qu'un tas d'andouilles le considerent salement, c'est une instruction dont on ne saurait se passer des qu'un projet depasse une certaine taille et une certaine complexite.
JKB wrote:
... Si pour éviter des constructions
de structures conditionnelles tu es contraint à l'utilisation du goto,
c'est que ton code a un sérieux problème de conception.
Ah, ca y est, le grand maitre du code et de la raison universelle a parle.
Puisque tu es un grand defenseur des grandes choses et un grand
attaquants des mauvaises. J'ai voulu voir si les grandes choses en
faisaient des mauvaises :
En tous cas, il semble que qmail ai environ 15 fois moins de "problemes
de conception" que sendmail ... environ. Tout ca pour arriver a un
objectif similaire (etre un MX).
J'attends aussi l'argument du "le goto, ça évite au programme de
gérer la pile en passant d'un point à un autre d'une routine", parce
Bof, pour moi le goto ca sert simplement a ce que j'ai deja dit : eviter
des if imbriques les uns dans les autres a en rendre le programme
illisible.
Il me semble d'ailleurs que malgre qu'un tas d'andouilles le considerent
salement, c'est une instruction dont on ne saurait se passer des qu'un
projet depasse une certaine taille et une certaine complexite.
... Si pour éviter des constructions de structures conditionnelles tu es contraint à l'utilisation du goto, c'est que ton code a un sérieux problème de conception.
Ah, ca y est, le grand maitre du code et de la raison universelle a parle.
Puisque tu es un grand defenseur des grandes choses et un grand attaquants des mauvaises. J'ai voulu voir si les grandes choses en faisaient des mauvaises :
En tous cas, il semble que qmail ai environ 15 fois moins de "problemes de conception" que sendmail ... environ. Tout ca pour arriver a un objectif similaire (etre un MX).
J'attends aussi l'argument du "le goto, ça évite au programme de gérer la pile en passant d'un point à un autre d'une routine", parce
Bof, pour moi le goto ca sert simplement a ce que j'ai deja dit : eviter des if imbriques les uns dans les autres a en rendre le programme illisible.
Il me semble d'ailleurs que malgre qu'un tas d'andouilles le considerent salement, c'est une instruction dont on ne saurait se passer des qu'un projet depasse une certaine taille et une certaine complexite.
Richard Delorme
Le 28/11/2009 23:24, Stephane TOUGARD a écrit :
Bof, pour moi le goto ca sert simplement a ce que j'ai deja dit : eviter des if imbriques les uns dans les autres a en rendre le programme illisible.
Il me semble d'ailleurs que malgre qu'un tas d'andouilles le considerent salement, c'est une instruction dont on ne saurait se passer des qu'un projet depasse une certaine taille et une certaine complexite.
On peut toujours se passer du goto, mais parfois le remède est pire que le mal.
-- Richard
Le 28/11/2009 23:24, Stephane TOUGARD a écrit :
Bof, pour moi le goto ca sert simplement a ce que j'ai deja dit : eviter
des if imbriques les uns dans les autres a en rendre le programme
illisible.
Il me semble d'ailleurs que malgre qu'un tas d'andouilles le considerent
salement, c'est une instruction dont on ne saurait se passer des qu'un
projet depasse une certaine taille et une certaine complexite.
On peut toujours se passer du goto, mais parfois le remède est pire que
le mal.
Bof, pour moi le goto ca sert simplement a ce que j'ai deja dit : eviter des if imbriques les uns dans les autres a en rendre le programme illisible.
Il me semble d'ailleurs que malgre qu'un tas d'andouilles le considerent salement, c'est une instruction dont on ne saurait se passer des qu'un projet depasse une certaine taille et une certaine complexite.
On peut toujours se passer du goto, mais parfois le remède est pire que le mal.
-- Richard
JKB
Le 28-11-2009, ? propos de Re: go, batyann811 ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Il y en a un dans toute bonne distributino Linux.
Chic une liste !
J'espère que tu ne considère pas que p2c est un préprocesseur ?
Et tu appelles ça comment ?
Je n'ai pas dit que c'était une régression. Simplement que la syntaxe trop stricte est une connerie.
C'est une affaire de goût on va dire. Je pense plutôt que c'est un ensemble de sécurités pour limiter les bugs.
Le problème est qu'on utilise un langage ou un autre en fonction du résultat. Rendre le C strict est une connerie parce que ça empêche de faire certaines choses. Rendre ADA moins strict est une autre connerie parce qu'il a justement été conçu pour d'autres choses.
Le problème n'est pas de risquer d'en oublier. Le problème est que le switch est ce qu'il est convenu d'appeler en Fortran un 'goto calculé'. Ça prend naturellement un entier en entrée.
Outre que le risque d'oubli ne me semble pas anodin je ne vois pas pourquoi l'entrée d'un switch doit être un entier. Un entier ou un enum on s'en fout c'est le compilo qui fait le traduction. Bien sûr il en fait un entier à la fin mais pour le programeur entier, enum ou caractère il s'en cogne.
Non, le C ne s'en cogne pas parce qu'il a été conçu pour être proche de ce qu'exécute effectivement le processeur. Les contraintes de conception des deux langages diffèrent donc il ne faut pas croire que le résultat final sera le même.
Le C n'a pas de garde-fous parce qu'il est conçu pour faire de la programmation système dans laquelle on fait souvent des trucs pas vraiment nets, mais nécessaire. Il suffit de regarder un noyau Unix pour s'en convaincre. Je n'aurais pas voulu l'écrire en Pascal.
Ce sur quoi j'ai déjà dit être tout à fait d'accord.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 28-11-2009, ? propos de
Re: go,
batyann811 ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Il y en a un dans toute bonne distributino Linux.
Chic une liste !
J'espère que tu ne considère pas que p2c est un préprocesseur ?
Et tu appelles ça comment ?
Je n'ai pas dit que c'était une régression. Simplement que la
syntaxe trop stricte est une connerie.
C'est une affaire de goût on va dire. Je pense plutôt que c'est un
ensemble de sécurités pour limiter les bugs.
Le problème est qu'on utilise un langage ou un autre en fonction du
résultat. Rendre le C strict est une connerie parce que ça empêche
de faire certaines choses. Rendre ADA moins strict est une autre
connerie parce qu'il a justement été conçu pour d'autres choses.
Le problème n'est pas de risquer d'en oublier. Le problème est que
le switch est ce qu'il est convenu d'appeler en Fortran un 'goto
calculé'. Ça prend naturellement un entier en entrée.
Outre que le risque d'oubli ne me semble pas anodin je ne vois pas
pourquoi l'entrée d'un switch doit être un entier. Un entier ou un enum
on s'en fout c'est le compilo qui fait le traduction. Bien sûr il en
fait un entier à la fin mais pour le programeur entier, enum ou
caractère il s'en cogne.
Non, le C ne s'en cogne pas parce qu'il a été conçu pour être proche
de ce qu'exécute effectivement le processeur. Les contraintes de
conception des deux langages diffèrent donc il ne faut pas croire
que le résultat final sera le même.
Le C n'a pas de garde-fous parce qu'il est conçu pour faire de la
programmation système dans laquelle on fait souvent des trucs pas
vraiment nets, mais nécessaire. Il suffit de regarder un noyau Unix
pour s'en convaincre. Je n'aurais pas voulu l'écrire en Pascal.
Ce sur quoi j'ai déjà dit être tout à fait d'accord.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 28-11-2009, ? propos de Re: go, batyann811 ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Il y en a un dans toute bonne distributino Linux.
Chic une liste !
J'espère que tu ne considère pas que p2c est un préprocesseur ?
Et tu appelles ça comment ?
Je n'ai pas dit que c'était une régression. Simplement que la syntaxe trop stricte est une connerie.
C'est une affaire de goût on va dire. Je pense plutôt que c'est un ensemble de sécurités pour limiter les bugs.
Le problème est qu'on utilise un langage ou un autre en fonction du résultat. Rendre le C strict est une connerie parce que ça empêche de faire certaines choses. Rendre ADA moins strict est une autre connerie parce qu'il a justement été conçu pour d'autres choses.
Le problème n'est pas de risquer d'en oublier. Le problème est que le switch est ce qu'il est convenu d'appeler en Fortran un 'goto calculé'. Ça prend naturellement un entier en entrée.
Outre que le risque d'oubli ne me semble pas anodin je ne vois pas pourquoi l'entrée d'un switch doit être un entier. Un entier ou un enum on s'en fout c'est le compilo qui fait le traduction. Bien sûr il en fait un entier à la fin mais pour le programeur entier, enum ou caractère il s'en cogne.
Non, le C ne s'en cogne pas parce qu'il a été conçu pour être proche de ce qu'exécute effectivement le processeur. Les contraintes de conception des deux langages diffèrent donc il ne faut pas croire que le résultat final sera le même.
Le C n'a pas de garde-fous parce qu'il est conçu pour faire de la programmation système dans laquelle on fait souvent des trucs pas vraiment nets, mais nécessaire. Il suffit de regarder un noyau Unix pour s'en convaincre. Je n'aurais pas voulu l'écrire en Pascal.
Ce sur quoi j'ai déjà dit être tout à fait d'accord.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
