Que choisir ? C# , VB.NET, C++, Delphi ? pourquoi ?

Version imprimable

Voir 40 message(s) de cette discussion en une page

15/11/2006, 10h12
bidou

Je vais rejoindre Maniak sur ce point. Même en étant expérimenté, ecrivez un code assez long sans l'option strict puis activez la. En toute rigueur vous devriez pouvoir dire exactement où ca va sauter avant l'activation. Et pourtant on est parfois surpris du résultat :oops:

Moi je ne suis pas spécialement fan des environnements coercitifs, mais je reconnais que j'utilise cette option puisqu'elle est un parfois un bon garde fou contre la bête faute d'attention. D'autant que dans VS2005, on peut régler l'utilisation des late bindings comme un simple warning quand on sait qu'on aura pas le choix.
15/11/2006, 14h24
Kelpan

Citation:

Envoyé par Maniak

Question subsidiaire : si tu pouvais bosser sur cette appli, mais depuis le début. Est-ce que tu choisirais de te reposer sur le late binding ou est-ce que tu ferais ton possible pour ne pas en avoir besoin ?

Je te dirais que cela dépend du type l'application.
En ce qui nous concerne, notre application doit pouvoir s'adapter aux besoins des clients et pas le client s'adapter à notre application.
Nous sommes dans le milieu de la gestion des ressources humaines et des salaires.
Nous avons une clientèle internationale est notre application doit s'adapter au mode de fonctionnement, de gestion du client et à la legislation du pays.

Pour nous, chaque nouveau client est un nouveau projet, avec ses spécificités à développer ou à adapter, sans que les spécificités des autres clients ne soient modifiées.
C'est pour cela que notre application est complexe.

Pour nous, la late binding (dans certain cas) permet de répondre rapidement aux client sans tout modifier dans l'application.
Donc oui, je pense que je choisirai de développer avec l'option strict à "OFF".
Par contre, je ne dis pas qu'une telle application ne peut être développé sans latebinding, mais cela impliquerai
- De revenir en permanence sur beaucoup de classes de base
- D'avoir le temps de la faire
- Mais aussi, d'engendrer de nouveaux bugs
- Et peut être d'autres problèmes auquel je ne pense pas...
17/11/2006, 11h39
Herwin78800

C# pour la majorité du developpement, et c++ pour des projets précis et limités

Je code en C# et c'est un vrai bonheur, même si je suis débutant, et je n'entrevois qu'à peine les possibilités de ce langage, et du framework .net en général.
Pour moi c'est C# dans la majorité des cas, et C++ dans des cas précis et restreints.

Mon appli du moment est un lecteur audio, écris en C# avec le framework .Net 2.0. Et ça me convient très bien.

Les seules restrictions sont :
- une certaine lenteur à l'exécution : 60 000 fichiers musicaux indexés dans un fichier xml, c'est lourd. Et le parcours de ce fichier pour afficher la bibliothèque multimedia met un certain temps en C# au démarrage de l'appli.
Un parcours de ce fichier en C, ou C++ serait sans doute plus raisonnable. L'autre solution étant d'utiliser une base de données.

- pour créer les effets visuels (courbe de gauss,...) en rapports avec la musique en cours de lecture, c'est sans doute techniquement possible avec C# et DirectX, mais je n'ai pas trouvé grand chose à ce sujet. C++ me semble donc plus approprié pour cette partie de mon projet
25/11/2006, 13h56
Thorna

Pour l'utilisation ludique, amateur et personnelle que j'en fais, Boo est très bien et correspond parfaitement à ce qu'il me faut: on ne se prend pas la tête avec des trucs trop compliqués et c'est un langage pythonesque qui sort un peu des classiques C & Co.
20/12/2006, 19h36
FRED.G

De quoi alimenter le débat ? :mouarf:
20/12/2006, 19h54
FremyCompany

Citation:

Envoyé par FRED.G

De quoi alimenter le débat ? :mouarf:

Pas d'accord... on compare du bon code C# avec du mauvais code VB...

Qui, je vous pose la question, fait des boucles FOR avec des Object = Interger ?? Personne !

C'est de la manipulation de l'information...

