>> Pour le langage cela va de VB à VC++ en passant par Delphi, BCB et Java.
VC++, BCB, etc... sont des langages ? Je pensais que c'était des IDE... le langage, c'est C++ non ? Pour moi ça parait tellement évident, mais je lis tellement cet amalgame chez des gens bien plus qualifiés que moi qu'en fin de compte, je me demande si ce n'est pas moi qui me trompe.
En général on ne choisit pas un "langage" quand on a un projet à développer, mais plutôt un environnement de développement parce qu'il va bien au delà du simple langage. Au point où parler de langage au sens strict aujourd'hui n'a pas beaucoup de sens, d'où peut-être l'amalgame.
Par exemple si on désire écrire un client base de données, je ne vois pas pourquoi a priori la sémantique C++ serait meilleure que la sémantique Pascal, Python, Perl... Par contre je te déconseillerais Python à cause du support ODBC par exemple, ce qui a à voir avec l'environnement et non le langage.
>> Pour le langage cela va de VB à VC++ en passant par Delphi, BCB et
Java.
VC++, BCB, etc... sont des langages ? Je pensais que c'était des
IDE... le langage, c'est C++ non ? Pour moi ça parait tellement
évident, mais je lis tellement cet amalgame chez des gens bien plus
qualifiés que moi qu'en fin de compte, je me demande si ce n'est pas
moi qui me trompe.
En général on ne choisit pas un "langage" quand on a un projet à
développer, mais plutôt un environnement de développement parce qu'il va
bien au delà du simple langage. Au point où parler de langage au sens
strict aujourd'hui n'a pas beaucoup de sens, d'où peut-être l'amalgame.
Par exemple si on désire écrire un client base de données, je ne vois pas
pourquoi a priori la sémantique C++ serait meilleure que la sémantique
Pascal, Python, Perl... Par contre je te déconseillerais Python à cause du
support ODBC par exemple, ce qui a à voir avec l'environnement et non le
langage.
>> Pour le langage cela va de VB à VC++ en passant par Delphi, BCB et Java.
VC++, BCB, etc... sont des langages ? Je pensais que c'était des IDE... le langage, c'est C++ non ? Pour moi ça parait tellement évident, mais je lis tellement cet amalgame chez des gens bien plus qualifiés que moi qu'en fin de compte, je me demande si ce n'est pas moi qui me trompe.
En général on ne choisit pas un "langage" quand on a un projet à développer, mais plutôt un environnement de développement parce qu'il va bien au delà du simple langage. Au point où parler de langage au sens strict aujourd'hui n'a pas beaucoup de sens, d'où peut-être l'amalgame.
Par exemple si on désire écrire un client base de données, je ne vois pas pourquoi a priori la sémantique C++ serait meilleure que la sémantique Pascal, Python, Perl... Par contre je te déconseillerais Python à cause du support ODBC par exemple, ce qui a à voir avec l'environnement et non le langage.
> Actuellement, qu'est-ce qui selon vous le plus rapide/puissant ?
A mon avis la solution la plus puissante du moment est: - C# pour l'IHM et les traitements classiques - C++ pour les traitements lourds si tu en as et l'interet de Microsoft .NET c'est que tu mixtes cela dans une seule application très simplement.
Rémi
-- Rémi Thomas - MVP Visual Studio .NET Développeur Windows indépendant http://www.xtware.com/cv
> Actuellement, qu'est-ce qui selon vous le plus rapide/puissant ?
A mon avis la solution la plus puissante du moment est:
- C# pour l'IHM et les traitements classiques
- C++ pour les traitements lourds si tu en as
et l'interet de Microsoft .NET c'est que tu mixtes cela dans une seule
application très simplement.
Rémi
--
Rémi Thomas - MVP Visual Studio .NET
Développeur Windows indépendant
http://www.xtware.com/cv
> Actuellement, qu'est-ce qui selon vous le plus rapide/puissant ?
A mon avis la solution la plus puissante du moment est: - C# pour l'IHM et les traitements classiques - C++ pour les traitements lourds si tu en as et l'interet de Microsoft .NET c'est que tu mixtes cela dans une seule application très simplement.
Rémi
-- Rémi Thomas - MVP Visual Studio .NET Développeur Windows indépendant http://www.xtware.com/cv
nospam-hello-world
> > Pour le langage cela va de VB à VC++ en passant par Delphi, BCB et Java.
VC++, BCB, etc... sont des langages ? Je pensais que c'était des IDE... le langage, c'est C++ non ? Pour moi ça parait tellement évident, mais je lis tellement cet amalgame chez des gens bien plus qualifiés que moi qu'en fin de compte, je me demande si ce n'est pas moi qui me trompe.
Je pense que cet amalgame est consenti parce que pour C++ notamment y'a pas de lib GUI standard. Donc dire qu'on fait une IHM en C++ n'indique pas vraiment avec quoi on programme... dire VC++ / BCB est + précis et sous-entend C++. De même TurboPascal est propre à Delphi il me semble... idem le basic de VB... Ce n'est pas tant le langage qui compte que la lib GUI utilisée, d'ou la spécif du RAD. Exception pour Java ou alors on sait qu'il s'agit de SWING.
> > Pour le langage cela va de VB à VC++ en passant par Delphi, BCB et Java.
VC++, BCB, etc... sont des langages ? Je pensais que c'était des IDE... le
langage, c'est C++ non ? Pour moi ça parait tellement évident, mais je lis
tellement cet amalgame chez des gens bien plus qualifiés que moi qu'en fin
de compte, je me demande si ce n'est pas moi qui me trompe.
Je pense que cet amalgame est consenti parce que pour C++ notamment
y'a pas de lib GUI standard. Donc dire qu'on fait une IHM en C++
n'indique pas vraiment avec quoi on programme... dire VC++ / BCB est +
précis et sous-entend C++.
De même TurboPascal est propre à Delphi il me semble... idem le basic
de VB...
Ce n'est pas tant le langage qui compte que la lib GUI utilisée, d'ou
la spécif du RAD. Exception pour Java ou alors on sait qu'il s'agit de
SWING.
> > Pour le langage cela va de VB à VC++ en passant par Delphi, BCB et Java.
VC++, BCB, etc... sont des langages ? Je pensais que c'était des IDE... le langage, c'est C++ non ? Pour moi ça parait tellement évident, mais je lis tellement cet amalgame chez des gens bien plus qualifiés que moi qu'en fin de compte, je me demande si ce n'est pas moi qui me trompe.
Je pense que cet amalgame est consenti parce que pour C++ notamment y'a pas de lib GUI standard. Donc dire qu'on fait une IHM en C++ n'indique pas vraiment avec quoi on programme... dire VC++ / BCB est + précis et sous-entend C++. De même TurboPascal est propre à Delphi il me semble... idem le basic de VB... Ce n'est pas tant le langage qui compte que la lib GUI utilisée, d'ou la spécif du RAD. Exception pour Java ou alors on sait qu'il s'agit de SWING.
Patrick Philippot
Cédric O. wrote:
Pour le langage cela va de VB à VC++ en passant par Delphi, BCB et Java.
VC++, BCB, etc... sont des langages ? Je pensais que c'était des IDE... le langage, c'est C++ non ? Pour moi ça parait tellement évident, mais je lis tellement cet amalgame chez des gens bien plus qualifiés que moi qu'en fin de compte, je me demande si ce n'est pas moi qui me trompe.
Oui... et non. Stricto sensus, vous avez raison. Cela dit, si je regarde le C++ de MS et celui de Borland, nous sommes loin de la normalisation. De plus BCB, au moins pour la dernière version que j'ai vue, utilise la VCL... écrite en Pascal. Ce qui signifie que l'on mélange joyeusement du code Pascal avec du code C++. Etant un fan de .Net , je ne suis pas contre mais ce "mélange" ne se fait pas dans des conditions idéales notamment au niveau de la construction / destruction des objets C++ vs. la construction / destruction des objets Pascal. C'est un exemple.
En outre, VC++ introduit pas mal de spécificités liées au COM, aux MFC, etc... La confusion entre les fonctionnalités de l'IDE et les spécificités de l'implémentation du langage est devenue tellement patente que l'on peut, à mon sens et à un certain niveau, parler d'un autre langage.
De même, Delphi est-il un IDE ou une implémentation vraiment particulière du langage Pascal? Vaste débat.
-- Patrick Philippot - Microsoft MVP [.Net] MainSoft Consulting Services www.mainsoft.xx (remplacez .xx par .fr si vous répondez par e-mail)
Cédric O. wrote:
Pour le langage cela va de VB à VC++ en passant par Delphi, BCB et
Java.
VC++, BCB, etc... sont des langages ? Je pensais que c'était des
IDE... le langage, c'est C++ non ? Pour moi ça parait tellement
évident, mais je lis tellement cet amalgame chez des gens bien plus
qualifiés que moi qu'en fin de compte, je me demande si ce n'est pas
moi qui me trompe.
Oui... et non. Stricto sensus, vous avez raison. Cela dit, si je regarde
le C++ de MS et celui de Borland, nous sommes loin de la normalisation.
De plus BCB, au moins pour la dernière version que j'ai vue, utilise la
VCL... écrite en Pascal. Ce qui signifie que l'on mélange joyeusement du
code Pascal avec du code C++. Etant un fan de .Net , je ne suis pas
contre mais ce "mélange" ne se fait pas dans des conditions idéales
notamment au niveau de la construction / destruction des objets C++ vs.
la construction / destruction des objets Pascal. C'est un exemple.
En outre, VC++ introduit pas mal de spécificités liées au COM, aux MFC,
etc... La confusion entre les fonctionnalités de l'IDE et les
spécificités de l'implémentation du langage est devenue tellement
patente que l'on peut, à mon sens et à un certain niveau, parler d'un
autre langage.
De même, Delphi est-il un IDE ou une implémentation vraiment
particulière du langage Pascal? Vaste débat.
--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.xx
(remplacez .xx par .fr si vous répondez par e-mail)
Pour le langage cela va de VB à VC++ en passant par Delphi, BCB et Java.
VC++, BCB, etc... sont des langages ? Je pensais que c'était des IDE... le langage, c'est C++ non ? Pour moi ça parait tellement évident, mais je lis tellement cet amalgame chez des gens bien plus qualifiés que moi qu'en fin de compte, je me demande si ce n'est pas moi qui me trompe.
Oui... et non. Stricto sensus, vous avez raison. Cela dit, si je regarde le C++ de MS et celui de Borland, nous sommes loin de la normalisation. De plus BCB, au moins pour la dernière version que j'ai vue, utilise la VCL... écrite en Pascal. Ce qui signifie que l'on mélange joyeusement du code Pascal avec du code C++. Etant un fan de .Net , je ne suis pas contre mais ce "mélange" ne se fait pas dans des conditions idéales notamment au niveau de la construction / destruction des objets C++ vs. la construction / destruction des objets Pascal. C'est un exemple.
En outre, VC++ introduit pas mal de spécificités liées au COM, aux MFC, etc... La confusion entre les fonctionnalités de l'IDE et les spécificités de l'implémentation du langage est devenue tellement patente que l'on peut, à mon sens et à un certain niveau, parler d'un autre langage.
De même, Delphi est-il un IDE ou une implémentation vraiment particulière du langage Pascal? Vaste débat.
-- Patrick Philippot - Microsoft MVP [.Net] MainSoft Consulting Services www.mainsoft.xx (remplacez .xx par .fr si vous répondez par e-mail)
Vincent Burel
"Spoofix" <spoofix[ENLEVEZ_CA]@free.fr> wrote in message news:blf110$nt8$
> Tous le problème est donc de savoir ou se situe la limite entre Win32 et > le reste, tu as par exemple l'air de considérer les resoures "comme > faisant partie de Win32" pourtant c'est déjà une certaines > abstraction... certains préfèrent leur propre système de resources.
Oui, c'est vrai..... Donc, certains créent eux meme une couche "maison" par dessus l'API Win32
?
C'est bien ca ?
oui c'est l'idéal pour plusieurs raisons : ca vous donne la maitrise maximale de votre source code. Ca vous évite de suivre les longues "Learning Curve" des autres Librairies, Le cas échéant, Ca vous permettra de porter votre appli sur un autre system en un minimum de temps... Ceci dit se faire des Lib propriétaire, fiable, homogènes, relativement indépendant et stable, c'est long et ca demande d'avoir produit déjà beaucoup de code, et d'avoir de l'expérience. Ma première Lib de controle GUI m'a couté 6 mois (faut dire que j'apprenais Windows en même temps) , ma seconde ma couté qu'un mois, mais j'ai été obligé de passé à une version 2 parce que la première intégrait trop d'élément généraliste finalement chiants à manoeuvrer, donc long à mettre en place, et dont les conséquences n'était pas controlable à 100% . D'ailleurs quand vous faites une Lib qui est sencé vous servir longtemps, la difiiculté est de trouver un compromis entre ce qui doit être généralisé et ce qui ne doit pas l'être. Si vous ne trouvez pas ce compromis, vous perdrez un temps faramineux (si ce n'est pas à la conception de la lib, ca sera à l'utilisation et la maintenance...).
Actuellement, qu'est-ce qui selon vous le plus rapide/puissant ?
Tout dépend ce que l'on entend par rapide/puissant.
De manière général un développement rapide , fait avec des composant/Library puissant, permettra effectivement de développer une appli béton si et seulement si , le ou les développeurs connaissent parfaitement leur environnement de travail.
La problématique du développement commerciale ne réside pas seulement dans la fabrication du logiciel, mais surtout dans sa maintenance et dans la capacité à maitriser tous les détails du logiciel. Entre la version 0 et la version commercialisé, y'a beaucoup de modifications et de corrections. Et entre une version RC0 et une version qui a 2 ans , aussi. L'enjeux est alors de prévoir dès le début, dans une large mesure, l'ensemble des modif ou corrections que l'on pourrait vous demander (bref avoir une idée assez précise de l'univers des possible et du domaine de ce qui sera impossible). Et si votre code n'est pas maitrisé, alors ou vous ne serez pas en mesure de faire évoluer votre logiciel , ou bien cela vous coutera très cher en temps ou/et en argent. D'ailleurs sans même parler de langage, c'est l'organization de vos sources codes qui condittionne en premier la bonne tenu d'un développement.
Alors la mode actuelle, c'est quand même de mettre une souris dans une carcasse d'éléphant, Parce que certains crois qu'une organization "maximum scalable" (surtout en C++ où de plus en plus les programmeurs font une confusion entre objet et données - object au détriment de la données - Alors qu'un programmeur ancienne génération priviligiera la donnée au détriment du code) permet toutes les évolutions, c'est parfois vrai, mais ca coute hyper cher à maintenir et utiliser car cela complexifie l'ensemble et vous éloigne énormément de ce que j'appelle "la maitrise du code". Donc la aussi y'a un compromis à trouver.
A+ Vincent Burel
"Spoofix" <spoofix[ENLEVEZ_CA]@free.fr> wrote in message
news:blf110$nt8$1@demo2.univ-lyon1.fr...
> Tous le problème est donc de savoir ou se situe la limite entre Win32 et
> le reste, tu as par exemple l'air de considérer les resoures "comme
> faisant partie de Win32" pourtant c'est déjà une certaines
> abstraction... certains préfèrent leur propre système de resources.
Oui, c'est vrai.....
Donc, certains créent eux meme une couche "maison" par dessus l'API Win32
?
C'est bien ca ?
oui c'est l'idéal pour plusieurs raisons : ca vous donne la maitrise
maximale de votre source code. Ca vous évite de suivre les longues "Learning
Curve" des autres Librairies, Le cas échéant, Ca vous permettra de porter
votre appli sur un autre system en un minimum de temps... Ceci dit se faire
des Lib propriétaire, fiable, homogènes, relativement indépendant et stable,
c'est long et ca demande d'avoir produit déjà beaucoup de code, et d'avoir
de l'expérience. Ma première Lib de controle GUI m'a couté 6 mois (faut dire
que j'apprenais Windows en même temps) , ma seconde ma couté qu'un mois,
mais j'ai été obligé de passé à une version 2 parce que la première
intégrait trop d'élément généraliste finalement chiants à manoeuvrer, donc
long à mettre en place, et dont les conséquences n'était pas controlable à
100% . D'ailleurs quand vous faites une Lib qui est sencé vous servir
longtemps, la difiiculté est de trouver un compromis entre ce qui doit être
généralisé et ce qui ne doit pas l'être. Si vous ne trouvez pas ce
compromis, vous perdrez un temps faramineux (si ce n'est pas à la conception
de la lib, ca sera à l'utilisation et la maintenance...).
Actuellement, qu'est-ce qui selon vous le plus rapide/puissant ?
Tout dépend ce que l'on entend par rapide/puissant.
De manière général un développement rapide , fait avec des composant/Library
puissant, permettra effectivement de développer une appli béton si et
seulement si , le ou les développeurs connaissent parfaitement leur
environnement de travail.
La problématique du développement commerciale ne réside pas seulement dans
la fabrication du logiciel, mais surtout dans sa maintenance et dans la
capacité à maitriser tous les détails du logiciel. Entre la version 0 et la
version commercialisé, y'a beaucoup de modifications et de corrections. Et
entre une version RC0 et une version qui a 2 ans , aussi. L'enjeux est alors
de prévoir dès le début, dans une large mesure, l'ensemble des modif ou
corrections que l'on pourrait vous demander (bref avoir une idée assez
précise de l'univers des possible et du domaine de ce qui sera impossible).
Et si votre code n'est pas maitrisé, alors ou vous ne serez pas en mesure de
faire évoluer votre logiciel , ou bien cela vous coutera très cher en temps
ou/et en argent. D'ailleurs sans même parler de langage, c'est
l'organization de vos sources codes qui condittionne en premier la bonne
tenu d'un développement.
Alors la mode actuelle, c'est quand même de mettre une souris dans une
carcasse d'éléphant, Parce que certains crois qu'une organization "maximum
scalable" (surtout en C++ où de plus en plus les programmeurs font une
confusion entre objet et données - object au détriment de la données - Alors
qu'un programmeur ancienne génération priviligiera la donnée au détriment du
code) permet toutes les évolutions, c'est parfois vrai, mais ca coute hyper
cher à maintenir et utiliser car cela complexifie l'ensemble et vous éloigne
énormément de ce que j'appelle "la maitrise du code". Donc la aussi y'a un
compromis à trouver.
"Spoofix" <spoofix[ENLEVEZ_CA]@free.fr> wrote in message news:blf110$nt8$
> Tous le problème est donc de savoir ou se situe la limite entre Win32 et > le reste, tu as par exemple l'air de considérer les resoures "comme > faisant partie de Win32" pourtant c'est déjà une certaines > abstraction... certains préfèrent leur propre système de resources.
Oui, c'est vrai..... Donc, certains créent eux meme une couche "maison" par dessus l'API Win32
?
C'est bien ca ?
oui c'est l'idéal pour plusieurs raisons : ca vous donne la maitrise maximale de votre source code. Ca vous évite de suivre les longues "Learning Curve" des autres Librairies, Le cas échéant, Ca vous permettra de porter votre appli sur un autre system en un minimum de temps... Ceci dit se faire des Lib propriétaire, fiable, homogènes, relativement indépendant et stable, c'est long et ca demande d'avoir produit déjà beaucoup de code, et d'avoir de l'expérience. Ma première Lib de controle GUI m'a couté 6 mois (faut dire que j'apprenais Windows en même temps) , ma seconde ma couté qu'un mois, mais j'ai été obligé de passé à une version 2 parce que la première intégrait trop d'élément généraliste finalement chiants à manoeuvrer, donc long à mettre en place, et dont les conséquences n'était pas controlable à 100% . D'ailleurs quand vous faites une Lib qui est sencé vous servir longtemps, la difiiculté est de trouver un compromis entre ce qui doit être généralisé et ce qui ne doit pas l'être. Si vous ne trouvez pas ce compromis, vous perdrez un temps faramineux (si ce n'est pas à la conception de la lib, ca sera à l'utilisation et la maintenance...).
Actuellement, qu'est-ce qui selon vous le plus rapide/puissant ?
Tout dépend ce que l'on entend par rapide/puissant.
De manière général un développement rapide , fait avec des composant/Library puissant, permettra effectivement de développer une appli béton si et seulement si , le ou les développeurs connaissent parfaitement leur environnement de travail.
La problématique du développement commerciale ne réside pas seulement dans la fabrication du logiciel, mais surtout dans sa maintenance et dans la capacité à maitriser tous les détails du logiciel. Entre la version 0 et la version commercialisé, y'a beaucoup de modifications et de corrections. Et entre une version RC0 et une version qui a 2 ans , aussi. L'enjeux est alors de prévoir dès le début, dans une large mesure, l'ensemble des modif ou corrections que l'on pourrait vous demander (bref avoir une idée assez précise de l'univers des possible et du domaine de ce qui sera impossible). Et si votre code n'est pas maitrisé, alors ou vous ne serez pas en mesure de faire évoluer votre logiciel , ou bien cela vous coutera très cher en temps ou/et en argent. D'ailleurs sans même parler de langage, c'est l'organization de vos sources codes qui condittionne en premier la bonne tenu d'un développement.
Alors la mode actuelle, c'est quand même de mettre une souris dans une carcasse d'éléphant, Parce que certains crois qu'une organization "maximum scalable" (surtout en C++ où de plus en plus les programmeurs font une confusion entre objet et données - object au détriment de la données - Alors qu'un programmeur ancienne génération priviligiera la donnée au détriment du code) permet toutes les évolutions, c'est parfois vrai, mais ca coute hyper cher à maintenir et utiliser car cela complexifie l'ensemble et vous éloigne énormément de ce que j'appelle "la maitrise du code". Donc la aussi y'a un compromis à trouver.
A+ Vincent Burel
Cédric O.
Merci pour vos réponses Cyrille, HelloWorld et Patrick...
Etant un fan de .Net ,
Ah tiens, moi aussi depuis que j'ai lu le dernier Petzold :o)
Céd...
Merci pour vos réponses Cyrille, HelloWorld et Patrick...
Etant un fan de .Net ,
Ah tiens, moi aussi depuis que j'ai lu le dernier Petzold :o)
Merci pour vos réponses Cyrille, HelloWorld et Patrick...
Etant un fan de .Net ,
Ah tiens, moi aussi depuis que j'ai lu le dernier Petzold :o)
Céd...
Alexandre
> > Actuellement, qu'est-ce qui selon vous le plus rapide/puissant ?
Sous quel point de vue ? Pour développer ? Pour executer ? Pour planter ? Pour maintenir ?
VB est lent à executer, mais le développement va assez vite. Hélas, langage pas assez bas niveau pour certaines applis, pas assez robuste pour d'autres. C++ est un bon langage (si on s'en sert bien) car à la fois bas niveau (rapide à executer, possiblité d'écrire même un OS, un jeu ou un driver) que ce soit avec l'EDI VC++ ou l'EDI BCB. Java c'est bien, mais TRES lent à l'execution (machine virtuelle oblige), impossible à utiliser pour du bas niveau (machine virtuelle oblige) mais portable (machine virtuelle oblige) PHP, Perl, etc... sont très bien pour faire des scripts, des pages web dynamiques, etc... pas pour des jeux par exemple ;-)
A mon avis la solution la plus puissante du moment est: - C# pour l'IHM et les traitements classiques - C++ pour les traitements lourds si tu en as et l'interet de Microsoft .NET c'est que tu mixtes cela dans une seule application très simplement.
Et que ça tourne pas sous Mac (oops, désolé, ça m'a échappé)
Rémi Thomas - MVP Visual Studio .NET
Ah ouais, je comprends la pub .net ;-)
Développeur Windows indépendant http://www.xtware.com/cv
> > Actuellement, qu'est-ce qui selon vous le plus rapide/puissant ?
Sous quel point de vue ? Pour développer ? Pour executer ? Pour planter ?
Pour maintenir ?
VB est lent à executer, mais le développement va assez vite. Hélas, langage
pas assez bas niveau pour certaines applis, pas assez robuste pour d'autres.
C++ est un bon langage (si on s'en sert bien) car à la fois bas niveau
(rapide à executer, possiblité d'écrire même un OS, un jeu ou un driver) que
ce soit avec l'EDI VC++ ou l'EDI BCB.
Java c'est bien, mais TRES lent à l'execution (machine virtuelle oblige),
impossible à utiliser pour du bas niveau (machine virtuelle oblige) mais
portable (machine virtuelle oblige)
PHP, Perl, etc... sont très bien pour faire des scripts, des pages web
dynamiques, etc... pas pour des jeux par exemple ;-)
A mon avis la solution la plus puissante du moment est:
- C# pour l'IHM et les traitements classiques
- C++ pour les traitements lourds si tu en as
et l'interet de Microsoft .NET c'est que tu mixtes cela dans une seule
application très simplement.
Et que ça tourne pas sous Mac (oops, désolé, ça m'a échappé)
Rémi Thomas - MVP Visual Studio .NET
Ah ouais, je comprends la pub .net ;-)
Développeur Windows indépendant
http://www.xtware.com/cv
> > Actuellement, qu'est-ce qui selon vous le plus rapide/puissant ?
Sous quel point de vue ? Pour développer ? Pour executer ? Pour planter ? Pour maintenir ?
VB est lent à executer, mais le développement va assez vite. Hélas, langage pas assez bas niveau pour certaines applis, pas assez robuste pour d'autres. C++ est un bon langage (si on s'en sert bien) car à la fois bas niveau (rapide à executer, possiblité d'écrire même un OS, un jeu ou un driver) que ce soit avec l'EDI VC++ ou l'EDI BCB. Java c'est bien, mais TRES lent à l'execution (machine virtuelle oblige), impossible à utiliser pour du bas niveau (machine virtuelle oblige) mais portable (machine virtuelle oblige) PHP, Perl, etc... sont très bien pour faire des scripts, des pages web dynamiques, etc... pas pour des jeux par exemple ;-)
A mon avis la solution la plus puissante du moment est: - C# pour l'IHM et les traitements classiques - C++ pour les traitements lourds si tu en as et l'interet de Microsoft .NET c'est que tu mixtes cela dans une seule application très simplement.
Et que ça tourne pas sous Mac (oops, désolé, ça m'a échappé)
Rémi Thomas - MVP Visual Studio .NET
Ah ouais, je comprends la pub .net ;-)
Développeur Windows indépendant http://www.xtware.com/cv
Alexandre
"Spoofix" <spoofix[ENLEVEZ_CA]@free.fr> a écrit dans le message de news:bleknv$ge4$
Salut,
J'aurais voulu savoir comment sont créée les applications comme Visual Studio, Office, Nero, Photshop etc... quel langage ? Quels standards ?
Quels
bibliotheques ?
Statistiquement, C++ est utilisé dans 90% des cas. Les bibliothèques utilisées sont maison dans 80% des cas. D'abord pour éviter d'être "lié" avec un éditeur. Ensuite pour éviter les problèmes de maintenance (par ex, les MFC qui n'existent plus, la VCL remplacée petit à petit par CLX, etc...)
L'idéal étant d'utiliser un langage te permettant, avec un paradigme objet par ex, de définir facilement une couche d'abstraction entre l'appli et le système (ou aute) de manière à être sur de pouvoir maintenir sur du long terme.
Merci d'avance.... Clément.
"Spoofix" <spoofix[ENLEVEZ_CA]@free.fr> a écrit dans le message de
news:bleknv$ge4$1@demo2.univ-lyon1.fr...
Salut,
J'aurais voulu savoir comment sont créée les applications comme Visual
Studio, Office, Nero, Photshop etc... quel langage ? Quels standards ?
Quels
bibliotheques ?
Statistiquement, C++ est utilisé dans 90% des cas.
Les bibliothèques utilisées sont maison dans 80% des cas.
D'abord pour éviter d'être "lié" avec un éditeur.
Ensuite pour éviter les problèmes de maintenance (par ex, les MFC qui
n'existent plus, la VCL remplacée petit à petit par CLX, etc...)
L'idéal étant d'utiliser un langage te permettant, avec un paradigme objet
par ex, de définir facilement une couche d'abstraction entre l'appli et le
système (ou aute) de manière à être sur de pouvoir maintenir sur du long
terme.
"Spoofix" <spoofix[ENLEVEZ_CA]@free.fr> a écrit dans le message de news:bleknv$ge4$
Salut,
J'aurais voulu savoir comment sont créée les applications comme Visual Studio, Office, Nero, Photshop etc... quel langage ? Quels standards ?
Quels
bibliotheques ?
Statistiquement, C++ est utilisé dans 90% des cas. Les bibliothèques utilisées sont maison dans 80% des cas. D'abord pour éviter d'être "lié" avec un éditeur. Ensuite pour éviter les problèmes de maintenance (par ex, les MFC qui n'existent plus, la VCL remplacée petit à petit par CLX, etc...)
L'idéal étant d'utiliser un langage te permettant, avec un paradigme objet par ex, de définir facilement une couche d'abstraction entre l'appli et le système (ou aute) de manière à être sur de pouvoir maintenir sur du long terme.
Merci d'avance.... Clément.
JeanLuc Acèque
"Alexandre" a écrit dans le message news: 3f7dc6d6$0$28893$
Statistiquement, C++ est utilisé dans 90% des cas. Les bibliothèques utilisées sont maison dans 80% des cas. D'abord pour éviter d'être "lié" avec un éditeur. Ensuite pour éviter les problèmes de maintenance (par ex, les MFC qui n'existent plus, la VCL remplacée petit à petit par CLX, etc...)
Les MFC n'existent plus ????
"Alexandre" <alex.g@netcourrier.com> a écrit dans le message news:
3f7dc6d6$0$28893$626a54ce@news.free.fr...
Statistiquement, C++ est utilisé dans 90% des cas.
Les bibliothèques utilisées sont maison dans 80% des cas.
D'abord pour éviter d'être "lié" avec un éditeur.
Ensuite pour éviter les problèmes de maintenance (par ex, les MFC qui
n'existent plus, la VCL remplacée petit à petit par CLX, etc...)
"Alexandre" a écrit dans le message news: 3f7dc6d6$0$28893$
Statistiquement, C++ est utilisé dans 90% des cas. Les bibliothèques utilisées sont maison dans 80% des cas. D'abord pour éviter d'être "lié" avec un éditeur. Ensuite pour éviter les problèmes de maintenance (par ex, les MFC qui n'existent plus, la VCL remplacée petit à petit par CLX, etc...)
Les MFC n'existent plus ????
Cédric O.
> Les MFC n'existent plus ????
Elles existent encore indubitablement, il suffit de voir Visual Studio .net pour le constater. Mais elles vont certainement disparaître très vite au proffit des Windows Forms qui sont clairement "mieux faites". Disons qu'il a un peu anticipé (de quelques années).
> Les MFC n'existent plus ????
Elles existent encore indubitablement, il suffit de voir Visual Studio .net
pour le constater. Mais elles vont certainement disparaître très vite au
proffit des Windows Forms qui sont clairement "mieux faites". Disons qu'il a
un peu anticipé (de quelques années).
Elles existent encore indubitablement, il suffit de voir Visual Studio .net pour le constater. Mais elles vont certainement disparaître très vite au proffit des Windows Forms qui sont clairement "mieux faites". Disons qu'il a un peu anticipé (de quelques années).
