Discussion:Programmation C

À faire

• Ajouter une section sur le préprocesseur (déclaration de constantes, déclaration de macros, compilation conditionnelle, ...) ;
• détailler les fonctions mathématiques de la norme C99 (celles forcant les types float et long double) ;
• augmenter la section sur les fonctions, notamment sur les entêtes de fonctions.

Il serait aussi intéressant de montrer les possiblités d'interaction entre le C et les autres langages dans les deux sens :

• inclusion de code assembleur, dans quel cas le faire et quels problèmes cela pose ;
• utiliser un langage plus « évolué » pour les opérations « pénibles » en C (lecture de fichiers et de texte en général, possibilité d'environnement interactif), je pense notamment à guile ou à python.

Suggestion

• L'ouvrage peut maintenant passer en Bien avancé, voire Très complet, non ? Esope 5 nov 2004 à 00:53 (UTC)

oui, je le met en « bien avancé ». Guillaumito 5 nov 2004 à 08:27 (UTC)

J'ai rajouté l'icône dans la page Programmation Esope 5 nov 2004 à 22:39 (UTC)

• Christian Casteyde ([1]) propose deja un cours (à mon humble avis très complet et pertinent...) sous licence GFDL (GNU Free Documentation License). peut etre qu'il serait judicieux de penser aux avantages que nous proposent cette licence libre. quite à modifier ce cours après : le plus gros du travail serait fait et le temps gagné serait très significatif. non ?

Ordre des chapîtres

J'aurais interverti les chapîtres « tableaux » et « pointeurs ». Les tableaux sont en fait des pointeurs pointant sur le 1er élément d'une zone mémoire réservée. D'ailleurs, dans mon bouquin de C/C++ les pointeurs sont vus avant les tableaux, de même dans mon cours de C à la FAC.

De plus, dans le chapître « Classe de stockage - Classe 'const' » on fait pas mal référence aux pointeurs, qui n'ont pas encore été vus à ce niveau si l'on suit l'ordre du livre !

Ça commence à prendre forme ce wikibook ! :]

L'ordre qui a été choisi pour l'instant est :

• tableaux statiques ;
• pointeurs ;
• tableaux dynamiques.

Si les tableaux dynamiques sont en effet exactement des pointeurs (et sont donc présentés dans la partie « pointeurs »), les tableaux statiques présentent quelques différences, les deux premières qui me viennent à l'esprit :

• calcul du nombre d'éléments : dans un tableau statique sizeof(tableau)/sizeof(élément) donne le nombre d'éléments, pas dans un tableau dynamique ;
• passage en argument et retour de fonctions : il est possible de passer un tableau dynamique par valeur à une fonction, pas un tableau statique, pareil pour le retour de la fonction.

Conclusion : j'aime bien la manière dont sont présentées les choses pour l'instant. :) Pour ce qui est du mot clef const, il faudrait peut être voir à déplacer des choses en effet. Guillaumito 11 nov 2004 à 11:32 (UTC)

Mon grain de sel Thierry 13 nov 2004 à 22:47 (-5:00)

Tout d'abord les tableaux qu'ils soient dynamiques ou statiques se manipulent par références. Il est impossible de faire passer un tableau sur la pile, autrement qu'en le déclarant dans une structure.

Je pense qu'il faudrait vraiment inverser les chapitres 'pointeurs' et 'tableaux'. Les tableaux sont un cas particulier des pointeurs et je mettrais les tableaux dynamiques à la suite des tableaux statiques.

Il y a aussi un point à expliquer dans la partie tableau : l'ambivalence tableau <=> pointeur ... difficile de le faire sans avoir vu les pointeurs avant. Et surtout le cas particulier des tableaux : les chaines de caractères qui peuvent poser des problèmes encore plus tordus, mais qui là encore nécessite de bien comprendre le concept de pointeur avant.

