C'est incroyable, la Fac d'orleans vient de passer au LMD et ils ont viré
le C des programmes.
Ils ont conservé le Caml pour les 2eme années
Et ont remplacé Pascal (1ere année) et C (2eme année) par je Java sur
les deux années.
En troisieme on aura directement droit au C++.
Je trouve ca injuste. Et dire que j'etais vraiment content de faire du C,
d'autant plus que je tourne uniquement sous Linux et que sous Linux le C
est tres abondant ... je devrais donc apprendre le C a coté : une masse
de travail supplémentaire ... Quel desastre ... vous voyez un bon coté
des choses dans cette histoire, moi je suis un tantinet deprimé la ...
--
ASPO Infogérance - http://aspo.rktmb.org/activites/infogerance
Unofficial FAQ fcolc - http://faq.fcolc.eu.org/
Linux User Group sur Orléans et alentours.
Tél: + 33 2 38 76 43 65 (France)
"Trognon Patrice" a écrit dans le message de news:4159228a$0$21179$
laissons faire, laissons faire ;)
Le bug de l'an 3000 n'a qu"à bien se tenir !...
Le Bug du 19 Janvier 2038 à 03:14:08 n'est pas si éloigné que ça ! Mais moi, je serais à la retraite ! (Enfin théoriquement...)
Bah, explosion du système de retraites en 2020 avec le Papy-Boom...
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"C is a sharp tool"
Charlie Gordon
"cedric" wrote in message news:415acda0$0$26074$
Ce qui est fastidieux en asm, amha, c'est plutôt de se passer d'analyseur d'expressions. Genre :
int i = (a * 5.1) /3 + 2;
Là, ce C économise la frappe !
Même remarque pour scheme, je pense que c'est la raison principale du succes des langages imperatifs. Ça a commencé avec Fortran dont Algol, C Basic et Pascal sont les dignes successeurs ;-)
Chqrlie
"cedric" <rixed@happyleptic.NOSPAM.org> wrote in message
news:415acda0$0$26074$626a14ce@news.free.fr...
Ce qui est fastidieux en asm, amha, c'est plutôt de se passer
d'analyseur d'expressions. Genre :
int i = (a * 5.1) /3 + 2;
Là, ce C économise la frappe !
Même remarque pour scheme, je pense que c'est la raison principale du succes
des langages imperatifs.
Ça a commencé avec Fortran dont Algol, C Basic et Pascal sont les dignes
successeurs ;-)
Ce qui est fastidieux en asm, amha, c'est plutôt de se passer d'analyseur d'expressions. Genre :
int i = (a * 5.1) /3 + 2;
Là, ce C économise la frappe !
Même remarque pour scheme, je pense que c'est la raison principale du succes des langages imperatifs. Ça a commencé avec Fortran dont Algol, C Basic et Pascal sont les dignes successeurs ;-)
Chqrlie
Charlie Gordon
"Eric Deveaud" wrote in message news:
cedric wrote:
L'assembleur peur aussi sembler un mauvais investissement du fait qu'il change de machine en machine. Pourtant, les principes de bases restent toujours plus ou moins les mêmes
dans ce cas pourquoi ne pas utiliser une machine de turing pour apprendre la programation ??
Ça alors! Je viens de réaliser que c'est mon cas !
En 1975, j'étais en 3ieme, avec une paire d'autres matheux, lecteurs assidus de la rubrique récréations mathématiques de Science et Vie tenue par Pierre Berloquin. Il avait fait plusieurs articles sur la machine de Turing et nous avions expérimenté pendant des semaines avec crayon et papier sur cette curiosité ! Il faut que je retrouve ces articles et les fasse encadrer ! Résoudre le mot le plus long et le compte est bon était un sujet de reflexion algorithmique quand j'y pense. Nous avons généralisé cette notion d'algorithme avec les jeux à information totale (du tic-tac-toe aux échecs) dont on démontre qu'il existe une strategie gagnante ou non perdante pour l'un des joueurs, et la notion de complexité s'impose d'elle même. Enfin en 1976 j'ai pu commencer à jouer en assembleur sur un mini de l'époque... avec des cartes perforées à la main. Puis en Fortran et Cobol en 1977 (vite jetés car beaucoup trop gros pour les 10000 octets de RAM de l'époque) Puis en APL, lisp, asm68K, Pascal, PL/1, Basic, ... Puis en C en 1981. Depuis, j'en ai regardé plein d'autres, mais je reviens toujours au C et au bout de 24 ans, et des millions de lignes de code produites, j'avoue qu'il y a encore des zones d'ombre, des doutes, et des bugs aussi. C force l'humilité !
Chqrlie
"Eric Deveaud" <edeveaud@pasteur.fr> wrote in message
news:slrncllm1j.fi0.edeveaud@bulgroz.sis.pasteur.fr...
cedric wrote:
L'assembleur peur aussi sembler un mauvais investissement du fait qu'il
change de machine en machine. Pourtant, les principes de bases restent
toujours plus ou moins les mêmes
dans ce cas pourquoi ne pas utiliser une machine de turing pour
apprendre la programation ??
Ça alors! Je viens de réaliser que c'est mon cas !
En 1975, j'étais en 3ieme, avec une paire d'autres matheux, lecteurs assidus
de la rubrique récréations mathématiques de Science et Vie tenue par Pierre
Berloquin. Il avait fait plusieurs articles sur la machine de Turing et
nous avions expérimenté pendant des semaines avec crayon et papier sur cette
curiosité !
Il faut que je retrouve ces articles et les fasse encadrer !
Résoudre le mot le plus long et le compte est bon était un sujet de
reflexion algorithmique quand j'y pense.
Nous avons généralisé cette notion d'algorithme avec les jeux à information
totale (du tic-tac-toe aux échecs) dont on démontre qu'il existe une
strategie gagnante ou non perdante pour l'un des joueurs, et la notion de
complexité s'impose d'elle même.
Enfin en 1976 j'ai pu commencer à jouer en assembleur sur un mini de
l'époque... avec des cartes perforées à la main.
Puis en Fortran et Cobol en 1977 (vite jetés car beaucoup trop gros pour les
10000 octets de RAM de l'époque)
Puis en APL, lisp, asm68K, Pascal, PL/1, Basic, ...
Puis en C en 1981.
Depuis, j'en ai regardé plein d'autres, mais je reviens toujours au C et au
bout de 24 ans, et des millions de lignes de code produites, j'avoue qu'il y
a encore des zones d'ombre, des doutes, et des bugs aussi. C force
l'humilité !
L'assembleur peur aussi sembler un mauvais investissement du fait qu'il change de machine en machine. Pourtant, les principes de bases restent toujours plus ou moins les mêmes
dans ce cas pourquoi ne pas utiliser une machine de turing pour apprendre la programation ??
Ça alors! Je viens de réaliser que c'est mon cas !
En 1975, j'étais en 3ieme, avec une paire d'autres matheux, lecteurs assidus de la rubrique récréations mathématiques de Science et Vie tenue par Pierre Berloquin. Il avait fait plusieurs articles sur la machine de Turing et nous avions expérimenté pendant des semaines avec crayon et papier sur cette curiosité ! Il faut que je retrouve ces articles et les fasse encadrer ! Résoudre le mot le plus long et le compte est bon était un sujet de reflexion algorithmique quand j'y pense. Nous avons généralisé cette notion d'algorithme avec les jeux à information totale (du tic-tac-toe aux échecs) dont on démontre qu'il existe une strategie gagnante ou non perdante pour l'un des joueurs, et la notion de complexité s'impose d'elle même. Enfin en 1976 j'ai pu commencer à jouer en assembleur sur un mini de l'époque... avec des cartes perforées à la main. Puis en Fortran et Cobol en 1977 (vite jetés car beaucoup trop gros pour les 10000 octets de RAM de l'époque) Puis en APL, lisp, asm68K, Pascal, PL/1, Basic, ... Puis en C en 1981. Depuis, j'en ai regardé plein d'autres, mais je reviens toujours au C et au bout de 24 ans, et des millions de lignes de code produites, j'avoue qu'il y a encore des zones d'ombre, des doutes, et des bugs aussi. C force l'humilité !
Chqrlie
Charlie Gordon
int moyenne(int data[], size_t nbEchantillon){ int somme=0; for(int i=0; i < nbEchantillon ; ++i){ somme+= data[i]; } return somme/nbEchantillon; }
somme est un int size_t est unsigned, pas forcément de la même taille la division est entière, non-signée (!) alors que le numérateur et le quotient peuvent être négatifs pas de test pour la division par zero pas moyen en C de forcer la cohérence entre la taille de data et nbEchantillon tant de choses à expliquer !
Chqrlie
int moyenne(int data[], size_t nbEchantillon){
int somme=0;
for(int i=0; i < nbEchantillon ; ++i){
somme+= data[i];
}
return somme/nbEchantillon;
}
somme est un int
size_t est unsigned, pas forcément de la même taille
la division est entière, non-signée (!) alors que le numérateur et le
quotient peuvent être négatifs
pas de test pour la division par zero
pas moyen en C de forcer la cohérence entre la taille de data et
nbEchantillon
tant de choses à expliquer !
int moyenne(int data[], size_t nbEchantillon){ int somme=0; for(int i=0; i < nbEchantillon ; ++i){ somme+= data[i]; } return somme/nbEchantillon; }
somme est un int size_t est unsigned, pas forcément de la même taille la division est entière, non-signée (!) alors que le numérateur et le quotient peuvent être négatifs pas de test pour la division par zero pas moyen en C de forcer la cohérence entre la taille de data et nbEchantillon tant de choses à expliquer !
Chqrlie
Marc Boyer
In article <ck0iqa$m0g$, Charlie Gordon wrote:
int moyenne(int data[], size_t nbEchantillon){ int somme=0; for(int i=0; i < nbEchantillon ; ++i){ somme+= data[i]; } return somme/nbEchantillon; }
somme est un int size_t est unsigned, pas forcément de la même taille la division est entière, non-signée (!) alors que le numérateur et le quotient peuvent être négatifs
Voui, c'est ce que j'aurais aimé que cédric réalise. unsigned u=3; int i = -6 / u; assert( i != -2);
pas de test pour la division par zero
Ca à la limite, c'est un problème de l'algorithme, pas du langage.
tant de choses à expliquer !
Ouaip.
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
In article <ck0iqa$m0g$1@news.tiscali.fr>, Charlie Gordon wrote:
int moyenne(int data[], size_t nbEchantillon){
int somme=0;
for(int i=0; i < nbEchantillon ; ++i){
somme+= data[i];
}
return somme/nbEchantillon;
}
somme est un int
size_t est unsigned, pas forcément de la même taille
la division est entière, non-signée (!) alors que le numérateur et le
quotient peuvent être négatifs
Voui, c'est ce que j'aurais aimé que cédric réalise.
unsigned u=3;
int i = -6 / u;
assert( i != -2);
pas de test pour la division par zero
Ca à la limite, c'est un problème de l'algorithme,
pas du langage.
tant de choses à expliquer !
Ouaip.
Marc Boyer
--
La contractualisation de la recherche, c'est me donner de l'argent pour
faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce
que je sais faire, je le fais sans moyens...
int moyenne(int data[], size_t nbEchantillon){ int somme=0; for(int i=0; i < nbEchantillon ; ++i){ somme+= data[i]; } return somme/nbEchantillon; }
somme est un int size_t est unsigned, pas forcément de la même taille la division est entière, non-signée (!) alors que le numérateur et le quotient peuvent être négatifs
Voui, c'est ce que j'aurais aimé que cédric réalise. unsigned u=3; int i = -6 / u; assert( i != -2);
pas de test pour la division par zero
Ca à la limite, c'est un problème de l'algorithme, pas du langage.
tant de choses à expliquer !
Ouaip.
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Vincent Lefevre
Dans l'article <ck0sfu$rhp$, Antoine Leca écrit:
Au-delà des stockages persistants, il y a aussi les programmes existants, eux aussi persistants. Dont un certain nombre ne seront pas recompilés (par exemple, sur une machine Linux en général on peut trouver les sources; sur une machine Windows NT, c'est une autre affaire). En actuellement, un programme DOS de 1982 comme VisiCalc tourne très bien sur Windows, en natif...
Le véritable problème, c'est les programmes dont on n'a pas les sources. AMHA évidemment (mais pas seulement le mien).
Dans l'article <ck0sfu$rhp$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.gov> écrit:
Au-delà des stockages persistants, il y a aussi les programmes
existants, eux aussi persistants. Dont un certain nombre ne seront
pas recompilés (par exemple, sur une machine Linux en général on
peut trouver les sources; sur une machine Windows NT, c'est une
autre affaire). En actuellement, un programme DOS de 1982 comme
VisiCalc tourne très bien sur Windows, en natif...
Le véritable problème, c'est les programmes dont on n'a pas les
sources. AMHA évidemment (mais pas seulement le mien).
Au-delà des stockages persistants, il y a aussi les programmes existants, eux aussi persistants. Dont un certain nombre ne seront pas recompilés (par exemple, sur une machine Linux en général on peut trouver les sources; sur une machine Windows NT, c'est une autre affaire). En actuellement, un programme DOS de 1982 comme VisiCalc tourne très bien sur Windows, en natif...
Le véritable problème, c'est les programmes dont on n'a pas les sources. AMHA évidemment (mais pas seulement le mien).
Dans l'article <ck0fgv$cv5$, Charlie Gordon écrit:
"cedric" wrote in message news:415acda0$0$26074$
Ce qui est fastidieux en asm, amha, c'est plutôt de se passer d'analyseur d'expressions. Genre :
int i = (a * 5.1) /3 + 2;
Là, ce C économise la frappe !
Même remarque pour scheme, je pense que c'est la raison principale du succes des langages imperatifs.
Mais qu'en est-il du temps mis à débugger à cause de tel ou tel effet de bord?
somme est un int size_t est unsigned, pas forcément de la même taille la division est entière, non-signée (!) alors que le numérateur et le quotient peuvent être négatifs pas de test pour la division par zero pas moyen en C de forcer la cohérence entre la taille de data et nbEchantillon
Remarque Le C a été conçu dans un certain but utilitaire on est sensé savoir ce que l'on fait. C'est son coté puissant difficilement remplacable pour l'embarqué. Je sui personnellement partisan d'utiliser au maximum des fonctions, en aidant le compilateur avec des protypages tres forts avec un bon niveau de warnning. Et c'est gagné, aide le compilateur et il t'aidera... Combien de bugs potentiels évités L'interet d'apprendre CAML justement avant.
Vincent Lefevre a écrit:
Dans l'article <ck0fgv$cv5$1@news.tiscali.fr>,
Charlie Gordon <news@chqrlie.org> écrit:
"cedric" <rixed@happyleptic.NOSPAM.org> wrote in message
news:415acda0$0$26074$626a14ce@news.free.fr...
Ce qui est fastidieux en asm, amha, c'est plutôt de se passer
d'analyseur d'expressions. Genre :
int i = (a * 5.1) /3 + 2;
Là, ce C économise la frappe !
Même remarque pour scheme, je pense que c'est la raison principale
du succes des langages imperatifs.
Mais qu'en est-il du temps mis à débugger à cause de tel ou tel effet
de bord?
somme est un int
size_t est unsigned, pas forcément de la même taille
la division est entière, non-signée (!) alors que le numérateur et le
quotient peuvent être négatifs
pas de test pour la division par zero
pas moyen en C de forcer la cohérence entre la taille de data et
nbEchantillon
Remarque
Le C a été conçu dans un certain but utilitaire on est sensé savoir ce
que l'on fait.
C'est son coté puissant difficilement remplacable pour l'embarqué.
Je sui personnellement partisan d'utiliser au maximum des fonctions,
en aidant le compilateur avec des protypages tres forts avec un bon
niveau de warnning.
Et c'est gagné, aide le compilateur et il t'aidera... Combien de bugs
potentiels évités
L'interet d'apprendre CAML justement avant.
Dans l'article <ck0fgv$cv5$, Charlie Gordon écrit:
"cedric" wrote in message news:415acda0$0$26074$
Ce qui est fastidieux en asm, amha, c'est plutôt de se passer d'analyseur d'expressions. Genre :
int i = (a * 5.1) /3 + 2;
Là, ce C économise la frappe !
Même remarque pour scheme, je pense que c'est la raison principale du succes des langages imperatifs.
Mais qu'en est-il du temps mis à débugger à cause de tel ou tel effet de bord?
somme est un int size_t est unsigned, pas forcément de la même taille la division est entière, non-signée (!) alors que le numérateur et le quotient peuvent être négatifs pas de test pour la division par zero pas moyen en C de forcer la cohérence entre la taille de data et nbEchantillon
Remarque Le C a été conçu dans un certain but utilitaire on est sensé savoir ce que l'on fait. C'est son coté puissant difficilement remplacable pour l'embarqué. Je sui personnellement partisan d'utiliser au maximum des fonctions, en aidant le compilateur avec des protypages tres forts avec un bon niveau de warnning. Et c'est gagné, aide le compilateur et il t'aidera... Combien de bugs potentiels évités L'interet d'apprendre CAML justement avant.
