Discussion :

[crjo]

salut à tous,

Après 5 ans d'expériences professionnelle en C/C++, j'ai découvert dotnet et j'ai été immédiatement séduit par C#.

C# est très propre, comparé à C++. Je vais pas me lancer dans l'enumération des avantages, mais je trouve que ceux ci sont vraiment un plus :

• pas de pointeurs. Le code n'en est que plus lisible (et si on veut vraiment utiliser des pointeurs pour des besoins de bas niveau ou que sais-je, on peut toujours écrire un petit bout en C++ non managé, si j'ai bien compris)
• un seul fichier source (plus besoin d'un fichier entête *.h). Si on doit modifier la signature d'une méthode, c'est immédiat. Ca simplifie la documentation également
• le garbage collector. Plus de memory leak (ou fuite mémoire) avec ça
• les concepts de délégué et d'événement. Les delegués (delegate) remplacent avantageusement les pointeurs de fonctions en C/C++.
• homogénéisation de la notion d'objet. Tout est objet. Même un entier ou une chaîne de caractère.
• meilleur typage. Il y a des erreurs qu'on pouvait faire en C++ qui ne passeront pas à la compilation en C#
• mécanisme d'assertion et d'erreur bien pensé. Si on accède hors du rang d'un tableau par exemple, on aura une belle erreur au run time qui explique que c'est un problème "out of range" et pas un satané "Violation access error 0x08830003" beaucoup moins explicite.

Bon, j'arrête ou je ne m'arrêterai plus

En tout cas, ça donne au final un développement super rapide et plus facile à maintenir.

Bon, maintenant, j'ai jamais travaillé sur un vaste projet dotnet. Certains disent "usine à gaz", peut-être, ch'sais pas, c'est pas le sujet de toute manière. Mais si c'est vrai, je ne pense pas que ce soit dû à la nature inhérente du langage C#.

[ousta]

.Net Is magic

[ATTOH Atsou]

J'ai beaucoup pratiqué Delphi et c'est un langage que j'ai apprécié à cause de la simplicité de la compréhension de sa structure et de l'extension objet qu'il offre. J'ai utilisé du C++ et java seulement à cause de leurs extensibilités avec les autes langage mais leur structure n'étant pas aussi facile à cerner par un débutant. pour ce qui du C# je l'ai appris pour les besoins professionnels et sa structure fait la synthèse de Delphi (par exemple using qui remplace uses...); Java dans l'utilisation des tableaux (même synthaxe)... C++ dans les structures de contrôle (if, do..while,for,switch..case..). Cependant c# à une stucture propre dans l'utilisation des tableaux( foreach) dans tous les cas le meilleur langage est celui que l'on maîtrise le mieux.
Pour ma par Je prefère C++ et Java à cause de leur portabilité si cela peux se réaliser avec C# alors est peut être meilleur.
A+

[Noodles]

J'ai beaucoup développé sous linux en C/C++ et Java.
J'ai été introduit à DotNet lors d'un stage pour mais études mais malheureusement (ou pas), on ne m'a pas laissé le choix du langage. Donc je programme en VB.NET.

Il est vrai que c'est un lagage laxiste et que la syntaxe est assez différente des autres langages mais je dois dire que programmer en VB.NET pendant 6 mois, quand je suis retourné en cours, j'étais incapable de pondre 2 lignes de codes en java....

Mais bon, avec un temps d'adaptation ca reviens.

Mais quand je fais des petits projets j'opte pour le VB.NET... Ca me détend!!

[dev01]

Mais quand je fais des petits projets j'opte pour le VB.NET... Ca me détend!!

Ben te dépend pas trop ... Le VB.Net c'est pour ... en fait je sais pas pour qui.
Mais si tu veux garder une syntaxe proche du java et du C tu n'as qu'a programmer en C# c'est bcp plus structuré .

[neo.51]

C# c'est bcp plus structuré .

T'aurais des ewemples concret où la syntaxe C# est plus structuré qu'en VB.NET ?

quasi 2 ans de VB.NET 1 an de C# mais je vois toujours pas en quoi le C# est beaucoup plus structuré...

[Thomas Lebrun]

quasi 2 ans de VB.NET

Comme quoi, personne n'est parfait

T'aurais des ewemples concret où la syntaxe C# est plus structuré qu'en VB.NET ?

L'Option Strict de VB.NET, qui n'existe pas en C# (et oui, en C#, on fait les choses bien du 1er coup )

[neo.51]

ça c'est juste un petit soucis de paramètrage par défaut pour que les personnes qui viennent de vb6 migrent en douceur

J'ai codé qu'un mois en strinf off

Si le seul agument valable en faveur de C# est une option de compilation par défaut il me parait évident que je vais me remettre au VB.NET avec l'apparition du mot My dans VB.NET 2.0

[Thomas Lebrun]

Si le seul agument valable en faveur de C# est une option de compilation par défaut il me parait évident que je vais me remettre au VB.NET avec l'apparition du mot My dans VB.NET 2.0

Bon, là je dois reconnaitre que ce serait bien pratique en C# aussi : remarque ca viendra p-e : il leur a fallu attendre la 2.0 pour intégrer "l'Edit & Continue" en C#, donc, pour la 3.0, on aura p-e le My en C# aussi

[linusgagnon]

Pour ma part je me demande pourquoi choisir??? Une des forces majeure de .NET est de permettre l'interactivité entre tout les codes inclus dans .NET.

Personnelement j'aime bien utiliser VB.net pour l'interfacage graphique et utiliser C# pour les traitements.

Finalement, venant de l'univers JAVA, j'ai trouvé beaucoup plus facile la conversion vers le c#.

[Nycos62]

Pour ma part, je ne connaissais pas le VB. J'étais bon en C++.
J'ai commencé par faire du VB.Net sans aucun problème. C'est un langage assez agréable une fois que l'on connait son fonctionnement, la prise en main de la bête à été très rapide (et franchement je trouve l'environement de développement microsoft génialissime).
Pour ce qui est du C#, je n'ai malheureusement eu que peu d'occasion de l'utiliser. Cependant en comparant des sources C# et VB.Net , j'ai eu l'impression que les deux langages se ressemblaient beaucoup. Je n'ai jamais été limité ou bloqué dans le travail de programmation alors pourquoi me pencher sur le C# ?