Il faut vraiment changer l'ordre là, ça devient difficile de faire quelque chose avec les pointeurs en chapitre 9 sur 11 ! J'ai voulu rajouter un paragraphe sur la fonction main() dans le chapitre des fonctions, mais avec **argv... c'est pas du tout évident. Dhenry 20 nov 2004 à 16:04 (UTC)

En attendant de changer l'ordonancement des chapitres, j'ai procédé à une grande modification du paragraphe "arithmétique sur les pointeurs", qui me semblait aller trop loin dans l'analogie pointeur <-> entier. J'ai tenté de clarifier, en me basant sur le n1124 (peut-être le n869 est-il différent sur ce point). La modification est importante, je suis prêt à en discuter avec ceux qui ont rédigé cette partie avant (et même les autres). Alveric 7 juin 2006 à 16:56 (CEST)

Par ailleurs, le chapitre "Types avancés" fait référence au préprocesseur, qui est étudié dans le chapitre suivant ! Faut-il réordonner ces deux chapitres, ou modifier les références pour indiquer que le préprocesseur sera étudié plus tard ? Alveric 7 juin 2006 à 17:59 (CEST)

Hello, c'est moi qui est écrit cette partie et c'est aussi moi qui ait en grande partie changé tes ajouts. J'ai décrits mes motivations sur la partie discussion de la page en question. Pour ta remarque concernant le préprocesseur, c'est vrai tu as raison. Je pense qu'il serait pas mal de déplacer cette partie, dans la section préprocesseur.Thierry Pierron 9 juin 2006 à 17:33 (CEST)

Hello aussi, j'ai répondu pour les pointeurs sur la page en question. Alveric 14 juin 2006 à 15:34 (CEST)

Le début du chapitre "Mathématiques" de la description de la bibliothèque standard fait appel à errno.h. Pour rester cohérent, ~il faudrait déplacer ce chapitre après "Erreurs", je pense. Alveric 14 juin 2006 à 15:34 (CEST)

Suppression du Wikibooks anglais

Bonjour à tous,

Il existe encore des vestiges du livre de programmation C sur l'ancien site :

• en:Fr Programmation C
• en:Fr Programmation C Bases du langage
• en:Fr Programmation C Types de base

A mon avis, il n'y a rien qui pourrait intéresser le livre de Programmation C de Wikilivres, mais ne connaissant pas très bien ce langage, je laisse les pros du C se charger de vérifier s'il n'y a rien là-bas qu'on aurait omis ici et de mettre le modèle {{delete}} dans ce cas. Merci d'avance !

Esope 14 nov 2004 à 00:12 (UTC)

Bah, il n'y a pas grand chose dans cette ébauche. Tout est déjà repris dans ce livre, on pourrait effectivement supprimer cette entrée.

Thierry 13 nov 2004 à 22:59 (-5:00)

Homogénéisation/uniformisation du code

Peut-être devrions-nous établir quelques règles pour « homogénéiser » le code ? Je veux dire, qu'on se mette d'accord si on écrit printf("hello\n");, printf( "hello\n" ); ou printf ("hello\n");, ou le nombre d'espaces pour les tabulations (il y'en a 8 en ce moment dans les listing, je trouve que ça fait un peu beaucoup, ça décale beaucoup. 4 serait suffisant), etc. --Dhenry 5 jan 2005 à 12:47 (UTC)

Personnellement, je suggèrerais puts("hello"); dans un tel cas, mais je pense que ce n'était pas le sens de ta question ;)

Plus sérieusement, mon style serait fonction(param); sans espace pour les appels de fonction, et if (test) { /* ... */ } ou while (false) { break; } avec des espaces pour les mots-clés. Mais le tout est de se fixer un style de codage, et de le respecter de manière uniforme dans tout le livre. Alveric 7 juin 2006 à 11:15 (CEST)

