Salut à tous!
 
Je viens juste de me payer Visual Studio .NET, après des années d'expérience sours VC 4,5 et 6;  
Quelles sont vos opinions sur ce nouvel environment? Des remarques particulières?
 
Pour ma part, déjà des problèmes de compatibilité quand je compile des petits programmes: la boite de dialogue toute con, CFileDialog, marche parfaitement bien sous 98,NT4 quand je compile sous XP/2000/NT avec VS6, et ne marche pas quand je compile sous VS .NET... y'a bcp de truc comme ça? (les CString aussi, sont des templates maintenant, fini l'opérateur []).
 
Merci d'avances pour vos quelques remarques et advices.
     

Pkoi je sent que ça va dégénérer ce topic?

Je veux pas troller mais bon ...
 
VS .NET ca sent franchement mauvais ...
j'ai passé un mois a essayer de le faire compiler des trucs mais bidons de chez bidon : rezultat kedal ...
 
Bref en clair, Bilou essaye encore de nous fourguer une belle daube ...
 
Sans parler de la taille du dll du framework .NET que je suppute etre necessaire à l'execution des eventuelles applications compiler par cette chose ...
 
Désolé mais d/l un programme de 1Mo Ok, mais si c piour d/l un dll kivaavecekifai 38Mo ca va merci ... j'ai VB 6 qui en fait autant.
 
Bref, sauf indication contraire( boulot etc ...) ben VC 6 ca suffit large. Tant que rien n'e nous oblige a migrer vers le .NET, je reste la ou je suis ...
 

 
Pour ce qui est de la taille (avec MFC et C++), au contraire, je suis plutôt content, vu que les executables sont un poil plus petit qu'avec la version 6. Vu qu'il fallait toujours aussi distribué les DLL MFC avec la 6, pas toujours présente, il n'y a pas de grosse différence la dessus; pas forcemment besoin en tout cas d'installer la plateform .NET sur chaque machine devant executer un programme compilé avec .NET, heureusement.

.Net a une tres gros avantage quand meme : l'interroperabilite entre langages.  
Vu que tous les langages .Net donnent le meme code execute par le CLR on peut faire une dll dans le langage qui nous chante et la reutiliser dans un autre langage. Et ça je trouve ça franchement tres bien.
 
Sinon il est clair que pour bricoler directement avec les API c'est pas fait pour. Ca s'eloigne du materiel pour ce positionner au meme niveau que Java (c'est aussi lent au demarrage d'ailleurs). Par exemple en C# on ne peut pas gerer de port serie : pas implemente dans .Net en natif !!
 
Pour la distribution de soft, c'est sur que tant que .Net ne sera pas plus present sur les machine ça vaux pas le coup. Mais c'est comme Java il faut installer le runtime une fois c'est tout...

pour 'bidouiller' dessus, comme l'a tres bien dit je sais plus qui, depuis un mois, je dois dire que c franchement nul, ca pue meme ...

Sachant que l'on peut très bien à l'occasion, généré des executable classique en C++ ! Pas forcemment besoin de pondre un binaire .NET, mais pouvoir profiter des nouvelles fonctionalité des MFC, ATL etc peux déjà valoir le coup, non?

ca dépend de combien ca t'a couté  

Quand on fait du C++ oui... Sinon on est condamne au CLR.  
Et quand on trouve la syntaxe du C++ imbuvable (comme moi) bah on recherche autre chose

juste pour fixer l'etat d'esprit de crosoft :
 
Multiplateforme = ki marche sous tout les Window$
 
Le C# est une ersatz sans saveur de Java qui pompe comme un malade sur sa grande soeur.
 
Les extensions ATL/MFC/WTL du VS .NET ? Tu peux choper les meme pour VS 6 ... mais bon c avous de voir.

Le prix qu'il faut pour rester dans la course technologique... c'est à dire un peu trop pour le moment, et peut être pas grand chose suivant l'avenir...  

Trracer a écrit a écrit : Quand on fait du C++ oui... Sinon on est condamne au CLR.   Et quand on trouve la syntaxe du C++ imbuvable (comme moi) bah on recherche autre chose

 
Ben Java ou Delphi c bien aussi ...

 
Ahem ! Et ca sert a quoi une API alors si on peut pas s'en servir ?

J'ai dit utiliser *directement* une API...  Y'a une legere nuance tout de meme...

 
A faire des trucs pas portable? J'déconne

Bon, dans ce cas je repose ma question autrement, je ne voulais pas jouer avec les mots : Tu utilise comment une API ?  
 