Qu'on me fasse une comparaison entre late-binding - reflection !
Ca c'est de la vrai comparaison...

Ici on compare late-binding - code typé !
C'est totalement injuste...
21/12/2006, 22h03
Maniak

Citation:

Envoyé par FremyCompany

Pas d'accord... on compare du bon code C# avec du mauvais code VB...

J'ai pas vu beaucoup de C# vs VB là-dedans.

Juste des conseils de perfs qui sont tout aussi applicables en C# qu'en VB.
07/04/2007, 04h22
Xzander

Le premier langage de prog que j'ai appris est le VB6. J'ai ensuite passé à VB.NET. Après quelques mois, j'ai essayé C# et je ne le regrette pas. Personnellement, je préfère } à End If. Je suis conscient que } n'est pas très instinctif, surtout au début, mais on s'y habitue rapidement. J'adore écrire en code ultra condensé alors C# me sert bien.
07/04/2007, 04h54
FRED.G

Moi j'ai commencé sans faire exprès avec VBA, puis comme ça m'a plu, je suis passé à VB.NET. Et là je fais découvrir la prog à mon petit frère avec C# directement.
Car C# est le langage privilégié par la communauté .NET pour les sources et autres tutos.
07/04/2007, 10h00
FremyCompany
Ce que tu dis est ridicule...
Un code fait en C# est portable sans problème en VB.NET (mais pas nécéssairement inversément car Optional n'existe pas en C#, etc)
==> VB .Net est plus riche et plus simple à comprendre.

Je ne dis pas que les langages en { ... } sont mauvais (je suis fan de programmation JavaScript, par exemple) mais C# permet moins de liberté au developpeur que VB .Net, et surtout du point de vue de l'usage COM...

Je t'en prie, fait moi un beau code qui utilise le WebBrowser en C#... Tu seras vite bloqué car l'API (faite en VB .Net) qui relie COM et .NET est limitée (pas de submit de formulaire, pas accès à la fonction eval de JS, ...), alors qu'en VB .Net je passe par l'Active X non typé et j'ai accès à toutes les possibilités offertes par IE.

On m'a bien fait le coup de yield return xxx; Alors pour clore cette polémique idiote, voici ma réponse :
Code:

1 2 3 4 5 6 Public Function UsingYield() as List(Of Integer) UsingYield = new List(Of Integer) For X as Integer = 0 to 10 UsingYield.Add(X) Next End Function
La deuxième chose est qu'on dit que VB .Net est plus propice à l'erreur, et je suis pas d'accord... Les erreurs faites en VB .Net à cause de sa lacheté ne sont pas causée par les developpeurs VB .Net eux-mêmes, mais par les développeurs qui connaissent C# et qui sont obligés de développés en VB .Net. Ils n'ont alors pas l'habitude de gérer VB comme il faut et font des fautes "de débutant".
07/04/2007, 11h51
FRED.G

Citation:

Envoyé par FremyCompany

Ce que tu dis est ridicule...

Oulà, pense à calmer tes ardeurs mon petit. Pas un seul de tes arguments ne contredit mon propos qui n'est que le constat d'un fait et surement pas un jugement de valeur ! Je ne vais pas me répéter, il tient en une seule phrase et tu es hors sujet.
07/04/2007, 12h23
Maniak

Citation:

Envoyé par FremyCompany

On m'a bien fait le coup de yield return xxx; Alors pour clore cette polémique idiote, voici ma réponse :
[snip]

Et c'est quoi au juste le rapport en ça et le yield de C# ?

Citation:

Envoyé par FremyCompany

La deuxième chose est qu'on dit que VB .Net est plus propice à l'erreur, et je suis pas d'accord... Les erreurs faites en VB .Net à cause de sa lacheté ne sont pas causée par les developpeurs VB .Net eux-mêmes, mais par les développeurs qui connaissent C# et qui sont obligés de développés en VB .Net. Ils n'ont alors pas l'habitude de gérer VB comme il faut et font des fautes "de débutant".