Par ailleurs, il y a des bouts de code écrits comme ça et d'autres commme ça. Pour l'instant, j'essaye d'homogénéiser vers la deuxième écriture, mais y a-t-il une règle définie au niveau du wikilivre, ou plus globalement au niveau de wikibooks ? Alveric 21 juin 2006 à 15:55 (CEST)

Autres suggestions

Le livre pourrait aborder l'utilisation de structures de données avancées, comme différents types de listes chaînées, les tables de hachage. Et peut-être aussi les tris ?

Dans un autre wikibook, oui pourquoi pas (ce serait chouette), mais dans celui-ci je ne pense pas que ce soit une bonne idée. Ce livre est dédié au langage C lui-même, pas aux méthodes ±avancées de programmation en C. --Dhenry 21 sep 2005 à 20:25 (UTC)

C'est en effet plus de l'algorithmique que du langage C El Charpi 24 septembre 2006 à 17:24 (CEST)

Arf, encore une suggestion. J'ai une doc détaillant la génération de bibliothèques personnalisées. Elle est divisée en 2 parties : lib statiques et lib dynamiques. La première est relativement simple et portable, facile à réaliser avec un environnement même ANSI C1870. La seconde est pas mal spécifique au système d'exploitation, bien qu'elle traite aussi de problèmes génériques, comme la compatibilité ascendante niveau API, niveau ABI, accès multi-threadé, convention d'appel, doc, ... J'ai décrit essentiellement les environnements Unix et Windows. Quelqu'un d'autre pense que ça à quand même sa place ici ? Thierry Pierron 21 juin 2006 à 05:21 (CEST)

Ça a sa place dans le livre, je pense. Mais ça rejoint une question que je me suis posée en repassant sur certains chapitres, et que j'ai amorcée sur la page de discussion de l'introduction: quel est l'objectif de ce livre ? Est-ce un livre "de référence", un livre pour débutants...? Les deux approches sont différentes, un livre de référence explicitant toutes les notions dans le détail une par une, alors qu'un livre pour étudiant propose plus une approche qui mèle "application des concepts de l'algorithmique en C" et "découverte des spécificités du C". Pour le C++, il y a un wikilivre pour les débutants, et un autre de plus haut niveau (enfin, c'est leurs buts, je ne les ai pas encore lus). Peut-être est-ce aussi une idée pour le wikilivre C ?

En tout cas, je suis pour de tels chapitres dans le wikilivre, dans son état actuel. Par contre, si on se décide à le couper en 2, alors ces chapitres auraient plus leur place dans le wikilivre "programmation C avancée" ou "de référence". Alveric 21 juin 2006 à 15:55 (CEST)

Les objectifs de ce livre ? Effectivement, c'est une bonne question. Pour faire court, j'avais dans l'idée de dire ce que le C peut faire, comment il est utilisé dans la plupart des cas et pourquoi il est utilisé comme ça et pas autrement.

S'il y a bien quelque chose qui m'exaspère dans une doc, c'est quand les fonctionnalités utilisés dans une minorité de cas, prennent la majorité de l'ouvrage. On est noyé d'informations, et c'est un calvaire sans fin pour avoir un premier programme fonctionnel, car on a l'impression qu'il faut maitriser tout ou rien. En tous les cas, je suis sûr qu'une retranscription plus ou moins littérale de la spec ISO C99 ne sert à rien. C'est imbitable, c'est dogmatique, c'est rebutant, autant filer une notation BNF à ce niveau, comme ça seuls ceux qui savent déjà, sauront mieux.

D'un autre coté, il faut aussi éviter de tomber dans l'excès inverse : tout décrire dans les moindres détails, en passant par le moindre transistor de tous les microprocesseurs où le C a pu être porté. On retombe un peu sur le point précédant : on noit d'informations les lecteurs, qui ne concernent qu'une minorité. Bref, il y a des limites à fixer et des prérequis à connaître, dont effectivement il serait bien d'indiquer quelque part.

Je pense que si ça n'a pas été fait, c'est surtout parce que l'ouvrage est loin d'être terminé (le sera t-il un jour d'ailleurs ?). Il y a encore pas mal d'améliorations possibles. En vrac, je dirais :

- Opérateurs : c'est de loin la partie la plus incomplète. J'avoue que dépendamment des objectifs fixées, elle peut être aussi bien torchée en 1 ou 2 pages, comme en 30. En gros, plus d'exemples, plus de détails sur les opérations binaires (algèbre de boole), la différence avec les opérateurs de comparaisons, ...

- Tableaux : l'exemple du tableau statique déclaré en tant que pointeur n'a rien à faire là (bon, c'est moi qui l'ait mis, hein). Trop avancé et assez tordu, nécessite une très bonne compréhension de la gestion de la mémoire en C, qui n'a ne serait-ce qu'été évoqué (pratiquement) nulle part. D'un autre coté, c'est pointu et l'éventuelle partie qui décrira ça, risque d'être imbitable.

- Sinon globalement, la partie "bases du langage" pourrait être encore plus pragmatique avec un plus d'exemples (on a des morceaux d'aspects du langage, mais je trouve qu'on a du mal à avoir une vision plus synthétique, plus globale, visions qui sont sensées être décrite plus en détail dans les sections suivamtes).

Sinon l'idée d'avoir deux ouvrages, un pour les débutants, l'autre pour ceux qui savent, je trouve ça pas terrible. Dans l'idéal, c'est l'organisation des chapîtres qui devrait aller en complexité croissante, bien qu'en C les différents concepts ont tendance à se chevaucher (pointeurs <=> tableaux <=> chaines de caractères <=> allocations dynamiques <=> ...). L'ordre actuel n'est pas trop mal, plus de détails dans un ou deux chapîtres et une vision plus globale dans le premier (éventuellement une description des objectifs dans l'intro), et on aurait quelque chose de pas mal du tout.

Page d'accueil du wikilivre

Je viens de commencer un avant-propos sur la page d'accueil du wikilivre. J'ai essayé de préciser les prérequis, et j'ai ajouté un lien pour permettre aux lecteurs de rajouter un message sur cette page (j'ai repris le lien «Ajouter un nouveau message» disponible en haut du Bistro), lien avec lequel je viens de créer cette section (rien que pour montrer ue ça marche ;).

