[Migration] Borland -> Visual

Version imprimable

30/11/2004, 12h52
10_GOTO_10

[Migration] Borland -> Visual

Je dois traduire du code écrit en Borland C++ Builder en Visual. Ceci, bien sûr avec le moins possible de modifications. Je suis confonté à au moins trois problèmes:

Problème 1 : Comment traduire les propriétés ?

J'ai bien sûr la solution de créer deux méthodes GetMyAttrib() et SetMyAttrib(). Mais ça force à modifier sensiblement le code:

Code:

MyAttrib++;

est à remplacer par :

Code:

SetMyAttrib(GetMyAttrib() + 1);

et ça sur des centaines d'attributs et des milliers de lignes de programme.

Problème 2 : Comment traduire les AnsiStrings ?

Je crois qu'il existe une bibliothèque qui reproduit les AnsiStrings, mais est-ce fiable ? Y a-t-il un autre moyen ?

Dernier problème, but not the least: Comment traduire les événements ?

Là, j'ai pas de solutions. Créer une classe virtuelle et la dériver, ça ne marche pas, à moins de faire des dizaines de classes dérivées (un pour chaque type d'objet appelé dans chaque type d'événement).
30/11/2004, 13h04
bigboomshakala

Re: [Migration] Borland -> Visual

bonjour,

Citation:

Envoyé par 10_GOTO_10

Problème 1 : Comment traduire les propriétés ?

J'ai bien sûr la solution de créer deux méthodes GetMyAttrib() et SetMyAttrib(). Mais ça force à modifier sensiblement le code:

Code:

MyAttrib++;

est à remplacer par :

Code:

SetMyAttrib(GetMyAttrib() + 1);

et ça sur des centaines d'attributs et des milliers de lignes de programme.

pourquoi tu veux faire des modif ici???
c'est très bien MyAttrib++ si c'est dans la classe dont MyAttrib est l'attribut.
c'est pas parce que tu passes de BC++ à VC++ que les règles de base du C++ sont modifiées :D

pour le problème 2, je ne sais pas

pour le problème 3 : j'ai bien peur que tu ne sois obligé de modifier tous le projet si tu passes aux MFC
et si tu ne passes pas aux MFC, mais que la gestion des évènements que tu utilisais jusqu'à maintenant étais spécifique à Borland C++ (perso je ne connais pas ce compilo) même combat

bonne chance
30/11/2004, 13h38
mtopoloff

Pour les ansi strings tu peux toujours faire un wrapper vers les MFC ou la STD...
30/11/2004, 14h03
10_GOTO_10

Re: [Migration] Borland -> Visual

Citation:

Envoyé par bigboomshakala

pourquoi tu veux faire des modif ici???
c'est très bien MyAttrib++ si c'est dans la classe dont MyAttrib est l'attribut.

Parce que MyAttrib peut être défini comme ça, par exemple:

Code:

__property int MyAttrib = {read = PorteNaouak, write = PorteNaouakAutre};
30/11/2004, 16h02
10_GOTO_10

Citation:

Envoyé par mat.M

J'ai vu le message côté Visual C++ , _property ça n'existe pas , enfin si cela existe peut-être mais exceptionnellement utilisé.
Parce que c'est un mot clé de BC++ qui permet d'afficher les propriétés dans l'inspecteur d'objet.
Or sous VC++ l'inspecteur d'objet n'existe évidemment pas ce n'est qu'un outil PARTIELLEMENT RAD contrairement à BC++

Comme le dit Bigboomshakala tu vas être obligé de .....tout refaire
Parce que BC++-> VCL et VC++-> MFC ou non mais sans MFC , difficile ( avec API win32 pure )

Le framework de la VCL est radicalement différent d'un point de vue de la forme ( déclarations etc.... ) comparé avec MFC.
Mais sur le fond les méchanismes sont assez similaires.

Je sais bien que ça n'existe pas en Visual. Ce que je cherche, c'est la manière la plus simple et la plus élégante de faire la transformation, en changeant le moins possible le code d'appel.

Ne me faites pas croire que je suis la première personne au monde à vouloir faire migrer du code ???
30/11/2004, 16h14
bigboomshakala
non, yan a d'autre qui veulent migrer.
mais la seule façon de migrer d'un compilo à l'autre sans problème, c'est de faire du code purement standard