Bizarrement, les développeurs C# que j'ai vus qui doivent faire du VB.NET font du code bien plus propre/clair/solide que les développeurs VB.NET 'purs'. Tout bonnement parce qu'ils appliquent les règles d'un langage plus 'strict' et évitent du coup les problèmes liés aux fonctions surpuissantes de VB.NET telles que... la conservation de l'héritage de VB6 et... euh... bah c'est tout en fait. Et vu que l'héritage de VB6 est une abomination sans nom dont l'utilisation devrait donner envie de vomir...

Blablabla COM blablabla, oui ok, mais heureusement on peut faire une petite DLL en VB.NET pour faire un wrapper autour de ces appels COM, en exposant ensuite une interface typée bien propre, utilisée par le reste de l'appli en C#. Et c'est bien dommage que MS ne se soit pas fatigué à le faire. D'autant que comme ça on peut s'assurer que les ressources sont bien libérées comme il faut, à un seul endroit, contrairement à ce qui a tendance à être fait par des dévs VB qui éparpillent les appels et créations d'objets COM aux quatres coins de l'appli.

(et hop, le topic repart pour une nouvelle boucle :)
07/04/2007, 13h00
FremyCompany
1.

Citation:

Car C# est le langage privilégié par la communauté .NET pour les sources et autres tutos.

Ma réponse étant

Citation:

Un code fait en C# est portable sans problème en VB.NET

Je vois pas du tout le hors sujet...

2.
Ben ma fonction fait exactement comme le yield
A chaque itération j'ajoute un élément à une liste "virtuelle" qui est retournée à la fin de la fonction. C'est strictement pareil à un certain
Code:

1 2 3 4 public IEnumerable<Integer>() { Integer x = 0 for (x=0; x!=11; x++) { yield return x; } }
3.
Quelle est la différence entre l'héritage en VB .Net et celui en C#...
Je tiens à rappeler que VB .NET comme C# ==> IL; et que l'IL ne gère qu'un seul type d'héritage (ben ca alors, ils ont pas fait une exception pour VB ??? Ben zut un argument de moins pour le C# alors... bof on finira bien par trouver autre chose... Ah oui, les developpeurs VB .Net veulent pas avouer qu'ils sont moins bons que nous et qu'ils comprennent rien à la programmation alors que nous on a tout compris... Franchement, si c'est pas un manque d'ouverture évident ! Tout le monde sait que C# est mieux. D'ailleurs MS developpe en C#... Sources ? Oh ben j'en ai pas... Ah, c'est normal ? Hein ? IL... Mais non, ils développent pas en IL... Oh, ce developpeurs VB .Net... Comprennent pas qu'on peut developper qu'en C#... D'ailleurs on devrait dire à MS qu'il doivent arrêter de dev de VB .Net... Pis de J# aussi... Pis de JScript.Net aussi... Pis aussi du delphi, c'est beacoup trop verbeux et ca fait tout le temps des appels aux API... Pis aussi de...)

EDIT:
Prière de ne pas tenir compte de mon "petit" speech
- Il sert juste à "détendre" l'atmosphère (lol, ca vous a pas fait sourrir de lire ca ?)
- Il ne reflète pas du tout mon avis
07/04/2007, 13h05
FremyCompany

Ah encore un truc :
4.
Je me considère comme un developpeur VB .Net pur...
- pur : qui ne résulte d'aucun alliage
- réutiliser du VB 6 dans .Net = alliage != pur

5.
Jamais développé en VB 6
07/04/2007, 14h59
davcha

De toute façon, ici il n'est pas question d'avoir fait le choix C# parce que c'est mieux que VB.NET, il est question d'avoir fait le choix C# parce que c'est ce qui est le plus utilisé pour les sources/tutos de la communauté .NET

Alors, n'importe quel code fait en C# est peut-être portable sans problème en VB.NET, mais là n'est pas la question.
Un français qui veut apprendre l'allemand se base sur des traductions allemand/français, pas sur des traductions anglais/allemand.

C'est une question de facilité de compréhension et, donc, de gain de temps.
07/04/2007, 15h47
Maniak
Citation:
Envoyé par FremyCompany

2.
Ben ma fonction fait exactement comme le yield
A chaque itération j'ajoute un élément à une liste "virtuelle" qui est retournée à la fin de la fonction. C'est strictement pareil à un certain

Code:

