Existe il un type indefini

Je me pose encore une petite question. Existe il un type "indefini" ? c'est à dire que l'on declare une variable indefinie puis plus tard on lui attribue un type.
ex :

Code:

---

1 2 3 4 5 6

typeindefini x; string y="test" int z=3; x=z; x=y;

---

En fait c'est pour creer une classe dont un des membre est une variable qui suivant le cas peut etre d'un type ou d'un autre totalement different.
en gros :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

class MACLASSE{ public : MACLASSE(string type); string type; TYPEINDEFINI variable; };   MACLASSE::MACLASSE(string type){ if (type=="type1"){ variable=new type1(); }else{ variable=new type2(); }

---

Un void* devrait résoudre ton problème, mais tu serra obligé de casté à tour de bras à chaque utilisation.

Le mieux serait d'utiliser l'héritage:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

class Base{ ... };   classe type1: public Base{ ... };   classe type2: public Base{ ... };     class MACLASSE{ public : MACLASSE(string type); string type; Base * variable; };   MACLASSE::MACLASSE(string type){ if (type=="type1"){ variable=new type1(); }else{ variable=new type2(); }

---

[/code]

Je ne sais pas en quoi tu développes, mais avec C++Builder il y a un type Variant qui est fait pour ça (hélas absolument pas portable).

je programme sous linux

Tu es obligé quelque part de stocker le type de l'objet à un moment donné. Et le C++ ne s'en occupe pas, donc c'est à toi de le faire. Par exemple, pour le type variant c'est une grosse union avec un champ qui précise quel est le type contenu.
Mais ce genre de bidouille n'est pas dans l'esprit C++. Pourquoi as-tu besoin d'un tel type ?

Oui il a raison ce type de problèmes signale souvent une erreur de conception au niveau le plus haut. Sinon, t'as qu'à faire du PHP et du Javascript :haha:

Il est quelques (peu de) cas où les boost::any et autres variants sont utiles. Mais que cherches-tu vraiment à faire ?
N'y a-t-il pas une interface publique commune à tes types ?

Citation:

---

Je me pose encore une petite question. Existe il un type "indefini" ? c'est à dire que l'on declare une variable indefinie puis plus tard on lui attribue un type.

---

Si peux définir un type indéfini en l'encapsulant dans une classe template.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

template <typename type> class Undef { public: type value; };   int i = 2; double d = 4.5; Undef<int> myInt; Undef<double> myDouble; myInt.value = i; myDouble.value = d;

---

Ta classe Undef se comporte indifféremment dans le type primitif de ton choix.

Gabrielly

Citation:

---

Si peux définir un type indéfini en l'encapsulant dans une classe template.

---

Ce que veux notre ami c'est une classe dont une même instance peut prendre des valeurs de type différents. Une classe de variants, quoi.
Dans ton exemple le template ne sert à rien, sinon ajouter une couche syntaxique inutile (puisque de toute façon le typage sera résolu à la compilation).

faudrait mieux une union 8O

Tu as raison Loulou, je m'en suis rendu compte après, mais j'ai essayé de corriger un peu avec ce programme qui tourne bien.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

#include "stdafx.h" #include <conio.h> #include <iostream>   using namespace std;   class Undef { public: template<typename type> class UndefType { public: type value; };   template<typename type> Undef& operator=(type t) { static UndefType<type> def; def.value = t; return *this; } };   int _tmain(int argc, _TCHAR* argv[]) { int i = 2; double d = 4.5; string str = "bonjour";   Undef def; def = i; def = d; def = str; getch(); return 0; }

---

il n'est pas très lien du code de notre ami :wink:

Code:

---

1 2 3 4 5 6

typeindefini x; string y="test" int z=3; x=z; x=y;

---

mais je crois que j'aurais personnellement opté pour une autre solution...

Gabrielly

8O Que ce n'est pas beau ce code non réentrant et qui ne permet pas d'avoir plusieurs variants du même type. À ne pas faire en vrai :nono:

(J'ai dit que boost proposait tout ce qu'il fallait pour faire ce genre de choses ?)

Mais on ne sait toujours pas dans quel cadre l'OP cherche à écrire ce genre de chose.

Excuser moi de pas avoir répondu plus tot mais j'avais pas de connnexion internet sous la main.
Sinon je me doute bien qu'il y a un probleme de conception.

voila je suis en train de realiser un jeu en 2d.

Pour l'instant j'ai crée :

Code:

---

1 2 3 4 5 6 7

classe cercle{ point centre; float rayon; void dessiner(); ... };

---

Code:

---

1 2 3 4 5 6 7 8 9

classe rectangle{ point centre; vecteur x; vecteur y; float longueur; float largeur; void ... };

---

et une classe collision qui gere la collision entre les rectangle et les cercles, les cercle et les cercles, les rectangle et les rectangles.

Maintenant j'aimerais creer une classe Objet qui ressemeblerai a ca

Code:

---

1 2 3 4 5 6 7

classe objet{ float masse; point position; vecteur vitesse; "indefini" form; // le indefini prendrais soit la classe cercle ou rectangle lors de la construction };

---

j'ai essayer de creer une classe mere "forme" et puis des classes filles "rectangle" et "cercle" et donc d'utilise la classe forme a la place de ma classe de type indefini mais le probleme c'est que la classe forme ne possede pas les attribut de cercle ou de rectangle
en effet rectangle , cercle sont totalement differente: elles ont un seul point commun le centre. Je ne pe pas modifier la conception de ces 2 classes car c'est le minimum necessaire pour pouvoir realiser les collisions.

Une autre solution serait de creer la classe forme qui possede tout les attributs de rectangle et cercle mais je trouve cela pas tres optimiser (mais peut etre que je me trompe car ca utilise de la memoire pour rien car pour si j ai un cercle tout les attributs du rectangle ne seront pas necessaire)de plus je compte rajouter quelles forme de plus.

Voila j'espere avoir etait assez clair

PS : le type "indefini" vient du flash ou je n'etait pas oblige de declarer le type de la variable avant ce que je concoit n'est pas top.

Tu te focalise trop sur les attributs, et pas sur les fonction. Assurément, pour définir un cercle ou un carré, il faut des variables membres différentes. Maintenant, ce qui compte, c'est ce que tu veux en faire.

S'il s'agit de les dessiner, une fonction virtuelle unique peut convenir.
S'il s'agit de savoir si un point est à l'intérieur, une fonction virtuelle unique peut convenir.

C'est ça qui compte.

Citation:

---

Une autre solution serait de creer la classe forme qui possede tout les attributs de rectangle et cercle mais je trouve cela pas tres optimiser (mais peut etre que je me trompe car ca utilise de la memoire pour rien car pour si j ai un cercle tout les attributs du rectangle ne seront pas necessaire)de plus je compte rajouter quelles forme de plus.

---

JolyLoic a raison, tu te trompes sur le sens classe de base. Elle ne rassemble pas les propriétés de tous mais les propriétés communes à tous et qui font que chacun est dans son genre une espèce particulière de la classe de base. les classe dérivées définissent chaque comportement particulier.

Le code que j'ai mis dans mon poste précédent est juste un code à la voléé que j'ai écris (Just work)

Mais je crois que j'avais dit:

Citation:

---

mais je crois que j'aurais personnellement opté pour une autre solution...

---

Pour moi j'aurais opté pour les VARIANT et encore mieux pour les COleVariant ou CComVariant.

Ce qui manque au code précédent c'est de récupérer la valeur une fois stocké dans l'objet Undef mais n'empêche que je peux stocker divers type et le programme tourne, je le trouve sympa et surtout que le type n'est pas précisé à la compilation mais à l'exécution.

Encore une fois Just Work :wink:
Thanks

template = spécialisation à la compilation. Donc le type est connu à la compilation.
Le problème avec ta classe Undef, c'est que si on crée 2 instances, on va avoir de maivaises surprises...

Code:

---

1 2 3 4 5 6 7 8 9

double d1 = 4.5; double d2 = 10.0;   Undef def1; def1 = d1;   Undef def2; def2 = d2; // aie aie aie

---

Pour info, COleVariant et CComVariant encapsulent VARIANT (elles en hérite en fait)

Oui je sais que COleVariant ou CComVariant hérite de Variant et dans le seul but de rendre l'usage de VARIANT facile comme une simple affectation.

Quelle genre de surprise avec une deuxième instance de Undef :?:
J'ai rapidement testé c'est OK mais je n'ai pas dit que c'est la solution qu'il fallait. Je m'en tiens toujours au CComVariant.

Code:

---

1 2 3 4 5 6

CComVariant var; doube d = 4.5; int i = 3; var = d; var = i;

---

Au fait ce que j'ai remarqué avec Undef est que une fois une valeur stocké j'ai du mal à le récuperer car je ne peux pas éviter le typage.

Pour une classe template le type est précisé à l'instanciation de la classe mais pour une fonction template le type est précisé à l'appel de fonction et donc tu as raison :) mais le type pour une fonction n'est pas forcément explicitement indiqué.

Je crois que les meilleurs types indéfinis sont les variants.

Tu utilises une var statiques, donc partagée par toutes les instances. 2 problèmes:
- on peut pas la récupérer
- modifier d2 fait qu'on modifie d1

cool
j'ai utilisé statique juste pour le garder plus longtemps lorsqu'on sort de sa porté. Je ne pouvais pas le mettre comme donnée membre de la classe Undef sans éviter le typage et encore moins le mettre comme var globale et effectivement je ne pouvais pas le récupérer.
cool, cool, cool, :D

Citation:

---

Tu te focalise trop sur les attributs, et pas sur les fonction. Assurément, pour définir un cercle ou un carré, il faut des variables membres différentes. Maintenant, ce qui compte, c'est ce que tu veux en faire.

S'il s'agit de les dessiner, une fonction virtuelle unique peut convenir.
S'il s'agit de savoir si un point est à l'intérieur, une fonction virtuelle unique peut convenir.

C'est ça qui compte.

---

J'ai besoin pour un cercle d'
un membre "centre" de type point qui indique la position du cercle
un membre rayon de type float pour la longueur du rayon

Pour le rectangle il me faut au minimum
un membre "centre" de type point
un membre "directionx" de type vecteur qui indique l'orientation du rectangle
deux membres "longueur" et "largeur" de type float pour la longueur et largeur

C'est le minimum requis pour caracteriser mes cercles et mes rectangles
d'autant plus que ces membres sont utilisés pour tester les collisions

Apres pour les fonctions telle que dessiner, deplacer,... des fonctions virtuelle ne me pose pas de probleme

Donc le probleme de conception viendrait t il de ma classe objet qui aurait pour membre "forme" qui serait soit de type rectangle ou de type cercle?

Citation:

---

Citation:

---

Une autre solution serait de creer la classe forme qui possede tout les attributs de rectangle et cercle mais je trouve cela pas tres optimiser (mais peut etre que je me trompe car ca utilise de la memoire pour rien car pour si j ai un cercle tout les attributs du rectangle ne seront pas necessaire)de plus je compte rajouter quelles forme de plus.

---

JolyLoic a raison, tu te trompes sur le sens classe de base. Elle ne rassemble pas les propriétés de tous mais les propriétés communes à tous et qui font que chacun est dans son genre une espèce particulière de la classe de base. les classe dérivées définissent chaque comportement particulier.

---

Ca je savais qu'il faut pas creer une classe de base avec tout les membres.

Comment faut il que je creer une classe de base de type forme ayant pour classe derivee une classe de type "cercle " ou "rectangle" avec les membre énoncé au dessus?

Citation:

---

d'autant plus que ces membres sont utilisés pour tester les collisions

---

Pour répondre avec pertinence au problème Comment représenter les données ?, il faut savoir un peu plus sur le traitement qu'elles vont subir. Apparemment leur position est donnée par le membre commun centre. Comment envisages-tu de tester si deux formes sont entrées en collision ? Que deviennent-elles ensuite après collision ?

pour tester la collision entre deux cercles je calcule la distance entre les 2 centres des cercles et si la somme des rayons des cercles est superieurs à la distance entre les 2 centres alors il y a collision.

pour tester la collision entre 2 rectangles il faut projeter chaque rectangle sur les 2 vecteurs direction de chaque rectangle et ensuite regarder si sur las 4 axe les projections des rectangles se superposent.

Apres collision les objet sont translaté du vecteur de pénétration.