[Noodles]

C# est très propre, comparé à C++. Je vais pas me lancer dans l'enumération des avantages, mais je trouve que ceux ci sont vraiment un plus :

• pas de pointeurs. Le code n'en est que plus lisible (et si on veut vraiment utiliser des pointeurs pour des besoins de bas niveau ou que sais-je, on peut toujours écrire un petit bout en C++ non managé, si j'ai bien compris)
• un seul fichier source (plus besoin d'un fichier entête *.h). Si on doit modifier la signature d'une méthode, c'est immédiat. Ca simplifie la documentation également
• le garbage collector. Plus de memory leak (ou fuite mémoire) avec ça
• les concepts de délégué et d'événement. Les delegués (delegate) remplacent avantageusement les pointeurs de fonctions en C/C++.
• homogénéisation de la notion d'objet. Tout est objet. Même un entier ou une chaîne de caractère.
• meilleur typage. Il y a des erreurs qu'on pouvait faire en C++ qui ne passeront pas à la compilation en C#
• mécanisme d'assertion et d'erreur bien pensé. Si on accède hors du rang d'un tableau par exemple, on aura une belle erreur au run time qui explique que c'est un problème "out of range" et pas un satané "Violation access error 0x08830003" beaucoup moins explicite.

Effectivement, C# et C++... rien à voir!!

Mais d'un autre coté, Java avait déjà tous ces avantages avant .net...

[Pete]

Juste pour rajouter mon grain de sel... (tiens ça s'écrit comment un grain? grin? )
Entre VB.NET et C# : je choisi sans le C#.
J'ai travaillé sur C# puis sur VB et il est vrai que les 2 langages sont très proches et et que l'on passe très facilement de l'un à l'autre. Il suffit de changer les accolades par des mots et de d'enlever les ;

Mais les avantages du C#:
- Moins verbeux et donc plus lisible (et ça c'est important)
- En VB.NET il fait des cast chelou
- Approche complètement objet. Alors qu'en VB.NET outre les fonctions qui sont présentes pour conserver la "compatibilité" VB6, la gestion des handlers n'est pas top (Addhandler...)
- Dans le designer VS.NET, pour l'ASP.NET, les évènements des objets ne sont pas affichés dans la property grid qd on fait un projet VB.
- La gestion des Namespace n'est pas terrible non plus avec le fameux RootNamespace du projet qui peut prêter à confusion
- Je ne reparle pas de la doc XML
-Et puis je me répette masi c'est vraiment plus lisible le C#, ça c'est bien...

[Noodles]

- En VB.NET il fait des cast chelou

Ah?
Il fait des cast chelou que si tu lui dit de faire des cast chelou... ou si tu lui dis rien!

[naw]

salam

Et celui qui programmer avec delphi quesque je peu utiliser en .Net le C# ou vb.net

merci

[Pete]

- En VB.NET il fait des cast chelou

Ah?
Il fait des cast chelou que si tu lui dit de faire des cast chelou... ou si tu lui dis rien!

Le propre d'un bon compilo c'est de t'éviter de faire des erreurs, donc il ne doit pas t'autorise à faire des cast chelou.

Autre exemple, apparement tu peux compiler une méthode qui à une valeur de retour même si tu as oublié de mettre le "return ta_valeur" et dans ce cas il retourne "null". J'ai perdu 5 minutes à chercher un bug qui en fait était une erreur d'étourderie que le compilo aurais du me signaler directement. Et non, Mr VB a préféré me dire que tout allait bien. Tu peux me dire à quoi ça sert de compiler de code qui plante ?
A te faire perdre du temps. C'est tout. Sous un prétexte de te rendre la vie plus facile en te simplifiant des choses, VB te fait perdre ton temps. C'est surtout ça son gros défaut à mon avis.

naw : prends le C#, vraiment c'est mieux. Tu apprendras aussi facilement l'un que l'autre ce n'est pas le pb, quelque soit le langage que tu as fait avant. Sauf qu'en C# tu as une syntaxe que tu retouves ds bcp de langages donc c'est pratique de la connaitre et le C# est mieux que le VB. Regarde les stats d'utilisation d'ailleurs, les gens préfère C#

[Noodles]

Autre exemple, apparement tu peux compiler une méthode qui à une valeur de retour même si tu as oublié de mettre le "return ta_valeur" et dans ce cas il retourne "null".

Et puis je sais pas si c'est pareil en C#, mais en C j'avais souvent ce problème:
Tu fais une fonction comme ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
public Function toto(maVar as Int32) as Int32
 If (maVar = 1) Then
            Return 1
        Else
            Return 0
 End If
End Function

Et là, en C ca compilait pas parce que comme mes return sont dans le If, il croyait que je retournait rien. Or en l'occurence, je retourne toujours quelque chose....

Et en VB.net ca passe

Bon évidemment, faut pas trop être étourdi

[neo.51]

Tu fais une fonction comme ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
public Function toto(maVar as Int32) as Int32
 If (maVar = 1) Then
            Return 1
        Else
            Return 0
 End If
End Function

Et là, en C ca compilait pas parce que comme mes return sont dans le If, il croyait que je retournait rien. Or en l'occurence, je retourne toujours quelque chose....

Et en VB.net ca passe

Bon évidemment, faut pas trop être étourdi

ça en C# ça passe

Mais ça ça passe pas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
public Function toto(maVar as Int32) as Int32
 If (maVar = 1) Then
            Return 1
 End If
End Function

par contre en VB.NET ça va surement passer

[Noodles]

ça en C# ça passe

Bon ben dans ce cas là.... j'avoue que le vb.net a un petit train de retard...

Mais ça ça passe pas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
public Function toto(maVar as Int32) as Int32
 If (maVar = 1) Then
            Return 1
 End If
End Function

Heureusement!

par contre en VB.NET ça va surement passer

Effectivement...

[Causa Sui]

• le garbage collector. Plus de memory leak (ou fuite mémoire) avec ça
• homogénéisation de la notion d'objet. Tout est objet. Même un entier ou une chaîne de caractère.

Cela dit, je pense qu'il ne s'agit pas là forcément d'avantages. Dans le premier cas, je pense à tous ceux qui étaient habitués à gérer la déstruction de objets (et autres primitives), ce qui peut être avantage en mode de performances, risquent d'être dérouté de ne plus avoir ce controle.
Pour ce qui est du coté "objet pur", je trouve cela parfois un peu pénible, je pense notament au fonctions statiques des classes mathématiques qui auraient aussi bien pu être des fonctions globales, sans que cela n'entrave vraiment la logique; la POO n'est pas toujours justifiable à mon sens, et c'est ce que j'aimais en C++: programmer comme on veut: depuis le C++ qui resemble plus a du C, jusqu'a la POO.

Cela dit je pense que d'un certain coté, les partis-pris de C# ne sont pas réelement injustifiés (au contraire) ou pénalisant à long terme, c'est juste une question "d'aclimatation"

Et pour moi, C++ dans .net (en managé), c'est un peu une hérésie... On à le C#, alors je me demande pourquoi il n'est restent pas à VC++7 natif...