/* Topic des codeurs couche-tard [2] */

Pylades · Le 06/11/2010, à 01:51

Tu nous montres comment est foutue Str ?
(Ça peut être utile.)

Au fait, penses-tu vraiment qu'il faille renommer option en Option pour ne pas choquer les gens ?

Dernière modification par Pylade (Le 06/11/2010, à 01:53)

cm-t · Le 06/11/2010, à 02:00

'Nuit;

Pylades · Le 06/11/2010, à 02:01

Et pouf, dodo…

grim7reaper · Le 06/11/2010, à 02:23

Pylade a écrit :

Tu nous montres comment est foutue Str ?
(Ça peut être utile.)

C'est une astuce qui joue les déclarations et sur l'organisation du code.

Str.h: on définit un pointeur sur un type qui n'existe pas (du moins pas encore), ça fonctionne car le compilo n'a pas besoin de connaître le type pointé pour allouer un pointeur (un pointeur à toujours la même taille), et tant que l'on ne le déréférence pas et bien pas besoin de connaître l'objet pointé (comme on ne le déréférence pas dans le header, no problem).

#include <stdlib.h>
#include <stdio.h>
#include <string.h>

typedef struct Str__* Str;

/* Constructors. */
Str Str_new(void);

Str Str_new_with_text(const char* s);
[…]
#endif

Str.c: là on définit vraiment notre type pour pouvoir l'utiliser.

#include "str.h"

struct Str__
{
    char*  str_;
    size_t slen_;
    size_t mlen_;
};

Str Str_new(void)
{
    Str str = malloc(sizeof *str);

    if(str != NULL)
    {
        str->slen_ = 0;
[…]

L'astuce vient fait que l'utilisateur inclut le header (donc la définition incomplète du type) ce qui l'empêche de déréférencer ses variables Str pour modifier les champs à la main. Autre point positif, on masque l'implémentation (car même dans le header on ne voit rien) donc il ne peut pas voir comment c'est codé (ce qui fait que nous on peut modifier la structure interne sans problème en cas de besoin, car personne ne va produire de code qui se base directement sur nos champs, ils passent obligatoirement par l'interface que l'on a défini).
Pour le coup, on a vraiment un ADT là .

Au fait, penses-tu vraiment qu'il faille renommer option en Option pour ne pas choquer les gens ?

Non, tu fais comme tu veux.
Moi j'ai pour habitude de mettre la première lettre de mes types (struct, enum, union et parfois typedef) en majuscule mais ce n'est pas une obligation. Je rencontre couramment les deux.

Dernière modification par grim7reaper (Le 06/11/2010, à 04:41)

gnuuat · Le 06/11/2010, à 02:28

!_!

Кຼزດ · Le 06/11/2010, à 03:14

hop

Askelon · Le 06/11/2010, à 04:06

samυncle · Le 06/11/2010, à 04:48

.

nesthib · Le 06/11/2010, à 04:51

plop

Compteur du TdCCT · Le 06/11/2010, à 08:42

Scores totaux, depuis le début :

1) 1771    nesthib
2) 1710    samuncle
3) 1454    Pylade
4) 1053    Кຼزດ
5) 878    cm-t
6) 723+5  grim7reaper /* ./viewtopic.php?pid=3486252#p3486252 */
7) 676    Р☢w ! ✰ :mad: ✰ (эй !)
8) 665    \\Ouranos//
9) 636    helly
10) 368    Lagierl
11) 315    gnuuat
12) 266    tshirtman
13) 167    Kanor
14) 146    Askelon
15) 121    ǤƦƯƝƬ
16) 93    petifrancais
17) 82    nathéo
18) 78    edge_one
19) 70    gulp
20) 66    pierguiard
21) 59    kamui57
22) 50    The Uploader
23) 37    ilagas
24) 30    keny
25) 27    Le Rouge
26) 25    GentooUser
27) 24    ไ୦บเઢ'
28) 20    Morgiver
28) 20    CROWD
30) 18    Ph3nix_
30) 18    xapantu
32) 15    timsy
33) 14    kouskous
34) 12    stratoboy
34) 12    sailing
36) 11    alexises
36) 11    Crocoii
38) 10    Toineo
38) 10    NutMotion
38) 10    pseudovingtcinqcaracteres
38) 10    pfriedZ
42) 8    Mornagest
43) 7    Vista
44) 6    Zeibux
44) 6    ubuntlin
44) 6    asma.geek
47) 5    tendances-tdct
48) 4    danychou56
48) 4    Neros
48) 4    Biaise
48) 4    totoflute
48) 4    pinballyoda ㋛
53) 2    SoJaS
53) 2    ceric
55) 1    geenux

