Reprise du message précédent :
non mais franchement, fait un hello world en C#, look la taille en mémoire vive ...

Ouais, mais NON!!!!
heheheehehhehehe
Ce sujet Est un troll, dès le départ. Donc, on se lâche...
 
Un peu de sérieuxe siouplé... non je rigole bien sûr
 
Harko, heum... disons que oui, je me suis rendu compte de ça (et la lecture des source de Mono m'est d'un grand secours),  mais finalement, et je pense que tu en est bien conscient, un programme est toujours exécuté par le processeur. Tout language qui ne <<colle>> pas au language machine est lent (exercice: de combien plus lent? MuHaHa). J'était moi-même très entousiaste lorsque Java est sorti (un assembleur portable!!! ouwa!!). Mais force est de constater que le contrôle de la machine passe par le contrôle des instructions, des registres, des cycles machines, des transfert de bits au sein des divers bus d'un ordinateur -- même si... l'assembleur n'est plus aussi rigoureux qu'il l'était.
 
Pour reprendre un fameux dicton: point ne suffit de courrir, il faut partir à point. Autrement dit, lorsque l'on m'a présenté C# on a mis en avant: facilité (tient, j'y crois pas) et portabilité (tiens, ça va être lent). En réalité, la syntaxe ressemble à C++, elle est même plus simple, mais l'idée même de départ d'utiliser CIL (un language assembleur portable, pour résumer), d'utiliser un garbage collector, et de faire un environnement de programmation 99% dérivé du type <<object>> (donc avec Obligatoirement 1 pointeur [de trop]), me rebute car je vois clairement le résultat: des programmes plus lents et plus gourmands.
 
Personellement, je n'ai pas le choix pour l'instant, mais je préfèrerai coder tout en C++. Finalement, quand tu fait le total, coder en C# ça ne rapporte rien d'autre que de l'auto-insatisfaction. A chaque instant mon 3.4GHz se transforme P90. À la longue, c'est fatiguant.
 
D'un autre côté, je dois avouer qu'avant de maîtriser C++, qui te laisse tellement libre de ta manière de coder, il y a du bouleau. Mais lorsque tu as fait plié le dernier <<Segmentation Fault>> et que tu mesure les performances de ton programme, aussi bien au niveau du temps d'éxécution, de la mémoire utilisée, du nombre de requêtes simultanées, du temps de réponse, de la charge maximale, etc... tu as de quoi être fier. Et quand je compare, il me faut au moins autant de temps en C# pour arriver à un résultat optimum mais moins satisfaisant.
 
Bref, ne vous prenez pas la tête, codez en PHP !!! Au moins, c'est sûr que ce sera lent, et personne ne vous dira le contraire
 
En dehors de mes impressions, les faits présentés sont démontrables mathématiquement, et si C++ permet de faire des progrmmaes aussi lents qu'en C#, faire Un programme plus performant en C# qu'en C++ est physiquement impossible. Celà vaut aussi pour les languages procéduraux par rapports aux languages objets, et aux languages assembleurs par rapport aux languages procéduraux. Pas la peine de chercher plus loin: plus on peut maîtriser l'électronique d'un ordinateur, plus performants sont les programmes. La véritable question étant: Quel part de travail doit être idéalement faite par le programmeur ou la machine? Et à cette question aucun language n'est capable de répondre sans exécuter préalablement un programme.

performancesblahblah... consommations mémoire ahahaha.... performances§§§... CONSOMMATION §§§  MAIS PERFORMANCES BOURDEL §§§ /FOU/
 
 
 
J'crois que vous n'avez pas compris la finalité du C#.
Personnellement je suis en train d'apprendre le langage, et ce n'est pas pour ses performances. Pour ça, il y a le C, le C++ et, globalement, tous les langages compilés et sans VM.
 
