Citation : heizmann

Mais je continue à glaner la toile. Il semblerait qu'à ce sujet, un expert en la matière serait Laurent Deniau, et ses fameux projets COS/POOC etc.

Citation : ChristopheG

J'ai dut mal a croire que cela soit souvent nécessaire de le faire. Tu a souvent besoin de faire 36 fonctions avec chaque types possibles et inimaginable ?
C'est très pratique, j'en convient, mais mise a part pour des bibliothèque générique, cela n'ai pas franchement courant de devoir utiliser beaucoup de types sur une même fonction. Et si tu veux pouvoir changer facilement avant compilation, tu peux utiliser un typedef. En général si tu réfléchis bien ton code, tu peux t'en passer (a part pour des cas comme des listes)

Citation : ChristopheG

Que ça existe ne veut pas dire que c'est propre pour autant. On peut tout trouver, le problème n'est pas là. Il est probable que dans ce cas c'étais la solution la moins mauvaise, mais je ne trouve toujours pas ça terrible.

Citation : ChristopheG

Même si c'est très intéressant, je ne pense pas qu'un tuto sur la question soit si intéressant. Car même si c'est "fun" et cela peut avoir (très rarement) de l'utilité, globalement autant prendre un langage OO directement, au moins tu leur aprend la POO avec un langage adapté. Car là juste sur les bidouilles de syntaxe tu en perdra les 3/4

Un LOO est-il vraiment adapté pour apprendre la POO?

Citation : ChristopheG

Ce n'étais pas une attaque personnel hein

Citation : ChristopheG

J'ai juste un peu de mal avec l'utilisation massive du pré-processeur.

Citation : QuentinC 2

a- C'est aussi là qu'on se rend compte de certains manques à mon avis complètement idiots du C++, comme par exemple l'interdiction d'appeler les constructeurs d'une même classe en cascade (notons que je suis plutôt un amateur de java, donc certains points particuliers du C++ me paraissent être de véritables hérésies)

b- Exceptions: avec setjmp et longjmp... par contre ça devient vite le bordel avec l'allocation dynamique... C'est là qu'on se rend comtpe à quel point les desctucteurs ont été une magnifique invention, et à quel point les systèmes de GC sont encore bien mieux que ça puisqu'ils passent complètement par-dessus le problème.

c- Surcharge d'opérateur: c'est juste un bonus syntaxique

d- Surcharge de méthode: pareil, c'est aussi un bonus syntaxique... comme déjà montré dans un post précédent, essayer d'en faire c'est vraiment du gros bidouillage.

