POO en C

ld a écrit :

On 12 août, 16:53, Wykaaa <wyk...@yahoo.fr> wrote:

candide a écrit :

ld a écrit :

sur quels points?

Est-ce que ce qu'il propose dans son exposé permet faire de la POO en C de façon
simple et efficace ? Est-ce que son approche objet du C est comparable à celle
de GTK ?
Est-il réaliste de donner un design OO à ses programmes en utilisant son exposé
? Je n'arrive pas à voir s'il donne une méthode pour faire de la POO en C ou
s'il explique comment faire un framework qui va me permettre ensuite d'en faire
? Ce qui me titille c'est j'ai toujours eu l'impression que faire de la POO en C
à la différence de C++ ou Objective C est assez lourd à mettre oeuvre (parce
que le langage n'a pas été prévu pour ça au départ).

Il me semble qu'aujourd'hui, se poser toutes ces questions à propos de C
est sans intérêt.
Si on veut faire de la POO on choisit un langage objet. Point-barre.

Quel langage objet aussi efficace que C (ou mieux, C++) connais-tu qui
supporte

- les multi-methodes
- la delegation generique (a la SmallTalk)

Tu nous parles de COS là ?

Ces deux concepts (apres avoir joue avec pendant deux annees) sont
pour moi, l'aboutissement d'un language OO.

Sinon, pourquoi pas se poser aussi la question, par exemple, de faire de
la programmation fonctionnelle en Cobol...

On peut multiplier les questions farfelues à loisir !

Les motivations ne sont pas forcement farfelues.

C'est vrai !

Jean-Marc Bourguet a écrit :

Wykaaa <wykaaa@yahoo.fr> writes:

Sinon, pourquoi pas se poser aussi la question, par exemple, de faire de
la programmation fonctionnelle en Cobol...

Si je vois comment faire de la POO en C, j'ai du mal voir comment faire de
la programmation fonctionnelle en Cobol. Tu as une page a proposer?

A+

Voilà la page en question :
http://www.volle.com/travaux/objet.htm

Regarde le § programmation fonctionnelle.

C'était une "private joke" ;-)

ld a écrit :

On 12 août, 17:38, Manuel Pégourié-Gonnard <mpg+n...@elzevir.fr>
wrote:

ld scripsit:

On 12 août, 11:29, candide <cand...@free.invalid> wrote:

Bonjour,
Vous pensez quoi de ce livre de Axel-Tobias Schreiner sorti en 1994 :
http://www.cs.rit.edu/~ats/books/ooc.pdf ?

sur quels points?

Bon, du coup j'en profite pour greffer ma question (en remerciant au
passage Candide pour la référence).

Que pensez-vous d'utiliser ce livre dans l'optique de mieux comprendre
comment sont implémentés les langages à objet,

_les_ langages objets, ca representent pas mal de modeles differents
et chacun implique souvent des methodes de POO differentes (sorti des
design patterns).

tout en enrichissant un
peu sa culture C ?

sur ce point d'accord, bien que ooc date un peu et les methodes
utilisees sont peut fiable. Je ne suis pas un fan de la programmation
defensive.

Quand je lis l'extrait cité de la préface, j'ai
l'impression que c'est un des buts du livre. Avez-vous l'impression
qu'il atteint cet objectif ?

oui et non. Il n'explique pas vraiment ce qu'est la POO. Je pense
qu'aujourd'hui je conseillerais plutot les Doc Apple sur Objective-C
(il en a plein et bien ecrite). Mais la aussi, c'est un modele objet
parmi d'autres, probablement transposable pour une bonne partie en C++
ou Java/C#/D, mais pas en totalite (tres dynamique).

Si non, que recommanderiez-vous comme lecture sur le sujet de
l'implémentation des langages objet ?

en C? il n'y a pas grand chose et pour ce qu'il y a, je ne le
recommanderais pas. Il n'y a deja pas grand chose sur la programmation
en C qui soit correct alors sur la POO en C...

Il faut d'abord savoir par quel modele on est interesse, choisir un
langage OO qui est base dessus et lire des ouvrages focalises sur le
modele OO (voir le design, c'est souvent lie). Pour les modeles les
plus courus (du plus statique au plus dynamique):

modele statique generatif -> C++ (+RAII+TMP)
modele statique generic -> Java, C#, D, Eiffel
modele dynamique -> Objective-C
langage dynamique -> Python, IO

Pendant le developpement de OOC-2.0 (pas ooc) puis de COS, j'ai etudie
une quarantaines de languages differents (sans les pratiquer tous)
pour comprendre leur avantages, leur inconvenients et une
implementation possible. J'ai lu plus de mille papiers sur les sujets
concernes (le sujet est vaste) mais je n'ai jamais rien trouve de
satisfaisant sur la POO en C.

Et pendant tout ce temps, la seule chose qui m'ait vraiment
impressionne, c'est la bibliotheque chaos-pp sur la meta-programmation
avec cpp. Pour le reste, j'ai vu du code pseudo OO propre (la machine
virtuelle Sun pour Java par ex) mais pas de facon exceptionnelle
d'utiliser le C pour faire de la POO.

