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
C et C++ permettent d'avoir plus de contrôle sur le matériel
C et C++ vous permettent d'écrire du code très efficace
Les langages C et C++ sont portables
C et C++ sont des langages qui évoluent
C et C++ sont largement utilisés
C++ a peut-être de l'avenir, mais je doute que ça soit le cas de C
C a peut-être de l'avenir, mais je doute que ça soit le cas de C++
Je pense qu'ils n'ont plus beaucoup d'années devant eux
Autre (à préciser)
Pas d'avis
Discussion :
Envoyé par Jamatronic
En fait, le commentaire de SimonDecoline était ironique : le C++ est difficile à enseigner si le nombre d'heures de cours est trop réduit.
Mais, comme l'a dit _Bérenger_, il y a un problème de priorisation sur ce que les enseignants devraient enseigner quand ils manquent de temps. Et le RAII ne devrait surtout pas faire partie de ce qui est délaissé.
Ouf, merci pour la précision, je commençais à desespérer...
Sauf que l'informatique est devenue vraiment vaste et qu'on demande aux formations bac+5 d'au moins aborder la programmation, BD, archi, web, sécurité, big data... En plus, avec la mode actuelle du java, javascript, python... si tu arrives à enseigner les pointeurs et les new/delete, c'est déjà beaucoup alors le RAII...
Je programme en C++ également( de moins en moins), Et le terme qui utiliser le plus souvent en C++ est "cast". C est un langage vicieux et même les meilleurs font des erreurs. Et C++ est plus un progrès, mais il n'y a qu'à acheter un jeu vidéo pour voir le résultat final. Les programmes atteignent des niveaux de difficulté incomparable. Les programmeurs ne peuvent plus tout prendre en charge. Ces deux langages sont des dinosaures comme je l'ai mentionner, on doit envisager la conception de compilateur doté d'intelligence artificielle. ne afin qu'ils détecte eux-mème les fuites de mémoire.
Ruby est une preuve de concept pour une nouvelle génération de langage. Ruby a prouvé qu'il est possible de faire de la programmation sans devoir constamment faire des déclarations de type. Mais c'est uniquement possible qu'avec un langage pure-object. C et C++ sont des langages idiots. Si je met un variable a la gauche d'un fonction que retourne une chaîne de caractères, on ne devrait pas à avoir à déclarer le type. Mais comme on ne peut étendre les primitives, on ce retrouve invariable avec des variations de ces types. Alors on cast et on cast à ne plus finir.
En plus, il y a un autre problème avec ces deux langages: Ils sont mal enseignés ! C n'a jamais été imaginé pour être fortement typé. Il était destiné à produire un lien entre des routines en langage machine. Et les programmes qui ont servie à créer Unix.n'avait que trois types: pointer, int, double. Et c'est tout. Et ces comme cela qu'Il devrait-être enseigné.
Maintenant passons à C++. Tu as sûrement entendue parler de cette sonde qui s'est écraser sur Mars, à cause d'un erreur de calcul. Et bien cet erreur à été causé par une fonction privée ! Comme les programmeurs n'avaient pas accès au code, ils n'ont pu déterminer la marge d'erreur de la formule de conversion milles/kilomètre. Une simple observation de la formule aurait suffisante pour qu'un programmeur se demande si la constante utilisée avait suffisamment de chiffre après le point. Les attributs et variables privés sont une vrai plaie, J'ai du refaire des classes complètes en raison de ces saletés. Les professeurs devraient cesser d'encourager les programmeurs de les utiliser. Et si on comprend le concept de SOLID, on réalise que ces truc vont à l'encontre de cette pratique.
Autre archaïsme, l'emploi d’accesseur pour tout et pour rien, alors qu'ils sont inutiles en langage-objet (Pascal s'en passe très bien), En réalité, les accesseurs ne sont utiles qu'à la réception d'une entrée, Si tu as des oranges à l'entrée et que tu t'assure que c'est bien des oranges. Et bien à la suite de ton convoyeurs, tu n'aura que des oranges, Seule vérification nécessaire seront celle qui s'assureront que tu respecte les limites de tes conteneurs (arrays , collections, etc).
En SOLID, tu as trois types d'éléments: Les éléments de base: Cercle, carré, chiffre, structure. Les convoyeurs: ce sont eux ont la charge de remplacer les accesseurs et de vérifier la validité des types et ou de convertir ce qui ont reçue en quelque chose de compatible aux destinataires. Et enfin les contenants: Là rien nouveau, tableau, liste chaînée, fichier.
Une fois, que tu as tout dégraissé à l'essentiel, cela donne des objets très légers. Et conséquemment des programmes plus rapides. Et en bonus, des programmes plus facile à maintenir.
Considérant que Ruby est dans la section Autre sur ce site, c'est drôle !
A partir du C++11, on peut faire de l'inférence de type avec auto, par exemple : auto i = 1;.
Dans d'autres langages, on peut faire de l'inférence de type sans devoir taper un mot-clef spécifique.
Dans tous les cas, pour qu'un langage permette au développeur de ne pas devoir écrire explicitement le type, il n'a pas besoin de supporter le paradigme objet. C'est indépendant.
Les conversions explicites sont verbeuses, mais les conversions implicites sont des sources de bogues.
Par exemple, si on appelle une fonction qui prend en paramètre une chaîne de caractères et un entier mais que l'on écrit les deux arguments dans le mauvais ordre par mégarde, si l'entier n'est pas convertible en chaîne ou si la chaîne n'est pas convertible en entier, alors on aura une erreur de compilation et on verra tout de suite d'où vient l'erreur au lieu de perdre du temps en débogage, à l'exécution.
Au contraire, les professeurs doivent encourager les développeurs à les utiliser et surtout leur expliquer à quoi ça sert.
L'un des intérêts des variables privées est de pouvoir parfois changer l'implémentation de la classe sans avoir besoin de mettre à jour le code source des utilisateurs de la classe. Cela permet, entre autres, de travailler plus efficacement à plusieurs. En effet, quand une classe est utilisée par de nombreuses personnes différentes, s'il faut aller voir tout le monde chaque fois que l'on veut changer la liste des variables membres de la classe, on perd en productivité. C'est encore plus flagrant quand on ne connaît pas la liste exhaustive des utilisateurs, par exemple quand on code une bibliothèque.
Un autre intérêt des variables privées est de pouvoir avoir des invariants de classe. Cela permet de concentrer certains contrôles sur les constructeurs et les mutateurs de la classe au lieu de multiplier ces contrôles dans tout le code qui utilise la classe en question. Par exemple, si, dans un programme donné, un code utilisateur doit être une chaîne alphanumérique non vide sans majuscules, alors il vaut mieux créer une classe CodeUtilisateur avec une variable membre privée de type std::string et un constructeur qui vérifie que la chaîne en question respecte bien les contraintes plutôt que d'utiliser directement des variables de type std::string et écrire 500 fois dans le code assert(EstCodeUtilisateurValide(chaineCodeUtilisateur));.
Autant pour moi
Il ne s'agit pas d'une mode, mais une demande de marché.
"La révolution informatique fait gagner un temps fou aux hommes, mais ils le passent avec leur ordinateur !"
Si tu n'as même pas le temps d'enseigner le RAII en C++, autant ne pas enseigner le C++. C'est comme dire "bon les gars je vais vous enseigner la programmation, on va faire les fonctions, mais par contre j'ai pas de temps pour les boucles, mais de toute façon vous en avez pas besoin vous avez qu'à faire des fonctions récursives", ou "bon on va apprendre à lire, mais par contre on ira que jusqu'à la lettre L parce qu'après y'a piscine": au bout d'un moment, c'est soit tu apprends un ensemble cohérent, soit tu n'apprends rien, ou autre chose.
En plus il me semble quand même que le concept de RAII est bien plus simple à saisir, pour un débutant, que l'héritage et le polymorphisme, qui eux sont systématiquement enseignés, alors que l'on sait bien que ça en fait une méthode de codage par défaut quand elle devrait être une exception.
De ce que je vois, si tu parles de php-desktop, il s'agit au final d'un serveur http et d'un navigateur chromium encapsulé. Le seul intérêt qu'il reste aux appli desktop, c'est la performance, et cette encapsulation ne prédit rien de bon ^^
Au moins ça simplifie l'installation d'une application locale en PHP, si on trouve une utilité (ce que je ne nie pas)
Bravo pour ces idées merveilleuses, je suggère que tu ailles les mettre en pratique dans une école d'ingé ou fac et on en reparle ensuite.
C'est curieux, ça fait penser à ce qui existait jusqu'aux années '80, des terminaux passifs servis par un mainframe où tout tournait, son OS et les applis pour les terminaux (liaison RS232, écran noir-et-blanc, toussa toussa).
Ça ne nous rajeunit pas, ce retour en arrière.
Il a à vivre sa vie comme ça et il est mûr sur ce mur se creusant la tête : peut–être qu'il peut être sûr, etc.
Oui, je milite pour l'orthographe et le respect du trait d'union à l'impératif.
Après avoir posté, relisez-vous ! Et en cas d'erreur ou d'oubli, il existe un bouton « Modifier », à utiliser sans modération
On a des lois pour protéger les remboursements aux faiseurs d’argent. On n’en a pas pour empêcher un être humain de mourir de misère.
Mes 2 cts,
--
jp
ce que je remarque sur le marché c'est qu'il y a peu d'emploi pour ces langages comparativement à java.
même en embarqué, il n'est plus rare de voir du java, alors que je vois essentiel du C il y a plus de 12 ans.
une simple recherche sur des sites d'emploi américain démontre qu'il y a peu de demande pour ruby comparativement à java.Considérant que Ruby est dans la section Autre sur ce site, c'est drôle !
De ce que je vois, je suis d'accord avec la remarque de marc.colin : il y a clairement plus d'offres Java que C, même pour des domaines qui étaient "traditionnellement" réservés au C comme l'embarqué.
Quant à savoir si ça va durer ou non, il faut demander à ta boule de cristal. Mais la tendance montre, à mon sens, que ces marchés restent stables dans la demande et dans l'offre, et que c'est loin d'être un mauvais profil.
Comme on dit en bon français, une fonction, cela s'exécute avec méthode.
L'algorithme est lui méthodique.
J'ai fini par comprendre, mais pas par aimer.
Je sais utiliser, mais c'est plus une corvée si je n'y trouve pas d'intérêt. Donc je réutilise du code source existant ou des applications existantes.
Apprendre le codage, il faut donc commencer tôt, ne pas s'en lasser et ne pas se poser la question "est-il possible de faire autrement ?" tout en faisant tout soit même avec les progiciels, E.D.I. et autres.
Pour ma part, j'utilise souvent php pour des petits scripts, et pas besoin de serveur HTTP. En batchant le commande "php.exe script.php" tu peux te servir de PHP pour des petites procédures genre : conversion d'images, nettoyage de fichiers, récupération de données depuis un ou plusieurs sites. Je pourrais le faire en C/C++ ou en Java, mais l'avantage c'est qu'avec PHP, y a pas besoin de compiler à chaque modification de code, et c'est tout aussi cross-platform.
"La révolution informatique fait gagner un temps fou aux hommes, mais ils le passent avec leur ordinateur !"
Ce que je pense aussi. Un profil C/C++ sera plus à même de s'adapter à d'autres langages au besoin. L'inverse n'est pas toujours vrai. Pour avoir bosser dans une équipe J2EE, j'ai été surpris de voir le peu d'ouverture qu'avaient les développeurs Java sur les autres technos. Pour eux, Java est un monde à part (presque parfait) que les autres finiront pas rejoindre de toutes façons.
"La révolution informatique fait gagner un temps fou aux hommes, mais ils le passent avec leur ordinateur !"
Je ne suis pas d'accord.
Déjà le C/C++ sont des langages au départ impératif (on peut y coder en fonctionnelle c'est pas la pratique courante), il aura beaucoup de mal à s'adapter sur du fonctionnel (scheme, prolog...)
Un développeur ne connaissant que le C vas avoir du mal avec la prog objet, par pitié ne sorter pas votre mauvaise foi en disant qu'on peut faire de l'objet en C, car c'est pas fait pour et c'est à chié.
Le C/C++ c'est pas des langages universelles, d'autre langages ont des approches très différente, comme Erlang ou SQL
Erlang je parle des concepts du langage (la distributions des taches), pas de l'aspect fonctionnelle.
cela dit on trouve plus facilement du taf avec du C/C++ que les reliques que j'ai cité
Quoique j'ai oui dire que les langages fonctionnelles semble revenir à la mode comme Rust, Kotlin qui peuvent etre utilisé à 100% en fonctionnelle.
Tout dépend du marché: La petite et moyenne entreprise n'ont pas les moyens de payer pour des applis en pure Java. Par contre, Un site fait avec Rails sur Jruby, leur suffit largement. Et comme Truffle est sur le point d'arrivé ainsi que Crystal, les opportunités ne vont pas manquées. De toute façon, le marché américain, c'est de l'histoire ancienne pour moi. Et avec Trump au pouvoir les Américains vont subir des pressions pour qu'ils embauchent des américains. La bel époque où isl engavaient des programmeurs indiens pour des peanuts, est terminé !
http://chrisseaton.com/rubytruffle/
https://crystal-lang.org/
Ben pour moi, cela ne représante pas un énorme progrès. Ceci dit, je suis convaincu que le programmeur devrait déclaré la taille des valeurs numériques à un moment donnée pour augmenter la performance. Mais ce sera après avoir écrit la logique.Ruby est une preuve de concept pour une nouvelle génération de langage. Ruby a prouvé qu'il est possible de faire de la programmation sans devoir constamment faire des déclarations de type. Mais c'est uniquement possible qu'avec un langage pure-object. C et C++ sont des langages idiots. Si je met un variable a la gauche d'un fonction que retourne une chaîne de caractères, on ne devrait pas à avoir à déclarer le type.
Je sais, et on n'y échappe pas si une partie du code à été écrite par quelqu' un d'autre. Mais déjà en C objective , c'est déjà moins archaique. Tant C++ ne sera pas remplacer par un langage pure-object, ce sera toujours aussi chiant.Alors on cast et on cast à ne plus finir.
Mais les inversion d'arguments, je ne crois que les AI vont pouvoir rattraper ce genre d'erreurs. Quand on est à ce point, c'est le temps d'aller dormir.
Il y a deux problèmes dans cette affirmation. Le premier problème est qu'il va à l'encontre du S dans SOLID, Responsabilité unique implique que ta fonction privé ne devrait pas être. Le deuxième problème est avec le L de SOLID un couplage léger évite d'avoir ce genre de problème. C'est un objet convoyeur que tu donne la charge de convertir les données. En ayant des intermédaires qui ne servent principalement à cela que tu évite ce genre de problème. Et je n'ai pas inventé le concept. c'est une formule épouvé dans les universités américaines tu n'y échappe pas.
.Jette un coup d'oeil sur ce document. C'est pratiquement du speudo-code. Et tu va voir que qu'en je dis des objects dégraissés, c'es vraiment jusqu'à l'os !
https://subvisual.co/blog/posts/19-s...iples-in-ruby/
L'avenir va ressemblé à cela: http://www.i-programmer.info/news/98...r-android.html
Un serveur en PHP, ou Python ou Ruby et un client en Javascript. Les téléphones portables vont devenir un marché de plus en plus important.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager