Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #201
    Membre habitué
    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#.

  2. #202
    Membre à l'essai
    .Net Is magic

  3. #203
    Nouveau Candidat au Club
    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+

  4. #204
    Membre du Club
    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!!

  5. #205
    Rédacteur

    Citation Envoyé par Noodles

    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é .
    - MVP C#
    -Tout problème a une solution, le vrai problème est de trouver la solution .....
    - Linux & mono : l'avenir

  6. #206
    Expert confirmé
    Citation Envoyé par dev01
    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é...

  7. #207
    Rédacteur

    Citation Envoyé par neo.51

    quasi 2 ans de VB.NET
    Comme quoi, personne n'est parfait

    Citation Envoyé par neo.51
    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 )

  8. #208
    Expert confirmé
    ç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

  9. #209
    Rédacteur

    Citation Envoyé par neo.51
    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

  10. #210
    Nouveau Candidat au Club
    Pourquoi choisir
    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#.


  11. #211
    Membre du Club
    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# ?

  12. #212
    Membre du Club
    Citation Envoyé par crjo
    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...

  13. #213
    Membre régulier
    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...

  14. #214
    Membre du Club
    Citation Envoyé par 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!

  15. #215
    Membre à l'essai
    salam

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

    merci
    Amicalement Nawel

  16. #216
    Membre régulier
    Citation Envoyé par Noodles
    Citation Envoyé par 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#

  17. #217
    Membre du Club
    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

  18. #218
    Expert confirmé
    Citation Envoyé par Noodles

    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

  19. #219
    Membre du Club
    Citation Envoyé par neo.51

    ça en C# ça passe
    Bon ben dans ce cas là.... j'avoue que le vb.net a un petit train de retard...
    Citation Envoyé par neo.51

    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!

    Citation Envoyé par neo.51

    par contre en VB.NET ça va surement passer
    Effectivement...

  20. #220
    Membre actif
    Citation Envoyé par crjo
    • 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...

###raw>template_hook.ano_emploi###