Nan si je demande ca c'est simplement parce que pour moi API c'est un peu Application Programmer Interface, autrement dit les interfaces a utiliser "directement" pour acceder aux ressources de plus bas niveau. Alors je vois pas trop comment tu veux faire ?
 
Edit: Décidement, je comprendrais jamais rien aux smileys

Et encore, si tu a ecrit un programme en Win32, MFC, et que tu veux le faire tourner tel quel sous Solaris, HP UNIX... faut utiliser Mainwin, (www.mainsoft.com), c'est l'outil magique qui génère une appli native dont les performances sont tout à fait satisfaisante! Pas besoin d'être un pro de 2 plateformes (Windows et UNIX), pas besoin de trop se brider quand aux fonctionalités, pas besoin d'ecrire des tonnes de #ifdef __WIN32 ou #ifdef sunos ...
Portage d'une appli avec applications graphique complexe de Windows à UNIX en quelques jours... garantie!  
 
Y'a encore 3ans, on avait de grosses surprises une fois le programme compilé sous unix (bug, réactions différente de la GUI etc); maintenant ça marche nickel. presque MAGIQUE!

A, j'oubliais... ça supporte aussi Linux.
Et maintenant .NET ; .NET sous unix, j'en connais qui vont hurler!  

 
tu as des exemples de code qui compile pas?
 
j'avais cru comprendre que le compilateur
de VC7 est beaucoup amélioré par rapport à celui
de VC6.  
 
LeGreg

 
faut pas oublier que ms a concu ça dans le but d'anéantir java...
est-ce que ça va fonctionner?
 
je crois pas..., mais bon seul l'avenir nous le dira

 
Grrr, je sens que je vais être méchant là !!!
T'as pas dû l'essayer beaucoup le c# mon coco    
- J'adore les gens qui parlent d'un truc qu'ils ont regardé 2s -
 
Oui, c# c'est du java, mais du java en bien mieux. Ils ont rajouté des fonctionnalités intéressantes au niveau de l'approche Objet, des petits mots-clés qui t'obligent a bien faire attention a qui-hérite-de-quoi. T'as un garbage collector controllable (enfin ce que je controle me suffit), c'est plus rapide que java pour une application (évidemment ca toune que sur leur plateforme pour le moment).
La création d'interface est sans commune mesure avec ce que propose java. En java, si tu veux faire les choses proprement, tu dois le faire a la main et c'est long et ingrat pour un résultat des fois décevant, ou alors t'utilise JBuilder ou un truc dans le genre et t'as du code de porc !
 
Autre truc : tu peux aller taper du code assembleur en cas de besoin, utiliser du code écrit en VB, en C++ et en C, acces aux pointeurs si tu veux, quand tu veux, ou tu veux.
 
Tu peux facilement te lancer dans ce langage, y a des milliers de tutoriels partout, la MSDN est une fois de plus présente et bien utile.
Mais en plus, t'es pas obligé de l'utiliser pour les trucs simples, t'as un explorateur d'objet dans l'interface de VS.NET
 
Et puis l'environement VS.NET est excellent, j'adore l'interface que tu peux customiser comme tu veux. C'est bien plus sympa que la ligne de commande, enfin ca dépends des gouts.
 
Pour en revenir au sujet de départ, j'aime VS.NET, j'aime le c# et M$ pompe bien les choses et les améliore. J'ai compilé des tas de codes en Win32 écrits sous VS6 sans pb, du code MFC aussi (un peu moins), jamais de pb de compatibilité.
 
3 points noirs : le prix, et surtout une installation longue au gout douteux (quand elle plante, elle désinstalle ce qu'elle avait commencé a installé, c'est bien mais ca prend un temps fou), et enfin : le c# est décompilable (le java aussi).

Bill, pardonne le, il ne sait pas ce qu'il dit

moi je sais ce que je dis, et c nul

Tu parles de Mono ? C'est une très bonne idée, tout le monde a le droit d'avoir de la merde s'il le désire.

 
Groumph, compile pas chez moi

Bah moi j'utilise VC et MFC pour la boite ou je fais mon stage en ce moment et je commence à émettre de GROSSES réserves sur les MFC.
 
Récemment j'ai eu un bug qui m'a révélé le fonctionnement interne de la classe CArray (et de toutes celles qui en découlent). Alors j'ai analysé la fonction qui me posait problème (SetSize) et voici ce que j'ai trouvé :
 
