Discussion :

[TJ1985]

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 !

[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

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

[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

[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

[Iradrille]

Je ne vois pas un seul argument qui pourrait les convaincre d'en changer.

L'argument de "transformer" des erreurs d'exécution en erreurs de compilation est pourtant assez fort.
Il est plus simple (une fois qu'on a compris comment lire les centaines de lignes d'erreurs à cause des templates ) de corriger une erreur de compilation qu'une erreur d’exécution; et on a la garantie que cette erreur sera corrigée.

Le C++ permet de mettre en place des abstractions de plus haut niveau que le C (ou plus facilement en tout cas); tout en étant capable d'une approche aussi bas niveau que le C (intrinsincs / inline assembly).

[nikko34]

A noter qu'actuellement il y a de gros efforts pour justement simplifier les messages d'erreurs rebutants des compilateurs.

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

[Luc Hermitte]

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

Oui elle peut l'être. Elle peut même être moindre grâce à des nouveaux outils absents du C, ou pour des raisons obscures aussi (cf la video de Bartosz dont j'ai déjà donné le lien)

1- Ceux qui font du C aujourd'hui savent en général pourquoi ils ne font pas de C++. 2- 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

1- Cela démontre juste une totale méconnaissance du C++ de leur part. Quelle que soit la raison : réduction du C++ à du C avec OO, mauvaise foi, effet de groupe, apriori, pas le temps/volonté de monter en compétence sur cette techno, ...
2- Mais comme tu le dis très bien : aucun argument ne les fera changer d'avis. Ca rejoint le message récurrent de Dan Saks : "If you argument, you loose!". Et c'est n'est pas un problème de véracité technique derrière les arguments. C'est un problème humain.

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.

Et l'auteur rappelle que cette implémentation n'est pas compatible avec le LSP:

One potential criticism of the canEqual approach is that it violates the Liskov Substitution Principle (LSP). For example, the technique of implementing equals by comparing run-time classes, which led to the inability to define a subclass whose instances can equal instances of the superclass, has been described as a violation of the LSP.5 The reasoning is that the LSP states you should be able to use (substitute) a subclass instance where a superclass instance is required. In the previous example, however, “coll.contains(cp)” returned false even though cp's x and y values matched those of the point in the collection. Thus it may seem like a violation of the LSP, because you can't use a ColoredPoint here where a Point is expected. We believe this is the wrong interpretation, though, because the LSP doesn't require that a subclass behaves identically to its superclass, just that it behaves in a way that fulfills the contract of its superclass.

Il botte en touche en disant que ce n'est pas important car le LSP exige juste un respect du contrat des parents. Justement j'estime qu'il y a rupture du contrat des parents.
Dans Effective Java, J.Bloch conclue que la seule bonne implémentation ici, c'est la composition. En C++, on a aussi l'héritage privé.

[Pyramidev]

Justement j'estime qu'il y a rupture du contrat des parents.

-Si ColoredPoint dérive de Point,
-si on pose comme contrat que deux objets de type Point ou qui dérivent de Point sont égaux ssi ils ont les mêmes coordonnées et
-si on pose comme contrat que deux objets de type ColoredPoint sont égaux ssi ils ont à la fois les mêmes coordonnées et aussi la même couleur
alors, oui, forcément, si on veut que ces conditions soient remplies par la même fonction de comparaison, on arrive à une contradiction.

Mais, ça, c'est la faute de celui qui rédige les contrats, pas de l'OO. Il faut juste plusieurs fonctions de comparaison.

Par exemple, en C++, on pourrait faire ceci :

Code :

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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
class Point
{
    friend bool operator==(const Point& lhs, const Point& rhs)
    {
        return (lhs.m_x == rhs.m_x) && (lhs.m_y == rhs.m_y);
    }
public:
    bool equals(const Point& other) const
    {
        return canEqual_1(other) && other.canEqual_2(*this);
    }
    // ...
private:
    virtual bool canEqual_1(const Point& other) const
    {
        return (*this == other);
    }
    virtual bool canEqual_2(const Point& other) const
    {
        return true;
    }
    // ...
};
 
 
class ColoredPoint : public Point
{
    friend bool operator==(const ColoredPoint& lhs, const ColoredPoint& rhs)
    {
        return static_cast<const Point&>(lhs) == rhs && (lhs.m_color == rhs.m_color);
    }
public:
    // ...
private:
    bool canEqual_1(const Point& other) const override
    {
        const ColoredPoint* that = dynamic_cast<const ColoredPoint*>(&other);
        return that != nullptr && (*this == *that);
    }
    bool canEqual_2(const Point& other) const override
    {
        const ColoredPoint* that = dynamic_cast<const ColoredPoint*>(&other);
        return that != nullptr;
    }
    // ...
};

Pour comparer deux objets de type Point ou qui dérivent de Point, on aurait alors le choix entre :
-equals(const Point& other) const pour la comparaison virtuelle et
-bool operator==(const Point& lhs, const Point& rhs) pour la comparaison de coordonnées.

A part ça, dans l'article, l'auteur utilise java.util.HashSet<E> qui ne permet pas de choisir la fonction de comparaison à utiliser. Mais, ça, c'est la faute de Java, pas celle de l'OO.

PS : Désolé pour le HS. Si la conversation se poursuit, je continuerai dans un autre fil.

[Iradrille]

-Si ColoredPoint dérive de Point,
-si on pose comme contrat que deux objets de type Point ou qui dérivent de Point sont égaux ssi ils ont les mêmes coordonnées et
-si on pose comme contrat que deux objets de type ColoredPoint sont égaux ssi ils ont à la fois les mêmes coordonnées et aussi la même couleur
alors, oui, forcément, si on veut que ces conditions soient remplies par la même fonction de comparaison, on arrive à une contradiction.

Mais, ça, c'est la faute de celui qui rédige les contrats, pas de l'OO. Il faut juste plusieurs fonctions de comparaison.

Par exemple, en C++, on pourrait faire ceci :

Code :

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

dynamic_cast

Dans 99% des cas dynamic_cast est synonyme d'erreur de conception, j'ai pas l'impression qu'on soit dans les 1% ici.

Vu l'énoncé, je verrais plutôt une composition.

Code C++ :

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

1
2
3
4
5
6
7
8
9
10
11
struct Point {
   int x;
   int y;
};
 
struct Color { ... };
 
struct ColoredPoint {
   Point point;
   Color color;
};

Si ColoredPoint hérite de Point, il doit ÊTRE un Point (c'est le principe de l'héritage; et donc se comporter comme tel).
Aussi, un Point sera (très souvent) un POD -> pas d'héritage donc.

[Pyramidev]

Si la conversation se poursuit, je continuerai dans un autre fil.

Du coup, je viens de créer un nouveau fil : http://www.developpez.net/forums/d16...tuelle-equals/

[sarnikoff]

Personnellement je suis sorti du marché , au moment de l' arrivée de C++
C'était le moment de l'intégration de travailleurs de l' EST ... Et
donc l' état nous "paya" des reconnaissances de compétances par des "formations".

Donc le grand débat de la programmation objet :
J'ai essayé de l'expérimenter en C mais aussi par le php5 .
Je ne suis pas convaincu.

Pour ex: je citerais l'annecdote de 1994 ( qui nous fut transmis au CESI d' Ecully) :
HP s'était lancé dans la récolte de ses objets : Plus de 5000, personne n'y voyait plus rien.
est
DONC : Pour moi se pose la capacité d' absorption
Pour le C++ : Les classes.
Mais aussi de toutes les fonctions : Car il y a celle que l' "on" fabrique mais qui existent déjà dans des bibliothèques que l'on ne connait pas.

Donc : Se pose pour quelle utilisation.
Parfois, on a besoin de reccourcir le temps de traitement, et on rentre dans le code objet.
Si je me souviens : Le C++ n' est qu' une forme de syntaxisme qui crée un mode de vision (objet) et donc qui signale les dérappagent par des règles de compilation qui seraient plutot des règle de précompilation.

Conclusion : Il s'gait d'un concensus ... pour justement pouvoir partager entre développeur ... Et je n'ai jamais connu cette phase ...