Discussion :

[10_GOTO_10]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

MyAttrib++;

est à remplacer par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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).

[bigboomshakala]

bonjour,

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

MyAttrib++;

est à remplacer par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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

[mtopoloff]

Pour les ansi strings tu peux toujours faire un wrapper vers les MFC ou la STD...

[10_GOTO_10]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

__property int MyAttrib = {read = PorteNaouak, write = PorteNaouakAutre};

[10_GOTO_10]

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 ???

[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.

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

exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

redéfinir Fonction

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[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.

[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".

[Gabrielly]

Salut

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

10_GOTO_10 a écrit:

mat.M a écrit:

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.

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

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

[Aurelien.Regat-Barrel]

Elles existente en Managed C++/C++ CLI. C'est du .Net. Elles n'y sont pas en C++ classique.

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Aurelien.Regat-Barrel]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[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.

[Gabrielly]

Salut

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

Property<int> J = I + 42;

sinon ?

Il manque pour écrire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[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

[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.

[Gabrielly]

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

Gabrielly

[Gabrielly]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.
style more perfect!!!

Gabrielly

[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.