BPL: version C de la STL

Emmanuel Delahaye wrote:

In 'fr.comp.lang.c', Bertrand Mollinier Toublet
<bertrand.molliniertoublet@enst-bretagne.fr> wrote:

void* est indispensabple pour faire de la programmation générique. Même
l'idiome:

typedef struct obj obj_s;

<...>

obj_s *p_obj;

definit en fait un

void *p_obj;

sans le dire. Ca fait partie du langage.

La, il va falloir que tu clarifies, parce que j'ai pas suivi.

C'est le B.A. BA de l'ADT! J'ai maintes fois exposé cette technique...

/* main.c */
typedef struct obj obj_s;

int main (void)
{
obj_s *p_obj;

return 0;
}

A part '= NULL', je ne peux rien faire de plus, car le type sous-jacent de
'p_obj' est 'void*' (La taille de l'objet n'est pas définie).

Question idiote, reponse... a cote de la plaque :-)

Ce n'est pas ce que je voulais dire. Je connais bien la technique
decrite (et coupee), et je sais bien comment elle marche. Ce qui me fait
tiquer, c'est la phrase ci-dessus: "le type sous-jacent de 'p_obj' est
'void *'". La je ne suis pas bien sur d'etre d'accord.

Que le type de p_obj soit incomplet, d'accord, qu'on ne puisse pas le
dereferencer, d'accord, que ce soit un type void *, il va falloir me le
prouver.

--
Bertrand Mollinier Toublet
"Reality exists" - Richard Heathfield, 1 July 2003

Emmanuel Delahaye wrote:

In 'fr.comp.lang.c', Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote:

Je m'adresse plus à des gens qui font du C procédural
"classique", qui manipulent déjà des listes à coup de
macros qui castent tout en void*.

void* est indispensabple pour faire de la programmation générique.

As-tu regardé la proposition que j'ai faite ?

Même l'idiome:

typedef struct obj obj_s;

<...>

obj_s *p_obj;

definit en fait un

void *p_obj;

typedef struct foo foo_s;
typedef struct bar bar_s;

int main(){
foo_s *pfoo;
bar_s *pbar;
void* pvoid;
pfoo = pvoid;
pvoid= pfoo;
pfoo= pbar; /* AVERTISSEMENT: affectation d'un type pointeur incompatible */
return 0;
}