1 2 3 4 public IEnumerable<Integer>() { Integer x = 0 for (x=0; x!=11; x++) { yield return x; } }
Moui. Résultat identique, fonctionnement différent. Et vu qu'utiliser yield pour faire une bête boucle est un peu idiot, je vois mal l'intérêt de faire des comparaisons sur une utilisation de ce genre :)

Maintenant... pourquoi pas une itération sur une collection dont les éléments doivent être initialisés à la volée, initialisation qui prend beaucoup de temps ? Si tu n'as pas besoin de parcourir l'ensemble de la collection, avec yield tu n'initialiseras que les éléments parcourus.
Plus tout ce qui nécessite un suivi du stade actuel de l'itération.

Alors bon, je ne suis pas spécialement fan de yield, mais c'est pas une raison pour laisser raconter que ça ne sert qu'à écrire une boucle différemment :)

Inversement, yield n'est pas non plus un gros argument pour proclamer C# supérieur à VB.NET. Les situations où ce mot-clef est utile ne sont quand même pas si nombreuses que ça.

Citation:

Envoyé par FremyCompany

(grmbl grmbl grmbl)

He be ? Tu craques déjà sous la pression ? :)

Ah tiens, j'avais fait trop vite la dernière fois :

Citation:

Envoyé par FremyCompany

Qui, je vous pose la question, fait des boucles FOR avec des Object = Interger ?? Personne !

Oh si, un paquet de gens, c'est bien le problème.

Citation:

Envoyé par FremyCompany

Ici on compare late-binding - code typé !
C'est totalement injuste...

Totalement. C'est aussi ce que se dit Caliméro ainsi que ceux qui ont dû se taper des reprises de projets faits en VB.NET en abusant du late-binding pour cause de fainéantise/incompétence des développeurs, en se demandant "mais bon sang, qui est l'idiot qui a décidé de laisser les gens faire ça avec ce foutu langage ?".

À la base ce n'est pas un problème de langage. C'est un problème de développeur.
07/04/2007, 16h31
FremyCompany

Citation:

Envoyé par Maniak

À la base ce n'est pas un problème de langage. C'est un problème de développeur.

Ouf tu me rassures là... J'ai cru un instant que tu pensais vraiment que VB .Net c'était mal (lol)

