Non mais les vrais warriors codent en C et puis c'est tout.
:dehors:
Version imprimable
Non mais les vrais warriors codent en C et puis c'est tout.
:dehors:
J'ai moi même fait la transition de C à C++ (je n'ai pas abandonné le C pour autant :D) et honnêtement si c'était à refaire je ne le referais pas. C++ est syntaxiquement d'une complexité infinie par rapport aux langages modernes qui offrent les mêmes fonctionnalités et même avec un usage quasi quotidien je n'arrive pas à m'y faire. Je pense que ce fut une erreur de vouloir conserver aussi longtemps la rétrocompatibilité.
Sauf besoin impératif de compatibilité avec du code existant je ne pense pas que ça vaille la peine de se mettre maintenant au C++.
A mon avis, le principal problème maintenant, c'est qu'il y a compatiblité avec le C et que le programmeur C refait du C au bout de quelques jours plutôt que de devoir chercher comme faire plus efficacement en C++.
Il faut aussi se poser la question de ce que l'on fait avec le langage. En C++ on ne fait pas la même chose sur un micro-controlleur que pour un GUI ou un process server. C'est assez ouvert et c'est peut-être ça qui est déroutant (mais c'est le but du langage).
Si le C++ est si complexe, que dire du Java ou même du Javascript? Ca doit vous paraitre des usines à gaz incompréhensibles.
J'ai 47 ans, j'ai commencé à programmer à 14 ans en BASIC et assembleur 6502. Après PASCAL et assembleur 8085 pendant mes études d'électronique, puis assembleur 8051 pour mon stage de fin d'études. J'ai une formation d'électronicien, ce qui explique peut-être mon approche très près du matériel lorsque je programme. J'ai pratiqué VB et VBA au cours de ma carrière professionnelle, mais que c'est mauvais le VBA. Aujourd'hui, je ne me qualifie pas comme développeur. À la maison, je pratique le C (appris avec le K&R) et l'assembleur 8051 en loisir. Au boulot, c'est BASH et PYTHON quand le BASH ne suffit plus.Citation:
Envoyé par Luc Hermitte
Je n'arrive pas à comprendre ce que veut dire "Depuis le C++11, le C++ n'est plus du C (même si la compatibilité est assurée)". Ça me parait contradictoire. Tu peux expliquer ?Citation:
Envoyé par foetus
Regarde la documentation en ligne :mrgreen: :mrgreen: : (et encore je ne parle pas de toutes les ambiguïtés :whistle: supprimées comme le "perfect forwarding" ou les rvalues, lvalues, xvalues, glvalues, et prvalues (universal ref???))Citation:
Envoyé par Traroth2
- Gestion de la mémoire (Dynamic memory management) que des templates
- Test de types (Type support) que des templates
- La STL c'est comme cela depuis 1998
- Les utilitaires comme std::function ou std::move ou function objects : des templates, encore des templates
Comme l'a dit nikko34 (et les vieilles habitudes qui ont la vie dure), le programmeur C qui veut faire du C++ moderne va vite abandonné :mrgreen:
Au contraire le langage Java en lui même est très simple par rapport au C++. Il a volontairement choisi de se débarrasser des aspect compliqués de C++. Après si tu compte les bibliothèques standard ça n'est pas comparable su que celle de Java est bien plus fournie.Citation:
Envoyé par nikko34
JavaScript c'est assez différent. C'est a la base un beau bordel qu'on a essayer de spécifier a postériori.
Pourquoi les generics en Java c'est simple et vector< string > en c++ ce serait compliqué?
Pourquoi se plonger dans la lib Java et pas dans la lib C++?
Parce qu'il me semble que ce n'est pas la même chose :mrgreen:Citation:
Envoyé par nikko34
En C++, c'est du texte à trou, et c'est la compilateur qui va remplacer et ensuite te dire si "le contrat" n'est pas respecté.
En Java, le generic estvérifié à l'exécution. "disparaissent à l'exécution" me dit rt15
Je sais bien que c'est pas la même chose, mais je pense que c'est pas si compliqué à utiliser quand même?
Je veux dire, le duck typing, yen a dans plein de langage c'est si désobligeant de voir ses erreurs à la compilation?.
Je développe en C++ pour de l'embarqué, avec un environnement de cross compilation pour générer les binaires dans l’architecture cible.
Une fois compilé, optimisé, transformé en instruction processeur, qu'est-ce que ça change si en amont ça a été fait en C ou en C++ ?
Non, les génériques disparaissent à l'exécution.Citation:
Envoyé par foetus
List<String> c'est la même chose que List<Object> à l'exécution.
Sérieusement le C++ est au moins 10 fois plus compliqué que le Java.
Héritage multiple.
Alignement des champs de structures.
Possibilité de faire de l'asm inline.
Pas de garbage collector.
Pas de caractères "magiques" UTF-32 [edit : lire UTF-16].
Longtemps il a manqué des trucs de bases dans la librairie standard genre les threads. Il fallait traiter chaque OS. J'imagine qu'il en reste.
Surcharge des opérateurs.
Possibilité de faire du procédural, pas juste des fonctions statiques dans des classes.
Les pointeurs...
Les macros.
...
Alors que pouvoir implements multiple est beaucoup plus simple :roll:Citation:
Envoyé par rt15
Tu peux très bien t'en moquer, tu es libre de plomber tes perfs.Citation:
Envoyé par rt15
J'en ai jamais eu besoin, peut-être rencontré 1 seule fois.Citation:
Envoyé par rt15
Hé oui, il faut savoir ce que l'on fait, personne pour balayer derrière toi :roll:Citation:
Envoyé par rt15
J'ignore de quoi tu parles, n'en ai donc jamais utilisé ni rencontré, ça a pas l'air bien important donc.Citation:
Envoyé par rt15
Longtemps il a existé tout un tas de libs pour le faire (pthread, TBB, Boost, ...) :roll:Citation:
Envoyé par rt15
Ne les utilise pas si tu sais pas y faire, c'est juste un truc super utile sinon :weird:Citation:
Envoyé par rt15
C'est vrai que devoir écrire une classe mytho pour avoir une fonction main m'a toujours paru bien plus intelligent :roll:Citation:
Envoyé par rt15
Cf le garbage collector. J'imagine qu'il est plus simple de croire que tout est magie et laisser JAVA manipuler tout ça pour toi :roll:Citation:
Envoyé par rt15
Un outil très pratique hérité du C à la base :roll:Citation:
Envoyé par rt15
Sinon pour le troll JAVA vs C++ ça se passe ici http://www.developpez.net/forums/d18...t-cpp-vs-java/
Ce ne sont que des possibilités, dans un restaurant 3 étoiles, on ne prend pas tous les plats à la carte.Citation:
Héritage multiple.
Alignement des champs de structures.
Possibilité de faire de l'asm inline.
Pas de garbage collector.
Pas de caractères "magiques" UTF-32.
Longtemps il a manqué des trucs de bases dans la librairie standard genre les threads. Il fallait traiter chaque OS. J'imagine qu'il en reste.
Surcharge des opérateurs.
Possibilité de faire du procédural, pas juste des fonctions statiques dans des classes.
Les pointeurs...
Les macros.
Et les "Pas de", c'est juste pas en standard, sinon, on trouve toujours notre bonheur avec des librairies supplémentaires.
Et avec JAVA 8 (fonctionnel, ...), tu vas péter un anévrisme. :aie:
P.S.: En plus, les trucs les plus cheloux (Les pointeurs, Les macros, ...), c'est à cause du C, donc comme argument pour interdire la migration/évaluation C vers C++, c'est assez moyen. :mouarf:
Oui, ici c'est un troll C vs C++.Citation:
Envoyé par Bousk
C'est de la provoc. Pascalien d'élection (Pascal VMS, Delphi, fpc, ...), COBOLISTE par obligation, j'ai maintenu du code C et C++. Je parle d'applications bancaires sur grands systèmes. Y a pas photo, pour comprendre ce qui se passe quand on ne l'a pas écrit soi-même C++ est infiniment meilleur que C.
Je me suis intéressé aux dernières versions, franchement, tout ça est fichtrement bien foutu. Ajoutez la portabilité, la communauté, et vous comprendrez que je regarde avec perplexité les managers réticents à ce langage. Notez, ils sont managers, pas forcément bons, donc ! :mrgreen:
J'ai une très nette préférence pour le C++ par rapport au C# / Java (pour poser le contexte).Citation:
Envoyé par rt15
Mais en quoi c'est un problème ?
En C# (mais je ferais la même chose en Java), j'ai toujours au moins une class static dans laquelle je mets des fonctions utilitaires (qui auraient été des fonctions libres en C++). J'imagine que c'est mal et trop collé sur la façon de penser C++, mais... c'est bien à ça que servent les classent statiques ? (Équivalent d'un namespace + fonctions libres en C++ ??)
Sinon la feature la plus intéressante, c'est quand même le destructeur appelé de manière déterministe.
Et ça ya peu de langage qui le font en fait?
Après reprocher au C++ de pouvoir faire plein de choses différentes avec, c'est fort. Mes programmes pour micro-controlleurs sans STL ni exceptions (pas dispo dans le compilateur) utilisent des features différentes du langage. Et c'est normal non? Mais on retrouve aussi des classes, des templates, des destructeurs (oui! plein!).
C'est effectivement ce qui me manque le plus dans les autres langages, et c'est sans doute l'amour de cette possibilité qui me fait détester les GC (sauf en programmation fonctionnelle <3).
Après en C, on peut facilement faire du nettoyage à base de Goto (plus fiables qu'en C++ à cause des exceptions), mais c'est moins propres. Dans les autres langages faut attendre que le GC fasse son boulot. Beeeurk
C'est totalement différent et incorrect :mrgreen: :mrgreen:Citation:
Envoyé par nikko34
En généralisant à fond, on peut dire que le "duck typing" c'est un branchement à l'exécution, alors qu'avec le C++ moderne on "va programmer" le compilateur.
Je pense que c'est le seul langage et sauf cas d'optimisation poussée, où on doit s'en remettre autant au compilateur.
En Java, lorsqu'on fait un new on s'en fiche de ce que le ramasse-miettes fait. Lorsque tu vois les vidéos sur Youtube sur les déductions de types du Javascript tu te marres :mouarf: Mais, le Javasctipt fait tourner des millions de sites et les programmeurs s'en fichent.
C'est pour cela que nikko34 est côté de la plaque lorsqu'il dit "Après reprocher au C++ de pouvoir faire plein de choses différentes avec, c'est fort."
Ce qu'on reproche au C++ c'est 1) avoir trop d'outils 2) de connaître parfaitement le compilateur et ses subtilités
Je suis d'1 œil l'actualité Visual C++ :oops: :oops:, mais il me semble que même Microsoft a jeté l'éponge du compilateur C++: il prend CLang
Mauvais œil. Ils sont en train en réécrire le compilateur C++ qu'ils se trainent depuis l'époque où ils avaient un truc qui compilait en multipasses, en streamant, etc. A tous les coup, c'est juste que la licence de clang permet une intégration dans leur IDE que gcc ne permet pas vraiment.Citation:
Envoyé par foetus
Et comme d'autres projets remarquables, ils ont migré des gros morceaux de C vers le C++ (leur bibliothèque C est maintenant en C++ à l'intérieur). gcc a migré on savait. Mais aussi MAME (autre video des CppCon 2016).
Vas-y, tu me cherches ? :mrgreen:Citation:
Envoyé par rt15
Je suis en train de péter un plomb à faire un Raytracer en C pour un projet d’école, et avec tout mes calculs de vecteur, je me retrouve avec des pâtés dans le genre :
au lieu d'écrire simplement ceci :Code:
2
3
4
5
6
Après, je suis qu'un pauvre petit étudiant de 24 piges qui code que depuis 5 ans (déjà oO), je suis encore jeune et c**, et j'ai peut être rien compris :mrgreen:Code:vp.upleft = pos + (dir * vp.dist + up * (vp.height / 2.)) - right * (vp.width / 2);
https://blogs.msdn.microsoft.com/vcb...2015-update-1/Citation:
Envoyé par Luc Hermitte
Jette un oeil à Rust.Citation:
Envoyé par foetus
Après c'est peut-être moi mais vu le typage fort et les erreurs de compil, ça évite quand même d'écrire un paquet de test par rapport à des langages style "script" et ne nécesitte pas forcément un IDE poussé?
On dirait qu'effectivement pour certains avoir des erreurs des compilation est un drame apparement. Moi je dirais que c'est un avantage (encore plus en embarqué où les possibilités de debug sont faibles..).
le C++ n a d interet que pour des produits complexes. Si vous devez programmer un microcontroller tout simple et rester pres du materiel (genre un thermostat, un controleur d une vitre electrique) , quel est l interet, vu que le C a deja tout ce dont vous avez besoin
Second point, a une certaine epoque (10 ans) le C++ c etait une grosse perte en performance
acceptable sur un gros systeme ou de toute facon le CPU ne sera pas utilise a fond. plus vraiment sur un microcontrolleur 8 bits ...
Bonjour
Je fais partie de ces développeurs C qui reste en C. De surcroît, mes consignes à mon équipe sont encore plus restrictives : C - ISO 89, à quelques exceptions près.
La raison : je considère que connaitre un langage informatique n'est pas mon premier métier. Mon premier métier, c'est la connaissance fonctionnelle des besoins de mes clients, et le langage informatique n'est que le moyen de mettre en oeuvre mon métier. Comme ce n'est qu'un moyen, je veille à limiter les coûts de son usage.
Le C est globalement simple à apprendre, et empiriquement, un développeur contraint à n'utiliser que du C fait des programmes globalement maintenables par tout le monde sans beaucoup d'expérience en C (et oui il existe quelques contre-exemple, mais ils sont rares).
Empiriquement, dès qu'on autorise le C++, les développeurs utilisent immédiatement un empilement de classes et autres mécanismes complexes, qui fait qu'au final le programme est difficilement maintenable excepté par un expert C++, voir uniquement par l'auteur du programme. Oui, en théorie un programme C++ pourrais être simple et élégant, mais en pratique je n'en n'est quasiment jamais vu. Et dans ce cas, je considère alors que le C++ devient un coût inutile au projet.
Pour l'OO ... le python a très bien répondu à mon attente. Le Python est facile à appendre, et il est très facile de lier le Python et le C.
Conclusion, tout le haut niveau, ne nécessitant pas de performance, je le fais en Python, orienté objet. Tous les parties critiques, je le fais en C.
Mon équipe me suit sans problème, les programmes sont simples, lisibles et maintenables. La valeur ajoutée (les fonctions critiques et performantes) et alors dans le C. Le Python nous fais tout l'habillage.
( point important que les développeurs C++ devraient méditer : en python, l'approche est que les choses simples doivent se faire simplement)
Et pour le C - ISO 89 : parfois, une partie de mes codes sont portés sur architectures un peu spécifique (embarqué, PLC etc ...), et là on est alors confronté au faite que les compilateurs sont ancien, donc les dernières évolutions du standard C ne sont pas supporté.
Cordialement
Emmanuel
Je troll pas, j'énumère juste des différences incontestables entre le Java et le C++. Ces différences sont positives ou négatives, ce n'est pas mon problème ici. Je pense juste que ces différences rendent globalement le C++ bien plus compliqué et vaste.
Me semble que personne n'ayant pratiqué ces deux langages un minimum ne peut contester que l'un est 10 fois plus compliqué que l'autre... Si ?
Oui implements multiple c'est beaucoup plus simple et plus limité que l'héritage multiple. Par exemple en Java, impossible avant tout d'avoir maman et papa implémentant la même méthode.
J'ai pas dit que le garbage collector c'est bien ou c'est pas bien. J'ai dit que c'est une différence. Et il est généralement admis que coder avec un GC est plus simple. On créé des objets et ils sont libérés au petit bonheur la chance. En première approche, c'est plus simple qu'un XXXX_pointer.
Les caractères UTF-32 magiques (UTF-16 en fait, mea culpa) c'est une différence entre le type primitif char du java et le type primitif char du C++. En C/C++, le char est le plus souvent un octet et la chaîne peut au final être encodé en n'importe quoi genre ISO-8859-1 ou UTF-8. En java le char et les String sont considérées dans 99% des cas comme de l'UTF-16 (C'est un peu comme si le wchar_t du C/C++ avait toujours été à la place de char). Regarder un programmeur débutant chercher le caractère 'é' dans un char[] en utilisant les deux langages, vous verrez dans lequel il y arrive en premier.
La surcharge des opérateurs ça peut simplifier des portions de code comme plus haut, mais ça ne rend pas le langage plus simple. L'écriture de la surcharge des opérateurs est pas triviale.
Pour les pointeurs, que le premier qui parvient à faire un seg fault en java me lance la première pierre. En Java on risque que des null pointers et des index out of bound. Ne trouvez vous pas ça plus simple ?
Le C++ c'est une navette spatiale et le Java c'est une mobylette. Avec le C++ tu peux aller sur la Lune après 7 ans d'études. Avec le Java tu peux aller t'acheter une bière au bar du coin après 10 minutes d'explication sur un parking. L'un n'est pas mieux que l'autre, mais l'un EST plus compliqué que l'autre. Juste comptez le nombre de mots clé réservés en Java et en C++. Oh mais attendez, vous tomberez pas sur le même nombre en fonction du compilo C++.
Tout à fait d'accord, le Rust apporte les avantages de C++ (Multi paradigme) mais en excluant une grande partie de sa complexité (lourd héritage).Citation:
Quel intérêt pour un programmeur C de passer au C++ plutôt qu'au Rust par exemple ?
Par contre contrairement au C++ le Rust n'est pas un sur ensemble du C il est donc impossible d'importer directement le code (il faut donc tout recoder)
Je sais toujours pas pourquoi vous voulez empiler les classes et faire de l'héritage à gogo en C++ sur micro-controleur.
Vous faites pas de struct en C? Ca ressemble pas à des classes avec des méthodes?
Dans mon code C++ embarqué on va avoir:
- une couche physique d'abstraction (à base de code pré-compilé, aucun overhead).
- des classes qui représentent mes composants physique
- pas d'héritage (pas besoin de polymorphisme dynamique..) plutôt du polymorphisme statique ( à base de template, sans overhead donc, déduit à la compil).
- des classes outils (ma petite bibliothèque) pour faciliter par exemple l'utilisation de flash string, de l'eeprom, la machine à état (entièrement en template).
Du coup par exemple, la machine à état va ressembler à ça :
plutôt qu'à des if imbriqués à la toque.Code:
2
3
4
5
:ptdr: :ptdr: :ptdr: :ptdr: :ptdr: :ptdr:Citation:
Envoyé par rt15
Mais comme Uther a dit, si on compare la librairie standard du Java et celle du C++. En fait, on ne peut même pas, C++ n'a pas de librairie standard :mrgreen: (enfin, depuis le C++11 cela semble changer, mais les développeurs ont au moins 10 ans de code palliatif)
:mouarf: :mouarf: :mouarf: :mouarf: :mouarf: :mouarf:Citation:
Envoyé par nikko34
Déjà caler une machine, quelle qu'elle soit (pure objet, tableau comme en C, mi les 2, une vue == un état, ...), c'est déjà hardcore.
Alors en pure template. J'espère me tromper ;)
je developpe tout en c++ ou c
mais j'utilise x14 dernière validation
j'avoue que les fuite les distorsions et les petites infraction ne passe plus même si elles sont sans importances.
je fais du web en c++ et cela fonctionne très bien
en c++ on peut développer son propre LG4 pour ma part je suis a 80% du rpgile as400 autant vous dire qu'un programme passe a 200 ou 300 lignes
les lib sont solides la rapidité sans aucune mesure ,
dire que j'utilise a fond c++ x14 NON mais la transition ce fait tranquillement, quand au barrière des class , et de la OO c'est une histoire de ce remonter les manches , et un bonne informaticien ce doit d'être à l'école du début de sa carrière jusqu'à la fin ...
j'arrive des gros system ou tout est pris en charge à la retraite je me suis mis un pti défit ecrire mon L4G avec toutes les macros rpg400 d'ou cela devient ROO relation objet objet avec pour méthode AXIAL et comme interface websocket (interactif web temps reel voir mon article ) ...
pour moi le c++ englobe le c et vas beaucoup plus loin , structure les programmes , bon les puriste me diront que c'est pas vrais ils auront raisons mais ils devront dire que dans n'importe quel langage cela peut être un foutoir...
@bientôt:mouarf:
Venant du C++, je ne vais pas forcément prêcher pour ma paroisse. Le C est loin d'être aussi complexe que le C++, pour moi c'est parfois un défaut*, mais cela a aussi ses avantages, généralement en C :
- Le temps d'apprentissage du langage est plus rapide.
- Le temps de compilation en C est plus rapide.
- Le poids du binaire en sortie est plus léger (on peut toujours débattre là-dessus avec les #include et modules de C++).
:fleche: Tant que le système n'est pas critique et que le matériel à disposition présente une configuration adéquate pourquoi s'embêter ? Sauf si la compétence ou le plaisir y est, les gens n'ont pas forcément envie de tout programmer avec un langage de bas niveau non plus : on met en place le bas niveau en C pour les appels système (la POO n'est pas forcément très utile pour ce cas) et fait le reste avec un langage de haut niveau.
* : En C, j'aurais bien aimé avoir un système de template léger pour éviter les void* (et je ne parle pas du _Generic moisi du C11), et des lambdas.
"Oh la la ! Quel stress ma courbe débande ... alors que celle de K&R se dresse ...
Mon boulot de normalisateur du C++ va bientôt s'envoler...
Vite, vite, il faut faire une opération séduction auprès des développeurs C."
Non, mais c'est CppCon 1996. C'est une parodie de Back to the future.
Et pourquoi ne choisirait-on pas ObjC plutôt ?
Oh et puis n'hésitons pas à recoder les commandes de vol, les logiciels critiques de centrales nucléiares, trains, etc en C++, nous nous sentirons plus en sécurité...
Et tous les drivers HW aussi.
Franchement, rien que RAII c'est pour moi une raison de passer au C++. Tu mets un objet sur la pile, peu importe comment tu sors de ta fonction : return multiple ou exception -> l'objet est détruit et désalloué. En C c'est le bordel monstre avec des goto à foison pour "nettoyer" le code.
Après il y a tellement d'autres avantages, rien que ce truc simple qu'on ne peut pas faire en C : vector<int> v{1, 2, 3}; ... plus loin dans le code : v = { 4, 5, 6 };Puis les namespaces, codez avec gtk, allez essayer vous allez adorer. gtk_widget_create_with_my_bunch_of_parameters(GTK_WINDOW(oh_my_object));Puis les (variadic) templates, faire un thread qui prend 0-n paramètres. En C tu es obligé de passer par un void * complètement non-typé, non-safe. Je pourrais continuer encore des heures :)
Je crois que tu as complètement manqué la question de départ qui était a propos de la simplicité.Citation:
Envoyé par Bousk
Personne ne nie que C++ est globalement plus performant que Java et qu'il a des outils qui permettent de résoudre la plupart de ces problèmes.
Mais il faut être de mauvaise foi ou mal renseigné pour dire qu'il est plus simple. Tous les points relevé par rt15 sont corrects, et le fait que ça ait un impact sur les performance ou qu'il y ait des moyen de les contourner via des bibliothèques ou d'autre outils ne change rien au fait qu'au final c'est plus complexe.
C'est un peu plus compliqué que ça. Il y a pas mal de fonctionnalités tu subis que tu les veuilles ou non, car tu es bien obligé tôt ou tard à composer avec le code et les bibliothèques d'autres.Citation:
Envoyé par bacelar
Il y a des trucs où le C++ sera plus complexe, effectivement les templates qui ne sont pas une surchouche à du void*, la notion de déplacement, plus des fonctionnalités qui font défaut en face et que l'on paiera en complexité d'utilisation (a+b*c restera toujours plus simple à utiliser que 2 appels de méthodes ou un appel à un saxpy -- et ça, c'est pas à nous de le redéfinir à chaque fois, il y a déjà assez de bibliothèques disponibles dans l'ensemble, au pire, un expert suffit à le fournir aux autres pour d'éventuels types métiers où cela aurait du sens).
Mais le Java a aussi ses complexités: les annotations, l'impossibilité d'importer du code par héritage sans entrainer une substituabilité syntaxique, la réflexion, les paramètres de contrôle du GC. L'absence de passage par référence (tout en passé par valeur comme en C, même les références qui ne sont que des sortes de super-pointeurs), et plus généralement un traitement à deux vitesses des variables en fonctions de leur nature. Il a aussi ses idiomes : p.ex. l'écriture des types valeurs a des règles à suivre (tout non mutable, pas d'héritage) (tout comme les classes à sémantique de valeur en C++) si on ne veut pas faire trop n'importe quoi. equals est tout sauf triviale à définir (beaucoup n'ont toujours pas compris qu'héritage et equals ne sont pas compatibles -- mais c'est un problème OO et non langage). Il ne peut pas y avoir de fonctions libres non plus, ce qui conduit à des désigns faussement OO (confusion entre la philo orientée messages de l'OO avec "il ne doit rien exister hors classes". Pour l'héritage multiple, certains ont raté la possibilité avec Java 7 de définir des méthodes par défaut dans les interfaces (on est de retour avec les problèmes d’ambiguïté).
Après, franchement, OK, il y a plus de features (ou un set différent). Et alors? Si un tel sous-ensemble permet d'écrire plus simplement des choses (revenons au débat C++ VS en embarqué ou ailleurs), n'est-ce pas mieux ? Ce n'est pas parce qu'il y a plus de possibilités que l'on se sert nécessairement de toutes.
Sinon, J'ai vu passer un argument comme quoi Meyers disait que C++ n'était pas objet. Allons voir du côté de celui qui a "dit OO" pour la première fois -- Alan Kay. Pour lui, Java n'est pas OO non plus. Je suis tombé sur un bon résumé historique il y a peu d'ailleurs: https://medium.com/skyfishtech/retra...g-f8b689c4ce50 -- depuis la compréhension/signification de "OO" a bien shifté, et pas pour le meilleur AMA.
PS: j'ai vu avancé les arguments du RAII et du meilleurs typage. Ne pas oublier qu'en embarqué il y a très peu de ressources allouées et de fait, ce sujet n'est pas aussi critique qu'ailleurs. Et pour le meilleur typage, cf de nouveau la première vidéo, et les 2 interventions où "une erreur du compilateur est redoutée/mal prise".
C'est compatible. Ce n'est pas trivial, mais c'est possible.Citation:
Envoyé par Luc Hermitte
Pour ceux qui voudraient plus de détails sur comment implémenter correctement equals en Java, je conseille la lecture de l'article suivant, à partir de "Pitfall #4: Failing to define equals as an equivalence relation" :
http://www.artima.com/lejava/articles/equality.html
L'auteur prend en exemple une classe ColoredPoint qui dérive de Point.
Il présente deux implémentations fausses de equals, puis une troisième avec getClass() qui n'est pas terrible car restrictive, puis une quatrième qui est la bonne :
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Ceux qui font du C aujourd'hui savent en général pourquoi ils ne font pas de C++. Je ne vois pas un seul argument qui pourrait les convaincre d'en changer.
Perso, c'est le C pour tout ce qui est électronique ou demande de la performance. Si j'ai besoin de quelque chose de moins performant, nécessitant la POO c'est python3, C# ou mono pour windows
Est-ce que la taille du code compilé est la même qu'en C ? Pour de petit micro controller, je pense que ça fait la différence, on a pas forcément envie d'un RPI juste pour prendre une température et la transmettre.
Je me trompe peut-être (trop longtemps que je ne pratique plus le C++):D
Est-ce que vous avez regardé la conférence sur le C64?
https://www.youtube.com/watch?v=zBkN...hO1WvGHUUFgUQH
Ca correspond beaucoup à ce qu'on ferait sur micro-controlleur. Avr-gcc compile du C++11 pour des puces atmel (arduino) par exemple (il n'y a pas de librairie standard ni d'exception ni de virtuel, mais c'est pas très important pour de l'embarqué où on va essayer d'éviter les allocations dynamiques de toute façon).
Si tout est calculé à la compilation, il n'y a pas d'overhead particulier pour la taille du programme.
On peut utiliser des structures haut niveau (pour par exemple avoir des cibles processeurs différentes qui ont des registres à des adresses différentes) qui à la compilation vont finalement juste écrire le bon registre au bon endroit dans le code.