chart?chs=675x280&cht=p3&chco=d80020,d88000,ffd840,20d820,2080ff,101080,a020d8&chf=bg,s,fbf9f4&chl=01h%20-%2001h59|02h%20-%2002h59|03h%20-%2003h59|07h%20-%2007h59|18h%20-%2018h59|19h%20-%2019h59|20h%20-%2020h59|21h%20-%2021h59|22h%20-%2022h59|23h%20-%2023h59&chd=t:4,1,3,2,1,3,4,1,2,4&chp=1.6&chtt=R%C3%A9partition%20des%20posts&chts=606060,16

Compteur du TdCCT · Le 06/11/2010, à 08:42

Scores de la période en cours :

1) 50    samuncle
1) 50    nesthib
1) 50    nathéo
4) 45    grim7reaper
5) 32    cm-t
6) 30    Кຼزດ
7) 26    gnuuat
8) 19    Pylade
9) 16    Askelon
10) 11    \\Ouranos//
11) 10    tshirtman
12) 8    Lagierl
13) 3    Kanor

Pylades · Le 06/11/2010, à 20:33

Ah, tiens, tu mets la définition de la structure directement dans le fichier source où sont tes fonctions pour travailler dessus… Hum, ça paraît bizarre au début, mais en fait je trouve ça assez séduisant, j'adopte (en réorganisant mes headers).

http://gitorious.com/libstropt/

grim7reaper · Le 06/11/2010, à 20:41

Pylade a écrit :

Ah, tiens, tu mets la définition de la structure directement dans le fichier source où sont tes fonctions pour travailler dessus…

C'est ça qui permet la "privatisation" de la structure, seule les fonctions qui bossent dessus connaissent sa composition interne et y ont accès, le monde extérieur (et surtout l'utilisateur) non.

Pylades · Le 06/11/2010, à 21:27

Oui, j'ai compris. ^^
Bon, super, j'ai découvert un bug !

Et comme je n'ai pas finalisé l'interface, je suis obligé garder une copie des définitions des structures dans mon header principal…

Et j'espère que je n'ai pas fait de conneries en mettant à jour mon makefile…

xapantu · Le 06/11/2010, à 21:44