L'avantage du Java, du C#, et d'autres langages dans ce goût-là, c'est que c'est un niveau au-dessus des langages compilés traditionnels, c'est-à-dire qu'on s'affranchit de la machine presque totalement pour se concentrer sur les fonctionnalités. Ca signifie que le programme est portable sans recompilation (pour ceux qui vont venir chouiner sur la portabilité de C# je leur demanderais de réfléchir à celle de Java il y a quelques années et donc stfu), et qu'on trouve en natif plein de fonctionnalités réseau, graphiques, etc, ce qui simplifie pas mal la tâche.
 
C# ne rend pas obsolète le C++. Et C++ n'enterre pas C#.
Pour la simple et bonne raison que ces langages ne jouent pas dans la même cours. Si je veux m'amuser à créer rapidement un bomberman en réseau pour m'éclater, je vais faire ça en Java ou en C#. Si je veux créer un petit programme pour me résoudre une équation mathématique complexe et qui demande un max de calculs, je vais faire ça en C++.
 
A partir de là, ce topic n'a pas lieu d'être. Soit on réfléchit au meilleur langage que l'on connait pour un projet dédié et on gagne sur les temps de développement et de maintenabilité, soit on s'enferme dans le talibanisme à coup de "C++ c'est plus performant §§§" ou "C# caÿ l'avenir §§§".
 
 

ah oui, on était vendredi;
 
Sinon +1 avec Elmoricq, c#(et son environnement) permettent enfin de se concentrer sur le programme en lui-même, et plus de sa configuration, de galères d'environnement, de compilation ... Ca fait tout bizarre la première fois, et on s'y fait très vite.

Salut !
 
ma question serai plus orenté vers les Pro : Et vous dans vos boites respective vous utilisez plus quoi ?
par ce que l'année prochaine (enfin septembre...) je commence mes écoles d'ingé pour essayer de savoir enfin bien programmer...   Donc j'ai regardé les offres d'emplois et je vois pas beaucoup d'offre pour des programeur C#. Est-ce que d'un point de vue professionel il serait intéressant de l'apprendre ?  Je vois que les programeur Java sont plutôt demandé mais pour C# c'est en train de venir ?
 
Merci
 
[edit] je vois que dotnet est pas mal demandé... vous utilisez aussi dans vos boite ? Parce que a priori mon école va nous enseigner C++ et Java. Donc serait-il intéressant que je regarde aussi ces autres languages ?

 
C# / C++ / MFC / Managed C++

Merci de ta réponce !
 
Et C# tu l'a appris comment ? autodidacte ?

en ce qui me concerne, c'est le cas

Dans l'ordre d'apparition et d'utilisation:
VB - CVI / C - C++ / MFC - C#
 
Le service débute sur C#.

C# = propriétaire donc non portable et rattaché à Microsoft !! pas à une norme ! Si grosoft, décide d'abandonner C#, tu vaux plus rien sur le marché et les migrations se font très vite.
C++ = normalisé ! universel (portable un minimum entre les OS) ! et performant ! pas de garbage collector ... et reprends un programme C éventuellement
 
Est-ce qu'on peut inclure du code C/C++ dans du code C# ?

C# a été normalisé ECMA et ISO-CEI respectivement en 2001 et 2003. Mono propose de ce fait une implémentation C# pour linux qui n'a rien à voir avec Microsoft.
 

... et c'est bien dommage ! quand à faire du C en C++, c'est une aberration
 

