Je débute (depuis 2 jours) en C++, et je vois qu'il existe de très grosses
différences entre compilateurs.
J'ai testé DevC++ et C++Builder, avec le 1er ça met 30 secondes à compiler
un petit programme de 10 lignes et l'exécutable fais presque 700 Ko. Alors
qu'avec le 2eme, ça met moins d'une seconde et l'exécutable fait 10 Ko !
Je débute (depuis 2 jours) en C++, et je vois qu'il existe de très grosses différences entre compilateurs.
J'ai testé DevC++ et C++Builder, avec le 1er ça met 30 secondes à compiler un petit programme de 10 lignes et l'exécutable fais presque 700 Ko. Alors qu'avec le 2eme, ça met moins d'une seconde et l'exécutable fait 10 Ko !
Pourquoi de tels différence ?
Le premier exécutable comporterait-il des informations de debuggage et pas le deuxième ?
D'après Fr@d:
Je débute (depuis 2 jours) en C++, et je vois qu'il existe de très grosses
différences entre compilateurs.
J'ai testé DevC++ et C++Builder, avec le 1er ça met 30 secondes à compiler
un petit programme de 10 lignes et l'exécutable fais presque 700 Ko. Alors
qu'avec le 2eme, ça met moins d'une seconde et l'exécutable fait 10 Ko !
Pourquoi de tels différence ?
Le premier exécutable comporterait-il des informations de debuggage et pas
le deuxième ?
Je débute (depuis 2 jours) en C++, et je vois qu'il existe de très grosses différences entre compilateurs.
J'ai testé DevC++ et C++Builder, avec le 1er ça met 30 secondes à compiler un petit programme de 10 lignes et l'exécutable fais presque 700 Ko. Alors qu'avec le 2eme, ça met moins d'une seconde et l'exécutable fait 10 Ko !
Pourquoi de tels différence ?
Le premier exécutable comporterait-il des informations de debuggage et pas le deuxième ?
Stan
"" a écrit dans le message de news: 43383a55$0$7829$
Bonjour,
Je débute (depuis 2 jours) en C++, et je vois qu'il existe de très grosses différences entre compilateurs.
J'ai testé DevC++ et C++Builder, avec le 1er ça met 30 secondes à compiler un petit programme de 10 lignes et l'exécutable fais presque 700 Ko. Alors qu'avec le 2eme, ça met moins d'une seconde et l'exécutable fait 10 Ko !
Pourquoi de tels différence ?
Avec CBuilder, si tu changes les options de linkage ( par exemple au niveau des paquets ), tu auras une taille plus importante qui correspond à une liaison statique (plutôt que dynamique, option par défaut je crois). De plus, la taille varie en fonction des infos de déboggage. Le temps de compilation peut varier aussi si le compilateur utilise des entêtes pré-compilées ( en tout cas pour les compilation suivantes ). -- -Stan
"Fr@d" <vbload@free.fr> a écrit dans le message de news:
43383a55$0$7829$8fcfb975@news.wanadoo.fr...
Bonjour,
Je débute (depuis 2 jours) en C++, et je vois qu'il existe de très grosses
différences entre compilateurs.
J'ai testé DevC++ et C++Builder, avec le 1er ça met 30 secondes à compiler
un petit programme de 10 lignes et l'exécutable fais presque 700 Ko. Alors
qu'avec le 2eme, ça met moins d'une seconde et l'exécutable fait 10 Ko !
Pourquoi de tels différence ?
Avec CBuilder, si tu changes les options de linkage ( par exemple au niveau
des paquets ),
tu auras une taille plus importante qui correspond à une liaison statique
(plutôt que dynamique, option par défaut je crois).
De plus, la taille varie en fonction des infos de déboggage.
Le temps de compilation peut varier aussi si le compilateur utilise des
entêtes pré-compilées ( en tout cas pour les
compilation suivantes ).
--
-Stan
"" a écrit dans le message de news: 43383a55$0$7829$
Bonjour,
Je débute (depuis 2 jours) en C++, et je vois qu'il existe de très grosses différences entre compilateurs.
J'ai testé DevC++ et C++Builder, avec le 1er ça met 30 secondes à compiler un petit programme de 10 lignes et l'exécutable fais presque 700 Ko. Alors qu'avec le 2eme, ça met moins d'une seconde et l'exécutable fait 10 Ko !
Pourquoi de tels différence ?
Avec CBuilder, si tu changes les options de linkage ( par exemple au niveau des paquets ), tu auras une taille plus importante qui correspond à une liaison statique (plutôt que dynamique, option par défaut je crois). De plus, la taille varie en fonction des infos de déboggage. Le temps de compilation peut varier aussi si le compilateur utilise des entêtes pré-compilées ( en tout cas pour les compilation suivantes ). -- -Stan
Dimitri PAPADOPOULOS-ORFANOS
Bonjour,
En effet, DevC++ (enfin, MinGW, son compilo) est extrèmement long à compiler. En regardant le Task Manager, il semble que DevC++ lance un genre de make, qui prend des plombes à compiler.
Je ne pense pas que ce soit lié à GNU make. MinGW est simplement un compilateur lent. L'utilisation de fichiers en-tête précompilés peut peut-être accélérer les choses, mais dans le cas de ce programme de 10 lignes j'ai bien peur qu'il n'y ait rien à faire.
Egalement, je crois que MinGW compile en utilisant des DLLs qui servent à "émuler" les appels système de Linux, ce qui ajoute d'autant au temps de compile et à la taille de l'executable.
Il y a confusion entre MinGW et Cygwin.
Dimitri Papadopoulos
Bonjour,
En effet, DevC++ (enfin, MinGW, son compilo) est extrèmement long à
compiler. En regardant le Task Manager, il semble que DevC++ lance un
genre de make, qui prend des plombes à compiler.
Je ne pense pas que ce soit lié à GNU make. MinGW est simplement un
compilateur lent. L'utilisation de fichiers en-tête précompilés peut
peut-être accélérer les choses, mais dans le cas de ce programme de 10
lignes j'ai bien peur qu'il n'y ait rien à faire.
Egalement, je crois que MinGW compile en utilisant des DLLs qui
servent à "émuler" les appels système de Linux, ce qui ajoute d'autant
au temps de compile et à la taille de l'executable.
En effet, DevC++ (enfin, MinGW, son compilo) est extrèmement long à compiler. En regardant le Task Manager, il semble que DevC++ lance un genre de make, qui prend des plombes à compiler.
Je ne pense pas que ce soit lié à GNU make. MinGW est simplement un compilateur lent. L'utilisation de fichiers en-tête précompilés peut peut-être accélérer les choses, mais dans le cas de ce programme de 10 lignes j'ai bien peur qu'il n'y ait rien à faire.
Egalement, je crois que MinGW compile en utilisant des DLLs qui servent à "émuler" les appels système de Linux, ce qui ajoute d'autant au temps de compile et à la taille de l'executable.
Il y a confusion entre MinGW et Cygwin.
Dimitri Papadopoulos
Fabien LE LEZ
On Tue, 27 Sep 2005 10:46:22 +0200, "Stan" :
Le temps de compilation peut varier aussi si le compilateur utilise des entêtes pré-compilées ( en tout cas pour les compilation suivantes ).
Ça peut effectivement jouer, de même que les infos de débogage) mais même en faisant un build complet, gcc (et surtout son linker) est beaucoup plus lent.
On Tue, 27 Sep 2005 10:46:22 +0200, "Stan" <none@none.fr>:
Le temps de compilation peut varier aussi si le compilateur utilise des
entêtes pré-compilées ( en tout cas pour les
compilation suivantes ).
Ça peut effectivement jouer, de même que les infos de débogage) mais
même en faisant un build complet, gcc (et surtout son linker) est
beaucoup plus lent.
Le temps de compilation peut varier aussi si le compilateur utilise des entêtes pré-compilées ( en tout cas pour les compilation suivantes ).
Ça peut effectivement jouer, de même que les infos de débogage) mais même en faisant un build complet, gcc (et surtout son linker) est beaucoup plus lent.
Martin
fraca7 wrote:
Non, ça c'est Cygwin. MingGW est un environnement natif Win32. En ce qui concerne la taille de l'exécutable, c'est bizarre. Peut-être que le project est configuré en debug, avec les bibliothèques liées statiquement...
Je pense aussi que l'exécutable n'a pas été "strippé" (option -s du l'éditeur de liens, configurable dans les options de DEVC++, ou strip.exe "chemin/vers/executable.exe"), ceci réduit considérablement la taille (enlève tous les symboles, utiliser --strip-unneeded sur une dll , ne pas le faire sur une version de déboggage de l'exécutable).
Néanmoins pour la taille des exécutables mingw-g++ (le compilateur C++) a un gros désavantage par rapport aux autres compilateurs windows: Pour une raison dont je ne me souviens plus -mais qui a surement à voir avec la licence puique autant que je sache il n'y a aucun projet pour que cela change- le runtime C++ fournit par Microsoft n'est pas utilisé (le runtime C lui l'est, msvcrt.dll ou un truc du genre), à la place mingw-g++ a par défaut recours à l'implémentation GNU de la librairie standard, qu'il lie statiquement (rien n'empêche une fois que l'on s'est familiarisé avec gcc d'utiliser STLport http://www.stlport.org/ à la place par exemple, y compris la version dll).
Pour la qualité du code produit, la comparaison est donc plus facile entre compilateurs C. Manifestement gcc 3.4.* est très convaincant (le compilateur intel fait nêtement mieux sur leurs propres processeurs... mais pas toujours). Mais tout ça est anecdotique, plus important gcc respecte bien les standards C (C99 par exemple) et C++. Pour se lancer dans la programmation c'est donc un excelent choix.
Pour ce qui est de la lenteur de gcc, elle est relative. C'est pas demain qu'il fera concurence à digitalmars (http://www.digitalmars.com/), mais c'est tout à fait acceptable si on ne fait pas n'importe quoi. J'ai un projet où j'utilise wxWidgets + boost, sans problème. En particulier les entêtes précompilés, pour la compilation, et le recours à une version dll des grosses librairies, pour l'édition des liens, accélèrent énormément les choses. Le projet Ultimate++ a aussi produit une version plus rapide du linker pour windows, selon leurs dires. Je l'ai essayé, mais je me suis ramassé des erreurs à l'exécution de mon programme. Comme je n'ai pas insisté, il est possible que celà vienne de moi.
fraca7 wrote:
Non, ça c'est Cygwin. MingGW est un environnement natif Win32. En ce qui
concerne la taille de l'exécutable, c'est bizarre. Peut-être que le
project est configuré en debug, avec les bibliothèques liées
statiquement...
Je pense aussi que l'exécutable n'a pas été "strippé" (option -s du
l'éditeur de liens, configurable dans les options de DEVC++, ou
strip.exe "chemin/vers/executable.exe"), ceci réduit considérablement la
taille (enlève tous les symboles, utiliser --strip-unneeded sur une dll
, ne pas le faire sur une version de déboggage de l'exécutable).
Néanmoins pour la taille des exécutables mingw-g++ (le compilateur C++)
a un gros désavantage par rapport aux autres compilateurs windows: Pour
une raison dont je ne me souviens plus -mais qui a surement à voir avec
la licence puique autant que je sache il n'y a aucun projet pour que
cela change- le runtime C++ fournit par Microsoft n'est pas utilisé (le
runtime C lui l'est, msvcrt.dll ou un truc du genre), à la place
mingw-g++ a par défaut recours à l'implémentation GNU de la librairie
standard, qu'il lie statiquement (rien n'empêche une fois que l'on s'est
familiarisé avec gcc d'utiliser STLport http://www.stlport.org/ à la
place par exemple, y compris la version dll).
Pour la qualité du code produit, la comparaison est donc plus facile
entre compilateurs C. Manifestement gcc 3.4.* est très convaincant (le
compilateur intel fait nêtement mieux sur leurs propres processeurs...
mais pas toujours).
Mais tout ça est anecdotique, plus important gcc respecte bien les
standards C (C99 par exemple) et C++. Pour se lancer dans la
programmation c'est donc un excelent choix.
Pour ce qui est de la lenteur de gcc, elle est relative. C'est pas
demain qu'il fera concurence à digitalmars
(http://www.digitalmars.com/), mais c'est tout à fait acceptable si on
ne fait pas n'importe quoi. J'ai un projet où j'utilise wxWidgets +
boost, sans problème. En particulier les entêtes précompilés, pour la
compilation, et le recours à une version dll des grosses librairies,
pour l'édition des liens, accélèrent énormément les choses. Le projet
Ultimate++ a aussi produit une version plus rapide du linker pour
windows, selon leurs dires. Je l'ai essayé, mais je me suis ramassé des
erreurs à l'exécution de mon programme. Comme je n'ai pas insisté, il
est possible que celà vienne de moi.
Non, ça c'est Cygwin. MingGW est un environnement natif Win32. En ce qui concerne la taille de l'exécutable, c'est bizarre. Peut-être que le project est configuré en debug, avec les bibliothèques liées statiquement...
Je pense aussi que l'exécutable n'a pas été "strippé" (option -s du l'éditeur de liens, configurable dans les options de DEVC++, ou strip.exe "chemin/vers/executable.exe"), ceci réduit considérablement la taille (enlève tous les symboles, utiliser --strip-unneeded sur une dll , ne pas le faire sur une version de déboggage de l'exécutable).
Néanmoins pour la taille des exécutables mingw-g++ (le compilateur C++) a un gros désavantage par rapport aux autres compilateurs windows: Pour une raison dont je ne me souviens plus -mais qui a surement à voir avec la licence puique autant que je sache il n'y a aucun projet pour que cela change- le runtime C++ fournit par Microsoft n'est pas utilisé (le runtime C lui l'est, msvcrt.dll ou un truc du genre), à la place mingw-g++ a par défaut recours à l'implémentation GNU de la librairie standard, qu'il lie statiquement (rien n'empêche une fois que l'on s'est familiarisé avec gcc d'utiliser STLport http://www.stlport.org/ à la place par exemple, y compris la version dll).
Pour la qualité du code produit, la comparaison est donc plus facile entre compilateurs C. Manifestement gcc 3.4.* est très convaincant (le compilateur intel fait nêtement mieux sur leurs propres processeurs... mais pas toujours). Mais tout ça est anecdotique, plus important gcc respecte bien les standards C (C99 par exemple) et C++. Pour se lancer dans la programmation c'est donc un excelent choix.
Pour ce qui est de la lenteur de gcc, elle est relative. C'est pas demain qu'il fera concurence à digitalmars (http://www.digitalmars.com/), mais c'est tout à fait acceptable si on ne fait pas n'importe quoi. J'ai un projet où j'utilise wxWidgets + boost, sans problème. En particulier les entêtes précompilés, pour la compilation, et le recours à une version dll des grosses librairies, pour l'édition des liens, accélèrent énormément les choses. Le projet Ultimate++ a aussi produit une version plus rapide du linker pour windows, selon leurs dires. Je l'ai essayé, mais je me suis ramassé des erreurs à l'exécution de mon programme. Comme je n'ai pas insisté, il est possible que celà vienne de moi.
Fabien LE LEZ
On Tue, 27 Sep 2005 16:26:57 +0200, Martin :
(le runtime C lui l'est, msvcrt.dll ou un truc du genre)
J'ai un exécutable fait avec Borland C++ 5.02, et il n'a pas l'air d'utiliser cette DLL -- il n'utilise que celles-là :
Néanmoins pour la taille des exécutables mingw-g++ (le compilateur C++) a un gros désavantage par rapport aux autres compilateurs windows: Pour une raison dont je ne me souviens plus -mais qui a surement à voir avec la licence puique autant que je sache il n'y a aucun projet pour que cela change- le runtime C++ fournit par Microsoft n'est pas utilisé (le runtime C lui l'est, msvcrt.dll ou un truc du genre), à la place
Ce runtime est celui de VC++ 6. Il n'est plus utilisé par les versions suivantes, et la politique a changé (ne plus l'installer comme "known dll" système mais le fournir avec son exe / le lier statiquement).
-- Aurélien Regat-Barrel
Néanmoins pour la taille des exécutables mingw-g++ (le compilateur C++)
a un gros désavantage par rapport aux autres compilateurs windows: Pour
une raison dont je ne me souviens plus -mais qui a surement à voir avec
la licence puique autant que je sache il n'y a aucun projet pour que
cela change- le runtime C++ fournit par Microsoft n'est pas utilisé (le
runtime C lui l'est, msvcrt.dll ou un truc du genre), à la place
Ce runtime est celui de VC++ 6. Il n'est plus utilisé par les versions
suivantes, et la politique a changé (ne plus l'installer comme "known
dll" système mais le fournir avec son exe / le lier statiquement).
Néanmoins pour la taille des exécutables mingw-g++ (le compilateur C++) a un gros désavantage par rapport aux autres compilateurs windows: Pour une raison dont je ne me souviens plus -mais qui a surement à voir avec la licence puique autant que je sache il n'y a aucun projet pour que cela change- le runtime C++ fournit par Microsoft n'est pas utilisé (le runtime C lui l'est, msvcrt.dll ou un truc du genre), à la place
Ce runtime est celui de VC++ 6. Il n'est plus utilisé par les versions suivantes, et la politique a changé (ne plus l'installer comme "known dll" système mais le fournir avec son exe / le lier statiquement).
-- Aurélien Regat-Barrel
Alexandre
bonsoir,
Alors je peux garder Borland C++ Builder 6 ? c'est une solution qui vas m'assurer rapidité et stabilité ?
Rapidité : oui, ce compilo est rapide.
je confirme, bien qu'il pourrait l'être un peu plus ça serait bien ;-)
Stabilité : je ne sais pas. Je n'ai pas assez testé cet IDE pour te répondre.
je m'en sers tous les jours, sans souci pour l'instant (touchons du bois)
Pérennité : vraisemblablement pas. Je ne parierais pas sur l'avenir de Borland. Néanmoins, si tu te sers juste de l'IDE et du compilo, et pas des bibliothèques "spéciales Borland" (VCL par exemple), changer d'IDE dans quelques mois/années ne devrait pas poser de problèmes.
tu sais, ça fait 10 ans que borland est censé mourir, et qu'ils renaissent toujours. Des petits phénix chez borland ;-) ... Leur produit Delphi marche plutôt bien, donc l'IDE et le framework VCL/CLX, etc... existeront pour quelques temps, mêmes avec des modifs (genre VCL.NET par exemple)... Et puis si on ne s'en sert que là où elles sont très utiles (la partie IHM par exemple...) la partie à modifier n'est pas très importante. On ne peut pas être sur de l'avenir de .NET à long terme, ce n'est pas non plus une raison pour de pas l'utiliser non ? Il faut juste bien séparer ce qui est "pur C++" de ce qui est dépendant de l'IDE (voire tout cacher via des interfaces, etc...).
bonsoir,
Alors je peux garder Borland C++ Builder 6 ? c'est une solution qui vas
m'assurer rapidité et stabilité ?
Rapidité : oui, ce compilo est rapide.
je confirme, bien qu'il pourrait l'être un peu plus ça serait bien ;-)
Stabilité : je ne sais pas. Je n'ai pas assez testé cet IDE pour te
répondre.
je m'en sers tous les jours, sans souci pour l'instant (touchons du bois)
Pérennité : vraisemblablement pas. Je ne parierais pas sur l'avenir de
Borland. Néanmoins, si tu te sers juste de l'IDE et du compilo, et pas
des bibliothèques "spéciales Borland" (VCL par exemple), changer d'IDE
dans quelques mois/années ne devrait pas poser de problèmes.
tu sais, ça fait 10 ans que borland est censé mourir, et qu'ils renaissent
toujours. Des petits phénix chez borland ;-) ...
Leur produit Delphi marche plutôt bien, donc l'IDE et le framework VCL/CLX,
etc... existeront pour quelques temps, mêmes avec des modifs (genre VCL.NET
par exemple)... Et puis si on ne s'en sert que là où elles sont très utiles
(la partie IHM par exemple...) la partie à modifier n'est pas très
importante. On ne peut pas être sur de l'avenir de .NET à long terme, ce
n'est pas non plus une raison pour de pas l'utiliser non ? Il faut juste
bien séparer ce qui est "pur C++" de ce qui est dépendant de l'IDE (voire
tout cacher via des interfaces, etc...).
Alors je peux garder Borland C++ Builder 6 ? c'est une solution qui vas m'assurer rapidité et stabilité ?
Rapidité : oui, ce compilo est rapide.
je confirme, bien qu'il pourrait l'être un peu plus ça serait bien ;-)
Stabilité : je ne sais pas. Je n'ai pas assez testé cet IDE pour te répondre.
je m'en sers tous les jours, sans souci pour l'instant (touchons du bois)
Pérennité : vraisemblablement pas. Je ne parierais pas sur l'avenir de Borland. Néanmoins, si tu te sers juste de l'IDE et du compilo, et pas des bibliothèques "spéciales Borland" (VCL par exemple), changer d'IDE dans quelques mois/années ne devrait pas poser de problèmes.
tu sais, ça fait 10 ans que borland est censé mourir, et qu'ils renaissent toujours. Des petits phénix chez borland ;-) ... Leur produit Delphi marche plutôt bien, donc l'IDE et le framework VCL/CLX, etc... existeront pour quelques temps, mêmes avec des modifs (genre VCL.NET par exemple)... Et puis si on ne s'en sert que là où elles sont très utiles (la partie IHM par exemple...) la partie à modifier n'est pas très importante. On ne peut pas être sur de l'avenir de .NET à long terme, ce n'est pas non plus une raison pour de pas l'utiliser non ? Il faut juste bien séparer ce qui est "pur C++" de ce qui est dépendant de l'IDE (voire tout cacher via des interfaces, etc...).
Fabien LE LEZ
On Mon, 3 Oct 2005 20:52:56 +0200, "Alexandre" :
tu sais, ça fait 10 ans que borland est censé mourir, et qu'ils renaissent toujours. Des petits phénix chez borland ;-) ...
J'ai voulu tester Borland C++ BuilderX. J'ai essayé de taper un code du style :
for (;;) { x
Après moult bricolages dans les options, je n'ai toujours pas réussi[*]. J'ai cherché des forums, des mailing-lists, etc., mais je n'ai rien vu d'actif. Donc j'ai laissé tomber, me disant que plus personne ne l'utilisait de toutes façons.
[*] Note : sous Dev-C++, j'ai eu un petit peu de mal, mais j'ai finalement réussi en indiquant "une tabulation = -1 espace" (sic). Sous Visual Studio 2003 et Borland C++ 5.02, ça ne pose pas de problème.
Et puis si on ne s'en sert que là où elles sont très utiles (la partie IHM par exemple...) la partie à modifier n'est pas très importante.
Ça dépend de l'application. Une application GUI a vite fait d'avoir 90 % de son code qui concerne l'IHM. J'ai justement une telle application, qui utilise les OWL de Borland, et qui me force à rester sous Borland C++ 5.02 car je n'ai toujours pas réussi à la linker avec autre chose.
On ne peut pas être sur de l'avenir de .NET à long terme, ce n'est pas non plus une raison pour de pas l'utiliser non ?
Ben... pour l'instant, j'attends que ce soit utilisable, i.e. : - une intégration décente avec C++ (c'est en préparation pour Visual Studio 2005 si j'ai bien compris) ; - l'assurance que tous mes clients potentiels ont le runtime .Net déjà installé sur leur machine.
Il faut juste bien séparer ce qui est "pur C++" de ce qui est dépendant de l'IDE
Pas de l'IDE, mais des bibliothèques propriétaires.
(voire tout cacher via des interfaces,
C'est un peu fastidieux, mais j'y pense.
On Mon, 3 Oct 2005 20:52:56 +0200, "Alexandre"
<alex.g@netcourrier.com>:
tu sais, ça fait 10 ans que borland est censé mourir, et qu'ils renaissent
toujours. Des petits phénix chez borland ;-) ...
J'ai voulu tester Borland C++ BuilderX.
J'ai essayé de taper un code du style :
for (;;)
{
x
Après moult bricolages dans les options, je n'ai toujours pas
réussi[*].
J'ai cherché des forums, des mailing-lists, etc., mais je n'ai rien vu
d'actif. Donc j'ai laissé tomber, me disant que plus personne ne
l'utilisait de toutes façons.
[*] Note : sous Dev-C++, j'ai eu un petit peu de mal, mais j'ai
finalement réussi en indiquant "une tabulation = -1 espace" (sic).
Sous Visual Studio 2003 et Borland C++ 5.02, ça ne pose pas de
problème.
Et puis si on ne s'en sert que là où elles sont très utiles
(la partie IHM par exemple...) la partie à modifier n'est pas très
importante.
Ça dépend de l'application. Une application GUI a vite fait d'avoir
90 % de son code qui concerne l'IHM.
J'ai justement une telle application, qui utilise les OWL de Borland,
et qui me force à rester sous Borland C++ 5.02 car je n'ai toujours
pas réussi à la linker avec autre chose.
On ne peut pas être sur de l'avenir de .NET à long terme, ce
n'est pas non plus une raison pour de pas l'utiliser non ?
Ben... pour l'instant, j'attends que ce soit utilisable, i.e. :
- une intégration décente avec C++ (c'est en préparation pour
Visual Studio 2005 si j'ai bien compris) ;
- l'assurance que tous mes clients potentiels ont le runtime
.Net déjà installé sur leur machine.
Il faut juste bien séparer ce qui est "pur C++"
de ce qui est dépendant de l'IDE
Pas de l'IDE, mais des bibliothèques propriétaires.
tu sais, ça fait 10 ans que borland est censé mourir, et qu'ils renaissent toujours. Des petits phénix chez borland ;-) ...
J'ai voulu tester Borland C++ BuilderX. J'ai essayé de taper un code du style :
for (;;) { x
Après moult bricolages dans les options, je n'ai toujours pas réussi[*]. J'ai cherché des forums, des mailing-lists, etc., mais je n'ai rien vu d'actif. Donc j'ai laissé tomber, me disant que plus personne ne l'utilisait de toutes façons.
[*] Note : sous Dev-C++, j'ai eu un petit peu de mal, mais j'ai finalement réussi en indiquant "une tabulation = -1 espace" (sic). Sous Visual Studio 2003 et Borland C++ 5.02, ça ne pose pas de problème.
Et puis si on ne s'en sert que là où elles sont très utiles (la partie IHM par exemple...) la partie à modifier n'est pas très importante.
Ça dépend de l'application. Une application GUI a vite fait d'avoir 90 % de son code qui concerne l'IHM. J'ai justement une telle application, qui utilise les OWL de Borland, et qui me force à rester sous Borland C++ 5.02 car je n'ai toujours pas réussi à la linker avec autre chose.
On ne peut pas être sur de l'avenir de .NET à long terme, ce n'est pas non plus une raison pour de pas l'utiliser non ?
Ben... pour l'instant, j'attends que ce soit utilisable, i.e. : - une intégration décente avec C++ (c'est en préparation pour Visual Studio 2005 si j'ai bien compris) ; - l'assurance que tous mes clients potentiels ont le runtime .Net déjà installé sur leur machine.
Il faut juste bien séparer ce qui est "pur C++" de ce qui est dépendant de l'IDE
Pas de l'IDE, mais des bibliothèques propriétaires.