dès qu'on emploie des bibliothèques spécifiques à un compilateur, c'est le bordel pour migrer. et la façon la plus propre (et souvent l'unique façon), c'est de reprendre tout le projet dans le nouveau compilateur.

je conçois que ça ne fasse pas plaisir de s'entendre dire qu'on va devoir tout refaire si on veut passer à un autre compilateur, mais j'y peut rien. :wink:

maintenant ya peut être moyen de faire la migration en redéfinissant toutes les fonctions de BC++ que tu utilises

exemple
Code:

1 2 3 // dans ton code #include "bibli_de_Fonction.h" Fonction(...); // fonction propre à BC++
redéfinir Fonction
Code:

1 2 3 4 5 // dans mes_fonctions.cpp Fonction(...) { ... }
Code:

1 2 3 // dans ton code #include "mes_fonctions.h" Fonction(...); // fonction redéfinies
ainsi ton code n'a pas changé, mais tu dois te taper la définition de tous ce que tu utilises et qui n'est pas dans VC++

autant dire que ce n'est pas simple

bon courage
30/11/2004, 17h25
farscape

Salut,
J’apporte mon grain de sel,
Pour l’architecture et l’interface IHM à mon avis pas trop d’espoir, il ne te reste plus qu’à refaire à l’identique, Tu perdras moins de temps.
en gros tu fais une coquille vide de l'interface en se rapprochant le plus possible
de l'existant apres tu remplis .
Pour la récupération du code il faut espérer que les traitements soient séparés le plus possible du code de l’ihm .

Bon Courage.
:D
30/11/2004, 17h45
Aurelien.Regat-Barrel

Traduire ou réutiliser ?
Si c'est réutiliser tu peux essayer une autre voie comme une dll par exemple.
Pour AnsiString utilise CString (MFC) ou std::string (standard). L'avantage de std::string est que le jour où il faut recomencer ce que tu fais ben ça fait ça de moins à "traduire".
30/11/2004, 18h16
Gabrielly

Salut

Qui as dit que les propriétés n'existe pas en Visual C++? 8O

10_GOTO_10 a écrit:

Citation:

mat.M a écrit:

Citation:

J'ai vu le message côté Visual C++ , _property ça n'existe pas , enfin si cela existe peut-être mais exceptionnellement utilisé.
Parce que c'est un mot clé de BC++ qui permet d'afficher les propriétés dans l'inspecteur d'objet.
Or sous VC++ l'inspecteur d'objet n'existe évidemment pas ce n'est qu'un outil PARTIELLEMENT RAD contrairement à BC++

Comme le dit Bigboomshakala tu vas être obligé de .....tout refaire
Parce que BC++-> VCL et VC++-> MFC ou non mais sans MFC , difficile ( avec API win32 pure )

Le framework de la VCL est radicalement différent d'un point de vue de la forme ( déclarations etc.... ) comparé avec MFC.
Mais sur le fond les méchanismes sont assez similaires.

Je sais bien que ça n'existe pas en Visual. Ce que je cherche, c'est la manière la plus simple et la plus élégante de faire la transformation, en changeant le moins possible le code d'appel.

Ne me faites pas croire que je suis la première personne au monde à vouloir faire migrer du code ???

Les propriétés si elle n'existe pas! Ce n'est plus pour longtemps. :wink:

Voir les liens
http://msdn.microsoft.com/visualc/default.aspx?pull=/library/en-us/dnvs05/html/bakerdozen.asp#bakerd_topic2

Visual C++ in “Whidbey”
What's New
http://www.financialdevelopers.com/assets/presentations/Microsoft%20-%20What's%20New%20in%20Visual%20C++%202005.ppt

Visual C++ “Whidbey”:
New Language Design And Enhancements
http://www.gotdotnet.com/team/pdc/4064/tls310.ppt

Citation:

Basic syntax:
ref class R {
int mySize;
public:
property int Size {
int get() { return mySize; }
void set( int val ) { mySize = val; }
}
};

R r;
r.Size = 42; // use like a field; calls r.Size::set(42)

Trivial properties:
ref class R {
public:
property int Size; // compiler-generated
};
// get, set, and backing store

Gabrielly :D
30/11/2004, 18h26
Aurelien.Regat-Barrel

Elles existente en Managed C++/C++ CLI. C'est du .Net. Elles n'y sont pas en C++ classique.
30/11/2004, 18h37
10_GOTO_10
J'ai peut-être été pas tout à fait clair sur mon problème:

1) J'ai un très gros projet en C++. La plus grande partie est du C++ standard (portable).

