Bonjour à tous,
je développe actuellement en C++ Builder 6 et je dois réaliser un gros
projet (environ 10 mois) pour Windows exclusivement. Comme la VCL est
abandonnée, je ne souhaite pas le faire avec C++ Builder 6.
Comme l'apprentissage d'un environnement demande un certain investissement
et que je veux pouvoir maintenir cette application plusieurs années, quel
compilateur me conseillez vous ?
C++ Builder X ou Visual C++.NET ?
Est-on certain qu'il y aura maintenance pour ces compilateurs ?
Borland/Inprise ne risque t-il pas d'abandonner C++ Builder X ?
Merci de vos conseils éclairés.
Marc
Merci de ta réponse détaillée. Mais j'avoue que je reste perplexe. Tu utilises toujours OWL
Oui, parce que je travaille toujours sur le même projet, qui commence à dater sérieusement. Il n'est d'ailleurs pas impossible que je "traduise" ce projet en wxWidgets si jamais la portabilité Linux/MacOS devient un argument commercial important.
Ce qui m'embête le plus, c'est la classe AnsiString, obligatoire pour utiliser la VCL et qui rend le code non portable.
Tu peux toujours en offrir une implémentation qui se base sur std::string, une fois que tu auras abandonné la VCL. En passant, c'est marrant, il me semble que AnsiString est assez vieux, pourtant OWL n'en parle jamais.
J'ai un peu regardé le site de Borland, et la communication sur C++ Builder X y est tellement réduite, que honnêtement, je me suis demandé si c'était pas déjà abandonné.
Franchement, je trouve le site de Borland assez mauvais -- je n'ai jamais réussi à y pêcher la moindre information utile.
-- schtroumpf schtroumpf
On Thu, 1 Jul 2004 10:48:40 +0200, "Marc" <metrica@free.fr>:
Merci de ta réponse détaillée.
Mais j'avoue que je reste perplexe. Tu utilises toujours OWL
Oui, parce que je travaille toujours sur le même projet, qui commence
à dater sérieusement.
Il n'est d'ailleurs pas impossible que je "traduise" ce projet en
wxWidgets si jamais la portabilité Linux/MacOS devient un argument
commercial important.
Ce qui m'embête le plus, c'est la classe AnsiString, obligatoire pour
utiliser la VCL et qui rend le code non portable.
Tu peux toujours en offrir une implémentation qui se base sur
std::string, une fois que tu auras abandonné la VCL.
En passant, c'est marrant, il me semble que AnsiString est assez
vieux, pourtant OWL n'en parle jamais.
J'ai un peu regardé le site de Borland, et la communication sur C++ Builder
X y est tellement réduite, que honnêtement, je me suis demandé si c'était
pas déjà abandonné.
Franchement, je trouve le site de Borland assez mauvais -- je n'ai
jamais réussi à y pêcher la moindre information utile.
Merci de ta réponse détaillée. Mais j'avoue que je reste perplexe. Tu utilises toujours OWL
Oui, parce que je travaille toujours sur le même projet, qui commence à dater sérieusement. Il n'est d'ailleurs pas impossible que je "traduise" ce projet en wxWidgets si jamais la portabilité Linux/MacOS devient un argument commercial important.
Ce qui m'embête le plus, c'est la classe AnsiString, obligatoire pour utiliser la VCL et qui rend le code non portable.
Tu peux toujours en offrir une implémentation qui se base sur std::string, une fois que tu auras abandonné la VCL. En passant, c'est marrant, il me semble que AnsiString est assez vieux, pourtant OWL n'en parle jamais.
J'ai un peu regardé le site de Borland, et la communication sur C++ Builder X y est tellement réduite, que honnêtement, je me suis demandé si c'était pas déjà abandonné.
Franchement, je trouve le site de Borland assez mauvais -- je n'ai jamais réussi à y pêcher la moindre information utile.
-- schtroumpf schtroumpf
M. B.
"Fabien LE LEZ" a écrit dans le message de news:
On Wed, 30 Jun 2004 11:30:53 +0200, "Marc" :
Microsoft a décidé d'abandonner les MFC pour une solution peut-être plus adaptée à son langage propriétaire C# qu'au C++, ...
Les MFC sont toujours disponible sous Visual Studio .NET, tout comme ATL.
MB
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de news:
i275e0dcruq54qmlu94r5hsudsnu7dppg0@4ax.com...
On Wed, 30 Jun 2004 11:30:53 +0200, "Marc" <metrica@free.fr>:
Microsoft a décidé d'abandonner les MFC
pour une solution peut-être plus adaptée à son langage propriétaire C#
qu'au C++, ...
Les MFC sont toujours disponible sous Visual Studio .NET, tout comme
ATL.
Alexandre BACQUART wrote in news:40e46de8$0$27616$:
M. B. wrote:
"Fabien LE LEZ" a écrit dans le message de news:
On Wed, 30 Jun 2004 11:30:53 +0200, "Marc" :
Microsoft a décidé d'abandonner les MFC pour une solution peut-être plus adaptée à son langage propriétaire C# qu'au C++, ...
Les MFC sont toujours disponible sous Visual Studio .NET, tout comme ATL.
Avec ses bugs et lacunes qui ne seront jamais corrigés.
Pas officiellement. Elles ne seront juste pas améliorées.
-- Luc Hermitte <hermitte at free.fr> FAQ de <news:fr.comp.lang.c++> : <http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/> Dejanews : <http://groups.google.com/advanced_group_search>
Gabriel Dos Reis
Fabien LE LEZ writes:
| On 1 Jul 2004 03:06:01 -0700, : | | >Il y en a d'autres qui ont peur que s'ils utilisent des logiciels GPL, | >ils seront obligés à rendre leurs sources disponibles gratuitement à | >tout le monde. | | Faut dire que la GPL est un sacré pavé, pas forcément facile à lire et | à comprendre... | | A comparer avec la licence de la Zlib, une licence comme je les aime, | en 15 lignes : <http://www.gnu.org/licenses/gpl.txt>
C'est fait exprès pour que ce soit ouvert à négociation :-) Une license est toujours négociable.
#define DISCLAIMER "Je ne suis pas un missionaire GNU"
#include DISCLAIMER
-- Gaby
Fabien LE LEZ <gramster@gramster.com> writes:
| On 1 Jul 2004 03:06:01 -0700, kanze@gabi-soft.fr:
|
| >Il y en a d'autres qui ont peur que s'ils utilisent des logiciels GPL,
| >ils seront obligés à rendre leurs sources disponibles gratuitement à
| >tout le monde.
|
| Faut dire que la GPL est un sacré pavé, pas forcément facile à lire et
| à comprendre...
|
| A comparer avec la licence de la Zlib, une licence comme je les aime,
| en 15 lignes : <http://www.gnu.org/licenses/gpl.txt>
C'est fait exprès pour que ce soit ouvert à négociation :-)
Une license est toujours négociable.
#define DISCLAIMER "Je ne suis pas un missionaire GNU"
| On 1 Jul 2004 03:06:01 -0700, : | | >Il y en a d'autres qui ont peur que s'ils utilisent des logiciels GPL, | >ils seront obligés à rendre leurs sources disponibles gratuitement à | >tout le monde. | | Faut dire que la GPL est un sacré pavé, pas forcément facile à lire et | à comprendre... | | A comparer avec la licence de la Zlib, une licence comme je les aime, | en 15 lignes : <http://www.gnu.org/licenses/gpl.txt>
C'est fait exprès pour que ce soit ouvert à négociation :-) Une license est toujours négociable.
#define DISCLAIMER "Je ne suis pas un missionaire GNU"
#include DISCLAIMER
-- Gaby
M. B.
"Alexandre BACQUART" a écrit dans le message de news: 40e46de8$0$27616$
M. B. wrote:
"Fabien LE LEZ" a écrit dans le message de news:
On Wed, 30 Jun 2004 11:30:53 +0200, "Marc" :
Microsoft a décidé d'abandonner les MFC pour une solution peut-être plus adaptée à son langage propriétaire C# qu'au C++, ...
Les MFC sont toujours disponible sous Visual Studio .NET, tout comme ATL.
Avec ses bugs et lacunes qui ne seront jamais corrigés.
Il faut savoir tourner la page.
La perenite, en informatique, ca n'a aucun sens.
MB
"Alexandre BACQUART" <tek512@hotmail.com> a écrit dans le message de news:
40e46de8$0$27616$626a14ce@news.free.fr...
M. B. wrote:
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de news:
i275e0dcruq54qmlu94r5hsudsnu7dppg0@4ax.com...
On Wed, 30 Jun 2004 11:30:53 +0200, "Marc" <metrica@free.fr>:
Microsoft a décidé d'abandonner les MFC
pour une solution peut-être plus adaptée à son langage propriétaire C#
qu'au C++, ...
Les MFC sont toujours disponible sous Visual Studio .NET, tout comme
ATL.
Avec ses bugs et lacunes qui ne seront jamais corrigés.
"Alexandre BACQUART" a écrit dans le message de news: 40e46de8$0$27616$
M. B. wrote:
"Fabien LE LEZ" a écrit dans le message de news:
On Wed, 30 Jun 2004 11:30:53 +0200, "Marc" :
Microsoft a décidé d'abandonner les MFC pour une solution peut-être plus adaptée à son langage propriétaire C# qu'au C++, ...
Les MFC sont toujours disponible sous Visual Studio .NET, tout comme ATL.
Avec ses bugs et lacunes qui ne seront jamais corrigés.
Il faut savoir tourner la page.
La perenite, en informatique, ca n'a aucun sens.
MB
Alexandre BACQUART
M. B. wrote:
Les MFC sont toujours disponible sous Visual Studio .NET, tout comme ATL.
Avec ses bugs et lacunes qui ne seront jamais corrigés.
Il faut savoir tourner la page.
La perenite, en informatique, ca n'a aucun sens.
Quand il s'agit de... choses comme la MFC, oui, ça n'a aucun sens, je suis bien d'accord :) Sinon en ce qui me concerne, je trouve au contraire que les API (ou interfaces d'API, ou encapsulateurs, décapsuleur... enfin tu l'appelles comme tu veux) qui durent ont plus de sens que les autres, mais ce n'est qu'un avis personnel peut-être... Je n'ai rien contre la MFC hein. J'ai juste mis un pied dedans, j'avais crû voir une lumière, et voyant que ce n'était qu'une lueur, je suis reparti dans la pénombre...
-- Tek
M. B. wrote:
Les MFC sont toujours disponible sous Visual Studio .NET, tout comme
ATL.
Avec ses bugs et lacunes qui ne seront jamais corrigés.
Il faut savoir tourner la page.
La perenite, en informatique, ca n'a aucun sens.
Quand il s'agit de... choses comme la MFC, oui, ça n'a aucun sens, je
suis bien d'accord :) Sinon en ce qui me concerne, je trouve au
contraire que les API (ou interfaces d'API, ou encapsulateurs,
décapsuleur... enfin tu l'appelles comme tu veux) qui durent ont plus de
sens que les autres, mais ce n'est qu'un avis personnel peut-être...
Je n'ai rien contre la MFC hein. J'ai juste mis un pied dedans, j'avais
crû voir une lumière, et voyant que ce n'était qu'une lueur, je suis
reparti dans la pénombre...
Les MFC sont toujours disponible sous Visual Studio .NET, tout comme ATL.
Avec ses bugs et lacunes qui ne seront jamais corrigés.
Il faut savoir tourner la page.
La perenite, en informatique, ca n'a aucun sens.
Quand il s'agit de... choses comme la MFC, oui, ça n'a aucun sens, je suis bien d'accord :) Sinon en ce qui me concerne, je trouve au contraire que les API (ou interfaces d'API, ou encapsulateurs, décapsuleur... enfin tu l'appelles comme tu veux) qui durent ont plus de sens que les autres, mais ce n'est qu'un avis personnel peut-être... Je n'ai rien contre la MFC hein. J'ai juste mis un pied dedans, j'avais crû voir une lumière, et voyant que ce n'était qu'une lueur, je suis reparti dans la pénombre...
-- Tek
darkman_spam
"M. B." wrote in message <cc4de4$em5$:
La perenite, en informatique, ca n'a aucun sens.
?
--drkm
"M. B." wrote in message <cc4de4$em5$1@news-reader4.wanadoo.fr>:
Avec ses bugs et lacunes qui ne seront jamais corrigés.
Pas officiellement. Elles ne seront juste pas améliorées.
Pourtant l'équipe de VC++ prétend travailler dur sur les MFC 8. Plus sûres, plus stables, plus simples, mieux intégrées avec .Net... Faut pas oublier que Microsoft est le premier à utiliser les MFC, et qu'ils ont pas mal de lignes de codes à maintenir.
-- Aurélien REGAT-BARREL
Avec ses bugs et lacunes qui ne seront jamais corrigés.
Pas officiellement.
Elles ne seront juste pas améliorées.
Pourtant l'équipe de VC++ prétend travailler dur sur les MFC 8. Plus sûres,
plus stables, plus simples, mieux intégrées avec .Net...
Faut pas oublier que Microsoft est le premier à utiliser les MFC, et qu'ils
ont pas mal de lignes de codes à maintenir.
Avec ses bugs et lacunes qui ne seront jamais corrigés.
Pas officiellement. Elles ne seront juste pas améliorées.
Pourtant l'équipe de VC++ prétend travailler dur sur les MFC 8. Plus sûres, plus stables, plus simples, mieux intégrées avec .Net... Faut pas oublier que Microsoft est le premier à utiliser les MFC, et qu'ils ont pas mal de lignes de codes à maintenir.