Lorsque l'on demande d'agrandir le tableau avec SetSize en lui donnant en paramètre une taille supérieure à celle du tableau au moment où on effectue l'opération la fonction recopie ENTIEREMENT le tableau dans un autre plus grand et ensuite détruit l'ancien tableau. Alors maintenant j'ai une question :
 
Pourquoi recopier le tableau la où il suffit de l'agrandir ?
Imaginez le temps perdu avec un tableau de 1000 objets.
 
Pour preuve voici le bout de code disponible dans le fichier AFXTEMPL.H :
 

 
Bon là je n'ai mis que la partie intéressante du code, celle qui s'exécute quand on agrandit le tableau. Le reste est dispo dans le fichier précédemment cité. J'ai aussi viré quelques ASSERT.
 
Un temps fou est inutilement perdu sur le memcpy().
 
J'ai vérifié dans la STL la classe la plus équivalente possible. Dans la STL on fait les choses correctement : on agrandit le tableau sans en créer un nouveau.
 
Bon alors je me plante peut-être, y'a peut-être un truc que j'ai pas vu mais ça me semble horriblement mal codé.
 
Maintenant je vous explique comment j'ai découvert ça : j'avais des objets stockés dans un de ces tableaux. J'avais également certains pointeurs sur certains de ces objets, des pointeurs temporaires bien sûr mais de temps en temps des pointeurs kand même. Eh bien dans un cas précis, aprés avoir ajouté un élément dans le tableau je me suis aperçu que je me retrouvais avec des pointeurs qui pointaient n'importe où alors qu'ils n'auraient pas du être affectés. Pourquoi ? Parce que la fonction SetSize() appelée par la fonction Add() si nécessaire, recopie le tableau ailleurs là où elle ne devrait pas le faire. Ceci n'est absolument pas documenté dans la documentation des MFC (ce qui serait la moindre des choses parce qu'au début je croyais que le problème venait de mon prog et j'ai perdu un temps fou avec le débugger).
 
Alors moi je dis que étant donné que sans doute toutes les MFC sont programmées de cette manière (CArray::SetSize est quand même une fonction pillier des MFC) et que ENORMEMENT d'applications et meme une grande partie de Windows s'appuie directement dessus eh ben il doit y avoir un bon gaspillage de puissance de calcul grâce à Microsoft.
 
Merci Billou.
 
P.S.: Merci de m'indiquer où je me trompe si je me trompe.

Non, regarde le code de la méthode reserve de stl::vector.

Non, justement reserve n'est pas la fonction équivalente, car reserve permet de reallouer le tableau. L'équivalent de SetSize() c'est resize() fonction ainsi définie :

On voit clairement qu'on ne détruit pas le tableau mais seulement ce qui est nécessaire si on défini une taille inférieure et qu'on l'agrandit sinon.

ET voici la fonction insert() pour ceux qui voudraient la voir :

Regarde ce qu'il passe avec insert quand tu dépasses la capacité de ton vector.

Ceci :    

Mais pourquoi ?
Personne ne peut répondre ?
Quelle est la raison de cette perte gratuite de cycles ?

Pour la stl ca fait partie de la définition de vector

Un vecteur doit avoir une représentation mémoire contigue et donc quand on dépasse la capacité, on s'alloue un bloc plus gros et on recopie tout.  

Rah ben ok là je comprends mieux, mais CArray n'est pas un vector normalement...

