L'expérience C # se traduit-elle bien en C ++? [fermé]

Mes cours de programmation à l'école étaient en C ++, mais j'ai fini par faire un travail en C # au cours des dernières années. S'il y avait un poste qui exigeait disons 1 ou 2 ans d'expérience en C ++, mon expérience en C # serait-elle digne de considération? Dans quelle mesure pourrais-je être efficace dans une telle position? Dois-je donc commencer en tant que programmeur C ++ d'entrée de gamme pour acquérir l'expérience nécessaire?

Le problème ici est que C ++ et C # sont, fondamentalement, des langages extrêmement différents avec des approches différentes à de nombreux problèmes. Il est facile de les regrouper en "langage OO", mais le simple fait est que de nombreux idiomes C # sont considérés comme un très mauvais code en C ++ (et vice versa).

Si vous connaissez réellement les différences et à quoi ressemblent les idiomes C ++, alors je ne vois aucune raison que cela ne devrait pas être bien.

J'étais dans le même bateau il y a environ 2 ans. Votre expérience c # ne vaut probablement pas autant pour un travail c ++ que c ++ pour un travail ac #. Cela dit, si vous savez comment c # fonctionne réellement (très peu de programmeurs c # le font réellement) et que vous avez bien appris votre c ++, alors le c ++ ne sera pas le problème. Quel sera le problème, c'est la façon dont vous vous êtes habitué à certains modèles de conception qui seront trop élevés pour c ++.

Par exemple, passer du joli modèle d'accès aux données ADO.NET à l'utilisation de cppcon pour l'accès mysql, System.Collections.Generic à l'utilisation de stl, l'héritage multiple, la collecte des ordures pour nettoyer votre mémoire dans les destructeurs et ainsi de suite ... tout tend être des transitions difficiles. C ++ n'est pas le problème, apprendre les bibliothèques, les modèles de conception et comment les utiliser est le défi. La plupart des recruteurs ne s'en rendent pas compte. Si vous pouvez faire une conception de base et utiliser les fonctionnalités réelles couramment utilisées de c ++, alors vous devriez aller bien dans l'entretien.

Cependant, prêt pour le travail est une autre histoire. C'est un défi amusant, j'espère que tout se passe bien.

Je ne peux pas parler pour chaque employeur, mais je considère personnellement la programmation comme la compétence et les spécificités linguistiques comme une bonne chose à avoir. Il est tout à fait possible d'être embauché dans un autre emploi de programmation qui n'est pas votre compétence principale.

Cela dit, il est très improbable que j'embauche quelqu'un qui n'a absolument aucune expérience dans la langue pour laquelle je les embauche. Passez quelques week-ends à apprendre et réalisez quelques projets pour améliorer votre CV. Même les plus petits prouvent que vous êtes capable d'apprendre et que vous êtes passionné.

Vous êtes exactement dans la même situation que j'étais il y a 4 ans.

J'ai fait du C ++ pendant mes études, mais je détestais ça. J'ai fait beaucoup de développement web quand je pouvais sur mon temps libre et j'ai trouvé un emploi dans ce domaine.

Quand j'ai déménagé, j'ai postulé pour un emploi C ++ qui avait 2 ans d'expérience C ++ comme exigence. Eh bien, j'ai rafraîchi mes souvenirs C ++ avant l'entrevue et quand le moment est venu pour les tests, j'ai réussi à m'en tirer avec quelques choses que je n'étais pas si sûr de bien faire.

Mais la plupart de l'interview portait sur la résolution de problèmes et les solutions créatives et le C ++ a fini par être un facteur mineur.

Les chances dépendent donc vraiment de l'employeur et des postes qu'il occupe.

Si vous passez par une agence de recrutement, on vous dira "probablement" que votre profil ne correspond pas. Mais avec un vrai employeur, vos chances sont bien meilleures car ils savent vraiment ce dont ils ont besoin.

Ça dépend. Si vous pouvez répondre à quelques questions d'entrevue de base sur les pointeurs et autres, alors ça devrait aller.

Il est également avantageux de répertorier les différences entre les modèles C ++ et les génériques .NET.

À part cela, il est assez facile de rattraper le reste au fur et à mesure.

Oui. Ce n'est peut-être pas aussi pertinent que l'expérience C ++, mais c'est bien.

Les bons employeurs vont être intéressés par votre façon de penser , plus que par le nombre d'années d'une langue spécifique que vous avez.

Une position C ++ d'entrée de gamme est très bien: vous pouvez apprendre rapidement et faire un excellent travail. Une bonne entreprise vous donnera de nombreuses opportunités de croissance. Sinon, vous pouvez aller ailleurs et avoir une expérience à la fois en C # et en C ++.

Cela dépend vraiment de la nature de l'entreprise à laquelle vous postulez. S'ils recherchent quelqu'un qui possède de bonnes compétences en programmation et en architecture basées sur OO, C # est probablement aussi bon que la prochaine chose.

S'ils sont fiers de la vitesse / réactivité de leur logiciel, alors vous devrez connaître vos algorithmes car cela importe plus que les micro-optimisations - Tables de hachage versus recherche linéaire, etc. C # est toujours pertinent ici, mais vous auriez besoin pour démontrer la compréhension des caractéristiques de performances - tout le monde ne connaît pas ngen.exe, par exemple.

S'ils se trouvent dans un environnement embarqué / mobile et / ou non récupéré, vous devez vraiment savoir comment gérer efficacement la mémoire. Les pointeurs intelligents, comme l'a souligné @DeadMG, sont essentiels ici, mais il en va de même pour la compréhension du profil d'allocation de mémoire. Les programmeurs de jeux pré-allouent souvent de grands tableaux d'objets et les recyclent afin de connaître à l'avance les besoins en mémoire et de réduire les inconnues image par image. C'est également la technique utilisée dans les tables de défilement dans iOS.

S'il y a un travail d'intégration, vous aurez probablement besoin d'une expertise de niveau C en termes de regroupement des données entre les langues (comme P / Invoke) mais également d'une compréhension au niveau octet de la façon dont ces structures de données peuvent être utilisées, ce qui n'est pas une pratique courante dans C # dans mon expérience.