a+, ld.

Ah oui, tu parlais bien de COS (voir mon message au-dessus) mais je
n'avais pas encore lu celui-ci.

Globalement, je suis d'accord avec ce que tu dis et tout
particulièrement avec le dernier §.

ld a écrit :

implementation possible. J'ai lu plus de mille papiers sur les sujets
concernes (le sujet est vaste) mais je n'ai jamais rien trouve de
satisfaisant sur la POO en C.

avec cpp. Pour le reste, j'ai vu du code pseudo OO propre (la machine
virtuelle Sun pour Java par ex) mais pas de facon exceptionnelle
d'utiliser le C pour faire de la POO.

On dirait que tu as fait le tour de la question et tu sembles un peu désabusé.

En tous cas, merci beaucoup de tes éclaircissements.

On 12 août, 23:41, Wykaaa <wyk...@yahoo.fr> wrote:

ld a écrit :





> On 12 août, 16:53, Wykaaa <wyk...@yahoo.fr> wrote:
>> candide a écrit :

>>> ld a écrit :
>>>> sur quels points?
>>> Est-ce que ce qu'il propose dans son exposé permet faire de la POO en C de façon
>>> simple et efficace ? Est-ce que son approche objet du C est comparabl e à celle
>>> de GTK ?
>>> Est-il réaliste de donner un design OO à ses programmes en utilis ant son exposé
>>> ? Je n'arrive pas à voir s'il donne une méthode pour faire de la POO en C ou
>>> s'il explique comment faire un framework qui va me permettre ensuite d'en faire
>>> ? Ce qui me titille c'est j'ai toujours eu l'impression que faire de la POO en C
>>> à la différence de  C++ ou Objective C est assez lourd à mett re oeuvre (parce
>>> que le langage n'a pas été prévu pour ça au départ).
>> Il me semble qu'aujourd'hui, se poser toutes ces questions à propos de C
>> est sans intérêt.
>> Si on veut faire de la POO on choisit un langage objet. Point-barre.

> Quel langage objet aussi efficace que C (ou mieux, C++) connais-tu qui
> supporte

> - les multi-methodes
> - la delegation generique (a la SmallTalk)

Tu nous parles de COS là ?

Oui. Mais si tu en connais un autre, je suis preneur, ca m'eviterais
de maintenir mon propre langage ;-)

> Ces deux concepts (apres avoir joue avec pendant deux annees) sont
> pour moi, l'aboutissement d'un language OO.

>> Sinon, pourquoi pas se poser aussi la question, par exemple, de faire de
>> la programmation fonctionnelle en Cobol...

>> On peut multiplier les questions farfelues à loisir !

> Les motivations ne sont pas forcement farfelues.

C'est vrai !

a+, ld.

On 13 août, 01:11, candide <cand...@free.invalid> wrote:

ld a écrit :

> implementation possible. J'ai lu plus de mille papiers sur les sujets
> concernes (le sujet est vaste) mais je n'ai jamais rien trouve de
> satisfaisant sur la POO en C.
> avec cpp. Pour le reste, j'ai vu du code pseudo OO propre (la machine
> virtuelle Sun pour Java par ex) mais pas de facon exceptionnelle
> d'utiliser le C pour faire de la POO.

On dirait que tu as fait le tour de la question et tu sembles un peu dé sabusé.

je ne suis pas desabuse. COS correspond exactement a ce que je
cherchais ;-). Sur le plan statique, je prefere biensur C++ pour ses
template + overloading + TMP + RAII. Mais je trouve que C pourrait
faire _beaucoup_ mieux avec trois extensions tres simples a
implementer dans un compilateur C. J'en ai deja parle ici:

- les acces simplifies au champ de struture (1) et la projection de
type (2, aka subtyping):

(1) signifie que le compilateur detecte automatiquement le 'chemin'
pour acceder a un champ de structure ou rapporte une ambiguite s'il y
a plusieurs possiblites.

(2) signifie que le compilateur accepte un struct D* a la place d'un
struct B* si struct D commence par un struct B. Si on veut converser
struct D comme un ADT, on peut utiliser l'extension 3 ci-apres pour le
specifier.

struct Base {
int a, b;
};

struct Foo {
int b;
};

