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
Choix de langage C++ ou C#
Bonjour a tous,
je suis développeur en Pascal depuis près de 30 ans (de Turbo pascal à Delphi 2007), mais pour développer mes applis Iphone, il va me falloir passer au SDK Apple et Objective-C
Il va donc falloir me résoudre à faire du C (argh quelle horreur) et du coup que faire : C++ ou C# ? Je dois avouer que .net ne m'arrange pas du tout car c'est un truc microsoft.
Donc question aux pros : il vaut mieux choisir quoi avec l'optique de Obective-C et développer sur PC...
Merci à tous
Bonjour,
Si je ne dis pas de bêtises, seule une poignée de langages sont supportés par IOS (en tout cas depuis la version 4). Il ma paraitrait surprenant que C# en fasse partie...
Je pense qu'il serait plus intéressent de s'orienter vers le c++ (mais pourquoi pas directement l'objectiv-C ?)
Rq: après vérification, Novell a fait un portage de Mono pour IOS, mais il a l'air payant...
Merci.
Pourquoi pas directement Objective-C ? Parce que je vais aussi peut être développer au taf sur PC...
Je crois malheureusement qu'Apple a tout fait pour que l'on passe par IoS et xcode pour réussir à faire quelque chose.
Il doit exister des manip' pour passer outre, mais j'ai peur que ce soit un peu bidouille...
oui la dessus le debat est simple et rapide : point de salut sans Xcode et Objective C...
Du coup, renseignemetns pris sur Internet (je sais j'aurais du commencer par ça) vu que le C# est orienté vers .NET, faudrait plutôt que j'apprenne C++.
pour la partie PC je ne vois pas du tout le rapport avec le fait qu'il te faille appendre et utiliser Objective-C pour les appli iPhone.
C# même s'il est d'origine Microsoft et tourne sur la plateforme dotnet, te paraitra plus naturel que C++ qui est à mille lieu de ce que tu connais et à l'habitude de voir...
et de toute façon il te faudra toujours apprendre Objective-C qui lui non plus n'a strictement rien à voir avec C++.
il faut savoir que C# est inspiré de Delphi, auquel on a appliqué une syntaxe orientée C que l'on a au passage pas mal étendue.
passer d'un environnement à l'autre n'est pas très dépaysant, syntaxe mise à part... tu va y retrouver les propriétés, que tu ne trouvera pas en oC ou en C++... le fait de pouvoir affecter une méthode à une variable, n'est pas possible sauf moyennant des écritures à coucher dehors en C++, en C# c'est aussi simple qu'en delphi...
Et accessoirement, les projets développés en C#, fonctionnerons sous linux grâce à mono, si tu n'est pas un aficionado des technologies type Entity Framework ou la série des Windows xxxx Foundation (xxxx pouvant être W pour workflow, P pour presentation), pour WCF il y a un sous ensemble implémenté à cause des dépendances pour moonlight.
C'est quoi ce préjugé à 2 balles sur C# sous prétexte que c'est "Microsoft", dans ce cas tu peux ne pas aimer Delphi car cela a été intégralement racheté par une boite portugaise qui fait clairement des produits de ....BEEEEEEEEEP.... et qui se saborde elle même, contrairement à Microsoft, pourtant Delphi est loin d'être une mauvaise plateforme en soit.
+1 cinemania
le monde informatique se porterait bien mieux sans bêtes pensées de ce genreEnvoyé par arkhamon
Il va donc falloir me résoudre à faire du C (argh quelle horreur
ba je peux comprendre qu'on ne veuille pas faire ni l'un ni l'autre à cause d'une syntaxe, pas forcément évidente, quand on est un habitué d'un langage fortement verbeux comme l'est Pascal et donc Delphi.
mais bon... il y à des jugements à l'emporte pièce qui font quand même désordre
tiens histoire d'en rajouter une couche... tu peux décider d'utiliser VB.NET plutot que C# si l'écriture à la C te perturbe tant que cela.
il n'y a aucune honte à développer en vb.net, et beaucoup de boites, très bien le font... on trouve plus facilement de développeurs, car il est vrai que relire une syntaxe C n'est clairement pas "intuitif" pour tout le monde, et accessoirement VB.NET est aussi voir plus verbeux que delphi donc... et surtout c'est du dotnet, donc c'est juste l'écriture qui change par rapport à C#, mais il n'y a pas de grande différence fonctionnelle sur les 2 (à part l'absence des méthodes anonymes dans VB.NET)
En fait, je veux à terme développer des applis pour Iphone, donc en Objective C. Or il me faut aussi développer des applis pour PC et je ne peux pas le faire en Delphi qui est mon premier langage et de loin mon préféré. Donc je dois me mettre au C de toutes manières. Ensuite ma question était entre C# et C++ ce qui sera le plus "rentable" pour moi. Sachant que je n'aime pas .NET.pour la partie PC je ne vois pas du tout le rapport avec le fait qu'il te faille appendre et utiliser Objective-C pour les appli iPhone.
C# même s'il est d'origine Microsoft et tourne sur la plateforme dotnet, te paraitra plus naturel que C++ qui est à mille lieu de ce que tu connais et à l'habitude de voir...
et de toute façon il te faudra toujours apprendre Objective-C qui lui non plus n'a strictement rien à voir avec C++.
Citation:
Envoyé par arkhamon Voir le message
Il va donc falloir me résoudre à faire du C (argh quelle horreur ) et du coup que faire : C++ ou C# ? Je dois avouer que .net ne m'arrange pas du tout car c'est un truc microsoft.Perso, après avoir eu des PC pendant 20 ans, j'ai maintenant des Mac et force est de reconnaître que au niveau stabilité et sécurité, c'est pas trop comparable... Quite à relancer un débat qui a déjà eu lieu 125 236 562 fois.le monde informatique se porterait bien mieux sans bêtes pensées de ce genre
Delphi et moi c'est une longue histoire. ET le préjugé à 2 balles je le trouve plutot dans ton ontervention qui ne fait rien progresser. Delphi s'appuie sur W32 (je ne développe aps sous .NET) alors que C# s'appuis sur .NET qui lui même s'appuie sur W32. Ca multiplie les risques d'avoir des applis ayant des "fuites mémoire" (ça ça me fait toujours marrer les fuites mémoires).C'est quoi ce préjugé à 2 balles sur C# sous prétexte que c'est "Microsoft", dans ce cas tu peux ne pas aimer Delphi car cela a été intégralement racheté par une boite portugaise qui fait clairement des produits de ....BEEEEEEEEEP.... et qui se saborde elle même, contrairement à Microsoft, pourtant Delphi est loin d'être une mauvaise plateforme en soit.
Donc voila je ne veux pas de polémique ni de discussions stériles, et en ce sens, la suite de ton intervention cinemania :
me semble plus constructive que le reste.il faut savoir que C# est inspiré de Delphi, auquel on a appliqué une syntaxe orientée C que l'on a au passage pas mal étendue.
passer d'un environnement à l'autre n'est pas très dépaysant, syntaxe mise à part... tu va y retrouver les propriétés, que tu ne trouvera pas en oC ou en C++... le fait de pouvoir affecter une méthode à une variable, n'est pas possible sauf moyennant des écritures à coucher dehors en C++, en C# c'est aussi simple qu'en delphi...
Et accessoirement, les projets développés en C#, fonctionnerons sous linux grâce à mono, si tu n'est pas un aficionado des technologies type Entity Framework ou la série des Windows xxxx Foundation (xxxx pouvant être W pour workflow, P pour presentation), pour WCF il y a un sous ensemble implémenté à cause des dépendances pour moonlight.
Donc si j'ai bien compris, il vaudrait mieux utiliser C# car :
- c'est plus proche de Delphi que C++
- C'est plus naturel après pour passer à Objective-C
C'est bien ça ?
Par contre faut que je passe au dev sous .NET que je ne connais pas.
Peut-on développer sous .NET sans connaître .NET (ça paraît bête comme question mais bon...) ?
Pour ceusses qui ne comprendraient pas bein ma problématique : j'ai un mac avec VMWare qui m'offre une session XP pour développer sous Delphi, et je vais passer au dev IPhone sous Xcode/IOS, mais il me faudra aussi développer sur PC pour le boulot en C++ ou C#...
il a lieu à chaque fois pourquoi à ton avis?
à cause de remarques dans le même genre que tu viens de faire: "apple c'est mieux que windows point barre".
on croirait entendre steve jobs, c'est impressionnant comme il arrive à transformer ses clients en agents marketing
windows serait si pourri que cela, il n'aurait pas une part de marché aussi énorme et des gens pleinement satisfaits depuis des années et des années.
Windows est un système correct, qui a ses avantages et ses défauts.
MacOS est un système correct, qui a ses avantages et ses défauts.
apple c'est cher, mais si des gens censés estiment que la différence de prix vaut la différence positive à leurs yeux qu'à ce système par rapport à la concurrence, libre à eux de se tourner vers ce produit c'est sans doute un bon choix.
Mais pitié que les applefanboys comprennent que les gens peuvent avoir une autre vision et des besoins différents en terme d'OS, et donc ne pas considérer apple/macos comme étant la meilleure solution pour eux!
ceci dit, concernant la sécurité il y a une énorme chose à souligner. vu la grande part de marché de windows, il est logique que les "pirates" s'attaquent à ce système. il a été mainte fois démontré que les autres Os comportaient aussi des failles.
concernant la stabilité: qui dit flexibilité, amène forcément moins de stabilité et vice-versa: question de choix, mais parfaitement logique
effectivement...
pour les fuites mémoires, ce n'est pas tellement dotnet qui sera la cause probable de cause mémoire, mais plutôt l'élément entre la chaise et le clavier.
En théorie... il n'y a pas de réel memory leaks en dotnet... ça c'est la théorie, car que ce soit en java ou en dotnet il est assez facile de provoquer un memory leaks pendant la durée de vie de l'application... et souvent le problème ne saute pas aux yeux.
en win32 provoquer un memory leaks c'est un peu l'enfance de l'art... suffit d'instancier un type quelconque sur le tas, dans le corps d'une méthode et croire que sous prétexte qu'on quitte la méthode, la variable sera détruite... effectivement elle le sera, mais l'instance référencée ne sera pas désallouée pour autant.
dans tous les cas les memory leaks sont juste la preuve d'une mauvaise analyse et d'un manque d'attention du développeur, mais il est clair que c'est assez amusant.
c'est d'autant plus drôle de les traquer en dotnet, quand tout le monde pense que c'est impossible d'en avoir... (à part ceux qui connaissent bien la plateforme)
on peut développer en dotnet sans connaitre la plateforme .NET ...
comme tu pourrais là développer en java, ou comme un développeur java développerais en dotnet... mal certes, mais c'est possible, et ça fonctionne quand même.
de même, c'est en programmant dessus qu'on apprend à mieux l'utiliser.
en fait si tu dois développer sous windows, à moindre mal, le mieux est de partir sur dotnet, quelque soit le langage.
on aura tendance à réserver le C++ pour un usage dans des environnements à fortes contraintes, ou dans des environnements "sûres" bien que là...( je n'ai jamais été très convaincu... vu la déconcertante facilité d'écrire une idiotie qui compile sous C++...)
la portabilité de dotnet se fait très bien sur d'autres OS via mono, tant que tu ne t'aventure pas à utiliser des technologies avec des brevets particuliers comme Windows Presentation Foundation ou Workflow Foundation.
l'accès aux bases de données notamment sous dotnet est nettement plus agréable que sous C++, et d'une facilité déconcertante. après on est libre ou non d'aimer le modèle sous-jacent d'ado.net mais bon c'est un autre débat.
Delphi te fourni tout un cadre, pour développer en win32, ce cadre te cache toute une partie de la logique de développement nécessaire, pour créer une application sous windows, nécessitant de bien connaitre les api. de plus tu es habitué à construire tes fenêtres en glissant déposant des composants à l'intérieur et en écrivant tout juste le code behind.
Ce modèle de développement est assez proche de celui que l'on retrouve sous dotnet avec visual studio (express pour du gratuit)
encore un point commun facilitant l'adaptation.
écrire en C++ sous windows, pour faire une appli avec des fenêtres, à moins d'avoir recours aux bonnes vieilles MFC c'est quelque part être atteint de masochisme chronique, quand on a pas déjà de base un petit framework pour le faire, car il faut connaitre l'api w32 et vu le genre de littérature... c'est pas gagné d'avance.
Merci pour ces explications.
Si en effet avec C++ faut se retaper les createwindow et autres sucreries de l'API Windows (j'ai fait ça avec Turbo Pascal for Windows il y a quelques années), C# devrait être un bon choix.
Donc au vu de ces explications claires circonstanciées et non polémiques, ma situation (future) semble se décanter.
Au fait en parlant de .NET et des "fuites mémoire", une personne développant sous C# m'a dit que ça tenait a des bugs du garbage collector, et que comme il était impossible de déréférencer manuellement le contenu d'une instance, c'était "inévitable". Flan ou vérité ?
Flan...
celui qui t'a dit ca, est un développeur qui essaie de cacher ses propres lacunes sur la plateforme.
bien qu'il n'est pas impossible qu'il demeure quelques bugs dans le GC, (vu la complexité du machin, il est impossible qu'il en soit exempt) la CLR de dotnet n'a pas changé pendant près de 8 ans, ce qui suppose quand même qu'on avait atteint un niveau de fonctionnement plus que suffisamment performant, et relativement peu buggué.
récemment les modifications apportées à la CLR se sont surtout fait pour gérer la covariance, la contravariance, la programmation avec contrat, et quelques autres joyeusetés, mais il n'a pas été annoncé d'améliorations sur le GC.
en fait généralement la plus grande source de fuite mémoire en .NET est due à une mauvaise utilisation des évènements.
en dotnet, on utilise des délégués pour répondre aux évènements. les délégués conservent une référence sur l'instance de la classe dans laquelle la méthode qu'ils doivent appeler ce trouve, c'est logique.
Le problème c'est que souvent les développeurs lorsqu'ils veulent que la dite instance soit détruite, se contentent de supprimer les références évidentes à celle-ci mais oublient les références cachées... et notamment oublie quasiment tout le temps de supprimer le delegué toujours rattaché à l'évènement.
S'ils déréférencent le délégué, il devient lui même candidat au GC, et vu qu'il est candidat au GC, l'instance référencée également, dans le cas contraire, vu que le délégué est toujours référencé par l'évènement, il référence toujours l'instance, donc lui comme elle ne sont pas éligible au GC.
C'est la seule vraie source de fuites existante, et souvent le fait d'oublier de faire des appels à Dispose sur des classes qui manipule des ressources non managées. (mais dans ce cas, ce sont des fuites "temporaires")
en dotnet, on dispose de libération déterministe, et de la possibilité d'écrire le pattern design Dispose qui permet d'écrire le code de libération des ressources non managées, de même le finaliseur est appelé comme un destructeur lors de la destruction réelle de l'objet pour faire le ménage au cas où. Les ressources non managées doivent être libérées explicitement, les ressources managées non, car si ton objet est détruit, il ne référence plus les autres objets qu'il utilisait et ils seront donc eux même candidat au GC...
effectivement ce sont des notions avancées quand à la plateforme... et certains développeurs ne la connaissant pas réellement préfère se voiler la face sur des probables bugs du GC plutôt qu'à un manque de réflexion et de connaissance de leur part.
néanmoins quand on débute... utiliser les délégués c'est un peu comme sortir le char d'assaut pour chasser la mouche...
maintenant au moins tu est avertis des problèmes qui se pose à leur utilisation... il faut penser à dé-référencer tout délégué dans les évènements dès qu'on en a plus besoin, et le tour est joué...
sur ce site on trouve la lib DvP qui fourni une implantation des évènements à "référence faible" et des délégués à "référence faible" qui permet de ne pas bloquer la libération d'une instance sous prétexte qu'il demeure une référence cachée, et neutralise ainsi les problème de fuite, malheureusement, cette implantation ne peut être utilisée que sur les objets que tu développe toi même et qui auraient recours aux évènements, mais c'est déjà pas mal.
OK. J'ai pas tout compris (delegate et autres instances...) car en Delphi j'ai pas çà, et comme je commence juste a regarde le dev Iphone ils en parlent...
Mais ça me parait plus clair.
Tu aurais un bon bouquin pour apprendre le C# (j'entends pour quelqu'un ayant un passé de dev objet mais n'ayant jamais fait de C ni de .NET) ?
Le top ça serait un bouquin permettant de passer sans fracture des méninges de Delphi à C#...
Merci
en fait en delphi tu as fait des délégués sans t'en rendre compte, car on ne les nommes pas.
quand en delphi tu écrit une propriété qui accepte une méthode, typiquement pour la gestion des évènements, cela correspond, plus ou moins de façon simplifié aux délégué en dotnet, même si les délégués sont bien plus que cela.
quand tu affecte une méthode à cette propriété, tu as créé un délégué
comprend tu mieux le concept maintenant ?
pour la transition je dirais quelle réside surtout dans les tutoriels, et souvent ce n'est qu'une différence d'écriture... écriture à la C pour C# et les mots clés qui diffèrent mais veulent dire la même chose...
je ne me souviens pas avoir vu d'ouvrage de référence sur le passage de l'un à l'autre, mais cela doit exister...
regarde sur ce site ils conseilles souvent des livres et autres, dans la section dotnet, comme ouvrages qui pourraient être susceptible de t'intéresser.
apprendre objective-C va un peu te familiariser avec cette écriture symbolique et peu verbeuse
Il y a régulièrement des hotfixes du framework, quand même.
Personnellement, je me souviens d'un bug dans Linq que j'avais découvert et rapporté à microsoft, qui a résolu le souci avec le framework 4.
bien sure qu'il y en a, des bugs... mais de là à jeter opprobre sur les bugs du GC pour couvrir son incompétence... il y a des limites...
comme par hasard tous les bugs seraient dans le GC...
comme je l'ai déjà dit, vu l'ampleur du machin, si on me disait qu'il était exempt de bugs, que je commencerais sérieusement à me méfier, mais bon, c'est pas windows 2000 non plus
Répondre avec citation
Partager