@Pylade : si j'ai bien compris, ta librairie sert à parser des arguments, c'est ça ? (en tout cas c'est ce que j'ai compris en lisant rapidement l'en-tête des fichiers sources...) Parce que ça m'intéresserai pour un projet qui n'a encore rien à ce niveau là...

Dernière modification par xapantu (Le 06/11/2010, à 21:44)

Pylades · Le 06/11/2010, à 22:01

Oui, c'est bien cela. Mais bon, ce n'est pas encore finalisé. En tous cas, tu peux récupérer l'archive et lancer Doxygen pour avoir une documentation plus ou moins complète.

xapantu · Le 06/11/2010, à 22:13

Pylade a écrit :

Oui, c'est bien cela. Mais bon, ce n'est pas encore finalisé. En tous cas, tu peux récupérer l'archive et lancer Doxygen pour avoir une documentation plus ou moins complète.

Merci
Je regarderai ça demain.

nathéo · Le 06/11/2010, à 23:04

Points…

Pylades · Le 07/11/2010, à 01:04

Bon, le gros bug que j'avais repéré est corrigé. À force de faire un gros code bien compliqué, j'avais interverti la valeur de deux codes de retour. ><"

Bon, je vais encore un peu bosser l'ADT.

grim7reaper · Le 07/11/2010, à 01:23

Je vais essayer de voir si je peux pas écrire des tests pour ta lib (de toute façon cette nuit je suis parti pour pas me coucher avant 8-9h donc bon…).

Par contre tu devrais virer smalloc et srealloc, tester et debugger aléatoirement c'est pas super .

Au fait, un truc qui pourrait t'intéresser que j'ai découvert il y a quelques semaines : gcc peut, via l'option -MM, générer une liste de dépendances que l'on peut utiliser directement dans les Makefile (moyennant un petit traitement avec sed).

En guise d'exemple, voilà un petit Makefile

# Makefile pour un projet C standard avec CUnit

# Variable qui permet de compiler en debug ou en release
# Mettre yes pour compiler en mode debug
DEBUG = yes
# Nom du compilateur
CC = gcc
# Flags d'erreurs :
ERROR_CFLAGS = -ansi -pedantic -Wall -Wextra -Wformat=2 -Wwrite-strings -Wstrict-prototypes -Winit-self
# Flags pour le compilateur :
DEBUG_CFLAGS = -g
RELEASE_CLAGS = -O2

# On regarde si la variable debug est vraie
ifeq ($(DEBUG),yes)
CFLAGS = $(ERROR_CFLAGS) $(DEBUG_CFLAGS)
else
CFLAGS = $(ERROR_CFLAGS) $(RELEASE_CLAGS)
endif

# Flags pour l'editeur de liens :
LDFLAGS = $(ERROR_CFLAGS) -lcunit
# Nom de l'executable a creer
EXEC = str_test
# Liste des fichiers sources
SRC = $(wildcard *.c)
# Liste des fichiers objets a creer
OBJ = $(SRC:.c=.o)

all: $(EXEC)

ifeq ($(DEBUG),yes)
    @echo "Generation en mode debug"
else
    @echo "Generation en mode release"
endif

$(EXEC):$(OBJ)
    @$(CC) -o $@ $^ $(LDFLAGS)

# Liste des dependances
-include $(SRC:.c=.d)

# Regle d'inference pour la generation du code objet
%.o: %.c
    @$(CC) -o $@ -c $< $(CFLAGS)

# Generation automatique des dependances
%.d: %.c
    $(CC) -MM $(CFLAGS) $< | sed 's/$*.o/& $@/g' > $@

.PHONY: clean mrproper
    
# Supprime tout les fichiers objet
clean:
    @rm -f $(OBJ)
    @rm -f *.*~

# Supprime tout les fichiers objet et l'executable
mrproper: clean
    @rm -f $(EXEC)

Dernière modification par grim7reaper (Le 07/11/2010, à 01:55)

Pylades · Le 07/11/2010, à 02:10

Je n'ai pas encore fait le commit pour la correction du bug que je viens de voir, donc ne t'affole pas si un argument est sauté… ^^

Pour smalloc et srealloc, je les garde car cela peut toujours servir, mais les chances qu'ils entrent en jeu sont infimes, ils ne sont donc pas un problème pour le debug.

Et sinon, je ne savais même pas que Make pouvait lire une liste de dépendances depuis un fichier spécifique… J'ai encore beaucoup à apprendre dessus, il faudrait que je m'y mette…

grim7reaper · Le 07/11/2010, à 02:16

Pylade a écrit :

Pour smalloc et srealloc, je les garde car cela peut toujours servir, mais les chances qu'ils entrent en jeu sont infimes, ils ne sont donc pas un problème pour le debug.

Servir en quoi ?
Si tu veux que le truc échoue tu le mets NULL à la main, au moins c'est déterministe.
Et puis infime n'est pas nulle

Ou alors rend les désactivables avec un simple paramètre lors de la compil' (genre un -DN_DEBUG). En tout cas, voire les fonctions s(m|re)alloc "partout" dans le code ça fait un peu moyen je trouve…

Dernière modification par grim7reaper (Le 07/11/2010, à 02:17)

cm-t · Le 07/11/2010, à 02:18

'Nuit;

// /me à trouvé dans son sac 3 pages d'exo cpp pour lundi …

grim7reaper · Le 07/11/2010, à 02:20

Arf, merde.

Maintenant que tu le dis j'ai aussi du C++ à faire, bah je commencerais à 2h.

Dernière modification par grim7reaper (Le 07/11/2010, à 02:41)

Pylades · Le 07/11/2010, à 02:38

grim7reaper a écrit :

Pylade a écrit :
Pour smalloc et srealloc, je les garde car cela peut toujours servir, mais les chances qu'ils entrent en jeu sont infimes, ils ne sont donc pas un problème pour le debug.
Servir en quoi ?
Si tu veux que le truc échoue tu le mets NULL à la main, au moins c'est déterministe.
Et puis infime n'est pas nulle
Ou alors rend les désactivables avec un simple paramètre lors de la compil' (genre un -DN_DEBUG). En tout cas, voire les fonctions s(m|re)alloc "partout" dans le code ça fait un peu moyen je trouve…

J'ai besoin que ça puisse échouer n'importe où, n'importe quand ; il est donc exclu de mettre NULL à la main. Mais OK, je vais utiliser NDEBUG (et puis je ne compte pas laisser ça comme ça pour la release).

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1101 Le 06/11/2010, à 01:51

Re : /* Topic des codeurs couche-tard [2] */

#1102 Le 06/11/2010, à 02:00

Re : /* Topic des codeurs couche-tard [2] */

#1103 Le 06/11/2010, à 02:01

Re : /* Topic des codeurs couche-tard [2] */

#1104 Le 06/11/2010, à 02:23

Re : /* Topic des codeurs couche-tard [2] */

#1105 Le 06/11/2010, à 02:28

Re : /* Topic des codeurs couche-tard [2] */

#1106 Le 06/11/2010, à 03:14

Re : /* Topic des codeurs couche-tard [2] */

#1107 Le 06/11/2010, à 04:06

Re : /* Topic des codeurs couche-tard [2] */

#1108 Le 06/11/2010, à 04:48

Re : /* Topic des codeurs couche-tard [2] */

#1109 Le 06/11/2010, à 04:51

Re : /* Topic des codeurs couche-tard [2] */

#1110 Le 06/11/2010, à 08:42

Re : /* Topic des codeurs couche-tard [2] */

#1111 Le 06/11/2010, à 08:42

Re : /* Topic des codeurs couche-tard [2] */

#1112 Le 06/11/2010, à 20:33

Re : /* Topic des codeurs couche-tard [2] */

#1113 Le 06/11/2010, à 20:41

Re : /* Topic des codeurs couche-tard [2] */

#1114 Le 06/11/2010, à 21:27

Re : /* Topic des codeurs couche-tard [2] */

#1115 Le 06/11/2010, à 21:44

Re : /* Topic des codeurs couche-tard [2] */

#1116 Le 06/11/2010, à 22:01

Re : /* Topic des codeurs couche-tard [2] */

#1117 Le 06/11/2010, à 22:13

Re : /* Topic des codeurs couche-tard [2] */

#1118 Le 06/11/2010, à 23:04

Re : /* Topic des codeurs couche-tard [2] */

#1119 Le 07/11/2010, à 01:04

Re : /* Topic des codeurs couche-tard [2] */

#1120 Le 07/11/2010, à 01:23

Re : /* Topic des codeurs couche-tard [2] */

#1121 Le 07/11/2010, à 02:10

Re : /* Topic des codeurs couche-tard [2] */

#1122 Le 07/11/2010, à 02:16

Re : /* Topic des codeurs couche-tard [2] */

#1123 Le 07/11/2010, à 02:18

Re : /* Topic des codeurs couche-tard [2] */

#1124 Le 07/11/2010, à 02:20

Re : /* Topic des codeurs couche-tard [2] */

#1125 Le 07/11/2010, à 02:38

Re : /* Topic des codeurs couche-tard [2] */

Pied de page des forums