En fait, le vrai problème, je penses (à ce que j'en ai compris du moins), est que la majorité des développeurs qui se disent "VB .NET" viennent du VB 6 / VBA et on acquis de mauvaises habitudes de programmation, qui dans des macros MS-Excel passent totalement inapercues, mais qui vont très mal avec le developpement de grosses applications .NET...

Mais dans ce cas, il ne s'agit pas de "pur" développeur .NET, vu qu'ils ont migré depuis une plateforme différente en pensant pouvoir faire pareil de l'une à l'autre....
------------------------------------
De toute facon, je pense personnellement que si un developpeur .NET n'est capable que de développer sur un langage, c'est qu'il a une vision fermée ou partielle de .NET et ne peut l'utiliser correctement. Evidement pour les développeurs C#, c'est moins grave vu que VB .NET n'apporte pas d'avantages réels (exception faite de COM, My, quelques ajouts spécifiques à VB pour X-LINQ, ...) mais pour un developppeur VB, ne pas savoir développer (un minimum au moins) en C#, c'est montrer une certaine incapacité à se structurer et s'emmerder ==> s'ennuyer (passez moi l'expression) à typer un peu ses convertions avec des (Type) partout...

Vous savez le non-typage a vraiment son intérêt coté gain de temps... son utilisation à mauvais escient elle en fait perdre 3x plus... Tout est question de mesure : "La carrence, comme l'excès, est néfaste" ou "Un bon verre de vin par jour est bon pour la santé, 2 tollérables, 3 ennuyants, 4 dévastateurs"
07/04/2007, 19h26
Maniak

Citation:

Envoyé par FremyCompany

Ouf tu me rassures là... J'ai cru un instant que tu pensais vraiment que VB .Net c'était mal (lol)

Ben c'est mal. Ça a une syntaxe tellement lourde et inutile que ça en est douloureux à lire.

Maintenant, ça c'est un avis perso totalement subjectif et pas du tout à vocation d'alimenter un quelconque débat :)
(et qui ne m'empêche pas d'avoir aligné pas mal de lignes de code en VB.NET depuis 6 mois, SSIS oblige. j'aime pas, mais il y a un boulot à faire, et aussi nulle que soit la syntaxe du VB.NET, il permet quand même de faire ce boulot :)

Sur un plan plus détaché et orienté développement :

Citation:

Envoyé par FremyCompany

En fait, le vrai problème, je penses (à ce que j'en ai compris du moins), est que la majorité des développeurs qui se disent "VB .NET" viennent du VB 6 / VBA et on acquis de mauvaises habitudes de programmation, qui dans des macros MS-Excel passent totalement inapercues, mais qui vont très mal avec le developpement de grosses applications .NET...

Rien à redire là-desus :)

Citation:

Envoyé par FremyCompany

Mais dans ce cas, il ne s'agit pas de "pur" développeur .NET, vu qu'ils ont migré depuis une plateforme différente en pensant pouvoir faire pareil de l'une à l'autre....

Là je te suis moins. Il n'y a rien de "pur" dans tout ça. Si par "pur" tu veux parler de quelqu'un qui n'a fait que du .NET, ce n'est pas de la pureté, c'est une expérience limitée à une plate-forme (et sans aucune garantie de qualité). Si tu veux parler de quelqu'un qui peut s'adapter à une nouvelle plate-forme quand il en change, c'est juste normal.

Citation:

Envoyé par FremyCompany

mais pour un developppeur VB, ne pas savoir développer (un minimum au moins) en C#, c'est montrer une certaine incapacité à se structurer et s'emmerder ==> s'ennuyer (passez moi l'expression) à typer un peu ses convertions avec des (Type) partout...

Il y a rarement besoin de faire des casts partout (ça indique plutôt un problème de design quelque part), mais sur le principe on est d'accord :)

Citation:

Envoyé par FremyCompany

Vous savez le non-typage a vraiment son intérêt coté gain de temps...

C'est bien là-dessus que tout se joue : "côté gain de temps".
Évidemment que ça fait gagner du temps à court terme. Évidemment que les risques de problèmes sont réduits sur de petits projets. Mais sur quelque chose de 'gros', est-ce que ça vaut vraiment la peine de risquer de perdre 3x plus de temps après-coup (au moment où les pertes de temps augmentent généralement de façon exponentielle) pour en gagner un peu au début ?

(exception faite des langages non-typés de base et qui le gèrent bien. il y en a pas mal, mais VB.NET n'en fait pas partie puisque bâti sur un framework typé et compilé en MSIL tout aussi typé, avec les ambiguités que ça implique au passage d'un mode à l'autre)

Citation:

Envoyé par FremyCompany

"Un bon verre de vin par jour est bon pour la santé, 2 tollérables, 3 ennuyants, 4 dévastateurs"

Un verre de vin par jour est suffisant pour être alcoolique, 4 à intervalles irréguliers peuvent causer bien moins de dégâts :)

Pas évident de trouver des règles qui s'appliquent dans toutes les situations :)
07/04/2007, 23h10
FRED.G

Citation:

Envoyé par FremyCompany

Je vois pas du tout le hors sujet...

C'est bien de le reconnaitre !
Mais rassure-toi personne n'aurait pu croire que tu fassses un HS exprès. :calin:
Pour le reste davcha a bien répondu.
08/04/2007, 12h14
Kelpan

Citation:

Envoyé par Maniak

(et hop, le topic repart pour une nouvelle boucle :)

Oui, avec moins de maturité apparement...

Citation:

Les développeurs C# sont meilleurs que les développeurs vb.net

Pitié. Merci de nous épargner vos reflexions immatures...
Je pensais que la qualité d'un développeur ne s'appréciait pas selon le language.

De plus, vous donnez vraiment l'impression d'être à des années lumière de la réalité d'un projet. Tout cela manque visiblement d'expérience...
08/04/2007, 13h31
FremyCompany

Citation:

Envoyé par Kelpan

Oui, avec moins de maturité apparement...

Pitié. Merci de nous épargner vos reflexions immatures...
Je pensais que la qualité d'un développeur ne s'appréciait pas selon le language.

De plus, vous donnez vraiment l'impression d'être à des années lumière de la réalité d'un projet. Tout cela manque visiblement d'expérience...

Lol, faut pas prendre au mot ce que j'ai dit en "râlant" ;) C'était juste pour détendre l'atmosphère et montrer que les avis fermés avait peu d'intérêt (comme par hasard j'ai pris l'avis opposé au mien :))

