Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C Quel tutoriel pour débuter ?

Quel tutoriel pour débuter ?

202 réponses
Avatar
Migrec
Bonjour,

Je cherche un tutoriel imprimable sur le web pour apprendre le C avant
d'acheter un bouquin "de référence".
Je suis débutant en programmation mais je connais les scripts shell
(linux), le HTML ou encore un peu de PHP.

Quel tutoriel imprimable me conseillez-vous pour débuter ? Les 560 pages
de celui du site du zéro
(http://www.siteduzero.com/tuto-29-8-0-apprenez-a-programmer-en-c.html)
découragent un peu mon imprimante, même avec le recto-verso
automatique... Mais le style me plaît ! Existe-t-il quelque chose dans
le même esprit mais en plus condensé ?

--
Migrec
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
4 5 6 7 8
Avatar
Antoine Leca
En news:489d6d59$0$966$, Wykaaa va escriure:
[...] il y a au moins 25 ans (la norme C ANSI était encore sous forme
de Draft (en fait le futur C ANSI commençait à être en discussion à
l'ANSI et nous communiquions avec eux via l'AFNOR).

Dans tous ces milieux, le K&R n'est jamais passé pour un "bon bouquin
sur le C", bien au contraire.

Pour ma part et toute mon équipe ainsi que de nombreuses personnes
dans le technical committee ANSI, c'était même le pire des livre sur
C.



Depuis, il semblerait qu'il ait été surpassé par un autre ouvrage
(ISBN: 978-007-881952-0)


Les ng (fussent-ils US) n'ont jamais été une référence en la matière
pour les professionnels.



Certes.

Par contre, les comités techniques, c'est bien autre chose.



C'est effectivement autre chose.


Antoine
Avatar
Antoine Leca
En news:, Thierry B. va escriure:
</troll>



Belle tentative d'essayer de fermer la discussion sans intérêt pratique,
mais je crains que ce ne soit vain...


Antoine
Avatar
Antoine Leca
En news:,
Emmanuel Delahaye va escriure:
On peut utiliser cette adresse pour accéder à cette mémoire via une
opération de déréferencement (ASM : (A0), SP:[BP] C : *p) d'une
mémoire contenant la valeur de cette adresse. Pour désigner ce genre
de mémoire, en assembleur, on parle de registre d'adresse, et en C,
C++, Pascal, Ada etc, on parle de pointeur.



Pointeur en Ada ? Pas sûr, ou au moins pas facile...

Sinon en Pascal (pas Turbo, le vrai de NW), les pointeurs ce sont des types
; on est assez loin des valeurs que sont les adresses.


Il n'y a pas lieu de confondre adresse et pointeur.



C'était bien l'ambition de Wirth et Ichbiah... ;-)


Antoine
Avatar
Jean-Marc Bourguet
"Antoine Leca" writes:

En news:,
Emmanuel Delahaye va escriure:
On peut utiliser cette adresse pour accéder à cette mémoire via une
opération de déréferencement (ASM : (A0), SP:[BP] C : *p) d'une
mémoire contenant la valeur de cette adresse. Pour désigner ce genre
de mémoire, en assembleur, on parle de registre d'adresse, et en C,
C++, Pascal, Ada etc, on parle de pointeur.



Pointeur en Ada ? Pas sûr, ou au moins pas facile...



Ca s'appelle "access", mais c'est bien présent. Réservé aux cas
d'allocation dynamique en Ada 83, mais Ada 95 a introduit la possibilité de
prendre un pointeur vers une variable (qui doit avoir une marque, l'inverse
de register en C qui interdit de prendre l'adresse).

Sinon en Pascal (pas Turbo, le vrai de NW), les pointeurs ce sont des types
; on est assez loin des valeurs que sont les adresses.



Dans mon usage pointeur est d'abord une famille de type et par raccourci de
langages les variables et les valeurs de ce type. Si je regarde les
occurances de pointer dans la norme, elles désignent plutôt les valeurs;
Les types sont dans les occurences que j'ai vu désignés par "pointer type"
et je n'ai pas vu de cas où il était question de variables spécifiquement
(ce qui ne m'étonne guère, il n'y a pas tellement de raison de parler de
ces variables là en particulier).

A+

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Avatar
Wykaaa
Antoine Leca a écrit :
En news:489d6d59$0$966$, Wykaaa va escriure:
[...] il y a au moins 25 ans (la norme C ANSI était encore sous forme
de Draft (en fait le futur C ANSI commençait à être en discussion à
l'ANSI et nous communiquions avec eux via l'AFNOR).

Dans tous ces milieux, le K&R n'est jamais passé pour un "bon bouquin
sur le C", bien au contraire.

Pour ma part et toute mon équipe ainsi que de nombreuses personnes
dans le technical committee ANSI, c'était même le pire des livre sur
C.



Depuis, il semblerait qu'il ait été surpassé par un autre ouvrage
(ISBN: 978-007-881952-0)



Pourquoi ?
Parce que l'ouvrage que tu cites (en fait "ANNOTATED ANSI C STANDARD")
contient entièrement la norme ISO C de 1990 ?
Le livre ne vaut que pour cela (moins cher que la norme) car les
annotations, il vaut mieux les ignorer.
De toute façon, ce livre est épuisé...


Les ng (fussent-ils US) n'ont jamais été une référence en la matière
pour les professionnels.



Certes.

Par contre, les comités techniques, c'est bien autre chose.



C'est effectivement autre chose.


Antoine



Avatar
Wykaaa
Antoine Leca a écrit :
En news:,
Emmanuel Delahaye va escriure:
On peut utiliser cette adresse pour accéder à cette mémoire via une
opération de déréferencement (ASM : (A0), SP:[BP] C : *p) d'une
mémoire contenant la valeur de cette adresse. Pour désigner ce genre
de mémoire, en assembleur, on parle de registre d'adresse, et en C,
C++, Pascal, Ada etc, on parle de pointeur.



Pointeur en Ada ? Pas sûr, ou au moins pas facile...



Je ne vois pas ce qu'il y a de difficile en ADA avec les pointeurs :
type Ptr_Int is access Integer;
P1 : Ptr_Int;

La seule différence avec les autres langages qui manipulent les
pointeurs, c'est qu'en ADA, on utilise le point (opérateur de
qualification) et non la flèche pour référencé une variable pointée.
Ichbiah avait ses manies...
Il a essayé de masquer au maximum la manipulation des pointeurs en ADA
mais le cahier des charge du DoD (Iron Man) les exigeait.

Sinon en Pascal (pas Turbo, le vrai de NW), les pointeurs ce sont des types
; on est assez loin des valeurs que sont les adresses.



Il faut plutôt dire que les pointeurs sont typés.
Un langage où les pointeurs ne sont pas typés est PL/1.


Il n'y a pas lieu de confondre adresse et pointeur.



C'était bien l'ambition de Wirth et Ichbiah... ;-)


Antoine



Avatar
Charlie Gordon
"Thierry B." a écrit dans le message de news:

--{ Charlie Gordon a plopé ceci: }--

Je n'ai pas de document pedagogique à conseiller qui utilise cette
approche,
mais je suis curieux de savoir s'il en existe. De nombreux développeurs
relativement à l'aise avec le langage C mais sans expérience d'assembleur
auraient beaucoup à en apprendre, et j'en connais qui sont demandeurs.



Pour avoir une vision un peu "étrange" de l'assembleur, dans le temps
(glorieuse époque de mon 286 :) j'avais beaucoup apprécié:

"Object-Oriented Assembly Language" de Len Dorfman (ed Windcrest)

Il utilise beaucoup les macros du MASM, et présente une bonne façon
de structurer un code assembleur. Evidemment, ce n'est pas trop un
ouvrage d'initiation, mais à cette époque-là, j'ai beaucoup appris
avec ce livre, jusqu'à écrire des programmes conséquents uniquement
en AsmOO :)



Oui, je connais cet ouvrage, mais c'est une approche totalement incongrue de
nos jours, et qui l'était déjà quand le bouquin est sorti.

Je prefere beaucoup "Zen of assembly language" de Michael Abrash, ou "Inner
Loops" de Rick Booth, mais il sont tous deux totalement obsoletes vu qu'ils
se focalisent sur des cores disparus (486 et premiers Pentiums).

Dommage, j'aime beaucoup l'approche hyper pragmatique de l'analyse de
performance : pour un probleme donné, et un algorithme envisagé, modeliser
l'opération au coeur de l'implementation, evaluer le nombre d'opérations
pour le cas elementaire, et multiplier par le nombre de cas. On obtient une
evaluation de l'ordre de grandeur de la performance brute qu'on peut cibler.
On peut alors comparer avec les programmes existants qui réalisent la
fonction et on a souvent des surprises.

L'un d'entre vous connait-il des ouvrages plus récents qui traitent de ce
genre de question ?

--
Chqrlie.
Avatar
Antoine Leca
En news:48a1cfaa$0$921$, Wykaaa va escriure:
Antoine Leca a écrit :
En news:489d6d59$0$966$, Wykaaa va escriure:




[À propos du K&R]
Pour ma part et toute mon équipe ainsi que de nombreuses personnes
dans le technical committee ANSI, c'était même le pire des livre sur
C.



Depuis, il semblerait qu'il ait été surpassé par un autre ouvrage
(ISBN: 978-007-881952-0)



Pourquoi ?



Je ne sais pas pour ton équipe, mais tant dans le comité C de l'AFNOR comme
dans celui de l'ISO et de l'INCITS (ex ANSI), parce que j'ai entendu plus de
critiques intransigeantes concernant le second que le premier.


Parce que l'ouvrage que tu cites (en fait "ANNOTATED ANSI C STANDARD")
contient entièrement la norme ISO C de 1990 ?



Non. D'abord parce qu'il ne la contient pas entièrement (mais ce n'est pas
l'important) ; mais les critiques que j'ai entendues sont surtout dirigées
vers le reste de l'ouvrage...


Le livre ne vaut que pour cela (moins cher que la norme) car les
annotations, il vaut mieux les ignorer.



Et voilà. Donc tu as un ouvrage qui te semble intéressant (au moins parce
qu'il est meilleur marché que le norme), mais il est critiqué (virulement).
En est-il moins intéressant pour autant ? Faut-il l'éviter ?


Antoine
Avatar
Charlie Gordon
"Alexandre BACQUART" a écrit dans le message de
news: 489e16cc$0$9739$
candide wrote:
Alexandre BACQUART a écrit :

"Présentation générale du C" ?



Si c'est la traduction française de "A tutorial Introduction" tu devrais
te procurer la VO.



Du coup je n'y tiens pas trop... mais bon, c'est une exception.

Si cela ne m'a pas posé trop de problèmes, c'est que j'avais beaucoup
pratiqué l'assembleur avant d'aborder ce bouquin, et ça, ça aide
énormément (les pointeurs passent alors comme une lettre à la poste,



Je note ce point tout à fait intéressant.



Charlie Gordon a posté dans cette enfilade et le résume assez bien.
Beaucoup considèrent C comme un macro-assembleur (et effectivement, le C
est une abstraction de l'assembleur) et les pointeurs jouent un rôle
prépondérant pour créer ce lien très étroit entre les deux.

L'assembleur apprend beaucoup sur le fonctionnement des micro-processeurs
(de *tous* les micro-processeurs). Bien-sûr, ce n'est pas portable, c'est
primitif, c'est fastidieux et rébarbatif. Mais ça a le mérite d'être très,
très instructif sur quelques concepts qu'on retrouve partout (il faut
pratiquer cependant, je doute que la théorie suffise vraiment). Mais si tu
pratiques déjà bien C, ce n'est peut-être pas très utile... tout au plus
tu en arrivera en C à faire des expériences que l'on pourrait qualifier de
"chimie amusante" (ie. dangereuses). Mais bon, nous parlions de pédagogie,
alors pourquoi pas.

Si tu veux t'y mettre par curiosité, contrairement à Charlie, je ne
conseillerais pas le x86, mais plutôt le 68000, beaucoup plus intuitif,
mieux foutu et moins contraignant (ce ne sont pas les émulations à base de
68k qui manquent).



J'ai hésité à mentionner le 68000 de motorola, qui est effectivement bien
plus regulier que l'architecture x86. Mais son utilisation a quasi disparu
des desktops, alors que l'assembleur x486 32 bits est encore facilement
exploitable et beaucoup utilisé, en particulier dans les optimisations en
assembleur in line dans la glibc. L'assembleur x64-64 est encore mieux,
mais il faut un OS 64 bits pour l'exploiter.

J'ai mis du temps avant de comprendre pourquoi pas mal de gens avaient
autant du mal avec les pointeurs de C alors que pour moi, c'était
intuitif. Après, la sémantique n'est pas toujours évidente en C, il faut
l'admettre (notamment en ce qui concerne les pointeurs de fonctions).



C'est l'interet de l'etape assembleur : donner un support concret à une
notion difficile à maitriser dans l'absolu, et encore plus fumeuse en C++
quand on rajoute les références (qu'on pourrait aussi adopter pour le C dans
un standard futur ;-).

Dernier point : à ma connaissance, la littérature en assembleur utilise
peu (voire pas) le terme "pointeur" mais plutôt "adresse" (et tout ce qui
va avec, comme les "modes d'adressage").



Les pointeurs sont des adresses typées.

...
Si je peux me permettre de me faire l'avocat du diable : je ne suis pas
un puriste, donc je n'ai pas grand-chose à en dire de ce site. J'ai
néanmoins jeté un oeil et je ne le trouve pas si mauvais en tant que
tutoriel, même si on peut regretter quelques écarts inutiles, comme le
fait d'utiliser le mot "librairie" en lieu et place de "bibliothèque",
volontairement de son aveu (le genre de choses qui donnera des boutons
aux puristes, mais les puristes ne sont pas censés lire des tutoriels).



Cet écart de langage est très fréquent y compris chez des informaticiens
très titrés.



Y compris chez moi ! Mais il y a des endroits (comme ici) où il vaut mieux
faire attention pour ne pas déclencher les foudres des puristes.

J'ai appris à être tolérants avec ce genre d'écart.



Surtout que c'est excusable en ce sens que "library" y ressemble beaucoup
et que la littérature informatique est essentiellement en anglais.



J'ai souvent entendu les abréviations "lib", "lib statique", "lib
dynamique", voire "dll".

--
Chqrlie.
Avatar
Charlie Gordon
"candide" a écrit dans le message de news:
489d6955$0$12000$
Wykaaa a écrit :

Combien de fois faudra-t-il répéter que le K&R N'EST PAS un livre pour
débuter ou apprendre le langage C ?
Il est tout sauf pédagogique.



Oui.


Sinon, pour répondre à la question du PO, le document «Introduction au
langage C» de Bernard Cassagne est je trouve très bien. Je l'avais
trouvé précis et clair. Après je ne suis pas capable de dire s'il
contient des faussetés...

http://www-clips.imag.fr/commun/bernard.cassagne/Introduction_ANSI_C.html




C'est effectivement un bon document pour apprendre le C.



Ce n'est pas du tout mon avis. J'ai essayé d'apprendre le C avec cet
ouvrage il y a trois ans. Je suis allé de déconvenues en déconvenues.
Pour moi, ça reste prototypiquement le mauvais document d'apprentissage du
langage C. Un livre qui dès sa page 5 en vient à nous jargonner avec des
"unités lexicales" et des "identificateurs" est un mauvais livre
d'apprentissage (à moins qu'on ne s'adresse à des gens qui connaissent de
manière approfondie un autre langage de programmation et tout son jargon
métalinguistique).



Le fait est que ce bouquin est beaucoup trop theorique pour mériter le nom
d'introduction. Expliquer dans le détail les trigraphes dès la page 13 (sur
230), est fort peu utile.

L'ouvrage est mal organisé (*), il ne part pas des préoccupations de
l'utilisateur, il est abstrait, les exemples sont peu nombreux, mal
choisis, décontextualisés, ou alors sont surchargés, l'ouvrage est
laconique ou peu clair sur de nombreuses questions ardues. Enfin bon une
vraie cata ce bouquin.



Je suis plutot d'accord. Ce n'est pas le bon choix pour débuter.

--
Chqrlie.
4 5 6 7 8