C'est l'avertissement qui fait, à mon sens, toute la différence.

Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(

In 'fr.comp.lang.c', Bertrand Mollinier Toublet
<bertrand.molliniertoublet@enst-bretagne.fr> wrote:

/* main.c */
typedef struct obj obj_s;

Que le type de p_obj soit incomplet, d'accord, qu'on ne puisse pas le

dereferencer, d'accord, que ce soit un type void *, il va falloir me le
prouver.

Disons que sémantiquement, c'est un void*, puisqu'on ne peut pas le
déreférencer, et qu'on ne connait pas la taille de l'objet pointé. Par
contre, il est 'nommé', ce qui permet au compilateur de faire quelques
vérifications de cohérence.

--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

In 'fr.comp.lang.c', Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote:

Je m'adresse plus à des gens qui font du C procédural
"classique", qui manipulent déjà des listes à coup de
macros qui castent tout en void*.

void* est indispensabple pour faire de la programmation générique.

As-tu regardé la proposition que j'ai faite ?

Non. Illisible. Pourquoi c'est pas du texte pur?

Même l'idiome:

typedef struct obj obj_s;

<...>

obj_s *p_obj;

definit en fait un

void *p_obj;

typedef struct foo foo_s;
typedef struct bar bar_s;

int main(){
foo_s *pfoo;
bar_s *pbar;
void* pvoid;
pfoo = pvoid;
pvoid= pfoo;
pfoo= pbar; /* AVERTISSEMENT: affectation d'un type pointeur
incompatible */ return 0;
}

C'est l'avertissement qui fait, à mon sens, toute la différence.

Certes, mais un warning n'est pas obligatoire. C'est un plus apporté par
certains compilateurs, en fonction de leur paramétrage. Ce n'est pas un
'diagnostic'.

--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

Emmanuel Delahaye wrote:

In 'fr.comp.lang.c', Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote:

void* est indispensabple pour faire de la programmation générique.

As-tu regardé la proposition que j'ai faite ?

Non. Illisible. Pourquoi c'est pas du texte pur?

C'est une archive, puisque cela regroupe plusieurs fichiers,
compressée, par respect pour ceux qui ont peu de bande passante.
Le code est en texte pur.
Le document d'accompagnement fait 16 pages avec des
figures. En général, les gens préfèrent alors avoir un
format imprimable. Toute requête particulière de format
texte, pdf ou html est étudiable.

Certes, mais un warning n'est pas obligatoire. C'est un plus apporté par
certains compilateurs, en fonction de leur paramétrage. Ce n'est pas un
'diagnostic'.

OK, ajoutons donc une couche.

typedef struct foo foo_s;
int main(){
foo_s* pfoo;
void* pvoid;
pvoid++;
pfoo++; /* KO: CQFD */
}

Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(

Bertrand Mollinier Toublet <bertrand.molliniertoublet@enst-bretagne.fr> writes:

| > C'est peut-être une erreur de présentation de ma part.
| > La solution "standart", c'est d'avoir un fichier qui recense
| > les instanciations courantes.
| > #ifdef VECTOR_INT
| > #include "VectorInt.h"
| > #else
| > #ifdef VECTOR_STRING
| > #include "VectorInt.h"
| > #endif
| > #endif
| > C'est rédibitoire à ton avis ?
| >
| En comparaison d'autres solutions, un petit peu, oui. Pour etre
| honnete, je ne suis pas un grand fan du preprocesseur.

et tu programmes en C ? ;-)

-- Gaby

Emmanuel Delahaye <emdelYOURBRA@noos.fr> writes:

| Certes, mais un warning n'est pas obligatoire. C'est un plus apporté par
| certains compilateurs, en fonction de leur paramétrage. Ce n'est pas un
| 'diagnostic'.

Ouarf, c'est quoi alors ?

-- Gaby

Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> writes:

| Disons que c'est vraiment une question de conception que je me pose.
| Je ne désire pas re-coder C++. Si on veut faire du C++, il existe
| des compilateurs, et pour cveux qui se plaignent de ne pas
| avoir de compilateur C++ sur leur plateforme, il paraît qu'il
| existe des traducteurs C++ -> C, donc, le problème est clot.

une question intéressante est donc : quels sont ces plateformes qui
ont des compilateurs C et pas de compilateurs C++ ?

-- Gaby

Emmanuel Delahaye <emdelYOURBRA@noos.fr> writes:

| In 'fr.comp.lang.c', Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
|
| > Emmanuel Delahaye <emdelYOURBRA@noos.fr> writes:
| >
| >| Certes, mais un warning n'est pas obligatoire. C'est un plus apporté par
| >| certains compilateurs, en fonction de leur paramétrage. Ce n'est pas un
| >| 'diagnostic'.
| >
| > Ouarf, c'est quoi alors ?
|
| Un 'diagnostic' est obligatoire et entraine une erreur, non?

Non. Tu confonds probablement avec les mentions « ill-formed » qui
elles demandent un diagnostic. La norme ne fait pas la différence
entre erreur, warning ou note informative. Un compilateur peut être
bien enovyer des diagnostics sur des programmes bien formés
(d'ailleurs la plupart des compilateurs de production ne se privent
pas de le faire)

[#1] diagnostic message
message belonging to an implementation-defined subset of the
implementation's message output

Marc Boyer wrote:

In article <3F05941D.60802@tb.fr>, AG wrote:

As tu vu :

et le lien cité : http://home.cern.ch/ldeniau/html/oopc/oopc.html

Oui, merci.
J'ai téléchargé, lu (mais pas essayé). Je le cite dans
la doc parmis les autres approches.
Disons que mon sentiment, c'est que les publics visés sont
différents. OOPC s'adressent à des gens convaincus par
la POO et qui veulent en retrouver les fonctionnalités avec
un compilateur C. Mais OOPC est quasiment un nouveau
langage.
Je m'adresse plus à des gens qui font du C procédural
"classique", qui manipulent déjà des listes à coup de
macros qui castent tout en void*.

Ca peut paraitre paradoxale, mais je n'encourage pas a utiliser ce qui est sur
la page OOPC. Encore une fois, il s'agit d'un exemple didactique sans interet
pratique (trop lourd). En revanche je peux (si demande il y a) mettre en acces
publique et sans garantie (et sans doc) un tar de ce qui est deja fait sur la
lib ooc (qui ne bouge plus beaucoup). Ca fait quelques lignes de C (cf liste des
fichier ci-dessous). Ce qui est dans le repertoire ooc forme le corps de la
technique (et peut etre utilise a part), le reste n'est qu'une lib d'objets
utiles. Je l'utilise depuis environ 6 mois dans un projet professionnel mais une
fois que celui-ci sera termine, je compte bien repasser serieusement a travers
le code pour enlever les UB et les trucs pas portables (normalement il y en a
peu) et surtout simplifier et optimiser certaines parties.

a+, ld.

165 ./array.h
284 ./array_bool.h
49 ./array_ptr_t.c
259 ./array_ptr_t.h
290 ./array_t.c
233 ./array_t.h
83 ./cfloat.h
48 ./complex.h
811 ./complex_t.c
681 ./complex_t.h
147 ./config.h
212 ./date.h
43 ./deque.h
68 ./deque_ptr_t.c
188 ./deque_ptr_t.h
375 ./deque_t.c
261 ./deque_t.h
161 ./exceptions.h
265 ./fdfstream.h
60 ./fft.h
98 ./file.h
104 ./float.h
242 ./fstream.h
42 ./hash.h
58 ./hash_ptr_t.c
231 ./hash_ptr_t.h
806 ./hash_t.c
412 ./hash_t.h
45 ./implementation_close.h
47 ./implementation_open.h
415 ./info.h
45 ./interface_close.h
47 ./interface_open.h
159 ./lib/array.c
38 ./lib/array_bool.c
42 ./lib/cfloat.c
53 ./lib/complex.c
232 ./lib/date.c
49 ./lib/deque.c
119 ./lib/exceptions.c
161 ./lib/fdfstream.c
241 ./lib/fft.c
70 ./lib/file.c
42 ./lib/float.c
156 ./lib/fstream.c
48 ./lib/hash.c
709 ./lib/info.c
47 ./lib/list.c
186 ./lib/lstrstream.c
60 ./lib/numeric.c
47 ./lib/queue.c
53 ./lib/ranvar.c
58 ./lib/real.c
51 ./lib/stack.c
43 ./lib/stream.c
78 ./lib/string.c
306 ./lib/strstream.c
51 ./lib/tree.c
716 ./lib/vector.c
48 ./list.h
54 ./list_ptr_t.c
230 ./list_ptr_t.h
410 ./list_t.c
312 ./list_t.h
124 ./lstrstream.h
92 ./numeric.h
63 ./ooc.h
45 ./ooc/alloc.h
127 ./ooc/array.h
43 ./ooc/assert.h
78 ./ooc/dbginfo.h
249 ./ooc/exception.h
379 ./ooc/exceptions.h
62 ./ooc/implementation_off.h
183 ./ooc/implementation_on.h
68 ./ooc/interface_off.h
187 ./ooc/interface_on.h
141 ./ooc/lib/alloc.c
137 ./ooc/lib/array.c
412 ./ooc/lib/class.c
401 ./ooc/lib/dbginfo.c
198 ./ooc/lib/exception.c
255 ./ooc/lib/exceptions.c
27 ./ooc/lib/init.c
23 ./ooc/lib/init.h
243 ./ooc/lib/object.c
61 ./ooc/lib/protocols.c
85 ./ooc/lib/shash32.c
102 ./ooc/lib/signal.c
96 ./ooc/lib/size.c
43 ./ooc/lib/utils.c
28 ./ooc/lib/utils.h
621 ./ooc/object.h
131 ./ooc/ooc.h
146 ./ooc/operators.h
36 ./ooc/private_off.h
67 ./ooc/private_on.h
70 ./ooc/protocols.h
114 ./ooc/shash32.h
102 ./ooc/signal.h
49 ./ooc/size.h
49 ./ooc/template_off.h
120 ./ooc/template_on.h
47 ./queue.h
68 ./queue_ptr_t.c
173 ./queue_ptr_t.h
101 ./queue_t.c
210 ./queue_t.h
48 ./ranvar.h
578 ./ranvar_t.c
463 ./ranvar_t.h
48 ./real.h
182 ./real_t.c
646 ./real_t.h
48 ./stack.h
67 ./stack_ptr_t.c
179 ./stack_ptr_t.h
205 ./stack_t.c
297 ./stack_t.h
91 ./stream.h
78 ./string.h
1512 ./string_t.c
716 ./string_t.h
191 ./strstream.h
174 ./sys/chrono.h
201 ./sys/lib/chrono.c
449 ./sys/lib/program.c
246 ./sys/lib/tcpclient.c
534 ./sys/lib/tcpserver.c
127 ./sys/program.h
115 ./sys/tcpclient.h
167 ./sys/tcpserver.h
44 ./template_off.h
42 ./template_on.h
55 ./tree.h
69 ./tree_ptr_t.c
264 ./tree_ptr_t.h
1411 ./tree_t.c
433 ./tree_t.h
73 ./utils/getline.c
31 ./utils/getline.h
69 ./utils/scanf.c
23 ./utils/scanf.h
122 ./utils/stdio.c
32 ./utils/stdio.h
53 ./utils/sys/msg.c
49 ./utils/sys/msg.h
63 ./utils/sys/sem.c
36 ./utils/sys/sem.h
81 ./utils/sys/signal.c
31 ./utils/sys/signal.h
348 ./vector.h
28891 total

--
[ Laurent Deniau -- Scientific Computing & Data Analysis ]
[ CERN -- European Center for Nuclear Research ]
[ Laurent.Deniau@cern.ch - http://cern.ch/Laurent.Deniau ]
[ -- One becomes old when dreams become regrets -- ]