Oui (cf mon plugin winamp dans ma signature, à base de C++ et de C# mélangés). Tu peux aussi inclure du Pascal, de l'Eiffel, du Python, et tout un tas d'autres langages

Amonchakai> A mon avis, si tu "va apprendre à bien programmer", ce n'est pas un langage que tu apprendra, mais des façons de faire, de concevoir, etc. Quand on a les concepts, le langage ne pose normalement pas trop de probleme : on met certes plus de temps quand on débute, mais sachant que C# et C++ sont proches au niveau syntaxique (attention, je parles sans avoir jamais essayé C#, je ne me base que sur ce que j'en ai entendu), le passage de l'un à l'autre se fait, je pense (encore une fois je n'en ai aucune expérience) assez bien. Je ne sais pas si beaucoup de boites recrutent leurs programmeurs sur le critère de savoir s'ils maitrisent un langage en particulier sur le bout des doigts, ou de s'ils savent concevoir des programmes sans faire n'importe quoi, mais si moi j'avais à choisir je me baserais sur le second critère...

 
Le 1er critère est vérifiable sur le CV.
Le 2ème critère est invérifiable.
Les boîtes se basent donc sur le 1er critère  

J'aurais plutôt dit "la syntaxe de C# est très similaire à celle de Java" parce que les différences sont quand même assez importantes entre C# et C/C++ à commencer par les pointeurs et la gestion de la mémoire...
 

C'est normalement le cas quand on recrute un programmeur (qui par définition ne fait rien d'autre qu'écrire du code). Or la limite est floue entre le programmeur, le développeur et le concepteur. Pour ma part je me considère développeur car je m'occupe des phases intermédiaires du projet : analyse (assez rare), spécifications (moins rare déja), conception (commence à occuper une part importante de mon emploi), programmation/codage (bon je ne vais pas le cacher ; c'était mon occupation première pendant pas mal de temps), voir recette, déploiement et MCO (ça dépend du projet).
 

Ton critère de recrutement vise donc un concepteur voir un développeur.
 
Il est vrai que l'offre de recrutement n'est pas toujours explicite. On voit souvent des offres du type "Cherche développeur (terme générique) ayant une parfaite connaissance du langage Z (métier de programmeur donc) et achant se débrouiller avec UML (plutôt orienté conception / analyse) idéalement maîtrisant le SGBD X (métier base de données sans aller jusqu'à l'administration).
Si l'offre concerne un poste qui n'est pas pure informatique, il y aura aussi des critères de recrutement lié au métier (finances, logistique, administration, assurances...)

Exact. C'est l'implémentation de Microsoft de la CLR qui est propriétaire.
 

Justement! N'existe t-il pas un pattern garbage collector ou quelque chose approchant ? Par exemple, Symbian OS (écrit en C++ de manière plutôt élégante) implémente une gestion de la mémoire (qui nécessite quand même des appels explicites)...

Il y a des garbage collectors pour le C et le C++ (e.g., Boehm GC, qui est d'ailleurs le GC utilisé par l'implé Mono). Ils demandent de remplacer les appels à malloc/new par des appels aux macros/fonctions du GC.
 
Mais ça reste non standard, et un peu crassou, par rapport aux langages garbage collectés nativement (dont certains avec des GC impressionnants, genre les stratégies de garbage collection implémentées par le compilateur SML MLTon)

Ouais, enfin quoi qu'il en soit, je pense quand même que si on sait programmer en C++, en java, ou en C#, on doit être capable d'apprendre rapidement les autres langages du même genre. Après, c'est sûr que quelqu'un qui veut recruter pour un CDD de 2 mois va prendre quelqu'un qui maitrise déjà le langage voulu... Je suppose donc que le mieux, si on veut se garder toutes les portes ouvertes, c'est donc d'avoir au moins les bases dans plusieurs langages ^^ Et je vais m'arrêter là parce que ça sort quand même un peu du sujet de base qui est de savoir quel est le meilleur entre C++ et C#.
 
A ce sujet, j'imagine qu'ils ont chacun leurs points forts et leurs points faible, et qu'il faut donc choisir celui qui a ses points forts sur les points sensibles de ce qu'on veut faire avec. Par exemple, pour ce que j'en sais (et j'en sais peu), ce serais peut-être une mauvaise idée de faire du C# sur un système embarqué disposant de peu de mémoire. Par contre, j'imagine que ça ira très bien pour faire un logiciel de comptabilité sur PC.

Mouais. Ca dépend si tu veux coder dans le langage, avec les idiômes et les structures du langage, ou si tu veux coder en C++/java/C# avec une syntaxe différente (après tout, on peut coder en Fortran dans n'importe quel langage)
 
Et de toute façon, "les autres langages du même genre" ça reste relativement limité, après ça dépend si tu veux apprendre des langages qui peuvent t'enrichir pécunièrement (C, C++, Java et C# principalement, peut-être également PHP et VB, sans compter les DSLs comme SQL) ou des langages qui peuvent enrichir tes connaissances et ton horizon programmatique.

Perso, on m'a recruté il y a deux mois pour du C#. Mais les tests que j'ai passé étaient basés sur des conaissance algorithmiques, et sur un problème <<métier>> à résoudre en C#.
 
J'ai bien indiqué à mon employeur que j'avais juste préparé l'entretient en lisant des compilations sur le net sur le thème: commment passer de C++ à C#. Et il m'a fait comprendre que ça irai très bien.
 
Ce qui m'a fait avoir le poste était d'une part la façon dont j'ai résolu le problème: en analysant et comparant les performances de deux algorithmes et d'autre part le manque de postulants sérieux ou motivés.
 
Je programme principalement en C#, le C et le C++ étant autorisés à condition d'être interfacés en C#.
 
Ce qui motive le choix du C# est clairement: la portabilité Windows/Linux au niveau binaire, et la facilité d'utilisation et d'apprentissage du C# par rapport au C++.
 
Ce qui motive l'utilisation du C ou du C++: quand une machine plante après 2 semaines de calcul parcequ'elle n'a plus assez de mémoire.

Oui, en autodidacte pour les besoins d'une missions.

 
Ca se produit dans quel cas ?

> Ca se produit dans quel cas ?
 
La dernière fois que ça a planté gravement c'était à cause d'une liste d'urls dans une table de hachage qui a explosé la mémoire d'un crawler spécialisé. La Hashtable a depuis été remplacée par une JudyArray (énormément plus rapide et deux fois moins gourmande, je vous la recommande chaudement en place de hashs de string), mais la liste d'urls a été perdue. Le développeur qui avait codé le programme fait du C# depuis déjà plusieurs années, et crawle le net depuis 6 ans, alors moi qui suis débutant...

 
 
c'est pas interdit de déréférencer les objets quand on en a plus besoin au lieu de les laisser dans une liste à la con d'ou ils serviront jamais
 
 
(au gfait, il y a des weak references dans .NET ? )

 
 
clair, le nombre de fois où je vois des dataset non Disposé à la fin Alors qu'un simple using{} fait deja tout le boulot...

> c'est pas interdit de déréférencer les objets quand on en a plus besoin
- on en a besoin, la dernière alternative étant d'utiliser un cache disque.

Dans ce cas, le probleme se poserait aussi en C++, il va pas t'inventer de la memoire la ou t'en n'as plus. Un garbage collector integre t'empeche pas de reflechir a la gestion memoire de ton appli.

Des binaires, visiblement.
 

Pour l'instant, j'ai l'impression que la syntaxe retenue pour la norme C++0x n'est pas encore fixée. Visiblement les compilateurs expérimentaux conceptgcc évoluent avec les propositions de norme. Visiblement, on s'oriente vers un truc très inspiré de la syntaxe Indiana, mais qui reprend certaines idées issues d'autres propositions.
Plus de détails ici.
Parallèlement, je crois que Gabriel est en train de développer un autre conceptgcc basé sur la syntaxe Texas, mais ça n'a pas l'air encore aussi abouti que celui d'Indiana.

ouais, visiblement

 
+1
mais j ajouterais que C# c est avant tout un killer de Java (faut juste que la portabilité soit ameliorée)
 
Pour en revenir a nos moutons ...
C# est plus orienté productivité en entreprise que C++. Ca nous donne en effet 3 fois moins de code,  donc 3 fois moins de temps perdu, pour un programme un peu plus lent.
Donc si tu cherches pas les optimisations de la mort qui tue, choisis le C# sans hesitations.

plus lent, plus lent... tu perds peut etre 2 ms sur un gros traitement lourd de plusieurs heures...

 
Le seul truc qui pourrait rendre le C++ sexy, c'est un String...    
 
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 

D'après ce que j'ai pu lire des nouvelles générations d'outils de Micrsoft (XNA pour ne pas le citer), Microsoft compte bel et bien enterrer le C++ avec le C#, même dans ses domaines de prédilection.
 
XNA notamment, c'est un nouvelle environnement qui contiendra une couche d'abstraction pour DirectX, et est dnc dédié au développement de jeux (avec portage implicite sur XBox 360).
 
Dans toutes les docs, forums et autres sur le sujet, Microsoft met un point d'honneur à dire que tant qu'on ne fait pas du unmanaged, le C# est au moins aussi rapide que le C++, et surtout, grâce au GC qui interdit les fuites mémoires et autres conneries classiques du unmanaged. Grace à cet aspet, Microsoft tente même de démontrer que du coup on a de meilleures perfs avec du C# que du C++, dans la mesure ou on n'a pas besoin de se faire chier à contrôler la mémoire en permanance et autres joyeusetés.
 
Au final, je suis plus ou moins convaincu par leurs arguments. Pour un programme en C++ unmanaged écrit de façon "classique", le C# reste un concurent viable au niveau performances. Par contre, pour un truc méga optimisé, là oui, le C# sera à la rue. Cependant, la grande force aussi du C#, c'est d'être capable de faire appel à des libs externes, hors dans un programme il n'y a quelques zones qui sont réellement critiques d'un point de vue optimisation, qu'on peut donc parfaitement placer dans des modules externes.

En même temps si tu veux un langage garbage-collecté avec une syntaxe et des perfs proches de celles du C++, pas besoin du C#, le D existe depuis un moment

ca depend de ce que tu fais ... si tu utilises beaucoup de conteneurs de donnees (Vector, List, Stack ...) tu as meme des chances d avoir un gain de performance.
 
Une seule chose qui est tout de meme regretable en C#, avoir a declarer un type pour avoir acces aux pointeurs classiques (et encore ils sont pas vraiment classiques) et devoir compiler avec l option /unsafe. Ils sont gentils les gens de crosoft mais je prefere controler ce que j ai en memoire (donc mon code est forcement unsafe). Je cite la msdn pour info.
 

 
J en deduis que si l on utilise du code "safe" (sans pointeurs), c est crosoft qui garantie la securite.
On est vraiment mal barré

 
oh, un linuxien kikoololers

Doton le d'un windows dans ce cas.

Heu tu m'expliques? En quoi du code interprété et avec des vérifications pour voir si on sort d'un conteneur sera plus rapide ?

unsafe ça veut simplement dire que le GC ne peut pas vérifier la validité de tes pointeurs ou le fait que tout la mémoire allouée est bien désallouée, ça me semble parfaitement normal. En fait, le fait même d'autoriser de l'unsafe de cette manière montre une flexibilité notable de la part de MS, la pluspart des langages de haut niveau refusent totalement ce genre de compromissions, le seul moyen de manager de la mémoire manuellement étant de créer des modules compilés C/C++ et d'utiliser les passerelles des langages.
 
Et c'est tant mieux
 
Si tu aimes "contrôler ce que tu as en mémoire", je ne veux pas être méchant mais faut rester au C, au C++ ou à l'ASM, pas utiliser des langages modernes.

 
Je n ai rien contre le C# loin de la. Je m y suis mis d ailleurs avec pas mal d appréentions, mais au final je trouve ca plutot pas mal (mieux que Java en tout cas). Cependant ce qui m indigne c est que l on a de moins en moins acces aux couches de plus bas niveau et c est bien dommage (cette reaction est un peu normal pour quelqu un qui s est passionné pour le C systeme).

 
justement, c'est ce  qui est proifitable et qui fait que l'on est plus efficace en java/C# qu'en C++./ Fini de se tirailler la tête sur de la gestion de la mémoire, fini les arithmétiques d'alignement. Fini la quicaillerie.
 
De la même façon que lorsque les premiers langage de programmation sont arrivé, on a pu s'éloigner du comportmeent interne de la machine. Fini la quicaillerie.