Une bonne nouvelle pour tous ceux qui aimerait s'initier aux joies de la programmation sous Windows, pour pas un rond:
 
Microsoft vient de mettre en ligne, sa nouvelle suite Visual Studio 2005, en version "Express", utilisable gratuitement pendant un an!!! (49€ après par module ; 1 module = ~1 language).
 
On trouve donc:
Visual Web Developer 2005 Express Edition    
Visual Basic 2005 Express Edition
Visual C# 2005 Express Edition
Visual C++ 2005 Express Edition
Visual J# 2005 Express Edition
 
Toutes les images ISO (ou IMG) des CDs se trouvent ICI.
 
Autre cerise sur le gateau, et pas des moindres, il est tout à fait permis de développer des applications commerciales avec ces produits!!! Et ça c'est vraiment nouveau, de la part de Microsoft (et ça va malheureusement surment faire très mal à la concurrence, ça c'est moins cool ; car jusqu'à maintenant, pour développer sous Windows avec les outils Microsoft, il fallait vraiment y mettre le prix; même les versions "étudiants" de Visual Studio étaient plus chères et pas moyen de sortir des version commerciales avec).
 
Pour ceux qui connaissaient Visual Studio 6, ou même la version 2002 et 2003; oubliez tout. Cette version offre vraiment de nouvelles possibilités, la framework .NET 2.0 est enfin très complète, l'éditeur est une pure merveille (plus besoins de plugins pour rajouter des fonctionalités)... Je bosse depuis plusieurs mois avec la version "Team Suite", et franchement, c'est assez terrible (alors que j'avais vraiment trouvé très bof bof les versions 2002 et 2003).
 
Bref, ça peut être un moyen intéressant d'entrer dans ce monde.
Tout s'installe très vite, sans soucis, MSDN (la documentation) est fournie avec en version "simplifiée" mais déjà bien suffisante... quand on connait déjà un peu la programmation.
Car sinon, comme toujours, MSDN reste une jolie doc bien obscure et pas toujours bien foutue. Rien ne vaut un bon bouquin pour démarrer.
 
Si certains veulent tenter le coup (y'a toujours des curieux pour ce genre de chose, non? ), je suis près à les aiders à démarrer un peu ici, dans ce topic.

Et avec Emacs, on ne peut pas faire tout ça ?

vie-aille powah

Mac-Patxaran a écrit :   Et avec Emacs, on ne peut pas faire tout ça ?

 
Du code refactoring, je suis pas sûr...

Oh super, j'vais pouvoir faire des virus et planter les machines de mes copains !!!

Vegastar a écrit :   Oh super, j'vais pouvoir faire des virus et planter les machines de mes copains !!!

 
Télécharge la version C++ alors (et programme en C++ pure, pas en managé .NET); parcequ'avec C#, je doute que tu fasses beaucoup de virus vraiment dangereux!  (quoi que... )

SpadVIII a écrit :   Télécharge la version C++ alors (et programme en C++ pure, pas en managé .NET); parcequ'avec C#, je doute que tu fasses beaucoup de virus vraiment dangereux!  (quoi que... )

 
Si tu veux, je te fais un programme en C, et je l'envoie par email.
Ca serait vraiment une sale coincidence si ton DD est mort.
 
Sans dec, même en VBS on tape des virus.
I love you était codé en VBS sans même avoir un GUI de développement.

Guixh a écrit :   Si tu veux, je te fais un programme en C, et je l'envoie par email. Ca serait vraiment une sale coincidence si ton DD est mort.   Sans dec, même en VBS on tape des virus. I love you était codé en VBS sans même avoir un GUI de développement.

 
Oui, tente le coup; si je suis pas loggé en admin, il risque pas de faire grand chose de mal à mon dur ton programme en C (quoi que... ... Ah merde, je l'ai déjà dit celle là).

SpadVIII a écrit :   Du code refactoring, je suis pas sûr...

 
Tiens v'là une petite définition de ton "code refactoring" :
 

 
GCC à produit les codes les plus optimisés que l'on ait pu rencontrer. Et donc ce code à dans la majorité des cas été pondu avec e-macs ou vi.

 
Il me semble difficile d'avoir une refactorisation aussi poussée sous e-macs qu'avec ce qu'il y a sous VS2005; tout simplement parceque la refactorisation sous VS2005 analyse le code des différents projets ouverts pour opérer ses modifications automatiquement (et de manière intélligente). Il faudrait donc qu'Emacs soit capable d'analyser de manière intrasèque le code qu'il édite. Si oui, comment tu fais???
 
Par exemple, si tu renommes une fonction d'une libraries, tous les projets ouverts utilisant cette fonction, vont voir l'appel à cette fonction renommé. Evidemment, sur une autre fonction à le même nom, mais n'est pas issue de la même librairie, elle ne va pas être renommé. Cela implique au moteur de refactoring de compiler le code pour reconnaître que l'appel de telle ou telle fonction correspond bien à celle que l'on veut renommer.  
 
De plus, GCC est certainement le compilateur C++ qui respecte le plus les normes de ce language; ce qui est une sacret qualité et surtout il tourne sur quasi toutes les plateformes. C'est donc un ami de choix quand on veut faire des applis portables en C++.
 
Par contre, en optimisation pure, sous Windows, le compilo de Visual génère du code encore plus performant (mais c'est l'inverse qui serait étonnant, non?).
 

SpadVIII a écrit :   Oui, tente le coup; si je suis pas loggé en admin, il risque pas de faire grand chose de mal à mon dur ton programme en C (quoi que... ... Ah merde, je l'ai déjà dit celle là).

 
Y'a plein de méthodes.
On peut forcer les CERTAINS droits admin temporairement en replacant des flags via quelques appels API (pas tous evidemment).
Il existe même des librairies (en C++ je crois) qui "s'occupent" du service "Emplacement protégé", et qui te permettent d'ajouter un utilisateur admin, et ce depuis une session non admin. <-
Etc, etc.
 
Vraiment je t'assure qu'il faut pas de droits admin pour bousiller une machine. :-)

Guixh a écrit :   Y'a plein de méthodes. On peut forcer les CERTAINS droits admin temporairement en replacant des flags via quelques appels API (pas tous evidemment). Il existe même des librairies (en C++ je crois) qui "s'occupent" du service "Emplacement protégé", et qui te permettent d'ajouter un utilisateur admin, et ce depuis une session non admin. <- Etc, etc.   Vraiment je t'assure qu'il faut pas de droits admin pour bousiller une machine. :-)

ça je n'ai jamais dit le contraire. Par contre, ce n'est pas forcemment à la porté de tout le monde... Sauf evidemment, si tu réutilise des libs existantes.

Borland C++ Editor ......

deux-sans-six a écrit :   Borland C++ Editor ......

 
Ok, je te propose de prendre la porte, même si c'est pas mon topic et qu'il fait très froid dehors...

deux-sans-six a écrit :   Borland C++ Editor ......

 
2 wagons de retards sur VS2005...
 
Surtout qu'il ne fait QUE du C++; alors il y avait bien l'éditeur C# de Borland; mais je crois qu'il n'est plus dispo (et ce n'était que pour .NET 1.0) donc sans plus aucun intérêt.

 
Ce que tu dis est vrai sur la répercution des changements de nom de fonction et la maintenance du programme mais sache qu'il y a des logiciel graphiques (gratuit) sous unix présentant exactement les même qualités de maintenance que VS mais utilisant gcc ou autres compilateur que l'on peut définir.  
 
Je rajouterai que la qualité d'un projet ne réside pas dans la perfection de son algorithme mais bien dans l'analyse préalable (cf Merise et UML pour la structuration du code et des outils permettant de maintenir les évolutions de cette analyse)
 
Par contre un point ou je ne suis, mais alors pas du tout d'accord, c'est dire que VS sort un code plus optimiser que gcc. Il est vrai que si l'on ne défini pas les options de compilation de façon cohérentes, on obtiendra pas le meilleur résultat. Mais il suffit de voir déjà que pour une ligne de code donné, gcc sortira une code qui en terme de taille n'aura aucun équivalent avec VS.
 
Je précise aussi que gcc permet de compiler autre chose que du C++

Sinon j'ai téléchargé la suite 2005 sur mon PC personel, ca a l'air plutot sympa.
 
La facilité avec lasquelle on peut créer une appli de base est carrément déconcertante, les composants sont edifiants de simplicité.
La grille de visialisation de données à l'air béton (avec les combos et tout)
 
Les liaisons ODBC, c'est une simple formalité avec la version 2005.
J'adore aussi les objets disponibles d'avance : 'background worker', nickel pour de l'asynchrone, les icones de notification toutes faites qu'il faut juste configurer. Quand on combine les deux on arrive à des trucs vraiment sympa.
 
J'aime bien aussi le système de panneaux pour grouper les controles, c'est très pratique pour les applications plutot visuelles.

 
Oui, mais là, je t'arrête tout de suite. La je parlais d'un outil simple, facile à installer. Tu peux faire la même chose sous UNIX (on peut tout faire avec UNIX), mais si il faut installer 36000 trucs pour obtenir le tout désirer (ce qui demande recherche, patience etc...) pour obtenir le même truc qu'en 2 clicks, il y a là déjà un petit problème. Même en étant un pro, on a autre chose à faire qu'à passer du tout à configurer ces outils et surtout, à chercher comment le faire.
 

 
Bien evidemment. C'est pour ça que tous les IDE modernes proposent de soutils intégrés de modélisation (basé souvent sous UML). VS2005 n'échappe pas à la règle. Mais  cela va au dela du sujet de ce topic, qui était plus déstinée à ceux qui veulent découvrir (ou re découvrir) un peu.
 

 
La taille peu importe. Je parlais de la vitesse d'exécution de 2 programmes identique, l'un compilé avec GCC, l'autre avec le compilo de Visual, et tout ça, surtout, sous Windows. Et ce n'est pas moi qui le dit, ce sont des benchs qui avaient été effectué il y a quelques années sur différents compilateurs.
GCC était très bon, mais pas le meilleurs. L'intérêt de GCC n'est pas là à mon sens (car si celui de Visual donne du code qui tourne très vite, son support de certaines spécifications du C++, comme les templates, sont catastrophiques et baclées... alors qu'avec GCC, pas de surprise, tout marche comme dans les livres! )
 

 
Bien possible!

Guixh a écrit :   Sinon j'ai téléchargé la suite 2005 sur mon PC personel, ca a l'air plutot sympa.   La facilité avec lasquelle on peut créer une appli de base est carrément déconcertante, les composants sont edifiants de simplicité. La grille de visialisation de données à l'air béton (avec les combos et tout)   Les liaisons ODBC, c'est une simple formalité avec la version 2005. J'adore aussi les objets disponibles d'avance : 'background worker', nickel pour de l'asynchrone, les icones de notification toutes faites qu'il faut juste configurer. Quand on combine les deux on arrive à des trucs vraiment sympa.   J'aime bien aussi le système de panneaux pour grouper les controles, c'est très pratique pour les applications plutot visuelles.

 
Et quand tu auras découverts, que tes customs contrôles (que tu auras fait en 3 cliques et 2 lignes de codes) s'intègrent automatiquement avec les autres, que tu peux les utiliser dans le module de design comme les autres sans rien avoir à faire, en éditant les même propriétés (ou de nouvelles que tu auras programmé), tu comprendras encore plus le fossé qui sépare cette version, d'un bon vieux VS6 par exemple.
 
Ce que tu devais faire en une heure avant (et avec pas mal de connaissance), tu le fais en 5mn maintenant, sans rien avoir lu dessus. C'est ça qui m'a vraiment bleuffé au début.  
 
Idem pour la FrameWork .NET 2.0; maintenant, c'est aussi complet que Java; y'a vraiment tout, c'est dingue. Je découvre chaque jour de nouvelles classes.  
Et surtout, il y a une vrai qualité conceptuelles dans ces classes, ainsi qu'une constance dans la logique; tout le contraire d'une lib C++ comme les MFCs, qui en plus d'être régulièrement discutable d'un point de vue "object", se permettait de montrer régulièrement des inconsistances notables dans la logique des classes exposées.
Bref, a force de critiquer Microsoft, ils s'améliorent!  Sans rire, ça n'a plus rien à voir avec le passé. (merci Java aussi...)

 
Mais j'ai déjà compris.
Clair que par rapport à mon VB6, y'a un enorme fossé.

Guixh a écrit :   Mais j'ai déjà compris. Clair que par rapport à mon VB6, y'a un enorme fossé.

 
La merde ultime. J'ai encore un petit projet que je dois maintenir dans ce language. L'exemple parfait de ce que Microsoft à fait de mauvais; dès que je clique sur l'îcone pour lancer cette saloperie, j'ai l'enervomètre qui grimpe en flèche!
 
Bon, je suis pas objectifs, parceque j'ai jamais pris la peine d'étudier VB (vraiment rien à foutre de cette vérue! ), mais bon, c'est quand même nulle. Sans parler de l'IDE qui est bien différente ce celle de VC++ 6; aucune unification.

 
Je parlais d'un outils unique à installer... GCC étant en natif dans le systèmes
 
De plus, lorsque tu te trouve dans un projet qui comporte plusieurs centaines de milliers de lignes de code... en étant pro, un conseil, c'est de passe beaucoup de temps à configurer ses outils qui permettront un gain de temps considérable par la suite. On programme pas à la volée quand on est pro.
 

 
Des outils de modélisation intégré au IDE, je les connais.. y'en a pas un qui respecte les normes UML. Si par contre tu parles d'outils tels que Power AMC permettant de modéliser absolument tout en partant des BDD, au classes, aux évènements et autres... alors je suis d'accord pour dire que l'analyse à une chance d'être correctes. Je rappelle quand même, avant de cloturer le HS, qu'on estime que pour des gros projets, avant de pondre la moindre ligne de code, on prévoit un stricte minimum de 6 mois d'analyse ... donc c'est pas la configuration d'outils prenant quelques heures qui va plomber ton travail
 

 
Y'a pas grand chose à rajouter de plus... de plus vu le nombdre d'appels système et de surcouche sur windows un code c tester sur une pateforme windwos n'est pas un indicatif cohérent comme test.
Si on veut un bench correcte, on écrit un programme en C ANSI parfaitement portable. on le compile et on le test sur plusieurs plateforme... et là fort à parier que tu n'auras plus du tout les mêmes résultat.

SpadVIII a écrit :   2 wagons de retards sur VS2005...   Surtout qu'il ne fait QUE du C++; alors il y avait bien l'éditeur C# de Borland; mais je crois qu'il n'est plus dispo (et ce n'était que pour .NET 1.0) donc sans plus aucun intérêt.

Mais euh, je sais, c'était parce que ça m'a fait penser à ça... Moi j'utilise parfois Visual Basic...
 

Crapahut a écrit :   Je parlais d'un outils unique à installer... GCC étant en natif dans le systèmes

 
Je suis d'accord avec toi sur tous les points que tu sites. Simplement, on ne se positionne pas au même niveau. Au niveau auquel est destiné ce topic, tu conviendras que toutes ces choses sont, comment dire, "superflues".
 
Et de plus, pour avoir pas mal bossé en petite boite, le meilleurs moyen de se couler, c'est justement de s'amuser à passer 6 mois avant de pondre la 1ère ligne de code. En eXtreme Programming (qui a fait ses preuves maintenant), non seulement tu commences à coder très vite, mais en plus, tu évites de passer trop de temps à écrire doc techniques complexes et schémas fastidieux. Mais ce n'est pas fait pour les grosses équipes et les très gros projets, c'est sur.
 
La meilleurs chose à dire, c'est que la meilleurs méthode et les meilleurs outils, sont ceux qui sont adpatés à tes besoins.
La pire chose est de vouloir suivre une méthode parcequ'on a l'a appris un jour dans un livre et que ça avait l'air bien... dans ce livre.
 
Et donc, pour quelqu'un qui veut faire un petit prog sous Windows, sans se prendre la tête, je pense que je peux dire sans risque de me tromper, que GCC & co, ce n'est pas forcemment la meilleurs méthode dans son cas!

deux-sans-six a écrit :   Mais euh, je sais, c'était parce que ça m'a fait penser à ça... Moi j'utilise parfois Visual Basic...

 
La vie est cruelle des fois, je sais...

SpadVIII a écrit :   Je suis d'accord avec toi sur tous les points que tu sites. Simplement, on ne se positionne pas au même niveau. Au niveau auquel est destiné ce topic, tu conviendras que toutes ces choses sont, comment dire, "superflues".   Et de plus, pour avoir pas mal bossé en petite boite, le meilleurs moyen de se couler, c'est justement de s'amuser à passer 6 mois avant de pondre la 1ère ligne de code. En eXtreme Programming (qui a fait ses preuves maintenant), non seulement tu commences à coder très vite, mais en plus, tu évites de passer trop de temps à écrire doc techniques complexes et schémas fastidieux. Mais ce n'est pas fait pour les grosses équipes et les très gros projets, c'est sur.   La meilleurs chose à dire, c'est que la meilleurs méthode et les meilleurs outils, sont ceux qui sont adpatés à tes besoins. La pire chose est de vouloir suivre une méthode parcequ'on a l'a appris un jour dans un livre et que ça avait l'air bien... dans ce livre.   Et donc, pour quelqu'un qui veut faire un petit prog sous Windows, sans se prendre la tête, je pense que je peux dire sans risque de me tromper, que GCC & co, ce n'est pas forcemment la meilleurs méthode dans son cas!

 
On est d'accord...  
 
Qu'ils fassent du VB alors ... pardon j'ai pas pu m'empêcher

SpadVIII a écrit :   La merde ultime. J'ai encore un petit projet que je dois maintenir dans ce language. L'exemple parfait de ce que Microsoft à fait de mauvais; dès que je clique sur l'îcone pour lancer cette saloperie, j'ai l'enervomètre qui grimpe en flèche!   Bon, je suis pas objectifs, parceque j'ai jamais pris la peine d'étudier VB (vraiment rien à foutre de cette vérue! ), mais bon, c'est quand même nulle. Sans parler de l'IDE qui est bien différente ce celle de VC++ 6; aucune unification.

 
Ne parles pas sans savoir
 
VB est un RAD dont l'utilite n'est pas du tout la meme c'est tout
Mais c'est loin d'etre une merde
 
 

Bloodymary a écrit :   Ne parles pas sans savoir   VB est un RAD dont l'utilite n'est pas du tout la meme c'est tout Mais c'est loin d'etre une merde

 
Je suis d'accord, c'est un bon outils... un ami qui est programmeur dans une boite de gestion de centre hospitalier est entrain (lui et ses collègues) de migrer une application en VB de + de 400 000 lignes de code en Java... et si ils le font c'est uniquement parce que Microsoft à prévu d'arrêter le support de VB... pas parce que l'outils est muavais

Mouais.
Je ne suis toujours pas d'accord. Il y a tellement mieux pour aussi simple.
D'accord il y a quelques années...
 
Aujourd'hui, un bon C# n'est pas plus complexe à appréhender, et offre tellement plus de possibilités...
 
VB6 s'était bien pour faire une appli graphique simple, en quelques clicks.
Dès que tu voulais faire un truc un peu plus complexe, merci et au revoir: Le support "object" est plus que limité (sympa l'abscence de polymorphisme quand tu veux faire une grosse appli un minimum structurée), gestion des threads inexistante ( ou alors faut passer par des contrôles ActiveX, super pratique) etc etc...
Je sais aussi, j'ai un collègue qui essaye de rendre plus "user friendly" une grosse applie de son cru, écrite en VB6. Une sacret galère... justement parcequ'il implémente des threads pour éviter le blocage de l'interface graphique à chaque opérations longue. Il s'amuse comme un fou et s'arrache les cheveux. Alors, que c'est si simple à faire avec un language moderne.
 
Maintenant, VB.NET, n'a de VB que le nom, c'est quasi identique au C# à part quelques détails. L'intérêt est d'ailleurs devenu limité à mon avis.

Crapahut a écrit :   Je suis d'accord, c'est un bon outils... un ami qui est programmeur dans une boite de gestion de centre hospitalier est entrain (lui et ses collègues) de migrer une application en VB de + de 400 000 lignes de code en Java... et si ils le font c'est uniquement parce que Microsoft à prévu d'arrêter le support de VB... pas parce que l'outils est muavais

L'outil est mauvais en lui meme.
 
Quand tu as ton IDE qui plante quand tu scroll, le debuggeur qui part en boucle au lancement, des crashs aléatoires, de la perte de complétion que tu sais meme pas d'ou ca vient, un gestion des dlls pourrie, des fuites de mémoire, tu peux pas dire que l'outil est bon.
 
VB ca va pour s'initier à la prog, histoire de faire ses premiers pas. Apres faut passer a autre chose. VB n'est pas concu pour des grosses applis, et encore moins pour des applis pro.  
 
Je suis pas non plus fan du principe .NET. C'est bien de vouloir faciliter la prog, mais tu t'enfonces immédiatement dans les méandres de classes microsoft. C'est comme les MFC, mais en plus accessible. Sur des gros projets, je suis persuadé qu'il reste plus efficace de développer soi meme ses classes effectuant les OP de bas niveau. Tu perds un peu de temps au debut à les ecrire, mais tu te fais pas chier à debugger par la suite des classes incompréhensibles.

 
Je ne suis pas d'accord pour dire que l’outil est mauvais. C'est trop réducteur.
 
Je suis d'accord avec toi pour dire qu'il y a des gros défauts au sein de l'IDE. Mais la gestion des DLL n'est pas plus pourrie qu'en MFC et C++ ... c'est tout aussi merdique dans ces deux derniers. Quand je vois l'intégration d'API comme l'ADSI en MFC, ce n'est pas mieux que la manipulation que l'on doit faire en VB.
 
Pour ce qui est des fuites mémoires, peut importe le langage utilisé, je me verrai mal commencer un gros projet sans implémenter un Garbage Collector plus sophistiqué.  
 
Je suis d'accord avec toi dans l'idée que tu défends et dans le cas d'un nouveau projet, je ne ferai jamais ce type de choix. Mais on ne peut pas dire que l’outil est mauvais. Ce qui fait qu'une application professionnel est viable ou pas en VB, c'est la qualité du travail effectué par les programmeurs. Malheureusement (et là je te rejoins) l'outil est très souvent pris très à la légère et offre donc une bonne excuse au gens pour travailler comme des gorets.  
 
Si je défend cette position (et presque à contre cœur ), c'est pour avoir vu une application médicale gérant à peu prêt tous ce que l'on peut imaginer (de la gestion des rapports médicaux, l'envoie de sms au médecin dans la gestion de rendez-vous, à la gestion des lits, des repas, des médicaments et j'en passe) faites en VB... avec (et là je souligne ce qui suit) quasiment aucun plantage.  
Une application fonctionnant dans 40% des hôpitaux en Wallonie, vendu 500k€ par centre hospitalier (un centre pouvant comprendre plusieurs hôpitaux) + 100k€ de maintenance par an (c.-à-d. amélioration des fonctionnalités suite au demande ressortant de conseil d'utilisateur).  
Bien entendu, 400 000 lignes de codes ne se pondent pas en 1 an ou deux. C'est un développement qui a plus de 10 ans. On ne peut donc pas critiquer les choix fait à l'époque fortement orienté par la formation de base du créateur de la société. Choix qu’ils n’auraient probablement pas fait de nos jours. Mais le résultat est là et très impressionnant.  
Le développement de leur société en étant également la preuve. (Effectif multiplié par 5 sur ces 5 dernières années).
 
Donc l’outil n'est pas foncièrement mauvais mais les programmeurs eux le sont dans la majorité des cas. C’est pour cela que j’apporte ce contre exemple en faisant remarquer que les centres hospitalier ne se contente pas de programme fonctionnant à moitié.
 
Je suis par contre parfaitement d’accord pour dire que ce n’est pas le choix le plus judicieux au vu des quelques contraintes auquel le langage en lui-même  nous expose. C’est un choix que je ne ferai pas non plus. Mais il y a moyen d’arriver à un travail de qualité même avec ce genre d’outils et pas exclusivement réservé à de petites applications.
 
Pour ce qui est du .NET… je suis parfaitement d’accord avec toi ainsi que pour l’idée de développer ses propres classes, cela rejoint d’ailleurs l’idée que je développais plus haut avec le Garbage Collector… quitte à faire ses propres classes pour les OP de bas niveau, gérons également soi même la gestion mémoire.

 
Pas du tout d'accord
 
L'outil est tres bon a la base
Simplement, comme il est facile d'acces, les bitos qui bossent dessus font n'importe quoi avec
 
Si tu l'utilises correctement il est aussi fiable que n'importe quel autre outil de dev
 
Les dll sont geres de la meme facon qu'en C / C++ donc je vois pas ou est le probleme
Et y'a pas de fuites memoire connues a part la string et ce dans un seul cas tres particulier et quasi innaccessible a part en passant par les pointeurs qui sont des fonctions cachees de VB
 
Faut juste savoir s'en servir correctement et ca devient un RAD particulierement efficace
 
 
Quant a .net, si tu bossais avec depuis un certain temps, tu serais surpris et changerais de point de vue a mon avis
C'est incomparable avec ces merdes de MFC et meme si j'etais plutot reticent au debut je dois reconnaitre que c'est pas mal du tout
Tu manipules en 10 minutes des objets que tu mettrais 3 mois a developper toi meme
 

 
Heu VB est un RAD hein pas un langage objet
Ne le compares pas a .net qui accessoirement a 10 ans de moins et est objet lui
 
Et quand je vois comme tu parles des threads sous VB, je vois que tu connais pas vraiment, evites donc de dire de trop grosses betises
 
 

SpadVIII a écrit :   Oui, mais là, je t'arrête tout de suite. La je parlais d'un outil simple, facile à installer. Tu peux faire la même chose sous UNIX (on peut tout faire avec UNIX), mais si il faut installer 36000 trucs pour obtenir le tout désirer (ce qui demande recherche, patience etc...) pour obtenir le même truc qu'en 2 clicks, il y a là déjà un petit problème. Même en étant un pro, on a autre chose à faire qu'à passer du tout à configurer ces outils et surtout, à chercher comment le faire.       Bien evidemment. C'est pour ça que tous les IDE modernes proposent de soutils intégrés de modélisation (basé souvent sous UML). VS2005 n'échappe pas à la règle. Mais  cela va au dela du sujet de ce topic, qui était plus déstinée à ceux qui veulent découvrir (ou re découvrir) un peu.       La taille peu importe. Je parlais de la vitesse d'exécution de 2 programmes identique, l'un compilé avec GCC, l'autre avec le compilo de Visual, et tout ça, surtout, sous Windows. Et ce n'est pas moi qui le dit, ce sont des benchs qui avaient été effectué il y a quelques années sur différents compilateurs. GCC était très bon, mais pas le meilleurs. L'intérêt de GCC n'est pas là à mon sens (car si celui de Visual donne du code qui tourne très vite, son support de certaines spécifications du C++, comme les templates, sont catastrophiques et baclées... alors qu'avec GCC, pas de surprise, tout marche comme dans les livres! )       Bien possible!

 
Il y a longtemps que tu as pas touché un Linux toi La gestion des paquetages et des dépendances a bien évolué
Un peu HS quand même ma remarque

Bloodymary a écrit :   Pas du tout d'accord   L'outil est tres bon a la base Simplement, comme il est facile d'acces, les bitos qui bossent dessus font n'importe quoi avec   Si tu l'utilises correctement il est aussi fiable que n'importe quel autre outil de dev   Les dll sont geres de la meme facon qu'en C / C++ donc je vois pas ou est le probleme Et y'a pas de fuites memoire connues a part la string et ce dans un seul cas tres particulier et quasi innaccessible a part en passant par les pointeurs qui sont des fonctions cachees de VB   Faut juste savoir s'en servir correctement et ca devient un RAD particulierement efficace

 
Comme il me résume ça lui... je me suis cassé le cul à mettre du lubifiant pour que ça passe mieux ... et il me ressort ça tout platement
 
Je rajouterai que concernant la mémoire, VB est nettement mieux concu que le C avec ses fonctions de merde de malloc, realloc et free qui font faire plein d'erreur au programmeur lambda et qui demande toujours de creer ses propres mécanismes de contrôles pour éviter les fuites.