avec le C, qd ca marche, c'est que c'est pas si mal, sinon, ca plante.
Alors là, je me gausse.
Le propre d'un UB, c'est que tout peut arriver - même que le programme
*semble* fonctionner. Le fait que le programme semble fonctionner n'est
en rien une preuve de correction. Quant à 'pas si mal', c'est une norme
de qualité que j'ignorais jusque là...
avec le C, qd ca marche, c'est que c'est pas si mal, sinon, ca plante.
Alors là, je me gausse.
Le propre d'un UB, c'est que tout peut arriver - même que le programme
*semble* fonctionner. Le fait que le programme semble fonctionner n'est
en rien une preuve de correction. Quant à 'pas si mal', c'est une norme
de qualité que j'ignorais jusque là...
avec le C, qd ca marche, c'est que c'est pas si mal, sinon, ca plante.
Alors là, je me gausse.
Le propre d'un UB, c'est que tout peut arriver - même que le programme
*semble* fonctionner. Le fait que le programme semble fonctionner n'est
en rien une preuve de correction. Quant à 'pas si mal', c'est une norme
de qualité que j'ignorais jusque là...
Juste pour info : pour une appli Windows avec une interface graphique,
juste pour ouvrir une fenêtre blanche qui ne fait rien, compte une
centaine de lignes de code de C non standard.
En Python, tu peux obtenir la même chose en moins de dix lignes.
Juste pour info : pour une appli Windows avec une interface graphique,
juste pour ouvrir une fenêtre blanche qui ne fait rien, compte une
centaine de lignes de code de C non standard.
En Python, tu peux obtenir la même chose en moins de dix lignes.
Juste pour info : pour une appli Windows avec une interface graphique,
juste pour ouvrir une fenêtre blanche qui ne fait rien, compte une
centaine de lignes de code de C non standard.
En Python, tu peux obtenir la même chose en moins de dix lignes.
Marc Boyer wrote:Et vous y faisiez quoi ? Complexité ? Terminaison et preuve ?
Tout pleins de choses interessantes..;-)
Entre autres, algo des graphes, calculs de complexite, methodes algo...
Et franchement, pour faire 99% des programmes C que je connais, ca sert
pas a grand chose (ou alors, ca sert tellement que je ne m'en rends plus
compte...).
Marc Boyer wrote:
Et vous y faisiez quoi ? Complexité ? Terminaison et preuve ?
Tout pleins de choses interessantes..;-)
Entre autres, algo des graphes, calculs de complexite, methodes algo...
Et franchement, pour faire 99% des programmes C que je connais, ca sert
pas a grand chose (ou alors, ca sert tellement que je ne m'en rends plus
compte...).
Marc Boyer wrote:Et vous y faisiez quoi ? Complexité ? Terminaison et preuve ?
Tout pleins de choses interessantes..;-)
Entre autres, algo des graphes, calculs de complexite, methodes algo...
Et franchement, pour faire 99% des programmes C que je connais, ca sert
pas a grand chose (ou alors, ca sert tellement que je ne m'en rends plus
compte...).
Je ne suis pas tout a fait d'accord avec l'analogie.
void stat(int *min,int *max, int *moy,int valeur[]);
1. ne protege pas le contenu de valeur (contrairement ce que l'on pourrait
attendre)
2. protege min seulement dans ce cas min n'est que le contenant de ce qui
C'est a mon sens une "bidouille" pour modifier le contenu de min.
Si tu passe une adresse comme argument : dans le cas du tableau cette
exemple:
void test(char t[]) {
t[0]= 'A';
}
void test2(int *i) {
i = (int *) malloc(sizeof(int));
printf("%pn",i);
}
int main () {
char t[1];
int *i;
t[0] = 'B';
printf("%cn",t[0]);
Tu test le contenu du tableau pas l'adresse de ce tableau. Le contenu
test(t);
printf("%cn",t[0]);
i = (int *) malloc(sizeof(int));
on teste le NULL en principe sinon explosion ligne suivante de plus je
printf("%pn",i);
test2(i);
printf("%pn",i);
Et les free alors!
return 0;
}
Je ne suis pas tout a fait d'accord avec l'analogie.
void stat(int *min,int *max, int *moy,int valeur[]);
1. ne protege pas le contenu de valeur (contrairement ce que l'on pourrait
attendre)
2. protege min seulement dans ce cas min n'est que le contenant de ce qui
C'est a mon sens une "bidouille" pour modifier le contenu de min.
Si tu passe une adresse comme argument : dans le cas du tableau cette
exemple:
void test(char t[]) {
t[0]= 'A';
}
void test2(int *i) {
i = (int *) malloc(sizeof(int));
printf("%pn",i);
}
int main () {
char t[1];
int *i;
t[0] = 'B';
printf("%cn",t[0]);
Tu test le contenu du tableau pas l'adresse de ce tableau. Le contenu
test(t);
printf("%cn",t[0]);
i = (int *) malloc(sizeof(int));
on teste le NULL en principe sinon explosion ligne suivante de plus je
printf("%pn",i);
test2(i);
printf("%pn",i);
Et les free alors!
return 0;
}
Je ne suis pas tout a fait d'accord avec l'analogie.
void stat(int *min,int *max, int *moy,int valeur[]);
1. ne protege pas le contenu de valeur (contrairement ce que l'on pourrait
attendre)
2. protege min seulement dans ce cas min n'est que le contenant de ce qui
C'est a mon sens une "bidouille" pour modifier le contenu de min.
Si tu passe une adresse comme argument : dans le cas du tableau cette
exemple:
void test(char t[]) {
t[0]= 'A';
}
void test2(int *i) {
i = (int *) malloc(sizeof(int));
printf("%pn",i);
}
int main () {
char t[1];
int *i;
t[0] = 'B';
printf("%cn",t[0]);
Tu test le contenu du tableau pas l'adresse de ce tableau. Le contenu
test(t);
printf("%cn",t[0]);
i = (int *) malloc(sizeof(int));
on teste le NULL en principe sinon explosion ligne suivante de plus je
printf("%pn",i);
test2(i);
printf("%pn",i);
Et les free alors!
return 0;
}
C'est pas ce que j'appelles les bases de l'algorithmique.
Après, ben, il faut différencier la culture et ce qui sert
au jour le jour. C'est bien de savoir la différence entre
une liste chainée et un arbre binaire équilibré. Même si
on le code pas souvent, il faut savoir choisir celui qui
est adapté à un problème donné.
Marc Boyer
C'est pas ce que j'appelles les bases de l'algorithmique.
Après, ben, il faut différencier la culture et ce qui sert
au jour le jour. C'est bien de savoir la différence entre
une liste chainée et un arbre binaire équilibré. Même si
on le code pas souvent, il faut savoir choisir celui qui
est adapté à un problème donné.
Marc Boyer
C'est pas ce que j'appelles les bases de l'algorithmique.
Après, ben, il faut différencier la culture et ce qui sert
au jour le jour. C'est bien de savoir la différence entre
une liste chainée et un arbre binaire équilibré. Même si
on le code pas souvent, il faut savoir choisir celui qui
est adapté à un problème donné.
Marc Boyer
c'est une allocation de trop. Tu perds la reference du contenu de ta
variable et une perte mémoire en plus. imagine une boucle sur cet
fonction, tu es un killer toi!
essayes plutôt ça :
*i++;
Ah bah oui mais la tu modifie pas la variable de ta fonction, desole,
printf("%pn",i);
Sans modification de i je ne vois pas l'interet de re-printer i.
int main () {
char t[1];
int *i;
t[0] = 'B';
printf("%cn",t[0]);
Tu test le contenu du tableau pas l'adresse de ce tableau. Le contenu
change mais pas son adresse utiliser dans l'appel de la fonction
on teste le NULL en principe sinon explosion ligne suivante de plus je
ne suis pas sur de ce que contient l'adresse retourner par malloc
c'est une allocation de trop. Tu perds la reference du contenu de ta
variable et une perte mémoire en plus. imagine une boucle sur cet
fonction, tu es un killer toi!
essayes plutôt ça :
*i++;
Ah bah oui mais la tu modifie pas la variable de ta fonction, desole,
printf("%pn",i);
Sans modification de i je ne vois pas l'interet de re-printer i.
int main () {
char t[1];
int *i;
t[0] = 'B';
printf("%cn",t[0]);
Tu test le contenu du tableau pas l'adresse de ce tableau. Le contenu
change mais pas son adresse utiliser dans l'appel de la fonction
on teste le NULL en principe sinon explosion ligne suivante de plus je
ne suis pas sur de ce que contient l'adresse retourner par malloc
c'est une allocation de trop. Tu perds la reference du contenu de ta
variable et une perte mémoire en plus. imagine une boucle sur cet
fonction, tu es un killer toi!
essayes plutôt ça :
*i++;
Ah bah oui mais la tu modifie pas la variable de ta fonction, desole,
printf("%pn",i);
Sans modification de i je ne vois pas l'interet de re-printer i.
int main () {
char t[1];
int *i;
t[0] = 'B';
printf("%cn",t[0]);
Tu test le contenu du tableau pas l'adresse de ce tableau. Le contenu
change mais pas son adresse utiliser dans l'appel de la fonction
on teste le NULL en principe sinon explosion ligne suivante de plus je
ne suis pas sur de ce que contient l'adresse retourner par malloc
"Bruno Desthuilliers" a écrit dans le
message news: 3f72084f$0$20645Juste pour info : pour une appli Windows avec une interface graphique,
juste pour ouvrir une fenêtre blanche qui ne fait rien, compte une
centaine de lignes de code de C non standard.
En Python, tu peux obtenir la même chose en moins de dix lignes.
je comprend pas une chose :
pourquoi se faire ch*** à apprendre
un autre langage
alors qu'il suffit de rester en C
et d'inclure des lib de fonctions
de haut niveau ?
avec une lib adequate, on fait une fenetre en
2 lignes de C...
"Bruno Desthuilliers" <bdesth.nospam@removeme.free.fr> a écrit dans le
message news: 3f72084f$0$20645
Juste pour info : pour une appli Windows avec une interface graphique,
juste pour ouvrir une fenêtre blanche qui ne fait rien, compte une
centaine de lignes de code de C non standard.
En Python, tu peux obtenir la même chose en moins de dix lignes.
je comprend pas une chose :
pourquoi se faire ch*** à apprendre
un autre langage
alors qu'il suffit de rester en C
et d'inclure des lib de fonctions
de haut niveau ?
avec une lib adequate, on fait une fenetre en
2 lignes de C...
"Bruno Desthuilliers" a écrit dans le
message news: 3f72084f$0$20645Juste pour info : pour une appli Windows avec une interface graphique,
juste pour ouvrir une fenêtre blanche qui ne fait rien, compte une
centaine de lignes de code de C non standard.
En Python, tu peux obtenir la même chose en moins de dix lignes.
je comprend pas une chose :
pourquoi se faire ch*** à apprendre
un autre langage
alors qu'il suffit de rester en C
et d'inclure des lib de fonctions
de haut niveau ?
avec une lib adequate, on fait une fenetre en
2 lignes de C...
blc wrote:
C'est très vrai. C'est pour ça qu'après avoir appris Python, langage de
haut niveau multi-paradigme (imperatif/fonctionnel et procedural/objet,
les deux grands axes), l'OP n'aura pas de difficultés majeures à
apprendre le C, langage de bas niveau, purement impératif et purement
procédural, dont la syntaxe est l'une des plus simples qui soient.
Mais qui contient des choses compliquees qui apparemment ne font pas
Dis, tu connais Python ?
Ben non...mais je devrais, je sais...
Le fait qu'il excelle comme langage de script
ne l'empêche pas d'être un langage généraliste complet.
Je n'ai jamais dis qu'un langage de script etait forcement incomplet...
http://www.python.org
Merci, je vais regarder
1/ Combien peux-tu me citer de langages de programmation dans lesquels
la notion de variable n'existe pas ?
En fait, je voulais parler de la declaration de variable qui n'est pas
2/ Le typage en Python est beaucoup plus fort qu'en C.
??? Je voulais dire que tu peux utiliser des variables sans meme les
3/ La gestion manuelle de la mémoire n'est en rien un 'concept
fondamental' de la programmation. Il y a d'ailleurs relativement peu de
langages - et aucun langage un tant soit peu récent - où la gestion de
la mémoire soit à la charge du programmeur.
En C/C++ tu peux faire un peu ce que tu veux je pense...
Avec un langage de script, on fait les choses vite et mal....
Ah bon ? Toi peut-être, mais ne généralise pas STP. Un programmeur
sérieux travaille sérieusement quelque soit le langage.
Mon idee c'est qu'un langage de script est trop permissif et "corrige"
avec le C, qd ca marche, c'est que c'est pas si mal, sinon, ca plante.
Alors là, je me gausse.
Le propre d'un UB, c'est que tout peut arriver - même que le programme
*semble* fonctionner. Le fait que le programme semble fonctionner n'est
en rien une preuve de correction. Quant à 'pas si mal', c'est une norme
de qualité que j'ignorais jusque là...
Et pourtant, qd tu as une deadline et que l'on te demande de faire un
De mon experience, qd ca marche trop vite, on ne retient rien du tout...
Par contre, si ca plante et que l'on passe du temps dessus, une fois
trouvee l'erreur, on ne la refait plus et c'est uniquement comme ca
que l'on progresse.
"Uniquement" ? C'est peut-être ton cas, mais n'en fait pas une
généralité. Tout le monde n'est pas adepte de l'éducation anglaise !-)
Connais pas desole...
Avant de décrire Python comme un langage "jouet",
Je parlais des langages de scripts en general Et tu conviendras que a
utilise le pendant
quelques mois. On en reparlera à ce moment là. Ou va demander aux
développeurs de Zope pourquoi ils utilisent un langage "jouet" pour
développer un serveur d'application.
Quant aux mauvaises habitudes, on peut les prendre avec n'importe quel
langage. Encore une fois, c'est plus un problème de sérieux que de langage.
Si le langage ne te force pas a etre serieux....c'est plus facile de ne
blc wrote:
C'est très vrai. C'est pour ça qu'après avoir appris Python, langage de
haut niveau multi-paradigme (imperatif/fonctionnel et procedural/objet,
les deux grands axes), l'OP n'aura pas de difficultés majeures à
apprendre le C, langage de bas niveau, purement impératif et purement
procédural, dont la syntaxe est l'une des plus simples qui soient.
Mais qui contient des choses compliquees qui apparemment ne font pas
Dis, tu connais Python ?
Ben non...mais je devrais, je sais...
Le fait qu'il excelle comme langage de script
ne l'empêche pas d'être un langage généraliste complet.
Je n'ai jamais dis qu'un langage de script etait forcement incomplet...
http://www.python.org
Merci, je vais regarder
1/ Combien peux-tu me citer de langages de programmation dans lesquels
la notion de variable n'existe pas ?
En fait, je voulais parler de la declaration de variable qui n'est pas
2/ Le typage en Python est beaucoup plus fort qu'en C.
??? Je voulais dire que tu peux utiliser des variables sans meme les
3/ La gestion manuelle de la mémoire n'est en rien un 'concept
fondamental' de la programmation. Il y a d'ailleurs relativement peu de
langages - et aucun langage un tant soit peu récent - où la gestion de
la mémoire soit à la charge du programmeur.
En C/C++ tu peux faire un peu ce que tu veux je pense...
Avec un langage de script, on fait les choses vite et mal....
Ah bon ? Toi peut-être, mais ne généralise pas STP. Un programmeur
sérieux travaille sérieusement quelque soit le langage.
Mon idee c'est qu'un langage de script est trop permissif et "corrige"
avec le C, qd ca marche, c'est que c'est pas si mal, sinon, ca plante.
Alors là, je me gausse.
Le propre d'un UB, c'est que tout peut arriver - même que le programme
*semble* fonctionner. Le fait que le programme semble fonctionner n'est
en rien une preuve de correction. Quant à 'pas si mal', c'est une norme
de qualité que j'ignorais jusque là...
Et pourtant, qd tu as une deadline et que l'on te demande de faire un
De mon experience, qd ca marche trop vite, on ne retient rien du tout...
Par contre, si ca plante et que l'on passe du temps dessus, une fois
trouvee l'erreur, on ne la refait plus et c'est uniquement comme ca
que l'on progresse.
"Uniquement" ? C'est peut-être ton cas, mais n'en fait pas une
généralité. Tout le monde n'est pas adepte de l'éducation anglaise !-)
Connais pas desole...
Avant de décrire Python comme un langage "jouet",
Je parlais des langages de scripts en general Et tu conviendras que a
utilise le pendant
quelques mois. On en reparlera à ce moment là. Ou va demander aux
développeurs de Zope pourquoi ils utilisent un langage "jouet" pour
développer un serveur d'application.
Quant aux mauvaises habitudes, on peut les prendre avec n'importe quel
langage. Encore une fois, c'est plus un problème de sérieux que de langage.
Si le langage ne te force pas a etre serieux....c'est plus facile de ne
blc wrote:
C'est très vrai. C'est pour ça qu'après avoir appris Python, langage de
haut niveau multi-paradigme (imperatif/fonctionnel et procedural/objet,
les deux grands axes), l'OP n'aura pas de difficultés majeures à
apprendre le C, langage de bas niveau, purement impératif et purement
procédural, dont la syntaxe est l'une des plus simples qui soient.
Mais qui contient des choses compliquees qui apparemment ne font pas
Dis, tu connais Python ?
Ben non...mais je devrais, je sais...
Le fait qu'il excelle comme langage de script
ne l'empêche pas d'être un langage généraliste complet.
Je n'ai jamais dis qu'un langage de script etait forcement incomplet...
http://www.python.org
Merci, je vais regarder
1/ Combien peux-tu me citer de langages de programmation dans lesquels
la notion de variable n'existe pas ?
En fait, je voulais parler de la declaration de variable qui n'est pas
2/ Le typage en Python est beaucoup plus fort qu'en C.
??? Je voulais dire que tu peux utiliser des variables sans meme les
3/ La gestion manuelle de la mémoire n'est en rien un 'concept
fondamental' de la programmation. Il y a d'ailleurs relativement peu de
langages - et aucun langage un tant soit peu récent - où la gestion de
la mémoire soit à la charge du programmeur.
En C/C++ tu peux faire un peu ce que tu veux je pense...
Avec un langage de script, on fait les choses vite et mal....
Ah bon ? Toi peut-être, mais ne généralise pas STP. Un programmeur
sérieux travaille sérieusement quelque soit le langage.
Mon idee c'est qu'un langage de script est trop permissif et "corrige"
avec le C, qd ca marche, c'est que c'est pas si mal, sinon, ca plante.
Alors là, je me gausse.
Le propre d'un UB, c'est que tout peut arriver - même que le programme
*semble* fonctionner. Le fait que le programme semble fonctionner n'est
en rien une preuve de correction. Quant à 'pas si mal', c'est une norme
de qualité que j'ignorais jusque là...
Et pourtant, qd tu as une deadline et que l'on te demande de faire un
De mon experience, qd ca marche trop vite, on ne retient rien du tout...
Par contre, si ca plante et que l'on passe du temps dessus, une fois
trouvee l'erreur, on ne la refait plus et c'est uniquement comme ca
que l'on progresse.
"Uniquement" ? C'est peut-être ton cas, mais n'en fait pas une
généralité. Tout le monde n'est pas adepte de l'éducation anglaise !-)
Connais pas desole...
Avant de décrire Python comme un langage "jouet",
Je parlais des langages de scripts en general Et tu conviendras que a
utilise le pendant
quelques mois. On en reparlera à ce moment là. Ou va demander aux
développeurs de Zope pourquoi ils utilisent un langage "jouet" pour
développer un serveur d'application.
Quant aux mauvaises habitudes, on peut les prendre avec n'importe quel
langage. Encore une fois, c'est plus un problème de sérieux que de langage.
Si le langage ne te force pas a etre serieux....c'est plus facile de ne
In article <3f7298af$0$2786$, TheChameleon wrote:c'est une allocation de trop. Tu perds la reference du contenu de ta
variable et une perte mémoire en plus. imagine une boucle sur cet
fonction, tu es un killer toi!
Cet exemple etait pour illustrer que i etait conserve lors de la sortie
de la fonction. Ce programme perd evidement la memoire et JAMAIS il ne
doit etre utilise.
D'ailleur, de facon general je deconseille de faire des allocations sur
les arguments (evidement pas sur le contenu des pointeurs passes en
argument). Je trouve cela crade.
Le seul but de cette fonction est de montrer que i est conserve en sortie.
Lorsque tu ecris void test2(int *i);
Tu passe en argument une variable de nom i et de type int *
Et donc la VARIABLE passe en argument est protegee.
Son contenu evidement non car tu attaques directement l'@.essayes plutôt ça :
*i++;
Ah bah oui mais la tu modifie pas la variable de ta fonction, desole,
mais le contenu de ce qui se trouve a l'@ pointee par ta variable ce
qui est totalement different.printf("%pn",i);
Sans modification de i je ne vois pas l'interet de re-printer i.int main () {
char t[1];
int *i;
t[0] = 'B';
printf("%cn",t[0]);
Tu test le contenu du tableau pas l'adresse de ce tableau. Le contenu
change mais pas son adresse utiliser dans l'appel de la fonction
Ah bah oui mais pour un programeur neophite ecrire void test(char t[]);
devrait proteger le tableau (c.a.d le contenu du tableau) or ce n'est
pas le cas.on teste le NULL en principe sinon explosion ligne suivante de plus je
ne suis pas sur de ce que contient l'adresse retourner par malloc
Le but de se programme n'est pas d'etre utilise mais simplement d'illustrer
un propos. Je ne vois pas ce que tester le retour de malloc ajoute vu
que je ne met rien en i.
L'explosion arriverais si je faisait derriere un *i = 2;
Mais je ne vois aucune allocation de ce style dans mon programme.
Tu pourrais re-argumenter en disant que l'allocation memoire est inutile
car je n'utilise a aucun endroit la memoire allouee.
In article <3f7298af$0$2786$626a54ce@news.free.fr>, TheChameleon wrote:
c'est une allocation de trop. Tu perds la reference du contenu de ta
variable et une perte mémoire en plus. imagine une boucle sur cet
fonction, tu es un killer toi!
Cet exemple etait pour illustrer que i etait conserve lors de la sortie
de la fonction. Ce programme perd evidement la memoire et JAMAIS il ne
doit etre utilise.
D'ailleur, de facon general je deconseille de faire des allocations sur
les arguments (evidement pas sur le contenu des pointeurs passes en
argument). Je trouve cela crade.
Le seul but de cette fonction est de montrer que i est conserve en sortie.
Lorsque tu ecris void test2(int *i);
Tu passe en argument une variable de nom i et de type int *
Et donc la VARIABLE passe en argument est protegee.
Son contenu evidement non car tu attaques directement l'@.
essayes plutôt ça :
*i++;
Ah bah oui mais la tu modifie pas la variable de ta fonction, desole,
mais le contenu de ce qui se trouve a l'@ pointee par ta variable ce
qui est totalement different.
printf("%pn",i);
Sans modification de i je ne vois pas l'interet de re-printer i.
int main () {
char t[1];
int *i;
t[0] = 'B';
printf("%cn",t[0]);
Tu test le contenu du tableau pas l'adresse de ce tableau. Le contenu
change mais pas son adresse utiliser dans l'appel de la fonction
Ah bah oui mais pour un programeur neophite ecrire void test(char t[]);
devrait proteger le tableau (c.a.d le contenu du tableau) or ce n'est
pas le cas.
on teste le NULL en principe sinon explosion ligne suivante de plus je
ne suis pas sur de ce que contient l'adresse retourner par malloc
Le but de se programme n'est pas d'etre utilise mais simplement d'illustrer
un propos. Je ne vois pas ce que tester le retour de malloc ajoute vu
que je ne met rien en i.
L'explosion arriverais si je faisait derriere un *i = 2;
Mais je ne vois aucune allocation de ce style dans mon programme.
Tu pourrais re-argumenter en disant que l'allocation memoire est inutile
car je n'utilise a aucun endroit la memoire allouee.
In article <3f7298af$0$2786$, TheChameleon wrote:c'est une allocation de trop. Tu perds la reference du contenu de ta
variable et une perte mémoire en plus. imagine une boucle sur cet
fonction, tu es un killer toi!
Cet exemple etait pour illustrer que i etait conserve lors de la sortie
de la fonction. Ce programme perd evidement la memoire et JAMAIS il ne
doit etre utilise.
D'ailleur, de facon general je deconseille de faire des allocations sur
les arguments (evidement pas sur le contenu des pointeurs passes en
argument). Je trouve cela crade.
Le seul but de cette fonction est de montrer que i est conserve en sortie.
Lorsque tu ecris void test2(int *i);
Tu passe en argument une variable de nom i et de type int *
Et donc la VARIABLE passe en argument est protegee.
Son contenu evidement non car tu attaques directement l'@.essayes plutôt ça :
*i++;
Ah bah oui mais la tu modifie pas la variable de ta fonction, desole,
mais le contenu de ce qui se trouve a l'@ pointee par ta variable ce
qui est totalement different.printf("%pn",i);
Sans modification de i je ne vois pas l'interet de re-printer i.int main () {
char t[1];
int *i;
t[0] = 'B';
printf("%cn",t[0]);
Tu test le contenu du tableau pas l'adresse de ce tableau. Le contenu
change mais pas son adresse utiliser dans l'appel de la fonction
Ah bah oui mais pour un programeur neophite ecrire void test(char t[]);
devrait proteger le tableau (c.a.d le contenu du tableau) or ce n'est
pas le cas.on teste le NULL en principe sinon explosion ligne suivante de plus je
ne suis pas sur de ce que contient l'adresse retourner par malloc
Le but de se programme n'est pas d'etre utilise mais simplement d'illustrer
un propos. Je ne vois pas ce que tester le retour de malloc ajoute vu
que je ne met rien en i.
L'explosion arriverais si je faisait derriere un *i = 2;
Mais je ne vois aucune allocation de ce style dans mon programme.
Tu pourrais re-argumenter en disant que l'allocation memoire est inutile
car je n'utilise a aucun endroit la memoire allouee.
Bruno Desthuilliers wrote:blc wrote:
C'est très vrai. C'est pour ça qu'après avoir appris Python, langage
de haut niveau multi-paradigme (imperatif/fonctionnel et
procedural/objet, les deux grands axes), l'OP n'aura pas de
difficultés majeures à apprendre le C, langage de bas niveau, purement
impératif et purement procédural, dont la syntaxe est l'une des plus
simples qui soient.
Mais qui contient des choses compliquees qui apparemment ne font pas
partie de Python..enfin je pense...
Dis, tu connais Python ?
Ben non...mais je devrais, je sais...
Le fait qu'il excelle comme langage de script ne l'empêche pas d'être
un langage généraliste complet.
Je n'ai jamais dis qu'un langage de script etait forcement incomplet...
1/ Combien peux-tu me citer de langages de programmation dans lesquels
la notion de variable n'existe pas ?
En fait, je voulais parler de la declaration de variable qui n'est pas
obligatoire dans la PLUPART des langages de script...
La déclaration de variable n'a de sens que dans les langages à typage
2/ Le typage en Python est beaucoup plus fort qu'en C.
??? Je voulais dire que tu peux utiliser des variables sans meme les
avoir declarees ce qui me gene un peu...
Mais c'est peut etre faux pour
Python
3/ La gestion manuelle de la mémoire n'est en rien un 'concept
fondamental' de la programmation. Il y a d'ailleurs relativement peu
de langages - et aucun langage un tant soit peu récent - où la gestion
de la mémoire soit à la charge du programmeur.
En C/C++ tu peux faire un peu ce que tu veux je pense...
Avec un langage de script, on fait les choses vite et mal....
Ah bon ? Toi peut-être, mais ne généralise pas STP. Un programmeur
sérieux travaille sérieusement quelque soit le langage.
Mon idee c'est qu'un langage de script est trop permissif
et "corrige"
des trucs sans meme nous le dire....
encore une fois, ce n'est peut etre
pas le cas pour Python...
Le propre d'un UB, c'est que tout peut arriver - même que le programme
*semble* fonctionner. Le fait que le programme semble fonctionner
n'est en rien une preuve de correction. Quant à 'pas si mal', c'est
une norme de qualité que j'ignorais jusque là...
Et pourtant, qd tu as une deadline et que l'on te demande de faire un
truc qui fait des choses..tu dis quoi a ton patron??
Desole, je pourrais effectivement le faire mais je prefere tout bien
coder propre et rendre mon truc dans 2 semaines quitte a perdre le
client??
Sincerement, je serais enormement etonne qu'a un moment ou a un
autre tu ne te sois pas surpris a coder comme un cochon pour gagner du
temps par manque de temps..;-)
Avant de décrire Python comme un langage "jouet",
Je parlais des langages de scripts en general Et tu conviendras que a
part python (que je ne connais toujours pas depuis le debut du post),
souvent il ressemble a ca...
utilise le pendant quelques mois. On en reparlera à ce moment là. Ou
va demander aux développeurs de Zope pourquoi ils utilisent un langage
"jouet" pour développer un serveur d'application.
Quant aux mauvaises habitudes, on peut les prendre avec n'importe quel
langage. Encore une fois, c'est plus un problème de sérieux que de
langage.
Si le langage ne te force pas a etre serieux....c'est plus facile de ne
pas l'etre, c'est uniquement ce que je voulais dire.
Maintenant, si je
t'ai fait du mal en critiquant indirectement Python, je suis desole..,-)
Bruno Desthuilliers wrote:
blc wrote:
C'est très vrai. C'est pour ça qu'après avoir appris Python, langage
de haut niveau multi-paradigme (imperatif/fonctionnel et
procedural/objet, les deux grands axes), l'OP n'aura pas de
difficultés majeures à apprendre le C, langage de bas niveau, purement
impératif et purement procédural, dont la syntaxe est l'une des plus
simples qui soient.
Mais qui contient des choses compliquees qui apparemment ne font pas
partie de Python..enfin je pense...
Dis, tu connais Python ?
Ben non...mais je devrais, je sais...
Le fait qu'il excelle comme langage de script ne l'empêche pas d'être
un langage généraliste complet.
Je n'ai jamais dis qu'un langage de script etait forcement incomplet...
1/ Combien peux-tu me citer de langages de programmation dans lesquels
la notion de variable n'existe pas ?
En fait, je voulais parler de la declaration de variable qui n'est pas
obligatoire dans la PLUPART des langages de script...
La déclaration de variable n'a de sens que dans les langages à typage
2/ Le typage en Python est beaucoup plus fort qu'en C.
??? Je voulais dire que tu peux utiliser des variables sans meme les
avoir declarees ce qui me gene un peu...
Mais c'est peut etre faux pour
Python
3/ La gestion manuelle de la mémoire n'est en rien un 'concept
fondamental' de la programmation. Il y a d'ailleurs relativement peu
de langages - et aucun langage un tant soit peu récent - où la gestion
de la mémoire soit à la charge du programmeur.
En C/C++ tu peux faire un peu ce que tu veux je pense...
Avec un langage de script, on fait les choses vite et mal....
Ah bon ? Toi peut-être, mais ne généralise pas STP. Un programmeur
sérieux travaille sérieusement quelque soit le langage.
Mon idee c'est qu'un langage de script est trop permissif
et "corrige"
des trucs sans meme nous le dire....
encore une fois, ce n'est peut etre
pas le cas pour Python...
Le propre d'un UB, c'est que tout peut arriver - même que le programme
*semble* fonctionner. Le fait que le programme semble fonctionner
n'est en rien une preuve de correction. Quant à 'pas si mal', c'est
une norme de qualité que j'ignorais jusque là...
Et pourtant, qd tu as une deadline et que l'on te demande de faire un
truc qui fait des choses..tu dis quoi a ton patron??
Desole, je pourrais effectivement le faire mais je prefere tout bien
coder propre et rendre mon truc dans 2 semaines quitte a perdre le
client??
Sincerement, je serais enormement etonne qu'a un moment ou a un
autre tu ne te sois pas surpris a coder comme un cochon pour gagner du
temps par manque de temps..;-)
Avant de décrire Python comme un langage "jouet",
Je parlais des langages de scripts en general Et tu conviendras que a
part python (que je ne connais toujours pas depuis le debut du post),
souvent il ressemble a ca...
utilise le pendant quelques mois. On en reparlera à ce moment là. Ou
va demander aux développeurs de Zope pourquoi ils utilisent un langage
"jouet" pour développer un serveur d'application.
Quant aux mauvaises habitudes, on peut les prendre avec n'importe quel
langage. Encore une fois, c'est plus un problème de sérieux que de
langage.
Si le langage ne te force pas a etre serieux....c'est plus facile de ne
pas l'etre, c'est uniquement ce que je voulais dire.
Maintenant, si je
t'ai fait du mal en critiquant indirectement Python, je suis desole..,-)
Bruno Desthuilliers wrote:blc wrote:
C'est très vrai. C'est pour ça qu'après avoir appris Python, langage
de haut niveau multi-paradigme (imperatif/fonctionnel et
procedural/objet, les deux grands axes), l'OP n'aura pas de
difficultés majeures à apprendre le C, langage de bas niveau, purement
impératif et purement procédural, dont la syntaxe est l'une des plus
simples qui soient.
Mais qui contient des choses compliquees qui apparemment ne font pas
partie de Python..enfin je pense...
Dis, tu connais Python ?
Ben non...mais je devrais, je sais...
Le fait qu'il excelle comme langage de script ne l'empêche pas d'être
un langage généraliste complet.
Je n'ai jamais dis qu'un langage de script etait forcement incomplet...
1/ Combien peux-tu me citer de langages de programmation dans lesquels
la notion de variable n'existe pas ?
En fait, je voulais parler de la declaration de variable qui n'est pas
obligatoire dans la PLUPART des langages de script...
La déclaration de variable n'a de sens que dans les langages à typage
2/ Le typage en Python est beaucoup plus fort qu'en C.
??? Je voulais dire que tu peux utiliser des variables sans meme les
avoir declarees ce qui me gene un peu...
Mais c'est peut etre faux pour
Python
3/ La gestion manuelle de la mémoire n'est en rien un 'concept
fondamental' de la programmation. Il y a d'ailleurs relativement peu
de langages - et aucun langage un tant soit peu récent - où la gestion
de la mémoire soit à la charge du programmeur.
En C/C++ tu peux faire un peu ce que tu veux je pense...
Avec un langage de script, on fait les choses vite et mal....
Ah bon ? Toi peut-être, mais ne généralise pas STP. Un programmeur
sérieux travaille sérieusement quelque soit le langage.
Mon idee c'est qu'un langage de script est trop permissif
et "corrige"
des trucs sans meme nous le dire....
encore une fois, ce n'est peut etre
pas le cas pour Python...
Le propre d'un UB, c'est que tout peut arriver - même que le programme
*semble* fonctionner. Le fait que le programme semble fonctionner
n'est en rien une preuve de correction. Quant à 'pas si mal', c'est
une norme de qualité que j'ignorais jusque là...
Et pourtant, qd tu as une deadline et que l'on te demande de faire un
truc qui fait des choses..tu dis quoi a ton patron??
Desole, je pourrais effectivement le faire mais je prefere tout bien
coder propre et rendre mon truc dans 2 semaines quitte a perdre le
client??
Sincerement, je serais enormement etonne qu'a un moment ou a un
autre tu ne te sois pas surpris a coder comme un cochon pour gagner du
temps par manque de temps..;-)
Avant de décrire Python comme un langage "jouet",
Je parlais des langages de scripts en general Et tu conviendras que a
part python (que je ne connais toujours pas depuis le debut du post),
souvent il ressemble a ca...
utilise le pendant quelques mois. On en reparlera à ce moment là. Ou
va demander aux développeurs de Zope pourquoi ils utilisent un langage
"jouet" pour développer un serveur d'application.
Quant aux mauvaises habitudes, on peut les prendre avec n'importe quel
langage. Encore une fois, c'est plus un problème de sérieux que de
langage.
Si le langage ne te force pas a etre serieux....c'est plus facile de ne
pas l'etre, c'est uniquement ce que je voulais dire.
Maintenant, si je
t'ai fait du mal en critiquant indirectement Python, je suis desole..,-)