Le texte pourrait encore être étoffé, mais c'est surtout la mise en page qui pourrait être améliorée, je pense. En regardant les autres wikilivres, je n'ai pas trouvé grand chose de bien, si ce n'est évidemment Photographie et Tribologie, qui sont des exemples à suivre. Je vais voir comment rendre la page moins «austère», et aussi s'il n'y a pas moyen de faire plus simple en syntaxe Wiki pour obtenir un résultat agréable, mais je ne suis pas super bon en design :( (j'ai voulu changer un peu la mise en page, ça m'a fait des choses pas jolies...).

Je pense aussi à ajouter dans le sommaire une phrase ou deux par chapitre pour expliquer rapidement ce dont il est question.

Alveric 24 août 2006 à 12:35 (CEST)

Ah ouais pas mal. Bon, c'est vrai que la forme est pas super, mais ce n'est pas à chier non plus. Dans la même veine, j'avais essayé de transformer le schèma dans le chapître sur les structures en tableau HTML. Bien c'était bien dégueux. Je n'arrivais pas à modifier correctement l'apparence et je voulais éviter le coup du HTML dégueux, version frontpage. De même que les styles CSS inline, c'est vraiment trop verbeux. L'idéal serait de pouvoir ajouter quelques règles dans la balise HEAD, mais je ne m'y connais pas trop donc, pour l'instant ça reste du texte et je sens que ça va finir en image bitmap :-/ Thierry Pierron 24 août 2006 à 17:53 (CEST)

