Discussion :

[Luc Hermitte]

Je suis d'1 œil l'actualité Visual C++ , 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.

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).

[CeluiQuiCode]

Surcharge des opérateurs.
...

Vas-y, tu me cherches ?
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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
vp.upleft = vec3_sub(
	vec3_sum(
		pos, vec3_sum(
			vec3_mult(dir, vp.distance),
			vec3_mult(up, vp.height / 2.))),
		vec3_mult(right, vp.width / 2.));

au lieu d'écrire simplement ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

vp.upleft = pos + (dir * vp.dist + up * (vp.height / 2.)) - right * (vp.width / 2);

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

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.

https://blogs.msdn.microsoft.com/vcb...2015-update-1/

[Matt_Houston]

Je pense que c'est le seul langage et sauf cas d'optimisation poussée, où on doit s'en remettre autant au compilateur.

Jette un oeil à Rust.

[nikko34]

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..).

[cdubet]

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 ...

[emmanuel_dumas]

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

[rt15]

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++.

[reynum]

Quel intérêt pour un programmeur C de passer au C++ plutôt qu'au Rust par exemple ?

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).
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)

[nikko34]

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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
typedef StateMachine< CDPlayer,
 //       Current state | event | Next state | Action
 Transition< Stopped, play,        Playing, StartPlayback >,
 Transition< Stopped, open_close,  Open,    OpenDrawer >,
 ...

plutôt qu'à des if imbriqués à la toque.

[foetus]

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.

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 (enfin, depuis le C++11 cela semble changer, mais les développeurs ont au moins 10 ans de code palliatif)

la machine à état (entièrement en template).

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

[JPLAROCHE]

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

[Gugelhupf]

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++).

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.

[captaindidou]

"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.

[Markand]

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

[Uther]

Alors que pouvoir implements multiple est beaucoup plus simple
- Tu peux très bien t'en moquer, tu es libre de plomber tes perfs.
- J'en ai jamais eu besoin, peut-être rencontré 1 seule fois.
- Hé oui, il faut savoir ce que l'on fait, personne pour balayer derrière toi
- J'ignore de quoi tu parles, n'en ai donc jamais utilisé ni rencontré, ça a pas l'air bien important donc.
- Longtemps il a existé tout un tas de libs pour le faire (pthread, TBB, Boost, ...)
- Ne les utilise pas si tu sais pas y faire, c'est juste un truc super utile sinon
- C'est vrai que devoir écrire une classe mytho pour avoir une fonction main m'a toujours paru bien plus intelligent
- 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
- Un outil très pratique hérité du C à la base

Je crois que tu as complètement manqué la question de départ qui était a propos de la simplicité.

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.

Ce ne sont que des possibilités, dans un restaurant 3 étoiles, on ne prend pas tous les plats à la carte.
Et les "Pas de", c'est juste pas en standard, sinon, on trouve toujours notre bonheur avec des librairies supplémentaires.

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.

[Luc Hermitte]

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".

[Pyramidev]

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).

C'est compatible. Ce n'est pas trivial, mais c'est possible.

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 java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
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
public class Point {
    // ...
    @Override public boolean equals(Object other) {
        boolean result = false;
        if (other instanceof Point) {
            Point that = (Point) other;
            result = (that.canEqual(this) && this.getX() == that.getX() && this.getY() == that.getY());
        }
        return result;
    }
    // ...
    public boolean canEqual(Object other) {
        return (other instanceof Point);
    }
}
 
public class ColoredPoint extends Point {
    // ...
    @Override public boolean equals(Object other) {
        boolean result = false;
        if (other instanceof ColoredPoint) {
            ColoredPoint that = (ColoredPoint) other;
            result = (that.canEqual(this) && this.color.equals(that.color) && super.equals(that));
        }
        return result;
    }
    // ...
    @Override public boolean canEqual(Object other) {
        return (other instanceof ColoredPoint);
    }
}

[vohufr]

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

[Jean.Luc]

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++)

[nikko34]

Est-ce que vous avez regardé la conférence sur le C64?

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.