oliv5 a écrit a écrit :     Grrr, je sens que je vais être méchant là !!! T'as pas dû l'essayer beaucoup le c# mon coco     - J'adore les gens qui parlent d'un truc qu'ils ont regardé 2s -   Oui, c# c'est du java, mais du java en bien mieux. Ils ont rajouté des fonctionnalités intéressantes au niveau de l'approche Objet, des petits mots-clés qui t'obligent a bien faire attention a qui-hérite-de-quoi. T'as un garbage collector controllable (enfin ce que je controle me suffit), c'est plus rapide que java pour une application (évidemment ca toune que sur leur plateforme pour le moment). La création d'interface est sans commune mesure avec ce que propose java. En java, si tu veux faire les choses proprement, tu dois le faire a la main et c'est long et ingrat pour un résultat des fois décevant, ou alors t'utilise JBuilder ou un truc dans le genre et t'as du code de porc !   Autre truc : tu peux aller taper du code assembleur en cas de besoin, utiliser du code écrit en VB, en C++ et en C, acces aux pointeurs si tu veux, quand tu veux, ou tu veux.   Tu peux facilement te lancer dans ce langage, y a des milliers de tutoriels partout, la MSDN est une fois de plus présente et bien utile. Mais en plus, t'es pas obligé de l'utiliser pour les trucs simples, t'as un explorateur d'objet dans l'interface de VS.NET   Et puis l'environement VS.NET est excellent, j'adore l'interface que tu peux customiser comme tu veux. C'est bien plus sympa que la ligne de commande, enfin ca dépends des gouts.   Pour en revenir au sujet de départ, j'aime VS.NET, j'aime le c# et M$ pompe bien les choses et les améliore. J'ai compilé des tas de codes en Win32 écrits sous VS6 sans pb, du code MFC aussi (un peu moins), jamais de pb de compatibilité.   3 points noirs : le prix, et surtout une installation longue au gout douteux (quand elle plante, elle désinstalle ce qu'elle avait commencé a installé, c'est bien mais ca prend un temps fou), et enfin : le c# est décompilable (le java aussi).

 
Suis plutôt d'accord avec toi! Mais il y a telement d'anti Microsoft qui ont perdu le sens des réalités... Oui il y a d'autre produits très bon aussi, oui il n'y a pas que Microsoft, mais bon, même si ce n'est pas parfait; Visual Studio 6 était quand même très bien pour développer vite de bonne applications robustes (la preuve, pour ma boite, dans le domaine ou nous sommes, nous n'avons pas le droit au moindre bug, car nous controlons la productions de grosses société... et ça marche très bien!)
Il y a encore bcp de programmeurs UNIX, à force de critiquer et de se bander les yeux, qui n'ont rien compris à la programmation moderne, à l'ecriture de code de grande qualité, et surtout, à la convivialité de leur soft, frein énorme pour le dévelopement de l'informatique pour tous (home ou business).

 
Au risque de dire une connerie, il me semble que la philosophie de java c'est de pouvoir fonctionnner sur n'importequelle machine sans avoir à effectuer le moindre recompilation. Hor y a aps plus pas portable que du code assembleur. Je vois donc pas en quoi c un avantage du C# sur java

 
Il a dit que s'était juste en cas de besoin: genre avec une directive de précompilation, si t'es sous x86, tu ponds des lignes assembleurs pour optimizer le code sur la version PC de ton soft. Même si il est vrai que de plus en plus, il devient très dur de faire de l'assembleur plus optimizé que celui généré par le compilo...Mais dans le cas du C#, comme il y a un interpréteur, ça peut être util dans certain cas très précis.

yung3001 a écrit a écrit :     Il a dit que s'était juste en cas de besoin: genre avec une directive de précompilation, si t'es sous x86, tu ponds des lignes assembleurs pour optimizer le code sur la version PC de ton soft. Même si il est vrai que de plus en plus, il devient très dur de faire de l'assembleur plus optimizé que celui généré par le compilo...Mais dans le cas du C#, comme il y a un interpréteur, ça peut être util dans certain cas très précis.

 
Je suis pas d'accord, si ça te permet de faire ça c la porte ouverte à plein de conneries.

 
Oui mais de ce cas la, arrête de conduir, tu peux faire plein de conneries avec ta voiture, supprime les prises de courant chez toi , tu peux mettre les doigts dedans, ne fait pas de sport c'est dangereux...
Si on se plaint des possibilités illimités d'un soft, y'a qu'a retourner sur Amstrad CPC, tu pouvais pas faire grand chose, et pas bcp de conneries avec le BASIC.  

yung3001 a écrit a écrit :     Oui mais de ce cas la, arrête de conduir, tu peux faire plein de conneries avec ta voiture, supprime les prises de courant chez toi , tu peux mettre les doigts dedans, ne fait pas de sport c'est dangereux... Si on se plaint des possibilités illimités d'un soft, y'a qu'a retourner sur Amstrad CPC, tu pouvais pas faire grand chose, et pas bcp de conneries avec le BASIC.

 
J'ai pas de bagnole et de toute manière vu comme les gens conduisent je suis pas pressé d'en avoir une.
Chez moi j'ai tellement peu de prises qu'elles sont toutes occupées donc pas de risques.
 
Et puis on va arréter de se prendre la tête sur un langage pouris. Je suis désolé mais quand on vois les réalisation précédentes de MS dans le domaine de la programation ça donne pas envie.
 
EDIT: Bon ok pour le pouris j'ai un poil exagéré, mais bon cette histoire d'intégratino de code assembleur dans un language interprété et à vocation multiplateforme (en tout cas pour ce que j'en ai entendu dire) ça me parrait être une faute conceptuelle.