Evidemment, je suis très loin de penser cela !
D'ailleurs si tu lis attentivements les posts suivants, tu verras que mon avis est tout à fait contraire à cette vision des choses...

Pour résumer ma pensée : Vouloir faire du VB6 avec VB .Net, c'est courrir le risque de perdre beacoups de temps par la suite mais faire du VB .Net "propre" est possible et même plus rapide que de C#. Je crois juste que la majorité des développeurs VB .Net viennent de VB 6 et que pour cela, il ne peuvent que difficilement apréhander (??? : désolé pour l'orthographe, je suis pas très bon... :() les notions propres à .NET

==> Imprécision VB 6 dans une macro == aucun danger
==> Imprécision VB .Net dans une application == danger !

Encore un petit truc avant de finir:
Je tiens à m'excuser de la manière dont j'introduis parfois mes idées... Je vois dans vos échos qu'elle vous semble un peu déplacée... Je m'en excuse profondément... Quand à mon immaturité, je crois qu'elle n'est qu'apparente, je suis capable d'une très grande maturité mais quand je m'énerve (par exemple quand j'ai l'impression qu'on s'en prend à un langage que j'aime bien, que ce soit VB .Net ou JavaScript, ou à mon avis en général, je le reconnais) il m'arrive de ne pas réfléchir avant de parler (comme Epiméthée quoi !) et de dire des conneries sans intérêt... Je voulais vraiment vous dire que de mes humbles 15 ans je m'en excuse profondément.
08/04/2007, 15h42
FremyCompany

Un excellent comparatif, extrêmement object entre C# et VB .NET
http://www.lacoude.com/docs/public/VBversusCsharp.aspx

Citation:

Each language has its inconveniences and its advantages. C# is not very well covered by the academic world even though getting technical training is easy. As a consequence, C# has a smaller community than VB.Net. However, C# programmers are likely to be highly trained technicians with abilities for self-education. Most of them will have some C++ background. Because Visual Basic has been around for a very long time under different forms, VB.Net has a very large community. That said, some Visual Basic programmers, when they come from the scripting world, will be more familiar with using objects than coding them.
08/04/2007, 16h38
davcha

Y'a de belles bétises dans ton papier quand même, Fremy.
08/04/2007, 16h46
FremyCompany

Citation:

Envoyé par davcha

Y'a de belles bétises dans ton papier quand même, Fremy.

Quel papier ? Quelles bétises ? Non mais j'aimerais savoir quand même... histoire de plus recommetre la faute...
08/04/2007, 17h02
davcha

Ce papier : http://www.lacoude.com/docs/public/VBversusCsharp.aspx.

Sinon, pour citer quelques bétises :
- l'absence du mot clef "final" en C#.... Ouais, effectivement, en C# c'est "sealed"...
- Fonction IsDBNull inexistente en C#, mais bon.. Comme y'a l'objet System.DBNull et effectivement Convert.IsDBNull ça n'a aucune importance.
- Le coup de la fonction overridée qui s'appelle elle-même. Très jolie d'ailleurs, ça nous démontre qu'une conception pourrie en C# ne fonctionne pas... comparaison très utile donc.
- Absence de AddressOf en C#, mais bon, on a les délégués, c'est pas fait pour les chiens.
- Absence de paramètres optionels en C#.... ce qui est en fait une bonne chose.

Euh....
* Je pensais que sealed c'était NotInheritable moi...
* VB .Net possède aussi les Délégués... Délégués != AdressOf
* En quoi les paramètres optionels sont ils mauvais ???
J'ai déjà vu des sources C# qui ressemblais à ca :
Code:

1 2 3 4 ... void f1(String s1, String s2, String s3) { /* ... */ } ... void f1(String s1, String s2) { f1(s1,s2,""); } ... void f1(String s1) { f1(s1, "", ""); } ... void f1() { f1("","",""); }
En VB on aurait eu :
Code:

