Migration vers C++ 2009 ou RAD 2009, retours d'expérience

Code:

---

Application->MessageBox( L"salut", L"salut", MB_OK);

---

merci Fbartolo

allez pour ceux qui ne savaient pas, la mise à jour 2009 et 2010 de la série Turbo Power :ccool: :
http://www.songbeamer.com/delphi/

noubliez pas de cocher les option "générer tous les fichier C++" à la place de DCU pour que cela fonctionne dans notre enviromment préféré..

j'ai toujours des problemes avec ça:

Code:

---

1 2	for(int i=0;i<5;i++)ShowMessage("je suis dans la boucle : "+IntToStr(i));

---

merci d'avance.

Citation:

---

Envoyé par dz_robotix

Bonjour,

est ce qu'il y a une personne qui a réussit à écrire ceci sous c++ 2009 sans avoir un message d'erreur ?

Code:

---

1 2	Application->MessageBox("salut", "salut", MB_OK);

---

c'est bête mais j'ai un message d'erreur avec les unicode string! 8O

et ceci aussi

Code:

---

1 2 3

for(int i=0;i<5;i++)ShowMessage("je suis dans la boucle : "+IntToStr(i));

---

---

Aucun soucis avec ShowMessage et l'addition de chaines dans mon cas.

Bonjour,

Je remonte le sujet... Quels retours d'expérience pour 2010?

Chez moi, on est passés de Builder 6 à 2007 cet été pour la principale application, sans trop de difficultés (deux jours de travail un peu dense pour une grosse appli).

La question qui se pose actuellement est un upgrade général des autres apps vers 2007, ou un passage direct à 2010. Le problème n'est pas réellement budgétaire, mais de coût de portage (compliqué, facile?) vs d'améliorations gains (notamment sur l'aide en ligne, celle de 2007, c'est pas ca...)

En termes de librairies, on utilise principalement TMS et les natives Borland (je suis en train de dégager Jedi, pas réellement de valeur ajoutée par rapport à TMS)

Des idées, des commentaires, des conseils?

Francois

Pas de problèmes majeur avec TMS, ni trop avec la Jvcl.

Seul quelques adaptations Unicode sont à précoir, et un bon déroulé de recette qui lui peut être long..

Et quels sont les gains, en face? Mon principal pb avec 2007, c'est la pauvreté de la doc (par rapport à Builder 6, j'utilise toujours ma doc 6 en fait...), le fait que ca plante quand même assez souvent, et le fait que les iostream de Dinkumware sont lentes à ch...

Pour le reste, ca compile un peu plus vite, l'EDI est plus pratique, et j'ai des composants supplémentaires chez mes fournisseurs externes (TMS)

C'est quoi, les points forts de 2010, à votre avis?

Francois

A part :
- gestion Unicode,
- Edi 2009 plus stable que le 2006,
- Edi plus rapide et mieux documenté (on n'arrive pas encore au niveau BCB6),
- sur 2010, la reconnaissance de l'écrit, aucun besoin en ce sens chez moi.

je n'ai retenu que ça, c'est pour cela que j'attend la version 64 bits..

Bon après quelques migrations et plus d'un an d'utilisation BDS2009:

- On arrive à une stabilité proche de BCB6,
- Pas aussi rapide en compilation de BCB6...,
- Une doc à la Windows très longue à charger et loins de la qualité de BCB6,
- Dommage que la compilation C++ soit largement plus longue qu'en Pascal, là ça booste.

concernant la nouvelle version 2011 (je ne voit vraiment pas ce qu'apporte 2010 quan on est sur 2009), pas encore de 64 bits mais multi plateforme, à voir..

1. cfr post précédent relatant les bugs des composants bcb 2009,
2. BDS 2009 a des leaks au niveau des services web qui ne sont pas corrigés à ce jour à ma connaissance en 2009, mais fonctionnent beaucoup mieux en bcb 2010 (aussi bien en design-time pour générer des types complexes qu'à l'exécution).
3. En attendant un patch pour ce souci, nous avions essayé l'outil gSoap pour utiliser les services Web. Le code généré par gSoap ne compile plus en bcb 2010 (qui serait un peu moins conforme aux standards).
4. Dans bcb 2010, les composants indy fonctionnent sans devoir aller chercher des patches un peu partout.
5. En 2009: Ole:
Variant m_vOleObj=m_vExcelApplication.Exec(PropertyGet("Application"));
provoque une gpf à l'exécution, sauf si on inclut explicitement variant.cpp au projet. En 2010, ca marche sans problème.
6. Bug STL en 2009: si tu déclares dans un formulaire:
std::map<AnsiString, QUERYTYPE *> qTab;
et que dans le OnDestroy, tu fais:
std::map<AnsiString, QUERYTYPE *>::iterator xx;
for (xx=qTab.begin(); xx!=qTab.end(); xx++)
second->Something();

Tu auras GPF car second->Something() est appelé même avec la map vide, ce qui veut dire qu'en 2009 tu dois tester que ta map n'est pas vide(size()).
Corrigé en 2010.

7. Inconvénient du 2010: l'outil installaware inclus n'a même pas été mis à jour pour prendre en compte la bonne version des .bpl. Heureusement, une simple copie des exes/bpl/cc32100*.dll marche sans installshield.

8. Bémol pour v2009 et v2010: ils sont fournis avec un outil de rapport "Rave reports", qui n'est plus supporté (la société Nevrona ne répond plus au téléphone). Il y a fort à parier qu'il faudra (encore) réécrire tous les rapports lors de la migration vers v 2011/12/13... (ET les rapports que les end-users auront personnalisés).

Bref, en ce qui me concerne, bcb 2009 est une catastrophe, 2010 a bien rattrapé la sauce. De plus, nous avons abandonné la version Enterprise et nous contentons de la version "pro" beaucoup moins chère.
Nous avions acheté la version enterprise pour:
* les composants Fastnet : ne sont plus inclus,
* les outils de services web : ils sont maintenant aussi dans la version pro,
* l'accès natif à Oracle : nous avons acheté une suite de composants ODAC, qui sont mis à jour dès que la dernière version d'oracle parait, bien avant une nouvelle mise à jour de bcb. En plus, les composants restent identiques.