2) J'ai quelques objets en "Borland pur" qui ne sont pas très nombreux, mais très utilisés. Ils contiennent toutes les spécificités Borland (AnsiString, _property, événements, SET, ...).

Lorsque la partie 1 utilise la partie 2, forcément, elle utilise ses spécificités.

Donc, je voudrais réécrire la partie 2 pour avoir à modifier le moins possible la partie 1, surtout manuellement (je peux très bien faire des remplacements systématiques, par exemple).

Par exemple, j'ai pensé à remplacer des événement par des pointeurs sur des méthodes:
Code:

1 2 typedef void (TMyClasse::* TMyEvenement)(); TMyEvenement MyEvenement;
Code:

1 2 3 4 5 6 7 void TMyClasse::SetMyEvenement(TMyEvenement NewEvenement) { MyEvenement = NewEvenement; } // Lorsque l'événement survient MyEvenement();
Mais cette façon de faire pose des problèmes lorsqu'il y a des classes virtuelles et des héritages.

Utilise un foncteur plutot (classe qui définit l'opérateur (), cf FAQ C++ ).
Pour les propriétés, tu peux créer un wrapper avec l'opérateur du type de ta propriété. Dans le genre :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 template<typename T> class Property { public: operator T() { return this->t_; } T & operator=( const T & t ) { this->t_ = t; return this->t_; } private: T t_; }; class Test { public: Property<int> I; };
Ca doit déjà exister, dans boost sûrement.

30/11/2004, 22h10
Luc Hermitte

Non, je ne crois pas qu'il y ait de proxy pour propriétés dans boost.
Il me semble qu'il y a eu toutes sortes de tentatives en ce sens, mais rien de retenu. Il y a toujours un petit détail qui fait que ce n'est pas parfait et que donc ce n'est pas validé. Des infos intéressantes dans More Effective C++ (MEC) de Scott Meyers.

Il est pas impossible de trouver ces tentatives dans les fichiers de la ML de boost, le CVS et même des discussions intéressantes dans les archives de news:comp.lang.c++.moderated.

Dans une extension pour wxWidget, il me semble avoir vu un truc qui associerait des données exposées via une IHM à des paires accesseur/mutateur.

Bref, pour le 1er problème, c'est un sujet récurrent sans bonne (/ultime) solution qui reste dans le standard du C++ -- d'ailleurs je me demande si le point n'a pas été soulevé pour le prochain standard.
Il faut donc se tourner vers des bibliothèques imparfaites ou des extensions propriétaires que l'on voit chez Borland et C++/CLI.

____
Généralement, on essaie de faire en sorte que cela soit la partie 2 (propriétaire) qui utilise la partie 1 (standard). Et pas le contraire.

________
Pour le second problème ... Pourquoi ne pas utiliser le type standard pour les chaines ?
Sinon, dans STLSoft il y a des adaptateurs pour faire dialoguer des chaines d'origines différentes -- il me semble que Matthew Wilson utilise un autre vocabulaire, mais l'idée reste l'adaptation entre chaines hétérogènes.
Ceci dit, s'il s'agit de recompiler le composant, codé pour VCL, avec VC, cela ne servira à rien. Il faudra probablement le reprendre.

Salut

je pensais exactement la même chose aujourd'hui matin

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
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
 
 
template<typename T> 
class Property 
{ 
public: 
    Property(): t_(0) { } 
 
    operator T() { return t_; } 
 
    T & operator=( const T & t ) 
    { 
        t_ = t; 
        return t_; 
    } 
 
    bool operator==(Property<T>& p) 
    { 
        T t = p;   // p.operator T() 
        if(t_ ==  t) return true; 
        else return false; 
    } 
 
    bool operator!=(Property<T>& p) 
    { 
        return !(*this == p); 
    }            
 
    T operator++() { return t_++; } 
    T operator++(int) { return ++t_; } 
    T operator--() { return t_--; } 
    T operator--(int) { return --t_; } 
 
    Property<T>& operator+=(const T t) 
    { 
        t_ += t; 
        return (*this); 
    } 
 
    Property<T>& operator-=(const T t) 
    { 
        t_ -= t; 
        return (*this); 
    } 
 
    Property<T>& operator*=(const T t) 
    { 
        t_ *= t; 
        return (*this); 
    } 
 
    Property<T>& operator/=(const T t) 
    { 
        t_  /= t; 
        return (*this); 
    } 
 
    friend T operator+(Property<T>& t1, Property<T>& t2); 
    friend T operator-(Property<T>& t1, Property<T>& t2); 
    friend T operator*(Property<T>& t1, Property<T>& t2); 
    friend T operator/(Property<T>& t1, Property<T>& t2); 
 
private: 
    T t_; 
}; 
 
T operator+(Property<T>& t1, Property<T>& t2) 
{ 
   return t1.t_ + t2.t_; 
} 
 
T operator-(Property<T>& t1, Property<T>& t2) 
{ 
   return t1.t_ - t2.t_; 
} 
 
T operator*(Property<T>& t1, Property<T>& t2) 
{ 
   return t1.t_ * t2.t_; 
} 
 
T operator/(Property<T>& t1, Property<T>& t2) 
{ 
   return t1.t_ / t2.t_; 
} 
 
class Test 
{ 
public: 
    Property<int>   I; 
};

Gabrielly :D

01/12/2004, 11h23
Luc Hermitte

Ta comparaison est compliquée.

Pour le constructeur, autant initialiser t_ avec T().

Les fonctions ne sont pas const-corrects.

Il te manque un des constructeurs les plus importants : celui qui prend un argument. Comment écrire

Code:

Property<int> J = I + 42;

sinon ?

Il manque pour écrire:

Code:

Property<double> D = I;

Pas de possibilité de choisir nos accesseur et mutateur -- approche plus classique.

Plein de bonnes choses à lire sur:
- news:comp.lang.c++.moderated, chercher p.ex. un vieux message de M-ID: <Pine.LNX.4.21.0209062121010.10517-100000@wonko.masitec.de>
- news://news.gmane.org/gmane.comp.lib.boost.devel ; avec un vrai client de news (XNews est fort acceptable) chercher property.
01/12/2004, 11h30
Aurelien.Regat-Barrel

Je pense qu'un petit lien HTML facilitera la vie de beaucoup:
http://www.google.fr/groups?as_umsgid=Pine.LNX.4.21.0209062121010.10517-100000@wonko.masitec.de&lr=&hl=fr
01/12/2004, 11h39
Luc Hermitte

Oui. D'avoir les archives de ces groupes en cache, je n'ai pas le réflexe google-groups.
Sinon, penser bien évidemment à lire les autres messages du fil.
01/12/2004, 11h54
Gabrielly

On peut toujours améliorer la classe Property!
Ce n'est pas un produit fini!!!!

Gabrielly :wink:

Pour ce qui est des constructeurs on peut ajouter des constructeurs de recopies.
Code:

1 2 3 4 5 6 7 8 template<typename T> class Property { public: Property(Property<T>& p): t_(p.t_) { } Property(T& t): t_(t) { } //... };
Ainsi
Code:

1 2 3 4 5 6 Property<double> D = I; // Property<double> D = Property<double>(I); // ou Property<double> D(I); Property<int> F = 12; Property<int> I = F + 42; // équivaut à Property<int> I = F + Property<int>(42);
A l'aide de la fonction amie operator+() on additionne F et 42 qui retourne un int. Et on applique le constructeur de recopie Property<int>(int&).

Et puis c'est juste pour apporter des solutions en plus. :wink:
style more perfect!!!

Gabrielly :)

01/12/2004, 12h23
Luc Hermitte

Et J = I + I + F ?
(-> rajouter les const qui manquent)

Mais les propriétés sans pouvoir spécifier nos propres accesseur et mutateur (définis au niveau de la classe) n'ont guère d'intérêt.
01/12/2004, 12h30
Gabrielly

Citation:

Et J = I + I + F ?
(-> rajouter les const qui manquent)

Et si on écrivait

Citation:

J = (I + I) + F?

l'operator+() additionne I et I et ensuite F et stocke à l'aide de operator=() dans J.

Gabrielly :D
01/12/2004, 12h49
Luc Hermitte

Arf. Je n'avais pas fait attention à l'opérateur de convertion qui fait en sorte que I + J + K additionne des int et non leur proxies.
Ce qui rejoint mon idée (non formulée) première que le proxy ne doit rien contenir d'autre que des indirections sur des set & get.

Ces opérateurs mathématiques ne servent à rien.
01/12/2004, 13h18
Gabrielly

Luc Hermitte a écrit:

Citation:

Arf. Je n'avais pas fait attention à l'opérateur de convertion qui fait en sorte que I + J + K additionne des int et non leur proxies.
Ce qui rejoint mon idée (non formulée) première que le proxy ne doit rien contenir d'autre que des indirections sur des set & get.

Ces opérateurs mathématiques ne servent à rien.

Aurelien.Regat-Barrel a écrit la classe en premier. Et j'étais content car j'avais la même idée celle de définir une classe template Property. Je l'ai juste perfectionné un peu avec suffisamment de méthodes d'opérateur surdéfinis pour permettre à 10_GOTO_10 à ne pas trop récrire tous son code. Et d'ailleurs Property recoit dans le contexte courant des types primitifs. Juste pour être plus prêts des besoins de 10_GOTO_10. Mais ces quelques postes sont intéressants car les solutions que l'on peut en tirer de C++ sont multiples ie les tiennent comme les miennes alors faisons simplement une union des solutions. Les opérateurs mathématiques simplifient la syntaxe, tu ne trouves pas? Les pointeurs intelligents les utilisent énormément (ATL). Ceux qui nous lisent veront combien la marge de manoeuvre de ce langage est grand. :wink:

Gabrielly :D

Merci à vous tous. Même si j'ai pas de solution parfaite, j'ai néanmoins pas mal progressé. Pour info, voici la solution que je pense adopter:

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
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
const WORD PROPERTY_READVAR   = 0x0001;
const WORD PROPERTY_READFONC  = 0x0002;
const WORD PROPERTY_WRITEVAR  = 0x0004;
const WORD PROPERTY_WRITEFONC = 0x0008;
 
template<class O, typename T>
class Property {
private:
  O * Owner;
  WORD TypeInit;
  union {
    T * Read_t;
    T (O::* Get_t) ();
  };
  union {
    T * Write_t;
    bool (O::* Set_t) (const T t);
  };
public: 
  Property() {
    Owner = NULL;
    TypeInit = 0;
    Read_t = NULL;
    Write_t = NULL;
  }
  void InitProperty(O * NewOwner, T * NewRead_t, T * NewWrite_t) {
    Owner = NewOwner;
    TypeInit = PROPERTY_READVAR | PROPERTY_WRITEVAR;
    Read_t = NewRead_t;
    Write_t = NewWrite_t;
  }
  void InitProperty(O * NewOwner, T (O::* NewGet_t) (), T * NewWrite_t) {
    Owner = NewOwner;
    TypeInit = PROPERTY_READFONC | PROPERTY_WRITEVAR;
    Write_t = NewWrite_t;
    Get_t = NewGet_t;
  }
  void InitProperty(O * NewOwner, T * NewRead_t, bool (O::* NewSet_t)  (const T t)) {
    Owner = NewOwner;
    TypeInit = PROPERTY_READVAR | PROPERTY_WRITEFONC;
    Read_t = NewRead_t;
    Set_t = NewSet_t;
  }
  void InitProperty(O * NewOwner, T (O::* NewGet_t) (), bool (O::* NewSet_t)  (const T t)) {
    Owner = NewOwner;
    TypeInit = PROPERTY_READFONC | PROPERTY_WRITEFONC;
    Get_t = NewGet_t;
    Set_t = NewSet_t;
  }
  operator T() {
    if (TypeInit & PROPERTY_READVAR) return * this->Read_t;
    if (TypeInit & PROPERTY_READFONC) return (Owner->*Get_t)();
    return 0;
  }
  T operator=( const T t ) {
    if (TypeInit & PROPERTY_WRITEVAR) * this->Write_t = t;
    if (TypeInit & PROPERTY_WRITEFONC) (Owner->*Set_t)(t);
    return T();
  }
};

Code:

1
2
3
4
5
6
7
8
9
10
class TMyClasse {
private:
  int FMyAttr;
 
  int GetMyAttr();
  bool SetMyAttr(const int NewAttr);
 
public:
  Property<TMyClasse, int> MyAttr;
};

Puis, dans le constructeur de MyClasse:

Code:

MyAttr.InitProperty(this, GetMyAttr, SetMyAttr);

ou bien

Code:

MyAttr.InitProperty(this, &FMyAttr, &FMyAttr);

01/12/2004, 15h45
Luc Hermitte

Tu n'as pas été voir sur http://groups.yahoo.com/group/boost/files/ (s'inscrire à la ML pour accéder à cette zone). J'y vois 3 implémentations de la bête.