Version imprimable
Hein ?Citation:
Envoyé par maa
Double hein ? tu lui reproches quoi à l'intellisens de Visual C# ?Citation:
Envoyé par maa
:koi: c'est possible aussi en C# et C++ ...Citation:
Envoyé par maa
Personnellement je n'en ai jamais eu besoin ...Citation:
Envoyé par maa
Pas par défaut en tout cas. Ou alors une option m'échappe ? Avec Resharper oui, mais ça ralentis pas mal.Citation:
c'est possible aussi en C# et C++ ...
Je l'ai toujours fait en C# et C++ avec VS2005 sans toucher à aucune option. Je lance un programme, je le met en pause, je modifie mon code et je le "resume" (comment on dit ça en français ? 8O:aie:) et là il applique les changements au code et continue l'exécution du programme ...
non tu n'as pas compris.
Je ne parle pas d'éditer du code à l'exécution mais du fait que Visual Studio souligne les erreurs au fur et à mesure que l'on écrit. Avec C#, il faut recompiler pour avoir la listes des erreurs.
Un des "avantages" de VB c'est les objets de l'assembly Microsoft.VisualBasic et le namespace My (Computer, Network, Mouse...). Mais je me demande bien pourquoi ils ont rendu ça spécifique à VB... rien n'empêche de référencer cet assembly dans un projet C# et d'utiliser ces objets !
Ah ? pas chez moi... la plupart des erreurs s'affichent au fur et à mesure.Citation:
Envoyé par maa
Ahhhhh
Et ça sert à quoi ? :aie:
Et puis oui en plus ... les erreurs qu'il montre VB de cette manière ce ne sont que les erreurs de syntaxes ? parce que si c'est le cas, Visual C# 2005 le fait aussi ...
non, toutes les erreurs que l'on obtiendrait si on compilait.Citation:
Et puis oui en plus ... les erreurs qu'il montre VB de cette manière ce ne sont que les erreurs de syntaxes ?
à gagner du temps. ;)Citation:
Et ça sert à quoi ?
Ouai bon en même temps dans un projet bien organisé la compilation ne prend que 5 secondes. Chaque langage a ces avantages et ces inconvéniants ...
Non là il faut avouer... c'est +1 pour VB (même si j'en suis pas un féru défenseur). Ca prend pas mal de temps si tu as un gros projet et que tu dois le compiler 3 ou 4 fois avant d'avoir corrigé toutes les erreurs.
Mais pire que tu t'en rend compte à la compilation que tout une parti de code est à revoir à cause d'une erreur de conception qui ne compile pas c'est un peu dômmage... il vaut bien mieux corriger l'erreur en temps réel.
J'attends avec impatience la sortie de Resharper pour VS 2008 pour combler ce manque. :P
En même temps choisir un langage pour une seule fonctionnalité ... et puis il y a toujours ReSharper comme tu dit, donc rien ne nous empèchera de rester dans notre C# :king:
VB.NET a hérité de l'expérience de ces prédécesseurs.
- Les paramètres optionnels
- La liaison tardive
- ParamArray
- Redim preserve
- ... et d'autres que j'oublie surement
Si VB6 n'était pas vraiment un langage très structuré, je pense que vb.net est devenu un langage qui mérite d'être pris en compte pour de grand projet.
Actuellement, nous sommes arrivés au point ou les développeurs sont d'accord pour dire que les langages s'equivalent, malgré quelques irreductibles qui considèrent que le langage qu'ils ont choisi est le meilleur.
Personnellement, je suis VBiste et j'ai une légère préférence pour VB :)
Juste pour en revenir aux paramètres optionnels, j'utilise une technique dans mon projet InfoBox qui permet d'avoir un pseudo comportement optionnel. Les paramètres obligatoires (le message) est un paramètre standard, tout le reste passe dans un params.
Le tout associé à une bonne documentation, et tout le monde est content. :D
Juste pour réagir à ce que tes arguments :
Peuvent être pratiques mais une surcharge de méthode utilisant une valeur par défaut est viable aussi. C'est dans ta liste, à mon avis, la fonctionnalité la plus intéressante.Citation:
Envoyé par Kelpan
Discutable, il y a des avantages et des inconvénients à ce concept.Citation:
Envoyé par Kelpan
params en C#Citation:
Envoyé par Kelpan
A t'on encore besoin de réallouer des array à l'heure des collections typées ?Citation:
Envoyé par Kelpan
Je ne le pense pas.
Ceci dit, je respecte ton point de vue et apprécie au plus haut point que pour une fois, quelqu'un à le courage de dire "je préfère VB.NET" plutôt que "VB.NET c'est mieux". :king:
En fait, je pense que VB.NET est plus ou moins équivalent à C#, à condition d'utiliser Option Strict On. Sinon c'est limite dangereux, il donne même pas un warning pour des trucs qui devraient être complètement interdits !
et pis d'abord, y'a pas un langage meilleurs qu'un autre ;)
Ca dépends de ce qu'on doit faire, de la taille du projet, et si on est à l'aise avec :bug:
Mais perso, je suis d'accord, j'adoooore C# :yaisse2:
Même si je trouve que le D est bien meilleurs 8-)
Heureusement que ce langage est toujours en cours de conception ... :roll:Citation:
Envoyé par TSalm
<troll incoming !>Citation:
Envoyé par Kelpan
-l'operateur d'[in][de]crementation.
Ha non ... =D
Plus serieusement, de toutes facons, pour les programmeurs .Net, la finalité est la meme, puisqu'on programme tous sur le meme langage in fine. De fait, je pense que VB.Net est un bon langage en soit (apres je n'aime pas du tout la syntaxe totalement illisible (subjectif inside)), et on peut faire au moins autant de chose qu'en C# (apres c'est le Fx qui va limiter de toutes facons).
Juste pour note, les late-binding implicites, je trouve plutot tres dangeureux qu'un vrai avantage.
Ce n'est pas le fait que la langage permette les liaisons tardives qui est dangereux, c'est l'utilisation que le développeur en fait.Citation:
Envoyé par SirJulio
Un développeur se doit d'être rigoureux et ne pas programmer n'importe comment.
Le fait de ne pas tester si le diviseur est égale à 0 avant d'effectuer une division est tout aussi dangereux. Pourtant C# ne t'oblige pas à le faire.
Le réel problème que je constate actuellement, c'est que beaucoup de monde se prétend développeur à partir du moment qu'il connait le langage. (qui deviennent de plus en plus accessible).
Combien de fois, ai-je vu quelqu'un poser un problème sur ce forum avec un source sans que mon cerveau se retourne tellement il y a de choses aberrantes ? ... pas beaucoup...
Franchement, je ne suis pas d'accord pour dire que c'est le langage qui doit s'adapter à ces "pseudo-développeurs".
Je reformule, dangeureux n'etait sans doute pas le bon terme.
Je trouve qu'il est risqué de masquer un appel tardif, surtout connaissant le surcout en performance que coute ce type d'appel. Je ne vois meme pas l'interet (a part l'aspect candy de la chose) d'autoriser ce genre d'appel. Ou comme on l'a vu dans ce thread, les problemes de conversions implicites de pointeurs managés (A& = B& passe à la compil mais plantera à l'execution).
Bref, comme tu dis la rigueur est importante, est dans ce cas quel est l'interet de cette option Strict desamorcable en VB (ce n'est pas un troll. y a t'il une raison historique ?).