e- Programmation générique avec type erasure: le void* suffit largement, sauf si on doit gérer les types primitifs (ce qui permet de comprendre pourquoi les génériques de java ne peuvent pas utiliser les types primitifs; en cela, les templates du C++ constituent plus une armée de moines copistes intelligents que de la véritable programmation générique, puisque chaque classe et chaque fonction est recopiée pour chaque type utilisée (ne me tuez pas, je ne suis pas un expert C++ et je n'ai pas lu stroustrup))

f- Là où ça commence à devenir vraiment intéressant, c'est pour les interfaces. Là je commence à avoir du mal de comprendre comment ça fonctionne exactement. Définir une interface c'est pas compliqué (juste une vtable de plus avec uniquement des méthodes abstraites), c'est ensuite que je coince. Si par exemple j'ai deux interfaces I1 et I2, une classe A qui implémente ces deux interfaces, comment un pointeur sur I1 pointant en réalité sur une instance de A peut-il être converti en pointeur sur I2 ? Ou en d'autre termes, comment fonctionne dynamic_cast en C++, ou ce genre de cast en java ?

Citation : Terbaddo

g- J'avais pourtant vu un programme qui transforme un code C++ en C.

Citation : ChristopheG

Pour moi,sur la question template / generic,

h- je dirais que la méthode java ou .net est clairement plus propre.

i- Le gros problème en c++ est l'absence de possibilité de specifier l'interface. Les compilateur font des remplacement pur et dur et en cas d'incompatibilité cela fait des messages d'erreurs incompréhensible et long de 4km.

Citation : QuentinC 2

j- Au fait ça m'amène à une question débile: pourquoi le C++ différencie-t-il delete et delete[] ? Quel est l'intérêt ? (Je ne parle pas de son utilisation mais bien de l'intérêt que ça a techniquement parlant... un bloc de mémoire est un bloc de mémoire)

Citation : heizmann

k- un truc du genre : "Pensez Orienté Objet" ou un truc du genre, [...] Un truc qu'il faudrait éclaircir au risque de me répéter, serait qu'on puisse se mettre d'accord sur une façon "standard" de penser POO en C. Notamment en ce qui concerne le rôle que pourrait avoir le préprocesseur, et puis aussi préciser sur les mécanismes d'autogestion des VTables - si possible.

Citation : GurneyH

Concernant, la technique, j'ai ceci dans mes favoris.

Méthode pour écrire du C orienté objet.

L'utilisation des vtables est différente de ce qu'a proposé Taurre(utilisation de offsetof), et on évite les void*.

C'est peu être intéressant à creuser.

EDIT : quelques liens intéressants sur :

• les astuces du prépro pour compter le nombre de variables insérées dans une macro (L. Deniau)
• un lien intéressant sur les pratiques du C (J. Larson, un peu vieux, 1996, mais intéressant)
• des idées sur l'implémentation de l'héritage et sur les fonctions virtuelles
• ici, un autre lien sur l'OO en C
• d'autres approches pour implémenter les idées OO en C
• l'implémentation des fonctions virtuelles en C, d'autres éléments

...

...la liste est longue (ouverture "(") mais a priori, comme on peut le constater, les anglosaxons sont souvent plus ouverts que nous en ce qui concerne l'OO en C (fermeture ")")

Citation : heizmann

1- À propos, quelqu'un pourrait-il expliquer en termes simples ce qui diffère dans la pratique quant à l'utilisation du C (via la méthode présentée dans le lien posté par GurneyH) par rapport à la POO avec un LOO ? Je veux dire, en termes de maintenance, de solidité du code, de réutilisabilité etc. ? je serais curieux de voir ce qu'en pense les gens...

2- ...la liste est longue (ouverture "(") mais a priori, comme on peut le constater, les anglosaxons sont souvent plus ouverts que nous en ce qui concerne l'OO en C (fermeture ")") </information>

Citation : lmghs

b- Les systèmes à GC se limitent à la mémoire.

Citation : lmghs

Ils ne comprennent rien aux autres ressources

Citation : lmghs

Les destructeurs (on dit RAII, ou RRID en C++), c'est déterministe et implicite.

Citation : GurneyH

Concernant, la technique, j'ai ceci dans mes favoris.

Méthode pour écrire du C orienté objet.

L'utilisation des vtables est différente de ce qu'a proposé Taurre(utilisation de offsetof), et on évite les void*.

C'est peu être intéressant à creuser.

personnage.h

#ifndef PERSONNAGE_H
#define PERSONNAGE_H  1

#define PERSONNAGE_DEFINITION \
	int vie; 

#define PERSONNAGE_VTABLE \
	void (*touche) (struct personnage *, int); \
	void (*delete) (struct personnage *);


struct personnage;
typedef void personnage_s;

struct personnage*
personnage_create (struct personnage *self);

void
personnage_touche (struct personnage *self, int degats);

int
personnage_vie (struct personnage *self);

void
personnage_delete (struct personnage *self);


#endif /* PERSONNAGE_H */

personnage.c

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

#include "personnage.h"


struct personnage_vtable {
	PERSONNAGE_VTABLE
};


struct personnage {
	struct personnage_vtable *vtable;
	PERSONNAGE_DEFINITION
};


static void
touche (struct personnage *self, int degats)
{
	self->vie -= degats;
}


static void
delete (struct personnage *self)
{
	free (self);
	puts ("destruction d'un personnage");
}


struct personnage*
personnage_create (struct personnage *self)
{
	static struct personnage_vtable vtable = {
		.touche = touche,
		.delete = delete
	};

	if (!self) {
		if (!(self = malloc (sizeof *self))) {
			return NULL;
		}
	}

	self->vie = 100;
	self->vtable = &vtable;

	return self;
}


void
personnage_touche (struct personnage *self, int degats)
{
	self->vtable->touche (self, degats);
}


int
personnage_vie (struct personnage *self)
{
	return self->vie;
}


void
personnage_delete (struct personnage *self)
{
	self->vtable->delete (self);
}

mage.h

#ifndef MAGE_H
#define MAGE_H  1


#define MAGE_DEFINITION \
	int mana;

struct mage;
typedef void mage_s;


struct mage*
mage_create (struct mage *self);


#endif /* MAGE_H */

mage.c

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

#include "personnage.h"
#include "mage.h"


struct mage_vtable {
	PERSONNAGE_VTABLE
};


struct mage {
	struct mage_vtable *vtable;
	PERSONNAGE_DEFINITION
	MAGE_DEFINITION
};


static void
touche (struct personnage *personnage, int degats)
{
	struct mage *self = (struct mage *)personnage;

	self->vie -= (degats - (self->mana / 10));
}


static void
delete (struct personnage *personnage)
{
	free (personnage);
	puts ("destruction d'un mage");
}


struct mage*
mage_create (struct mage *self)
{
	static struct mage_vtable vtable = {
		.touche = touche,
		.delete = delete
	};

	if (!self) {
		if (!(self = malloc (sizeof *self))) {
			return NULL;
		}
	}

	personnage_create ((struct personnage *)self);
	self->mana = 100;
	self->vtable = &vtable;

	return self;
}

main.c

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

#include "personnage.h"
#include "mage.h"



int
main (void)
{
	personnage_s *maurice;
	mage_s *adalbert;

	maurice = personnage_create (NULL);
	adalbert = mage_create (NULL);

	personnage_touche (maurice, 20);
	personnage_touche (adalbert, 20);

	printf ("maurice: %d\n", personnage_vie (maurice));
	printf ("adalbert: %d\n", personnage_vie (adalbert));

	personnage_delete (maurice);
	personnage_delete (adalbert);

	return EXIT_SUCCESS;
}

Citation : heizmann

euh, y'en a qui connaissaient pas le lien de GurneyH ? c'est l'un des premiers qu'on a en faisant des requêtes Google pourtant...

Citation : heizmann

PS : de manière générale (ça s'adresse à tout le monde) vous trouvez des trucs intéressants aussi dans ce que je poste ? (cf mes liens ci-dessus)

Citation : Taurre

Citation : heizmann

PS : de manière générale (ça s'adresse à tout le monde) vous trouvez des trucs intéressants aussi dans ce que je poste ? (cf mes liens ci-dessus)

Je ne les ai pas encore tous lu, mais l'astuce pour compter le nombre d'arguments d'une macro à nombres variables de paramètres est juste géniale! C'est ce genre d'astuce que j'adore

#define AFFICHE(format, ...) \
fprintf(stderr, "Erreur : " format, ##__VA_ARGS__);

(Edit du code : y'avait une erreur )

Citation : heizmann

À propos, regardez mes posts et mes codes les pages précédentes, le long de ce fil

@GurneyH

Citation : candide

Citation : heizmann

À propos, regardez mes posts et mes codes les pages précédentes, le long de ce fil

@GurneyH

Tu peux aussi poster un message sur le forum fclc, Laurent Deniau y est un participant fidèle depuis de nombreuses années et je pense que si tu as des questions ou un problème motivé à poser, il te donnera son avis d'expert.

int entier = 10;

_Generic (entier,
          int: abs,
          double: fabs,
          default: fabs) (entier);

#define sqrt(X) _Generic ((X),                    \
                          float: sqrtf,           \
                          double: sqrt,           \
                          long double: sqrtl,     \
                          default: sqrt) (X)      \