1 2 3 ... Sub f1(Optional s1 as String = "", Optional s2 as String = "", Optional s3 as String = "") ' ... End Sub

08/04/2007, 18h12
davcha
sealed/NonInheritable, c'est pas la question, l'histoire est qu'il y a des erreurs dans ce papier, et c'en est une : "final" existe en C#, c'est juste qu'il a une autre dénomination.

AddressOf et les délégués, c'est sensiblement la même chose, dans la mesure où AddressOf ne fait rien d'autre que de créer un délégué.

Les paramètres optionels, ça peut réduire la lisibilité du code et mener à des bétises du genre :
Code:

1 2 3 4 Public Overloads Function foo(bar as long = 0, foobar as long = 0) End Function Public Overloads Function foo(bar as long = 0) End Function
Dans un tel cas, c'est joyeusement ambigü.

Citation:
Envoyé par FremyCompany
J'ai déjà vu des sources C# qui ressemblais à ca :
Code:

1 2 3 4 ... void f1(String s1, String s2, String s3) { /* ... */ } ... void f1(String s1, String s2) { f1(s1,s2,""); } ... void f1(String s1) { f1(s1, "", ""); } ... void f1() { f1("","",""); }
plus simple :
Code:

1 2 3 4 5 void f1(params String[] para) { }
arguments variables en nombres

08/04/2007, 20h59
FremyCompany
Citation:
Envoyé par The_badger_man

plus simple :

Code:

1 2 3 4 5 void f1(params String[] para) { }

arguments variables en nombres
Lol, c'était pour l'exemple, j'avais pas envie de taper des types différents ;)

Parfois c'est un object X, un object Y, un Integer, ...
08/04/2007, 23h17
The_badger_man

je me doute bien. C'était pour alimenter le débat :mouarf:
31/05/2007, 00h07
LLB
Citation:

- Absence de paramètres optionels en C#.... ce qui est en fait une bonne chose.

Bien utilisée, c'est une fonctionnalité qui peut être vraiment pratique.

Citation:

Les paramètres optionels, ça peut réduire la lisibilité du code

Comme toute fonctionnalité : mal utilisée, c'est moche.
Code:

1 2 3 4 Public Overloads Function foo(bar as long = 0, foobar as long = 0) End Function Public Overloads Function foo(bar as long = 0) End Function
Tu peux considérer que le problème vient de programmeur (mais je comprends que ça puisse arriver involontairement). Tu peux aussi, et surtout, considérer que le problème vient de l'implémentation de cette fonctionnalité. Le compilateur devrait détecter l'ambigüité (je suis étonné que VB ne le fasse pas). Surtout que ça ne devrait pas être compliqué à faire.

Mais pour moi, ce n'est pas un problème dû à la fonctionnalité. Car tu pourrais tout aussi bien reprocher au langage d'autoriser la surcharge, précisément pour la même raison. Il existe d'ailleurs des langages qui possèdent les arguments optionnels, mais pas la surcharge (OCaml...).

Code:

void f1(params String[] para)

Non. Ce n'est vraiment pas pareil. D'une part, c'est moche de créer un tableau pour ça. Et surtout, c'est dangereux. La taille du tableau ne faisant pas partie du type, le compilateur ne peut pas vérifier que l'appel est correct. Je serais triste si une fonction d'une bibliothèque plante à l'exécution, juste parce que j'ai mis un argument de trop !

Et sinon, pour répondre à la question de départ, j'ai choisi F#. La puissance de la programmation fonctionnelle, la concision des langages dynamiques, la sûreté des langages à typage très fort, tout ça combiné aux avantages de .NET. Dommage qu'il ne soit pas proposé dans le sondage (et j'ai l'impression d'être le seul développeur F# de tout le forum).
31/05/2007, 13h53
Astartee

Je viens de voter... et j'ai choisi le C#. Mais pourquoi ?

- C# / VB : uniquement pour la syntaxe, car je n'ai aucune idée des autres différences qui peuvent exister !
Le C# a le même type de syntaxe que le C++ et le Java, langages déjà bien établis dans le domaine de la programmation objet, tandis qu'il me semble que le VB est moins courant (pas taper, je dis ça comme une impression personnelle, et parce que j'ai déjà vu dans mon école des cours de Java et de C++ (et de C et de Matlab et autres "langages" plus ou moins bizarres...) mais jamais de VB)

- C# / C++ : parce que le C# a été conçu spécialement pour .NET, contrairement au C++...

- C# / Delphi : euh... j'avoue... je ne connais pas du tout Delphi :p
01/06/2007, 17h34
FremyCompany

Effictivement, seul VB a une syntaxe VB ;)