Pour les images, je crois que wikipedia (au sens large) préfère le PNG, mais à part ça je ne me suis pas renseigné... Faudrait chercher sur un bistro ou une page d'aide (meta ?) des conseils de pro de la syntaxe wiki ou l'utilisation de modèles. Ca doit bien exister quelque part... Alveric 25 août 2006 à 16:26 (CEST)

Version imprimable

Je suis en train de voir comment faire une version imprimable du livre. J'ai ajouté des <div class="noprint">...</div> et des <noinclude></noinclude> dans les premières pages et le modèle {{Programmation C}} pour que ça soit à peu près bien. Vous pouvez voir le (début de) résultat sur Alveric/Livre C. Vous trouvez comment ? Alveric 31 août 2006 à 15:05 (CEST)

C'est une bonne idée mais c'est dommage qu'il faille créer une page dédiée pour avoir l'intégralité de l'article. C'est peut être le talon d'achile de la mise en page par liens hypertextes... -- Meithal 2 septembre 2006 à 01:21 (CEST)

J'ai parcouru le en.wikibooks, et je n'ai pas trouvé mieux comme méthode. Mais, si ça existe, je veux bien connaître ;)

Je pense qu'on peut arriver à jouer avec les noprint et les <noinclude> pour faire en sorte que, en demandant sur la "version imprimable" de la page de garde du wikilivre, on ait tout le wikilivre... Mais le code de la page serait plus complexe, et ça empêcherait un utilisateur de n'imprimer que la page de garde.

On peut imaginer un lien rapide "Version imprimable du wikilivre" dans la boîte à outils, qui ouvrirait une page qui serait spécifiée à l'aide d'une balise particulière dans la page courante (<printpage>, par exemple). Il suffirait, par exemple, que le modèle "Programmation C" inclue un lien vers la page de la version imprimable du livre entier avec cette balise, et on aurait le raccourci disponible depuis toutes les pages du livre.

Ou, tout simplement, ajouter un lien direct vers la version imprimable dans le modèle (ce qui ne nécessite pas de modifier le moteur wiki). Mais celà nécessite toujours une page spécifique où on définit le contenu du livre...

Alveric 4 septembre 2006 à 11:15 (CEST)

Gestion de la mémoire et chapitre socket BSD

J'ai fait une petite ébauche sur la gestion de la mémoire. C'est un gros manque je trouve.

Il pourrait également être intéressant d'ajouter un chapitre sur la programmation réseau en C avec les sockets BSD. Même cela ne fait partie de la bibliothèque standard, c'est un aspect intéressant je trouve. Il fait cela pour la version anglais (en:C Programming/Networking in UNIX). Sanao 15 février 2007 à 13:42 (CET)

Renommage massif Programmation_C_chapitre en Programmation C/chapitre ?

Bonjour,

Que pensez-vous de renommer tous les titres avec espace Programmation_C_chapitre vers Programmation C/chapitre, c'est pas urgent et un bot peut être dressé pour. Greudin 13 juin 2007 à 13:33 (CEST)

Je suis tout à fait  Pour. En plus, le bot pourrait se charger de mettre à jour les liens des pages liées et de supprimer les redirections alors obsolète. Attention également à ne pas casser la version imprimable (le bot pourrait aussi s'en charger). Sub 13 juin 2007 à 15:17 (CEST)

Rajouté dans Wikilivres:Requêtes aux bots Greudin 13 juin 2007 à 18:29 (CEST)

 Pour. Faire attention, car il y a déjà des pages avec le / (Sommaire et Version imprimable).

Pagination de la version PDF

Le fait de structure les pages en deux colonne enlève beaucoup d'espace pour écrire et lire du code de façon fonctionnelle et ergonomique, vous devriez le modifier pour qu'il afficher ces pages en une seule colonne de texte, malheureusement je doit le mettre à la corbeille, vu son illisibilité...

J'en ai posté un sur une seule colonne. JackPotte ($♠) 6 novembre 2014 à 08:58 (CET)