(déclaration de la structure)
C’est la MEME chose.[/quote]
L’affirmation que “c’est la même chose” est une aberration.
D’un côté il y a une déclaration d’un nouveau type, de l’autre il y a déclaration de la structure à proprement parlé. Dans le premier cas le compilo ne va pas réserver de mémoire car la déclaration reste juste une déclaration, dans le second cas, il y a réservation de mémoire (3x4 octets sur un processeur 32bits et avec un alignement inférieur ou égal à 4 octets).
L’utilisation d’un même nom pour un type et une donnée SAIMAL. Ca ne sert à rien mis à part générer du code illisibile. On peut aussi appeler des variable X, XX, XXXX, yxz, … etc mais ce n’est pas lisible, pas maintenable. Pourquoi y-a-t-il des recommandations sur l’écriture et le nommage ? B)
[quote]L’affirmation que “c’est la même chose” est une aberration.[/quote]C’est pas ce que j’ai voulu dire, je me suis mal exprimé B)
Je voulais dire que l’on parle de la même structure.
En effet, struct Fiche et Fiche ne sont pas la même chose.
[quote]L’utilisation d’un même nom pour un type et une donnée SAIMAL. Ca ne sert à rien mis à part générer du code illisibile. On peut aussi appeler des variable X, XX, XXXX, yxz, … etc mais ce n’est pas lisible, pas maintenable. Pourquoi y-a-t-il des recommandations sur l’écriture et le nommage ?[/quote]Je suis d’accord, si ça ne tenait qu’à moi je n’aurais peut être pas mis le même nom (bien que ça ne me choque pas plus que ça ici).
Cependant dans ce programme là je n’ai pas le choix puisque la syntaxe de la déclaration est imposée.
Le prof a explicitement demandé de faire « typedef struct Fiche * Fiche; » ? Oh mon dieu B) Et il fait quoi dans la vie ce prof ? Encore un qui a dû se faire catapulter prof de C parce que « monsieur Gludu a pris sa retraite, alors c’est toi qui t’y colles, voilà un livre de C, t’apprends ça et tu commence à donner cours dans deux semaines ».
Ben je sais pas moi, c’est en tout cas ce qu’il y a écrit. Il s’est peut être trompé aussi. Je vais changer je crois et rajouter un p devant pour qu’on voie mieux que c’est un pointeur.
Oui c’est une bonne idée de différencier les types. Ceci dit, « on » recommande également de différencier le type de variable d’une définition de type. Par exemple, un nommage tel que « pMyPointer » pour définir (instancier) une variable de type pointeur, genre « void * pMyPointer » et un truc du type « t_p_MyStruct » pour déclarer un type pointeur sur MyStruct". L’ajout du « t_ » permet de ne pas confondre un type avec une variable… après à toi de toujours choisir la même syntaxe mais je recommande de consulter des docs de recommandations, que tu adapteras en fonction de ton écriture.
[quote=“bluelambda, post:17, topic: 31032”]Je n’ai pas le choix non plus pour le tout pointeur sur les structures B)
Notre prof nous a dit qu’il ne veut plus voir de “.”… alors comme c’est lui qui note il vaut mieux pas le contrarier. Pour l’instant ça me va je m’en sort bien avec le tout pointeurs.[/quote]
dans ce cas, tu définis un typedef normal, et à l’utilisation, tu ne définis pas une structure, mais un pointeur vers une structure, qui ensuite se fait un petit malloc/free pour utilisation. Tu auras donc un pointeur, c’est plus clair, ca te permet les deux utilisations, et tu n’as plus de . “point” (CE QUI EST TOTALEMENT IDIOT COMME OBJECTIF MAIS BON).
et sinon il est clair que ton argumentation montre de grosses lacunes de compréhensions.
[quote=« bluelambda, post:13, topic: 31032 »]Ce que tu semble ne pas comprendre c’est que:
typedef struct Fiche * Fiche;
(déclaration du type)
et
struct Fiche
{
char * nom;
char * prenom;
char * tel;
};
(déclaration de la structure)
C’est la MEME chose. La même entité que je déclare. Donc en fait non, je n’utilise pas le même nom pour deux entités DIFFERENTES. Si c’était le cas ça ne marcherai pas en plus, gcc me sortirai au moins un beau Warning.
Et c’est comme ça qu’on déclare proprement une structure de type pointeur.[/quote]
Tout à fait, absolument, définitivement.
Et c’est ainsi que cela s’enseigne.
Ca se comprend mais il y a des conventions de codage comme ca. Ne reprochez pas à Blue et à son prof de faire ainsi.
Les jugements de valeur, ca va bien un moment: c’est pour ca qu’il y a des conventions.
Ca a sans-doute déjà été dit, mais le typedef n’est autre qu’une sorte spécialisation du #define pour les types (K&R p130). Le code à Blue est donc correct. Après, selon les conventions, ca choque ou c’est la forme normale…
Dans K&R, ils ont fait attention à prendre deux noms différents dans leur exemple, mais n’ont jamais évoqué ces questions de convention (ils font du langage, eux). Rangez-moi ces guns, les mecs…
Pardon d’insister mais ce n’est pas la même chose. Y’a pas à tortiller.
Pour le choix d’un nommage identique entre un type de pointeur et une structure, je donne rendez-vous avec un compilo C++ où le mot clé typedef n’est plus “nécessaire”, en clair, la déclaration d’une structure induit la définition d’un type par défaut. Là il y a aura “multiple definition” et le changement de compilo sur un ensemble de sources volumineux devra être accompagné d’une révision complète de chaque usage de ces définitions. Bonjour la plaie. Autant prendre les bonnes habitudes dès le début. Ce n’est pas parce que “le prof a dit” qu’il a raison. Je pense que certains forumers ont plus de 10ans d’XP en développement C/C++, je ne suis pas sûr que ce soit le cas de tous les profs B)
Perso, je ne fais pas de jugement de valeur mais juste appel à mon XP. Il y a des choses “qu’on ne fait pas”, jamais, sous peine de se faire rejeter des pierres B). L’apprentissage est aussi là pour acquérir de bon réflexes, à mon avis et sur les exemples cités, il y a des lacunes à mon sens, et elles proviennent apparemment de l’enseignant. Il faut rester critique vis-à-vis des traçages de lois, n’est-ce pas ?
Pour les enseignants, ca dépend vraiment sur qui tu tombes en ce qui concerne le niveau technique. Mais enseigner, ce n’est pas inculquer les usages en vigueur, et à mon avis vous vous cassez les dents à les prendre pour des débiles heureux.
Quant au reste, j’attends qu’on me sorte une norme ANSI pour démontrer un éventuel tort. Je rapelle que le bout de code qui fait polémique est considéré par ceux qui l’enseignent et le pratiquent comme une figure de style de base.
Quant aux compilos, faudrait-il encore qu’ils respectent scrupuleusement les normes en vigueur. Moi, je ne juge pas, je sors les normes…
J’espère qu’on leur a bien expliqué car j’ai eu trop de camarades qui derrière sont largués à cause d’une figure de style tellement naturelle pour le prof qu’il avait du mal à leur expliquer le pourquoi là c’est bon et pas à côté, plutôt que de rester dans les normes implicites (un exemple de norme implicite : on évite le mixed-case genre ma variable hAxOrKiTuEsAMeRe, c’est « évident » pour tout le monde, même si cette règle n’a jamais été transcrite en ANSI), norme étant pris dans son sens littéraire ici. Donc pour le coup, quand l’élève apprend le truc de base, j’évite les pièges prévisibles, et ce genre de figure, je le garde à la limite pour les exos avancés, quand tout le monde est censé avoir bien compris de quoi il s’agissait, pas lors du TP découverte. B)
Certes mais comme tout le reste, même si c’est pas parfait (les normes non plus d’ailleurs :D) dans un monde réel, on fait avec les compilos qu’on a, on n’est pas en lambda-calcul théorique mais en apprentissage d’un langage pratique (vu son « exercice ») B)
Un dernier truc pour finir, tout ce qui est sur un polycopié d’un prof n’est pas parole d’évangile, donc en cas de doute, faut pas hésiter à lui demander, ça peut être une faute de frappe ou d’inattention du prof (ou incompétence parfois ^^), bref errare humanum est…
Attends, planquer un pointeur, une figure de style de base ? Mais c’est quoi ce délire ? Le typedef des struct je suis d’accord, c’est clean et j’étais le premier à le faire dans mon jeune temps où je faisais du C, et je le collais même dans une seule ligne (typedef struct Toto_ { … } Toto;). Et on pouvait même laisser la struct sans nom, si on n’avait pas besoin de la référencer dans elle-même. Mais alors le (typedef struct Toto * Toto;) je maintiens que c’est catastrophique, aussi bien niveau usage pratique que pédagogique.
Et moi j’essaie de comprendre si on parle de la même chose. Est-ce que tu peux me sortir la moindre référence, un cours, un bouquin, n’importe quoi, où il est expliqué que le fait de cacher un pointeur dans un typedef du même nom que la struct vers laquelle il pointe est recommandé ?
Je ne dis pas que c’est forcément recommandé, et perso je serais un petit peu plus d’accord avec ta vision (distinguer) qu’avec celle-là. Quand j’ai enseigné du typedef, je ne m’y suis pas pris comme ca, sinon pour un premier TD, les nétudiants ils ne comprennent pas.
Ceci dit, ce code n’a rien de scandaleux non-plus, bien au contraire. Donc pas troll, hein.
Pour les cours: oui, bien sûr. Pour les bouquins: j’ai pu vérifier que le K&R n’infirmait pas cette notation sans la confirmer non plus. Le Soustrup s’en fout. Pour la norme GNU (coding standards), je n’ai pas réussi à retrouver cela sur la version en ligne, alors que je pense que ca vient justement de là. Pour la norme ansi C, je doute qu’elle en parle, mais la plupart de mes affaires sont dans les cartons, donc je peux pas vérifier de suite (et en plus je m’en moque un peu).
Pour ce dont je me souviens des cours où j’ai vu cela, il s’agit d’inciter à passer que des pointeurs pour éviter des recopies inutiles et dangereuses. Ca ne mord pas, en plus. Sans m’avancer, il me semble aussi que tous les objets en java sont passés par référence en interne (je suis une bille en Java).
Mais encore une fois, il s’agit de conventions. Cette convention-là existe, c’est tout, à titre officiel, et elle est tant suivie qu’enseignée. Les conventions de codage sont comme des types incomparables, comme la classe Voiture et la classe Oxymore. Rangez donc ces pieds-de-biche et cessez de me regarder comme ca…
[quote]> Sixth, there is a real « mess » about name spaces. It is true that
every C programmers knows the rule saying tags inhabit different name
space than variable of functions. However, all the C coding standards
I’ve read so far usually suggest
typedef struct foo foo;
but not
typedef struct foo *foo;
i.e. « bringing » the tag-name into normal name space to name the type
structure or enumeration is OK, but not naming a different type![/quote]
Je suis persuadé que tu mélanges les deux cas, t’es vraiment sûr d’avoir lu ça quelque part ?
Alors pourquoi derrière mon message parles-tu d’intégrisme ? C’est ce que je dis, non ? B) Et je continue à penser que je trouve pas ça judicieux dans un cadre éducatif.
Basse vengeance (cf threads avec Emacs, Common Lisp & co) B)
Z-êtes même pas concernés si ca se trouve, mais bon c’est de la méchanceté gratuite. Un peu comme quand on dit du mal de la fac par plaisir ou automatisme, c’est toujours froissant pour ceux qui s’y investissent. Mais rien de plus…
Ca dépend à quel niveau! Pour un apprentissage de base des structures et du typedef, c’est très inutilement et gratuitement complexe, ca me viendrait même pas à l’idée de le présenter ainsi. Dans d’autres modules où on a un bagage minimal, y’a plus ce problème…
Mais bon, wait ce soir que je retrouve la cellulose sur laquelle j’ai vu ca…
Bon, alors, dans mon cours à Bordeaux, y’a bel et bien ca, je n’avais pas rêvé. Par contre, pas de trace de ce genre de conventions dans la ‹ norme › GNU. J’ai aussi trouvé la même chose dans le bouquin de Braquelaire, mais c’est un Bordelais aussi, donc ca compte pour un seulement B)
En clair, je n’ai pas trouvé de coding standards qui affirme ni même infirme notre ‹ débat ›. Qui me fatigue, vu que j’ai autre chose à faire d’urgent là et que ca m’aide pas. Alors tiens, pouf, z’êtes mis à contribution:
Vous connaissez la méthode ICP (iterative closest point) pour aligner deux modèles polygonaux à partir de leurs points? Si vous avez eu vent de code pour des méthodes non-linéaires, PM please car là je craque...
et pendant ce debat sur les structures sur ce forum, dans ma boite juste a coté de moi y’a le software architect qui tente d’expliquer au plus vieux développeur de la société les avantages d’un objet sur une structure et le gars comprend pas. Ca me fait bien rire.