Delphi s'en rapproche un petit peu, sans que cela soit comparable
02/06/2007, 06h21
abelman

1 pièce(s) jointe(s)
Citation:
Envoyé par davcha

Les paramètres optionels, ça peut réduire la lisibilité du code et mener à des bétises du genre :

Code:

1 2 3 4 Public Overloads Function foo(bar as long = 0, foobar as long = 0) End Function Public Overloads Function foo(bar as long = 0) End Function

Dans un tel cas, c'est joyeusement ambigü.
Avant d'affirmer ce genre de chose, prenez la peine de tester svp!!
D'abord la syntaxe vb n'est pas bonne, et le compilateur VB détecte bien ce genre d'erreur (que l'on mette overloads ou pas)
Voir fichier image joint

En ce qui me concerne je trouve ça utile

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
 
' Exemple de fonction avec une dizaine de paramètres
Function MaFonction( _
    Optional Byval Str_Param1 As String = "", _
    Optional Byval Str_Param2 As String = "", _
    Optional Byval Str_Param3 As String = "", _
    Optional Byval Str_Param4 As String = "", _
    Optional Byval Str_Param5 As String = "", _
    Optional Byval Str_Param6 As String = "", _
    Optional Byval Str_Param7 As String = "", _
    Optional Byval Str_Param8 As String = "", _
    Optional Byval Str_Param9 As String = "" _
   )  As Integer
 
End Function
 
Public Sub Test()
    ' J'appel ma fonction avec les paramètres qui m'interessent ....
    ' ex : param2 et param8
    Int_Result1 = MaFonction(Str_Param2:= "P2", Str_Param8:= "P8")
End Sub

20/08/2007, 17h47
Polack77

Salut

:D Bonjour :D
Je viens de lire une partie de ce Topic (oui, une partie seulement :oops:, en faite ça commence à faire long quand même)

Ce que j'en comprends :
Le C# est équivalent au VB.NET du point de vue des performances (durée d'exécution, occupation mémoire,...) et seul reste la différence de syntaxe.
Donc il faut choisir le langage avec le quel on est le plus alaise.

A moins que je ne raconte des grosses conneries???
21/08/2007, 00h41
Maniak

Citation:

Envoyé par Polack77

A moins que je ne raconte des grosses conneries???

Il y en a de belles dans ce topic, mais pas vraiment dans ton post :)
Il ne rentre juste pas dans les détails hors-syntaxe qui peuvent faire préférer un langage à l'autre, et c'est pas forcément plus mal.
(bon ok, qui peuvent faire préférer C# à VB.NET vu qu'il est quand même nettement mieux. NA :)
30/11/2007, 17h14
npuzin

A voté :

C++ : rarement justifié
Delphi : bientôt au musée des langages de programmation
C# ou VB : peu importe

Mais j'ai voté C# quand même car je préfére sa syntaxe.

Bon développements .NET
06/05/2008, 00h56
osma_1978

mois j'ai voté C# , je viens de démarrer avec .Net,
Bon J'ai choisis C# parce que je suis un programmeur Delphi, et je voudrez migrer vers les produits microsot ,
Bon il y a bouceaup de cause : Politique , géographique,Emploi, Technique,...
17/05/2008, 16h07
Developpeur87

je vote pour C#

moi j'ai voter pour C# méme si j connais VB.NET plus que C# (mais j suis entrain d'apprendre et de m'approfondir dans C#) et j l'ai choisi parce qu'il est multi plateforme (on m'avait dit que VB n'est pa multiplateforme) et il a le syntaxe proche de ce lui de java que j métrise déja

Voir 40 message(s) de cette discussion en une page