struct Derived {
struct Base B;
struct Foo F;
int c;
};

void bar(struct Base *b) {
...
}

void foo(struct Foo *f) {
...
}

int main(void) {
struct Derived d;

d.a = 1; // Ok
d.b = 2; // ambiguity, path must be specified: d.B.b = 2; or d.F.b =
2;
d.c = 3; // Ok

bar(&d.B); // Ok
bar(&d); // Ok struct Derived starts with a struct Base

foo(&d.F); // Ok
foo(&d); // invalid: struct Derived doen't start with a struct Foo
}

La troisieme extension (overloading local) est un peu plus complique a
specifier techniquement mais simple a expliquer (et a implementer):

// --- my.h

void foo_char(char);
void foo_int(int);
void foo_double(double);
double add_double(double);

// overloading local, pas d'influence sur le linker (pas de
decoration).
_Alias foo(char) = foo_char(char);
_Alias foo(int) = foo_int(int);
_Alias foo(double) = foo_double(double);
_Alias _Operator + (vector,vector) = vector_add(vector,vector);
_Alias _Operator [] (vector,size_t) = vector_at(vector,size_t);

struct Base; // ADT
struct Derived; // ADT
struct Foo; // ADT

// accepte struct Derived* a la place d'un struct Base*
_Alias struct Derived = struct Base; // Ok
_Alias struct Derived = struct Foo; // erreur dans derived.c

// --- my.c

#include "my.h"

int main(void) {
char c = 'c';
foo(c); // = foo_char('c');
foo('c'); // = foo_int('c');
foo(0); // foo_int(0);
foo(0.0); // foo_double(0);

vector v1 = new_vector(10, 1.0);
vector v2 = new_vector(10, 2.0);
vector v = v1 + v2; // = vector_add(v1,v2);
double d = v1[3]; // = vector_at(v1,3);
del_vectors(v1,v2,v3,0);
}

Pour l'overloading, il faut que la signature exacte existe dans
l'unite de traduction via un _Alias avant ou apres les promotions
usuelles, inclus la projection de type mentionnee en (2). Pour les
operateurs unaires suffix ou binaires et ternaire, la convention que
l'argument qui precede est le premier de la fonction. Pour l'alias de
structures, sa visibilite dans l'unite ou Derived est definie garanti
la validite de l'alias et rejete celui avec Foo.

Si C avait l'ambition d'evoluer un peut, ces extensions lui ferait
faire un pas de geant sans impact ni sur la performance, ni sur la
machine abstraite, ni sur la predictabilite du comportement en terme
de performance vitesse et memoire (zero overhead) si chere aux
programmeurs C. Ca aurait couté moins cher que d'introduire le
tgmath.h et sa black-magic ou des extensions bancales comme _Complex
et les futures "safe strings extension" etc...

Le C est une necessite (un mal?) et encore pour longtemps. Alors si on
pouvait lui donner un peu de syntactic sugar, le gateau n'en serait
que meilleur.

a+, ld.

In article <9d1e5ef7-d655-4910-af37-ffbb52d1456b@g31g2000yqc.googlegroups.com>,
ld <Laurent.Deniau@gmail.com> wrote:

On 12 août, 20:52, Erwan David <er...@rail.eu.org> wrote:

ld <Laurent.Den...@gmail.com> écrivait :



> non, GTK c'est encore pire. J'admire ce que les gens de Gnome arrivent
> a faire avec une truc aussi lourd.

Moi aussi je peux parsemer mon code de
fprintf(stderr,"Critical assertion failed");

Neanmois, il faut reconnaitre que ca marche pas trop mal (en tout cas
sous linux).

a+, ld.

Perso, je n'admire pas. Je prefere largement des trucs moins lourds, kde
en tete.

On 13 août, 21:12, es...@lain.home (Marc Espie) wrote:

In article <9d1e5ef7-d655-4910-af37-ffbb52d14...@g31g2000yqc.googlegroups .com>,

ld  <Laurent.Den...@gmail.com> wrote:
>On 12 août, 20:52, Erwan David <er...@rail.eu.org> wrote:
>> ld <Laurent.Den...@gmail.com> écrivait :

>> > non, GTK c'est encore pire. J'admire ce que les gens de Gnome arrive nt
>> > a faire avec une truc aussi lourd.

>> Moi aussi je peux parsemer mon code de
>> fprintf(stderr,"Critical assertion failed");

>Neanmois, il faut reconnaitre que ca marche pas trop mal (en tout cas
>sous linux).

>a+, ld.

Perso, je n'admire pas. Je prefere largement des trucs moins lourds, kde
en tete.

Euh, la premiere phrase (sur GTK et Gnome) etait ironique...

a+, ld.