On 14 sep, 13:31, Gabriel Dos Reis wrote:(Marc Espie) writes:
| Non, par contre, comprendre ce qu'on peut faire avec, pourquoi c'est
| indispensable, montrer les idiomes vitaux aux etudiants, ca c'est
| complique.
Je me considère comme autodidacte en effet j'ai reçu une formation en
comptabilité à distance et de fait, je pense être devenu autodidacte
pour apprendre en programmer en C. Je voudrais comprendre ce langage
pour passer à d'autres langages. Je crois comprendre que python, c++,
java...sont écrit en C, alors comprendre le C même si ça demande
beaucoup de temps doit en valoir la peine...
De fait, je ne sais pas si apprendre par coeur est un avantage.
En fait, dans le langage C, aujourd'hui ce qui me pose le plus de
difficulté, c'est la portabilité entre Windows et Linux et les modes
de saisie utilisateur ou autre avec scanf, frets, getchar...et les
caractères de 'n' et autres.
C'est vrai que je n'ai pas encore mis
complètement un pied dans les pointeurs ni une grande maîtrise des
fonctions.
Mais comment se fait-il qu'une simple saisie sur un clavier puisse
fonctionner sous Windows et donner une boucle d'erreurs sans fin sous
Linux ou inversement?
J'ai 2 idées sur la question :
1° le passage d'une norme à une autre ne rend pas les choses faciles
entre les systèmes qui évoluent, mais pas au même moment que les
organismes de normalisation, d'où des décalages de comportements entre
les OS ....
Alors je dois encore me trouver un livre dans ce domaine?
On 14 sep, 13:31, Gabriel Dos Reis <g...@cs.tamu.edu> wrote:
es...@lain.home (Marc Espie) writes:
| Non, par contre, comprendre ce qu'on peut faire avec, pourquoi c'est
| indispensable, montrer les idiomes vitaux aux etudiants, ca c'est
| complique.
Je me considère comme autodidacte en effet j'ai reçu une formation en
comptabilité à distance et de fait, je pense être devenu autodidacte
pour apprendre en programmer en C. Je voudrais comprendre ce langage
pour passer à d'autres langages. Je crois comprendre que python, c++,
java...sont écrit en C, alors comprendre le C même si ça demande
beaucoup de temps doit en valoir la peine...
De fait, je ne sais pas si apprendre par coeur est un avantage.
En fait, dans le langage C, aujourd'hui ce qui me pose le plus de
difficulté, c'est la portabilité entre Windows et Linux et les modes
de saisie utilisateur ou autre avec scanf, frets, getchar...et les
caractères de 'n' et autres.
C'est vrai que je n'ai pas encore mis
complètement un pied dans les pointeurs ni une grande maîtrise des
fonctions.
Mais comment se fait-il qu'une simple saisie sur un clavier puisse
fonctionner sous Windows et donner une boucle d'erreurs sans fin sous
Linux ou inversement?
J'ai 2 idées sur la question :
1° le passage d'une norme à une autre ne rend pas les choses faciles
entre les systèmes qui évoluent, mais pas au même moment que les
organismes de normalisation, d'où des décalages de comportements entre
les OS ....
Alors je dois encore me trouver un livre dans ce domaine?
On 14 sep, 13:31, Gabriel Dos Reis wrote:(Marc Espie) writes:
| Non, par contre, comprendre ce qu'on peut faire avec, pourquoi c'est
| indispensable, montrer les idiomes vitaux aux etudiants, ca c'est
| complique.
Je me considère comme autodidacte en effet j'ai reçu une formation en
comptabilité à distance et de fait, je pense être devenu autodidacte
pour apprendre en programmer en C. Je voudrais comprendre ce langage
pour passer à d'autres langages. Je crois comprendre que python, c++,
java...sont écrit en C, alors comprendre le C même si ça demande
beaucoup de temps doit en valoir la peine...
De fait, je ne sais pas si apprendre par coeur est un avantage.
En fait, dans le langage C, aujourd'hui ce qui me pose le plus de
difficulté, c'est la portabilité entre Windows et Linux et les modes
de saisie utilisateur ou autre avec scanf, frets, getchar...et les
caractères de 'n' et autres.
C'est vrai que je n'ai pas encore mis
complètement un pied dans les pointeurs ni une grande maîtrise des
fonctions.
Mais comment se fait-il qu'une simple saisie sur un clavier puisse
fonctionner sous Windows et donner une boucle d'erreurs sans fin sous
Linux ou inversement?
J'ai 2 idées sur la question :
1° le passage d'une norme à une autre ne rend pas les choses faciles
entre les systèmes qui évoluent, mais pas au même moment que les
organismes de normalisation, d'où des décalages de comportements entre
les OS ....
Alors je dois encore me trouver un livre dans ce domaine?
ld writes:
[...]
| > et que j'ai passe bien trop
| > longtemps a me battre avec des trucs qui devraient compiler, mais qui ne
| > compilent pas, parce qu'ils redefinissent une macro au fond d'un ente te
| > de bibliotheque, mais l'entete entre en conflit avec un autre entete.
|
| Le preprocesseur est bien souvent le bouc emissaire d'un mal plus
| profond.
« Furthermore, I would like to abolish CPP. »
ld <laurent.den...@gmail.com> writes:
[...]
| > et que j'ai passe bien trop
| > longtemps a me battre avec des trucs qui devraient compiler, mais qui ne
| > compilent pas, parce qu'ils redefinissent une macro au fond d'un ente te
| > de bibliotheque, mais l'entete entre en conflit avec un autre entete.
|
| Le preprocesseur est bien souvent le bouc emissaire d'un mal plus
| profond.
« Furthermore, I would like to abolish CPP. »
ld writes:
[...]
| > et que j'ai passe bien trop
| > longtemps a me battre avec des trucs qui devraient compiler, mais qui ne
| > compilent pas, parce qu'ils redefinissent une macro au fond d'un ente te
| > de bibliotheque, mais l'entete entre en conflit avec un autre entete.
|
| Le preprocesseur est bien souvent le bouc emissaire d'un mal plus
| profond.
« Furthermore, I would like to abolish CPP. »
Marc Boyer writes:
|
| > La première chose que je fais le au premier cours est de présenter le
| > « syllabus »
| >
| > http://courses.cs.tamu.edu/gdr/2009.fall-315/syllabus.pdf
|
| J'ai lu ça, t'a donné la ref dans un autre post.
| Je viens de lire aussi "programming in an undergraduate CS curriculum"
| de BS que tu avais mentionné.
| J'ai du mal à comparer, car il parle en semaines, mais en gros, il
| a 12 semaines et une vingtaine de "lectures" pour faire ce que nous
| faisions en Algo/Pascal. Et il reconnait "this material is very extensive
| for a first course".
Oui ; on a observe que si le prof n'est pas raisonnablement ambitieux
avec les eleves, ces derniers montrent peu de motivation.
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> writes:
|
| > La première chose que je fais le au premier cours est de présenter le
| > « syllabus »
| >
| > http://courses.cs.tamu.edu/gdr/2009.fall-315/syllabus.pdf
|
| J'ai lu ça, t'a donné la ref dans un autre post.
| Je viens de lire aussi "programming in an undergraduate CS curriculum"
| de BS que tu avais mentionné.
| J'ai du mal à comparer, car il parle en semaines, mais en gros, il
| a 12 semaines et une vingtaine de "lectures" pour faire ce que nous
| faisions en Algo/Pascal. Et il reconnait "this material is very extensive
| for a first course".
Oui ; on a observe que si le prof n'est pas raisonnablement ambitieux
avec les eleves, ces derniers montrent peu de motivation.
Marc Boyer writes:
|
| > La première chose que je fais le au premier cours est de présenter le
| > « syllabus »
| >
| > http://courses.cs.tamu.edu/gdr/2009.fall-315/syllabus.pdf
|
| J'ai lu ça, t'a donné la ref dans un autre post.
| Je viens de lire aussi "programming in an undergraduate CS curriculum"
| de BS que tu avais mentionné.
| J'ai du mal à comparer, car il parle en semaines, mais en gros, il
| a 12 semaines et une vingtaine de "lectures" pour faire ce que nous
| faisions en Algo/Pascal. Et il reconnait "this material is very extensive
| for a first course".
Oui ; on a observe que si le prof n'est pas raisonnablement ambitieux
avec les eleves, ces derniers montrent peu de motivation.
Marc Boyer writes:
| Le 14-09-2009, Gabriel Dos Reis a écrit :
| > Je trouve que
| >
| > struct mpz_internal {
| > // ...
| > };
| >
| > typedef struct mpz_internal mpz_t[1];
| >
| > permet d'écrire des fonctions qui simulent très bien le passage par
| > réference const, e.e.
| >
| > mpz_t mpz_negate(const mpz_t);
| >
| > (et cela marche presque très bien pour des composantes
| > qui sont à l'intersection de C ou C++).
|
| Oui, c'est joli, mais est-ce bien recommandable ?
Pour une certaine catégorie de programmeur, oui.
| En plus, dans ton exemple, on retourne un tableau, il
| me semble, et c'est pas trop permis en C il me semble.
Oops, le resultat doit etre en passer en parametre non-const -- desole
pour la hate.
| Mais bon, ça permet de retrouver Java: à part int,
| float, bool et leurs copains, tout est référence...
Cela permet de s'en sortir pour un certain nombre de chose.
En realite, l'exemple est tire de GMP -- tu peux regarder les source.
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> writes:
| Le 14-09-2009, Gabriel Dos Reis <gdr@cs.tamu.edu> a écrit :
| > Je trouve que
| >
| > struct mpz_internal {
| > // ...
| > };
| >
| > typedef struct mpz_internal mpz_t[1];
| >
| > permet d'écrire des fonctions qui simulent très bien le passage par
| > réference const, e.e.
| >
| > mpz_t mpz_negate(const mpz_t);
| >
| > (et cela marche presque très bien pour des composantes
| > qui sont à l'intersection de C ou C++).
|
| Oui, c'est joli, mais est-ce bien recommandable ?
Pour une certaine catégorie de programmeur, oui.
| En plus, dans ton exemple, on retourne un tableau, il
| me semble, et c'est pas trop permis en C il me semble.
Oops, le resultat doit etre en passer en parametre non-const -- desole
pour la hate.
| Mais bon, ça permet de retrouver Java: à part int,
| float, bool et leurs copains, tout est référence...
Cela permet de s'en sortir pour un certain nombre de chose.
En realite, l'exemple est tire de GMP -- tu peux regarder les source.
Marc Boyer writes:
| Le 14-09-2009, Gabriel Dos Reis a écrit :
| > Je trouve que
| >
| > struct mpz_internal {
| > // ...
| > };
| >
| > typedef struct mpz_internal mpz_t[1];
| >
| > permet d'écrire des fonctions qui simulent très bien le passage par
| > réference const, e.e.
| >
| > mpz_t mpz_negate(const mpz_t);
| >
| > (et cela marche presque très bien pour des composantes
| > qui sont à l'intersection de C ou C++).
|
| Oui, c'est joli, mais est-ce bien recommandable ?
Pour une certaine catégorie de programmeur, oui.
| En plus, dans ton exemple, on retourne un tableau, il
| me semble, et c'est pas trop permis en C il me semble.
Oops, le resultat doit etre en passer en parametre non-const -- desole
pour la hate.
| Mais bon, ça permet de retrouver Java: à part int,
| float, bool et leurs copains, tout est référence...
Cela permet de s'en sortir pour un certain nombre de chose.
En realite, l'exemple est tire de GMP -- tu peux regarder les source.
Le 14-09-2009, Gabriel Dos Reis a écrit :Je trouve que
struct mpz_internal {
// ...
};
typedef struct mpz_internal mpz_t[1];
permet d'écrire des fonctions qui simulent très bien le passage par
réference const, e.e.
mpz_t mpz_negate(const mpz_t);
(et cela marche presque très bien pour des composantes
qui sont à l'intersection de C ou C++).
Oui, c'est joli, mais est-ce bien recommandable ?
Tout variable est un tableau de taille 1. Mais est-ce
vraiment raisonnable ?
Le 14-09-2009, Gabriel Dos Reis <gdr@cs.tamu.edu> a écrit :
Je trouve que
struct mpz_internal {
// ...
};
typedef struct mpz_internal mpz_t[1];
permet d'écrire des fonctions qui simulent très bien le passage par
réference const, e.e.
mpz_t mpz_negate(const mpz_t);
(et cela marche presque très bien pour des composantes
qui sont à l'intersection de C ou C++).
Oui, c'est joli, mais est-ce bien recommandable ?
Tout variable est un tableau de taille 1. Mais est-ce
vraiment raisonnable ?
Le 14-09-2009, Gabriel Dos Reis a écrit :Je trouve que
struct mpz_internal {
// ...
};
typedef struct mpz_internal mpz_t[1];
permet d'écrire des fonctions qui simulent très bien le passage par
réference const, e.e.
mpz_t mpz_negate(const mpz_t);
(et cela marche presque très bien pour des composantes
qui sont à l'intersection de C ou C++).
Oui, c'est joli, mais est-ce bien recommandable ?
Tout variable est un tableau de taille 1. Mais est-ce
vraiment raisonnable ?
-ed- a écrit :
> Euh, 't' est très précisément un pointeur, même si la syntaxe i nt t[]
> est différente de int *t, la finalité est la même... En tout cas, t
> *n'est pas* un tableau...
Je sais bien même si ta formulation pourrait se discuter, extrait de K& R2 :
-----------------------------------------
In getline, the arguments are declared by the line
int getline(char s[], int lim);
which specifies that the first argument, s, is an array, and the second, lim, is
an integer.
-ed- a écrit :
> Euh, 't' est très précisément un pointeur, même si la syntaxe i nt t[]
> est différente de int *t, la finalité est la même... En tout cas, t
> *n'est pas* un tableau...
Je sais bien même si ta formulation pourrait se discuter, extrait de K& R2 :
-----------------------------------------
In getline, the arguments are declared by the line
int getline(char s[], int lim);
which specifies that the first argument, s, is an array, and the second, lim, is
an integer.
-ed- a écrit :
> Euh, 't' est très précisément un pointeur, même si la syntaxe i nt t[]
> est différente de int *t, la finalité est la même... En tout cas, t
> *n'est pas* un tableau...
Je sais bien même si ta formulation pourrait se discuter, extrait de K& R2 :
-----------------------------------------
In getline, the arguments are declared by the line
int getline(char s[], int lim);
which specifies that the first argument, s, is an array, and the second, lim, is
an integer.
